On Apr 27, 6:21 pm, Steve Roberts <strob...@strobe.net> wrote: > On Apr 18, 6:46 am, jcbollinger <john.bollin...@stjude.org> wrote: > > > On Apr 17, 5:04 pm,SteveRoberts<strob...@strobe.net> wrote: > > > > On Apr 17, 6:25 am, jcbollinger <john.bollin...@stjude.org> wrote: > > > well, allowdupe doesn't fix the issue only masks it. I knew about > > > taht attribute but > > > it just adds a duped group instead of making right the user/group. > > Indeed, but that's what you asked about. > > actually I was asking if there was an attribute that would override > the other group with the same GID with the new group name. > > would require a provider that didn't just try to use 'useradd' but it > could be written. > > something like a 'authoritative' attribute that would check for an > existing user/group witht he spec'd UID/GID and replace it if it > exists. > > the allowdupe would still be around if you want to just have an > additional name with the same UID/GID.
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. > > 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. 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. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.
