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.
