The badge referenced the role id 58433 and linked to the unrelated role networking_role, so it neither showed the
download count of this role nor led anywhere useful. The heading is aligned with the galaxy role name as well.
Co-authored-by: Copilot <copilot@github.com>
Floating tags let a compromised or force pushed release change what the workflows execute. Pinning the actions to a
commit sha and restricting the default token to read access limits the blast radius of a supply chain attack. The
outdated ansible-lint and markdownlint-cli2 versions are raised along with the pinning.
The ansible-lint run installs the collections of the molecule scenario, because the scenario is linted as well and
depends on community.docker beside the community.general requirement of the role.
Co-authored-by: Copilot <copilot@github.com>
The role was not covered by any automated test, so regressions in the drop-in file handling only surfaced on real
hosts. The scenario starts one container per supported distribution family and covers all four conditional branches of
tasks/main.yaml: a user, a user acting as another user, a group and a group acting as another user.
Beside the created rules the verification asserts that a rule declared as absent is removed again, that the drop-in
directory is included exactly once and that visudo accepts the resulting configuration, because a rejected drop-in file
invalidates every rule of the directory.
Co-authored-by: Copilot <copilot@github.com>
The only variable of the role was documented in defaults/main.yaml comments alone. An argument spec makes the variable
discoverable through ansible-doc and lets ansible reject a wrong type early.
The entries are intentionally left without suboptions. Argument spec validation fills missing suboptions with none,
which would turn the item.user | default('') | length conditions in tasks/main.yaml into a runtime error.
Co-authored-by: Copilot <copilot@github.com>
The role ships vars/Debian.yaml and the README lists Debian, but the galaxy metadata did not advertise the platform, so
Ansible Galaxy hid the role from users searching for Debian.
Co-authored-by: Copilot <copilot@github.com>
The yamllint configuration enabled the default rule set, which includes document-start, but omitted the marker in its
own file. Linting the repository therefore reported a violation in the configuration itself.
Co-authored-by: Copilot <copilot@github.com>
The default filter only replaces undefined values unless its boolean flag is
enabled. An entry with 'filename: ""' - as documented in defaults/main.yaml -
therefore produced a sudoers drop-in file without a name. Enabling the flag
makes the role fall back to the user or group name for empty filenames as
well.
Co-authored-by: Copilot <copilot@github.com>
The conditions relied on 'is defined' and 'is not defined'. An entry which
declares the unused key with an empty string - as documented in
defaults/main.yaml - matched none of the four tasks, so the sudoers drop-in
file was silently not created. Comparing the length of the defaulted values
instead makes exactly one task apply to every entry accepted by the
validation.
Co-authored-by: Copilot <copilot@github.com>
Ansible 2.9 can neither resolve the used fully qualified collection names
reliably nor ship the community.general.sudoers module, which requires
ansible-base 2.10 or newer. Align the requirement with the sibling role
unix-users, which already declares 2.11.
Co-authored-by: Copilot <copilot@github.com>
The role uses the community.general.sudoers module, but did not declare the
collection dependency like the sibling roles unix-users and
certificate_authority do. The sudoers module was added in community.general
4.3.0, its runas parameter in 4.7.0, therefore 4.7.0 is the lowest usable
version.
Co-authored-by: Copilot <copilot@github.com>
The regular expression required a leading hash, but sudo 1.9.1 introduced @includedir and distributions such as
Debian 12, Ubuntu 22.04, RHEL 9 and Arch Linux ship /etc/sudoers with that syntax. Since the existing line was never
matched, lineinfile appended a second directive and /etc/sudoers.d was included twice.
The dot in sudoers.d is escaped as well, so the expression no longer matches unrelated paths.
Co-authored-by: Copilot <copilot@github.com>
Recreating /etc/sudoers.d on every run deleted every drop-in file on the host, not only the ones managed by this role.
That removes files shipped by packages or other tooling, such as 90-cloud-init-users on cloud instances, which can lock
out the remaining login paths. The task also reported changed on every run and therefore made check mode and CI runs
useless for detecting real drift.
The directory is now only ensured with its owner, group and permissions. To keep entries removable, each item of
sudo_users_sudoers accepts an optional state, which is passed to community.general.sudoers and defaults to present.
BREAKING CHANGE: Entries dropped from sudo_users_sudoers are no longer deleted implicitly. Set state: absent on the
entry to remove its drop-in file.
Co-authored-by: Copilot <copilot@github.com>
The variable verification was included via include_vars, which is meant for variable files only. Additionally the
first_found lookup had no paths defined, so it searched the files/ subdirectory and the role root instead of tasks/ and
failed with "No file was found". Switching to include_tasks and adding the tasks path makes the verification run at all.
The assertion itself was fully commented out and is now active, so a misconfigured entry fails early instead of being
silently skipped by all four sudoers tasks.
Co-authored-by: Copilot <copilot@github.com>
volker.raschekandCopilot
CSRBot