[PUP-1298] manage_membership for unix groups provider Created: 2013/12/30  Updated: 2019/05/16

Status: Accepted
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Normal
Reporter: redmine.exporter Assignee: Unassigned
Resolution: Unresolved Votes: 6
Labels: group, linux, redmine, type_and_provider
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Team: Night's Watch
CS Priority: Reviewed

 Description   

I searched and didn't see this feature request so if is/was at some point forgive me.

I'd like to be able to define the users that belong to a group in the group's resource. My compelling reason is that a specific unix group is used to determine ssh access via AllowGroups in sshd_config, and I'd like to make sure that at all times only specific users are in that group. My workaround is to manage /etc/group as a file resource, which isn't very puppet-like.



 Comments   
Comment by Antoine [ 2013/12/30 ]

There seems to be a working provider here:

https://github.com/pdxcat/puppet-module-group/blob/master/lib/puppet/provider/group/ggroupadd.rb

Looks simple enough/

Comment by LeLutin [ 2014/01/03 ]

hmm so basically this means that the builtin type doesn't work correctly on linux, and maybe others.

Comment by Trevor Vaughan [ 2014/06/09 ]

I hate that I double hopped this one, but I also created a direct patch for this that incorporates into the provider cleanly.

My issue was closed and I was told to make a module out of it so here you go https://github.com/onyxpoint/puppet-gpasswd.

Comment by Jeff McCune [ 2016/08/26 ]

To update this, I've worked with two clients who need to manage a local group in the event LDAP is down. The use case is this:

PAM is configured via /etc/security/access.conf to only allow certain groups to login to the system. Operations team members have local accounts which are not managed by Puppet. They are all a member of an "ops" group, which is defined in LDAP.

In the event LDAP is misbehaving, the ops team is unable to log into the machine to do maintenance becasue access.conf cannot resolve the + : ops : ALL rule and falls through to the default deny-all rule.

As a fallback mechanism, we want to define a group named "opslocal" which lists accounts who should always have maintenance access, even if LDAP is misbehaving.

We cannot do this in Puppet. This used to work in earlier versions of Puppet, and according to the documentation it should work with the membership field:

class opslocal {
  group { opslocal:
    ensure => present,
    forcelocal => true,
    gid => '12345',
    members => ['jeff.mccune'],
    provider => 'groupadd',
  }
}
include opslocal

When Puppet runs, it creates the opslocal group but does not manage membership like it should and is documented to with the members parameter. Here is the result:

$ grep opslocal /etc/group
opslocal:x:12345:

Comment by Scott Nolin [ 2017/02/09 ]

I'm surprised this still isn't in the default groups provider. Using the gpasswd based module does work - https://forge.puppet.com/onyxpoint/gpasswd

Scott

Comment by Patrick Grant [ 2019/05/14 ]

Adding on behalf of behalf of customer:

"Fundamentally, the request is to implement 'manages_members' in the 'groupadd' group provider.
Based on the description from the 'groups' resource, this should be available, but this is not the case.

While 'groupadd' group membership is defined in the group record, it is managed via the user resource.

1) May not be managed by puppet, such as
a. Root, sys, or other OS-created users
b. RPM-created users, such as the apache user
c. Users federated by such features as ldap, sssd, or other centralized authentication
2) May not exist (yet)

This is a level of configuration flexibility that is allowed by the underlying OS configuration, but cannot be expressed in Puppet."

Comment by Trevor Vaughan [ 2019/05/14 ]

The gpasswd module still works and Puppet, Inc is welcome to pick up the code as it's Apache licensed.

Generated at Sat Jul 20 13:27:44 PDT 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.