The repository mixed both extensions, the molecule scenario used yml while the role itself used yaml. The yml
extension is the one ansible-galaxy and molecule generate, so it is applied throughout and across the sibling roles.
The include_tasks calls in tasks/main.yml and tasks/create_unix_user.yml name their target explicitly and were
adjusted accordingly, otherwise the role would no longer find the included task files.
Co-authored-by: Copilot <copilot@github.com>
ansible-lint does not only lint the role but the molecule scenario as well, and the scenario creates its containers
with community.docker. Only the runtime requirements of the role were installed, so the linter could not resolve
community.docker.docker_container and failed the syntax check.
The collection list of the scenario is a superset of the runtime requirements, therefore it is used instead of adding
a test only dependency to requirements.yml.
Co-authored-by: Copilot <copilot@github.com>
Without a workflow the scenario only runs when somebody remembers to run it locally, which is exactly the situation
the tests were written to end.
The repository is checked out into a directory named after the role and not after the repository, because the scenario
includes the role by its name and molecule puts the parent of the project directory on the roles path.
Co-authored-by: Copilot <copilot@github.com>
The role changed a lot and none of it was verified against a real system so far. The scenario starts one container per
supported distribution family, applies the role and asserts afterwards that the users and groups exist as declared,
that the managed files carry the documented mode, owner and content, that a user without optional settings does not
receive any of the optional files and that a user declared as absent is gone again.
The idempotence step is the actual reason for the scenario. The deterministic password salt and the btrfs device
lookup were changed to stop reporting a change on every run, and only a second converge proves that.
A btrfs home is not covered, because a container has no btrfs filesystem to create a subvolume on.
The ssh key pair the scenario feeds into the role is generated during create and removed again during destroy, so no
private key material ends up in the repository. The generated files are ignored for the case that a destroy never
runs.
Co-authored-by: Copilot <copilot@github.com>
The role claimed to work with ansible 2.9, but two of its building blocks did not exist back then. The path_join
filter was introduced in ansible-base 2.10 and the btrfs_subvolume module in community.general 6.6.0, which in turn
requires ansible-core 2.11. Running the role on 2.9 therefore failed with an undefined filter instead of a readable
message about an unsupported control node.
The collection is now declared in a requirements.yml, mirroring the layout of the certificate_authority role, and the
lower bound is pinned because an older community.general still resolves but lacks the btrfs module. The linter
workflow installs that file, because ansible-lint cannot resolve the btrfs_subvolume tasks without the collection
being present, which only surfaced in CI where no collections are preinstalled.
Co-authored-by: Copilot <copilot@github.com>
Deleting a user whose home is a btrfs subvolume left that subvolume behind. The role passed remove=true to the user
module, but userdel removes a home directory with rmdir, which refuses to delete a subvolume that still holds nested
subvolumes or is otherwise not empty. The home therefore survived the removal and blocked a later recreation of the
same user, because btrfs_subvolume then found the path already occupied.
The subvolume is now deleted explicitly by the same module that created it, which keeps the creation and the removal
symmetric. Snapshots are stored outside the subvolume, so a btrbk based backup keeps the data available even though
the home itself is gone.
The removal is skipped when the home directory no longer exists, since findmnt fails on a missing path.
Co-authored-by: Copilot <copilot@github.com>
The `no_log: true` on the include in tasks/main.yaml only censors the include statement and its loop item. It is not
inherited by the included tasks, which was verified with a minimal playbook: a debug task inside an included file prints
its message in clear even though the include itself is censored.
Two tasks therefore leaked secrets. The netrc template exposes every machine password in its rendered content, and the
copy of the private ssh keys exposes the key material itself. Both are printed by the diff mode, which is exactly the
mode used when reviewing what a run would change. They are marked `no_log` individually now.
The user task is deliberately left alone. Its `password` argument is declared `no_log` in the argument spec of the
module, so ansible already censors it, and a task level flag would only make the remaining output useless.
The blanket flag on the include stays in place, because the loop item still carries the plaintext password.
Co-authored-by: Copilot <copilot@github.com>
The lineinfile task appends the source line to `~/.bashrc` but never declared `create`, so it aborted with "Destination
does not exist" whenever that file was missing. This hits every user configured with `create_home: false`, and it hit
every btrfs user as well, because their home is an empty subvolume and useradd therefore skips the skel rollout.
`mode` is added along with it, otherwise a newly created bashrc would inherit whatever the umask happens to be. The
existing `owner` and `group` were dead settings until now, since the file was never created by this task.
Co-authored-by: Copilot <copilot@github.com>
The two group tasks differed only in whether `gid` was passed, and the branch between them tested
`unix_group.value.gid | length`. The length filter has no meaning for an integer and raises "object of type 'int' has no
len()". The example in defaults/main.yaml declares `gid: 1001` unquoted, so the documented usage aborted the run, while
the quoted variant in the README happened to work.
Both tasks are merged into one that passes the gid through `default(omit, true)`. The boolean form of the filter is
required to keep the previous meaning of an empty gid, which is to let the system assign one. The only value that
changes semantics is gid 0, which is the root group and outside the scope of this role.
Co-authored-by: Copilot <copilot@github.com>
`set_fact` writes into the play scope, so `user_user_home` outlived the loop iteration that set it and collided with any
playbook variable of the same name. Worse, if the defining task were ever skipped, every following task would silently
operate on the home directory of the previously processed user.
Renaming it to `_unix_users_home` marks it as role internal and matches the underscore prefix already used by the other
internal facts in this role. Purely mechanical, no behaviour changes.
Co-authored-by: Copilot <copilot@github.com>
`password_hash('sha512')` without an explicit salt generates a new random salt on every invocation. The resulting hash
differed on each run, so the user module rewrote /etc/shadow and reported a change every time the role was applied. This
was the single biggest obstacle to a green idempotence check.
The salt is now derived from the user name, which keeps the hash stable across runs while still giving every account its
own salt, so two users sharing a password do not end up with an identical hash.
Verified locally: repeated runs produce a byte identical hash, and different user names produce different ones.
Co-authored-by: Copilot <copilot@github.com>
`findmnt` only reads the mount table, but the task declared `changed_when` on a successful return code and therefore
reported a change on every single run. Any btrfs backed user made the whole play non idempotent, which an idempotence
check would flag as soon as one exists.
The `failed_when` on a non zero return code is dropped along with it, since that is exactly what the command module does
by default.
Co-authored-by: Copilot <copilot@github.com>
Several defects accumulated in this task file and are fixed together, because they overlap in the same code paths.
The debug task was dead code. Its `msg` lacked the Jinja delimiters and would have printed the literal string
`_unix_users_btrfs_device.stdout`, and it was gated on `_unix_users_debug`, a variable that is neither defined in
defaults nor documented anywhere. It is removed instead of repaired, since the failure path already reports the device.
The four `ansible.builtin.user` tasks differed only in whether `uid` and `groups` were passed. They are collapsed into a
single task using `default(omit)`, which removes the risk that a fix lands in one of the four copies only. This also
fixes `comment`, which dereferenced `unix_user.value.name` unconditionally and aborted for every user that did not set
the undocumented and supposedly optional key.
Two conditions compared a length against zero with `>=`, which is true for any list. As a result an empty `ssh.config`
still produced a config file, and the removal counterpart never triggered. The create and remove pair for `.ssh/config`
now mirrors the one already used for `authorized_keys`.
The private key source was resolved through `{{ playbook_dir }}`, while the authorized key lookup in the template uses
the regular relative search path. Both now use the same mechanism, which is a superset of the previous location, so
existing playbook layouts keep working, and the role becomes testable from a molecule scenario.
BREAKING CHANGE:
The `.ssh` directory is only created when a user actually declares an `ssh` key, and an empty `ssh.config` list now
removes the client config instead of writing an empty one. Users who relied on the role to pre create an empty `~/.ssh`
have to declare `ssh: {}` explicitly.
Co-authored-by: Copilot <copilot@github.com>
The btrfs block chowned the freshly created subvolume to the user right after `btrfs_subvolume`, but the four
`ansible.builtin.user` tasks that actually create that user run further below. On a first run the chown therefore
aborted with an invalid user error, which made the whole btrfs code path unusable.
The task is removed rather than reordered, because an identical chown already exists in the "Adapt permissions and copy
skel" block below the user creation. That block also runs the skel copy first, so the file ownership set there is not
overwritten afterwards. The subvolume simply stays root owned for a few tasks longer, which a comment now records.
Co-authored-by: Copilot <copilot@github.com>
The template read `function.body`, while README and defaults/main.yaml document the key as `functions[].value`. Every
documented example therefore rendered an empty function body, and with a strict undefined policy the template failed
outright.
The documentation is the contract for this role, so the template follows it instead of the other way around.
Co-authored-by: Copilot <copilot@github.com>
The task guarded itself with `_skel_file.stat.exist`, but the stat module returns `exists`. The `is defined` check on the
misspelled attribute therefore always evaluated to false and the whole task was silently skipped, so no skel file was
ever copied into a home directory.
Two further defects surfaced once the guard was corrected. The source path interpolated the registered result dict
`_skel_file` instead of the loop variable `skel_file`, and the copy module read from the control node because
`remote_src` was missing, so `/etc/skel` of the managed host was never consulted.
The stat now probes the source instead of the destination. Distributions ship different skel files, for example Debian
has no `.bash_profile`, and copying a non existing remote source would abort the run. The "only copy when absent"
behaviour is delegated to `force: false`, which the copy module implements natively. The register variable is prefixed
with the role name so it can no longer be confused with the loop variable. The mode is corrected to 0644, the mode
`/etc/skel` uses for its dotfiles.
Co-authored-by: Copilot <copilot@github.com>
volker.raschekandCopilot