enable user addition to 'sudo' or root privilege group aligned to distribution

[ikonia]

Use Case

When adding managing users with this module across multiple linux and unix distributions the additional of a user should be able to be added to the group that the OS defaults to, to enable elevated root privileges (especially with later distributions locking the root account by default).

While the module supports adding users to groups, and a user can be added to a privilege group such as the examples/README or via hiera

accounts::user_list:
testuser:
uid: 1000
shell: '/bin/bash'
password: 'something'
locked: false
comment: 'test user'
create_group: true
groups:
- wheel
This would add the user to the wheel group - which on Enterprise Linux is mapped to the foundational sudo rules

However different distributions map their default sudo rules to different groups, the two main ones being
'wheel' and 'sudo' - with niche usage of 'admin'

There is no logic in the module to be able to map the admin group to the Linux distribution or version.

The ability to parameterise 'default_admin:: true' which will then evaluate which group is the correct privilege group and add / remove the user to that group enabling privilege escalation using the default OS group and sudo rules

Describe the Solution You Would Like

a hiera map within module that maps to either distribution or distribution+version referencing the correct privilege group (could be done with family rather than name depending on the model)

eg: prefixing to the module hiera data to look something like

• name: "Per-OS defaults"
  path: "os/%{facts.os.family}.yaml"

• name: "Per-OS Version Specific defaults"
  path: "os/version/%{facts.os.name}-%{facts.os.release.major}.yaml"

hierarchy:

• name: "Per-OS defaults"
  path: "os/%{facts.os.name}.yaml"
• name: "Per-OS Version Specific defaults"
  path: "os/version/%{facts.os.name}-%{facts.os.release.major}.yaml"
• name: "Default YAML hierarchy levels"
  paths:
  • "common.yaml"

enabling a parameter definition in either the OS Family if it's consistent, or specific versions, eg:
Redhat.yaml
accounts::privgroup: wheel
Debian.yaml
accounts::privgroup: wheel
Ubuntu.yaml
accounts::privgroup: sudo

and either via a parameter
accounts:enablepriv: true/false

which will enable a group addition to the value of accounts:privgroup

or allow reference to the parameter from within the accounts:group: parameter

eg:

accounts::user_list:
testuser:
uid: 1000
shell: '/bin/bash'
password: 'something'
locked: false
comment: 'test user'
create_group: true
groups:
- accounts::privgroup

due to this being a prvileged group the ability to remove the user from the privgroup is important.

Describe Alternatives You've Considered

adding a custom fact via a module and referencing that custom fact
trying to evaluate which group enables privilege and adding the user
depending on another module (such as sudo) to reference a similar parameter as accounts::privgroup and referencing it in the groups: parameter

Additional Context

a similar approach is already in place in the module for managing home directory locations when the differ for operating systems such as Solaris against Linux