Slow user resource-type when host is attached to LDAP directory

[Josh]

The majority of our servers are attached to large LDAP directories.  However, there are also cases when we need to define local service accounts for whatever reason.  We do this with the "user" resource-type.  If the host is attached to a LDAP directory, it takes Puppet a VERY long time to process the "user" resource-type.  In our case, it takes 60+ seconds to process each user type.  Running "puppet resource user username" on the host takes over 2 minutes.  During this time, the "puppet" process on each hosts is pegged at 100% CPU usage.

Is there any way around this?  I have seen it brought up on the list, but not anytime recently (2008, last I searched).

Thanks.

[jcbollinger]

On Tuesday, March 19, 2013 12:34:23 PM UTC-5, Josh wrote:

The majority of our servers are attached to large LDAP directories.  However, there are also cases when we need to define local service accounts for whatever reason.  We do this with the "user" resource-type.  If the host is attached to a LDAP directory, it takes Puppet a VERY long time to process the "user" resource-type.  In our case, it takes 60+ seconds to process each user type.  Running "puppet resource user username" on the host takes over 2 minutes.  During this time, the "puppet" process on each hosts is pegged at 100% CPU usage.

Is there any way around this?  I have seen it brought up on the list, but not anytime recently (2008, last I searched).

This sounds like an issue associated more with your hosts' configuration than with Puppet itself.  Try running your system's user management commands (for example, useradd / usermod / userdel) directly.  I think you will see similar long runtimes.  If so, then you cannot attribute your performance problem to Puppet.

It is possible that you could improve performance for existing local users by modifying the service priorities in your name service policy to give the local user and group files highest priority (but be aware that this makes local user and group entries supercede LDAP).  On common Linuxes that typically means modifying /etc/nsswitch.conf.

That's the best I can do without any details of your manifests or target node configurations.


John

[Alan Chalmers]

Josh,

Did you ever get a resolution for this?

thanks

alan

[Stefan Heijmans]

There is a user resource attribute;

forcelocal [1]

Forces the management of local accounts when accounts are also being managed by some other NSS

 

Doens't this help?

 

 

[1] https://docs.puppetlabs.com/references/latest/type.html#user-attribute-forcelocal

[Dan White]

Me too, please

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”  (Bill Waterson: Calvin & Hobbes)

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fbd46f2e-813e-4d6f-ad79-907f334167d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alan Chalmers]

Nope. we have forcelocal true already.