Issue #5608 has been updated by Sean Millichamp. Affected Puppet version changed from 2.6.4 to 2.7.21 Branch deleted (https://github.com/seanmil/puppet/tree/ticket/2.6.x/5608)
I did somewhat drop the ball on this one and never replied to Jesse or Daniel's points. As I have just finished working around this in our environment (ugly though it may be) I wanted to address the issue. I think that it does likely depend a lot on the local tools which are invoked whether the local users can or can not be manipulated. In my case, the useradd series of tools (and provider) is the one I needed to address the issue with. However, I also don't find it unlikely that in larger corporate shops with stricter security controls that the permissions needed to do anything significant to modify an LDAP tree would not be allowed on every system in the environment. More logical (to me, at least) would be to have Puppet interact with LDAP directly via a device type/provider, if there was a need found to actually manipulate the tree. In our environment, and for many of our customers, providing credentials with that level of LDAP access to the server environment at large would have us fail security audits all over the place. That said, though, I see a more tangible problem here than the more theoretical debate above. While some of the provider toolsets MAY allow modification of LDAP (or other backend) based users, the useradd family is (as far as I can tell) not one of them. The proper thing therefore to do on a useradd platform would be to return only local users. On RHEL 6, the useradd family of tools are not linked to any LDAP libraries and, if changes to an existing LDAP-based user are attempted, indicate that they will only work with /etc/passwd: <pre> # getent passwd ldapuser ldapuser:*:1000:1000:LDAP User:/home/ldapuser:/bin/bash # useradd ldapuser useradd: user 'ldapuser' already exists # usermod -c "New Name" ldapuser usermod: user 'ldapuser' does not exist in /etc/passwd # userdel ldapuser userdel: cannot remove entry 'ldapuser' from /etc/passwd </pre> The useradd provider makes calls to all of these binaries to perform its underlying functions. Instantiating the resources is, as I understand, only used in two places: * resources type (for purging) * 'puppet resources' While I can see the argument that having Puppet resources show and return the same list as the system's NSS can see is valuable, I would also argue that gives users the (false) impression that they could then go change those resources which is not desirable. As for the resources type... it makes this essentially completely unusable. For a large LDAP tree Puppet is instantiating and generating resources at run time for potentially thousands of users - putting a huge load on the LDAP server and adding a lot of time to the agent run - and then is unable to purge any of them (not that you would want it to). As there is no reliable way to distinguish between the various sources of users via NSS, there isn't even a sensible way to provide some type of optionally selected filter. What I have done in our environment to work around this problem with the useradd type is to include a copy of useradd.rb from the core Puppet distribution as-is, plus one added self.instances() method in useradd.rb that opens and parses /etc/passwd for a list of users instead of using NSS. It is reasonably simple and seems to be working well for us. If you'd like, I'm happy to turn that into a pull request if/when I can convince you it is the right thing to do. I haven't yet, but will likely be doing the same changes for groups. Thoughts? ---------------------------------------- Bug #5608: Puppet shouldn't enumerate LDAP users for local user unmanaged resource purge https://projects.puppetlabs.com/issues/5608#change-91205 * Author: Sean Millichamp * Status: Code Insufficient * Priority: Normal * Assignee: Sean Millichamp * Category: user * Target version: * Affected Puppet version: 2.7.21 * Keywords: * Branch: ---------------------------------------- When using: resources { 'user': purge => true } in a Puppet configuration not setup for LDAP management (intentionally) it is using the system getent functions via listbyname() (inherited from lib/puppet/provider/nameservice.rb) which nevertheless lists all the LDAP users because they show in the getent database via nsswitch. This causes a number of problems in my situation: 1) The LDAP tree is large enough that Puppet can't complete in a reasonable amount of time when it has to list all of the users in LDAP 2) Puppet will see users it can't delete 3) Even if it could delete those users, I only want to use Puppet to manage just the local users Based on my reading of the code, if Puppet is being used to manage LDAP users the ldap.rb provider manages that itself and doesn't require use of getpwent in nameservice.rb The workaround I used is by overriding the listbyname() function in a custom provider (which inherits from useradd) to look for users in /etc/passwd. It seems like it would be safe to just modify the listbyname() function in nameservice.rb to look directly in /etc/passwd but I am not certain what else that might impact. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
