On Apr 30, 6:10 am, jcbollinger <[email protected]> wrote: > > On Apr 27, 6:21 pm, Steve Roberts <[email protected]> wrote: > Ah. No. You're still missing a critical aspect of this situation: > independent of the system tools used (useradd, etc.), the UNIX > architecture provides username / groupname as the ONLY unique key to > the user and group databases. UIDs and GIDs don't cut it because they > are not required to be distinct. As such, Puppet will never change > the name of an existing user or group, at least on UNIX or Linux, > because that would change it into a *different* user / group than the > one being managed. Additionally, that presents a sticky problem if the > user having the target GID is also managed under its actual name. > > To put it a different way, Puppet provides no way to express the idea > "the group with GID 42 should have the name 'answer'" because it > cannot safely rely on GID 42 to uniquely identify one group. > > It is conceivable that providers for Windows or OS X, which use > different primary keys for their user and group databases, could be > given special parameters that would enable the behavior similar to > what you're looking for, based on their own unique keys, but even then > you wouldn't be identifying groups by GID per se.
well, that depends on what you mean by "unix" or "linux". at the system call level there is ONLY UID's, gids (see 'man 2 chown' for example). going to have to dust off my POSIX spec's to see what it guarantees. my old school Unix admin handbook (the red book since it is second edition) says UIDs have to be unique... In fact is has a specific warning to make sure you keep the UID the same for all machines for a gieven login otherwise you break things like NFS. However, I fully understand it is possible to have two entries in /etc/ passwd have the same UID but different login strings. what I am wondering is why not support that mapping coded into a puppet data structure? specify I want uid 542 to have a 'foo' and a 'bar' entry and then using the API functions make it so. >From a quick scan, looking like as far as POSIX and UNIX specs are concerned the UID,GID is unique. so unix implementations are just allowing the duplication in how they manage the user database. I get that since puppet uses the useradd utilitiy instead of an API to handle the user database it is currently limited to the functionality exposed by that userland utility. > > > I don't understand what you're looking for. You started off > > > dissatisfied that Puppet goes boom immediately, yet you don't want the > > > system to go boom later, either. You understandably don't want to > > > create groups with duplicate gids. What behavior would you actually > > > like to see? > > > Like I mentioned above a 'authoritative' type flag. > > You've taken that out of context. The point I was making was that it > is preferable for Puppet to report an error at runtime than to > silently ignore problems or exercise behaviors that risk causing a > failure later. I did not intend to. I was trying to clarify what I was looking for when I first looked into how puppet handles users. Which wasn't my first puppet usage. We kind of did it opposite of what most folks do at my work. we had a basic confman system handling system stuff but our applications needed help. so we started with the applications and then went to the system stuff later. And yes I agree splitting out an error is better than ignoring the problem. Although from a runtime effect it is basically ignoring the issue. the puppet run completes and you have to look for the error to see it occurred. My preference is to have it set the state to how I want it without having to cleanup the mess on a box. > As far as an 'authoritative' flag goes, you are free to create a > custom user provider that offers such a thing as an optional feature. > You would also need to modify the User type to know about that > feature. In the end, however, the fact remains that GID simply > *isn't* an authoritative identifier for UNIX groups, even if you > induce Puppet act as if it were. I have been pondering doing that. considering all of the unix/linux flavor specific attributes that are in the User Resource one more doesn't seem like such a huge hurdle. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
