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>
`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>
volker.raschekandCopilot