Part of the BAS Ansible Role Collection (BARC)
Performs minimal configuration required to enable management of a Vagrant VM by automated tools
- Unless disabled, creates a new OS user, 'controller' for performing privileged actions (such as
apt-get install
) using sudo or reading log files. - If enabled, the
authorized_keys
file for the controller user is set to contain any file in thebootstrap_vagrant_controller_user_authorized_keys_directory
directory.
This role is designed for internal use but if useful can be shared publicly.
- As of version 2.0.0 any OS this role is applied to MUST ensure passwordless sudo is enabled for the "sudo" group and SSH Agent Forwarding is preserved when using sudo.
- If using the antarctica/trusty base box with this role, ensure you are using version 2.0.0 or higher, which implements these requirements.
- Public keys which should be added to the
authorized_keys
file of the controller user, each key should be a separate file. Keys should be contained inbootstrap_vagrant_controller_user_authorized_keys_directory
.
bootstrap_vagrant_controller_user_username
- The username of the controller user, used for management tasks, if enabled
- This variable MUST be a valid UNIX username
- Default: "controller"
bootstrap_vagrant_controller_user_enabled
- If "true" a user for management tasks, termed a controller user, will be created.
- This is a binary variable and MUST be set to either "true" or "false" (without quotes).
- Default: "true"
bootstrap_vagrant_controller_user_authorized_keys_directory
- The path, relative to where this role is installed, to the directory that contains the public key files to be added to the controller user's
authorized_keys
file. - This variable MUST point to a directory, it MUST NOT include a trailing
/
. - Default: "../../../public_keys"
- The path, relative to where this role is installed, to the directory that contains the public key files to be added to the controller user's
This project welcomes contributions, see CONTRIBUTING
for our general policy.
The Git flow workflow is used to manage development of this package.
Discrete changes should be made within feature branches, created from and merged back into develop (where small one-line changes may be made directly).
When ready to release a set of features/changes create a release branch from develop, update documentation as required and merge into master with a tagged, semantic version (e.g. v1.2.3
).
After releases the master branch should be merged with develop to restart the process. High impact bugs can be addressed in hotfix branches, created from and merged into master directly (and then into develop).
Issues, bugs, improvements, questions, suggestions and other tasks related to this package are managed through the BAS Web & Applications Team Jira project (BASWEB).
Copyright 2015 NERC BAS. Licensed under the MIT license, see LICENSE
for details.