accounts

Content

Deploy users and public keys to your machines.

Requirements

This role requires ubuntu

Role Variables

Create a list with all users that need to be created on the system. You can set every parameter for the user that is available from http://docs.ansible.com/ansible/user_module.html. Also you can set every parameter (exept "user") for the key that is available from http://docs.ansible.com/ansible/authorized_key_module.html. The optional array "accounts_sshd_configs" allows to set sshd_config parameters.

accounts_users:
- name: __USERNAME__
  uid: __UID__
  state: present
  groups:
  - sudo
  public_keys:
  - key: ssh-rsa AAA...
    state: present

accounts_sshd_configs:
- key: PermitRootLogin
  value: 'no'
- key: AuthenticationMethods
  value: 'publickey password'
- PasswordAuthentication
  value: 'yes'

If you need additional users on host base, you can set an additional list accounts_host_users.

accounts_host_users:
- name: __USERNAME__
  uid: __UID__
  state: present
  groups:
  - sudo
  public_keys:
  - key: ssh-rsa AAA...
    state: present

Example Playbook

- hosts: accounts
  roles:
  - { role: andrelohmann.accounts }

Role Development

Special purpose

This repository supports the following features for the role development:

yamllint
ansible-lint
molecule test
github action
auto version-up
update ansible-galaxy
show build status
test within vagrant (for development purpose)
test with molecule (inside or outside vagrant)
test against docker container
test and develop inside vscode

Prerequisites

https://thedatabaseme.de/2022/01/17/automated-testing-your-ansible-role-with-molecule-and-github-actions/

Virtualbox + Vagrant installed (only necessary, if the role should be tested with vagrant as well)
Docker Desktop
VisualStudioCode + remote extensionpack (dependencies are defined within .vscode/extensions.json)

Development-Setup

This ansible role is developed using molecule for testing. It's development is based on visual studio code and a regarding development container, solving all dependencies in terms of necessary tools (ansible, linter, molecule).

The role will be tested on two ubuntu containers (focal, jammy).

To startup the molecule test containers from within the development container, the docker socket needs to be bind mounted into the development container.

Important folders and files

.devcontainer

Defines the Dockerfile for the development container
Configures the development container startup (e.g. bind mount docker socket)

molecule/default/Dockerfile.js

Used as a template for all platforms defined in molecule/default/molecule.yml
Prepares the environments to support systemd services (necessary for some ansible roles acting on systemd)
Installs all requirements to run ansible against the derived container
The file is aligned with the attributes of the platforms in molecule/default/molecule.yml
For more information - study the molecule documentation

Usage

Visual Studio Code

Change to the root directory of your role and start vscode

code .

From within the development container you can use the following run commands

yamllint .
ansible-lint .
molecule create
molecule test

Vagrant + Virtualbox

Change to the root directory of your role
Change to the vagrant folder
Start and enter the vagrant machine

vagrant up
vagrant ssh

Change to the role folder

cd /etc/ansible/roles/ansible-role- [tab]

Now you can run all tests

yamllint .
ansible-lint .
molecule create
molecule test

Build and Release process

The ansible role defines a bunch of github workflows to run molecule test and release management.

The release management requires a handful of settings.

Protecting the master/main branch

Settings -> Branches -> Add branch protection rule
Branch pattern name -> main or master (depending on your default branch)
Protect matching branches -> check "Require a pull request before merging"
"Require approvals" can be individually handled as required

Give read and write permissions to GITHUB_TOKEN

Settings -> Actions -> General -> Workflow permissions -> read and write permissions

Commit messages

Commit messages should follow a special format to achieve a patch, minor or major semantic versioning update.

patch

0.0.x

fix(single_word): description

minor

0.x.0

feat(single_word): description

major

x.0.0

perf(single_word): description
BREAKING CHANGE: describing the breaking change

It's absolutely important, that "BREAKING CHANGE: " is mentioned in the second+ line. On single line commit messages, the major version update will be ignored.