To start with, I don’t think Puppet did anything wrong here. I’ll pin this
mainly on `nscd`, but it’s something you might want to know about if you’re
using both services. I’ll skip the long story of discovery, panic, and
investigation.
For historical reasons that don’t matter, we do the following on each system:
user { "root":
comment => "$hostname",
}
Yesterday, `nscd` on one of our Puppet nodes lost its frakking mind and decided
there were no users on the box. Puppet comes along, looking to make sure the
comment for root has the correct value, and sees that there’s no such user… so
it adds it. I don’t know the exact command Puppet used (since it didn’t fail)
but either `useradd` or `usermod` was somehow aware of the next available UID
and that root already existed, so root had its UID (and home directory) changed.
That was a fun afternoon. “Why is root’s home set to `/home/root`? Holy shit!
Why is its UID 1273?!” And of course, though I was able to log in as root, I
didn’t have permission to examine most log files since its UID wasn’t 0.
Thankfully, the Puppet client was still up and running with UID 0, so I was
able to throw in a temporary rule to set root’s UID back to 0. After 30
minutes, I was able to get in and figure out what happened.
Like I said, Puppet didn’t do anything wrong, but I wonder: If its internal
logic leads it to conclude that it needs to create new user named “root”,
should it maybe think twice?
--
Rob McBroom
<http://www.skurfer.com/>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
