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 ) On Friday, January 25, 2013 1:26:13 PM UTC-6, John Julien 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 > > 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! > > -- 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.
