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. On Jan 26, 2013, at 5:00 PM, Andy Parker <[email protected]> wrote: Hi John, On Fri, Jan 25, 2013 at 11:26 AM, John Julien <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
