Last modified: 2014-10-01 15:33:15 UTC
We had a few LDAP rolling upgrades over the past few days. When puppet realize a User type, it apparently detects a provider of the user. When LDAP works, it does not create the user, but whenever LDAP does not, puppet fallbacks to adduser and creates a local user. An example is the beta cluster which recently had a local 'mwdeploy' user being created by puppet on deployment-rsync01 and deployment-bastion. The process we run (such as scap) ends up altering / creating files with the local UID and whenever LDAP comes back we have a few permissions errors all over the place. Puppet User supports a 'provider' attribute which can be set to 'ldap'. Bryan suggested to use hiera to set that on labs. Ref: https://docs.puppetlabs.com/references/latest/type.html#user-attribute-provider
A second though, maybe the l10nupdate and mwdeploy User definitions in puppet should be given UID/GID that matches the one from LDAP.
(In reply to Antoine "hashar" Musso from comment #1) > A second though, maybe the l10nupdate and mwdeploy User definitions in > puppet should be given UID/GID that matches the one from LDAP. Renumbering is going to be a pain, but it would less painful to ensure that the gid/uid pairs used in LDAP match the gid/uid pairs found in the production cluster. It's interesting to me that the mwdeploy user and group do not have explicit uid/gid in puppet. I wonder how that actually works in practice across production.
