(#7911) Allow Local User Managment in LDAP Environment

[John Julien]

Hi,

I've been working on extending the useradd/groupadd providers to allow local user management when duplicate names exist in a remote LDAP database.

I have the code complete which can be viewed here:

https://github.com/jjulien/puppet/compare/master...feature%237911

There has been some discussion about providing the libuser.conf file with this patch though.  So I'd like to bring that discussion up here and get a solution hashed out before I submit the pull request.  

Summary:

The useradd/groupadd commands will not add duplicate names in /etc/passwd if they find the account in LDAP.  The luseradd/lgroupadd commands are capable of this, so they are used to make sure the local accounts get managed in this patch.  luseradd/lgroupadd use /etc/libuser.conf to determine which create_module to use when creating accounts, its important for this patch that the modules used is "files".  If a system existed with an /etc/libuser.conf file that had ldap specified as a create_module it would produce undesired results from this provider.  However unlikely of a situation as that may be, it is a potential bug that could come up later if Puppet does not enforce a specific libuser.conf.  Luckily, libuser allows the configuration file, /etc/libuser.conf by default, to be overridden by setting the environment variable LIBUSER_CONF.  This is the reason for shipping the exact libuser.conf file needed by this provider with Puppet.  The placement of the file in lib/puppet/features/libuser.conf has been the main concern.  I'm definitely open to moving this, it would need to be in a place that could always be counted on and that the Puppet::Util::Libuser.setupenv module would be able to find through either hard coding, or relative pathing like it currently does.  

Please advise on the best way to handle this file.

Thank you!

[Andy Parker]

Hi John,

On Fri, Jan 25, 2013 at 11:26 AM, John Julien <jo...@julienfamily.com> wrote:

Hi,

I've been working on extending the useradd/groupadd providers to allow local user management when duplicate names exist in a remote LDAP database.

I have the code complete which can be viewed here:

https://github.com/jjulien/puppet/compare/master...feature%237911

Forgive me if this has already been brought up, but I'm wondering if this functionality might be better placed in a new provider (luseradd.rb and lgroupadd.rb) instead of modifying the existing providers. The reason that I'm thinking this is that the purpose of the added feature, use of optional command, and forcelocal param all seem to be in order to control how the existing useradd provider will behave in the same manner that having an additional provider would offer.

 

There has been some discussion about providing the libuser.conf file with this patch though.  So I'd like to bring that discussion up here and get a solution hashed out before I submit the pull request.  

Summary:

The useradd/groupadd commands will not add duplicate names in /etc/passwd if they find the account in LDAP.  The luseradd/lgroupadd commands are capable of this, so they are used to make sure the local accounts get managed in this patch.  luseradd/lgroupadd use /etc/libuser.conf to determine which create_module to use when creating accounts, its important for this patch that the modules used is "files".  If a system existed with an /etc/libuser.conf file that had ldap specified as a create_module it would produce undesired results from this provider.  However unlikely of a situation as that may be, it is a potential bug that could come up later if Puppet does not enforce a specific libuser.conf.  Luckily, libuser allows the configuration file, /etc/libuser.conf by default, to be overridden by setting the environment variable LIBUSER_CONF.  This is the reason for shipping the exact libuser.conf file needed by this provider with Puppet.  The placement of the file in lib/puppet/features/libuser.conf has been the main concern.  I'm definitely open to moving this, it would need to be in a place that could always be counted on and that the Puppet::Util::Libuser.setupenv module would be able to find through either hard coding, or relative pathing like it currently does.  

Is it ever a possibility that the libuser.conf file may need to be different in some circumstances? If it is possible that some of those settings may need to be different, then there will need to be a way of a user specifying what the correct ones are. The entries in [defaults] look like they might have that issue.

 

Please advise on the best way to handle this file.

Thank you!

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To post to this group, send email to puppe...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[John Julien]

Hey Andy,

It has not been brought up yet but it is something I consider when working on the patch.  I actually started writing a new provider for this using the current useradd/groupadd providers as parent classes and quickly abandoned it because I realized I was duplicating so much code.  Another, probably more considerable, reason is that I don't see people actually wanting to use a full blown libuser provider because of some of the limitations of the commands.  Take for example the libuser commands do not have the ability to manage multiple group membership of users.  In my current patch, changes to an existing user continue to use the usermod commands which support this and in the case of a new users luseradd is used to create the user and then a subsequent call is made to usermod to synchronize the group membership appropriately.   If I were to still provide this capability in the libuser provider I would have to call the usermod command instead of the lusermod command.  This put me in the same situation but in reverse order.  I'd be using a libuser provider to execute shadow-utils commands where in I'm currently using a shadow-utils provider to execute libuser commands.

Working on this I have found that in order to get the maximum benefit out of the user type a single provider combining the use of shadow-utils commands and libuser commands is needed.

To summaraize:

Without the libuser commands the shadow-utils providers cannot always manage local accounts.

Without the shadow-utils commands the libuser providers would not be able to manage all of the attributes of accounts.

In response to your question about libuser.conf.  The values of those should never change, the intent is not to expose the use of libuser commands to the user but to force specific behavior of the user type when a user sets forcelocal => true.

The only part of the config file that actually gets used is the "create_module: files shadow" I didn't test a config without the other settings, I suppose I could do that to shrink the file size.

[Andy Parker]

On Sat, Jan 26, 2013 at 3:29 PM, John Julien <jo...@julienfamily.com> wrote:

Hey Andy,

It has not been brought up yet but it is something I consider when working on the patch.  I actually started writing a new provider for this using the current useradd/groupadd providers as parent classes and quickly abandoned it because I realized I was duplicating so much code.  Another, probably more considerable, reason is that I don't see people actually wanting to use a full blown libuser provider because of some of the limitations of the commands.  Take for example the libuser commands do not have the ability to manage multiple group membership of users.  In my current patch, changes to an existing user continue to use the usermod commands which support this and in the case of a new users luseradd is used to create the user and then a subsequent call is made to usermod to synchronize the group membership appropriately.   If I were to still provide this capability in the libuser provider I would have to call the usermod command instead of the lusermod command.  This put me in the same situation but in reverse order.  I'd be using a libuser provider to execute shadow-utils commands where in I'm currently using a shadow-utils provider to execute libuser commands.

Alright, it guess putting them together sounds reasonable. I wouldn't be too worried about the duplication if the use case of these two things was completely separate, but it sounds like the libuser things are an implementation detail of how users have to be managed on systems with useradd. Do you know if libuser is a universal thing for systems that have useradd? If not, how would this be extended for the circumstance where a different system that is using the useradd provider needs to manage local-only accounts?

[John Julien]

Hey Andy,
I can say it will always be on a Red Hat/CentOS system because /usr/bin/passwd has it as a dependency.  I can't say for sure on other distros.  This patch will not change the way useradd/groupadd currently work for anybody already consuming this provider.  It only changes once they begin using the forcelocal parameter.  I coded the patch in a way that the forcelocal parameter will only work on a system that has libuser.  

Provider source contains:

 has_feature :libuser if Puppet.features.libuser?

Type source contains:

newparam(:forcelocal, :boolean => true, :required_features => :libuser )