Details
-
New Feature
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
PUP 6.6.0
-
Night's Watch
-
5
-
NW - 2019-08-21, NW - 2019-09-03, NW - 2019-09-18, NW - 2019-10-02, NW - 2019-10-16, NW - 2019-10-30, NW - 2019-11-13, 2019-11-27, 2019-12-11, 2019-12-24, NW - 2020-01-22, NW - 2020-02-05, NW - 2020-02-19
-
New Feature
-
The `groupadd` provider can now manage members using the `members` resource parameter.
-
Needs Assessment
Description
Puppet Version: 6.1.0
Puppet Server Version: 6.1.0
OS Name/Version: Red Hat Enterprise Linux 7
The group resource type supports the groupadd provider, but not the lgroupadd provider.
lgroupadd (and lgroupmod and lgroupdel) are part of the libuser library/package. While libuser is essentially a rewrite of the groupadd, groupmod, and groupdel programs from the shadow-utils package (because Red Hat tends toward NIH syndrome), lgroupmod has one important advantage over groupmod: lgroupmod can manipulate group members directly.
E.g., you can do this:
$ lgroupmod --member-add user1,user2,user3 somegroup
|
In contrast, groupmod cannot do this. Instead, you have to do this:
$ usermod -a -G somegroup user1
|
$ usermod -a -G somegroup user2
|
$ usermod -a -G somegroup user3
|
This is why the groupadd provider for the group resource type lacks the manages_members feature.
The implication of this is that in Puppet, if you want to have a class manage the contents of a group, the only way to do it (using default resource types) is to manage user resources for each user who should be a member of the group. But this doesn't scale, because if any other module is attempting to manage a user resource type for the same user, the resources will clash.
In contrast, if support were added for the lgroupadd provider, the manages_members feature could be enabled for it. This would permit managing the membership of an arbitrary group by managing a single group resource for the group, instead of managing individual user resources.
Granted, this could create the state where a Puppet user resource using the useradd provider could "fight" with a Puppet group resource using the lgroupadd provider. But this potential for conflict already exists in other places in Puppet (e.g., augeas resources can cheerfully fight with file resources). So I don't think the potential for conflict is a reason to avoid adding the lgroupadd provider.
So, in summary, I think Puppet should add support for the lgroupadd provider (and company) for the group resource type on platforms where the libuser library/package is available: Fedora, Red Hat, CentOS, and potentially others.
Yay or nay?
(I may be able to work on adding this provider myself, but I don't want to spend the time on a merge request if Puppet is philosophically opposed to adding support for the lgroupadd provider.)
Attachments
Issue Links
- blocks
-
PUP-10169 Generalize forcelocal parameter use for user/group resources
-
- Resolved
-
- is duplicated by
-
PUP-3745 Group membership should be a type of its own.
-
- Closed
-
- relates to
-
PUP-1913 Puppet user resource should respect the forcelocal option
-
- Closed
-
-
PUP-10168 user resource type misunderstands/misuses libuser
-
- Closed
-
-
DOCUMENT-800 Improve documentation of forcelocal and libuser in user management workflows
-
- Resolved
-
-
PUP-1298 manage_membership for unix groups provider
-
- Accepted
-