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