On May 14, 9:05 pm, Steve Roberts <strob...@strobe.net> wrote:
> On Apr 30, 6:10 am, jcbollinger <john.bollin...@stjude.org> wrote:
> > 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).
The kernel level is irrelevant here, because there are no system calls
for managing the user and group databases, nor indeed any concept of
user and group names at that level at all. Your issue is not directed
there.
>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...
That's excellent advice, but regardless of POSIX, there is a wide
variety of real-world systems that do not enforce such a constraint,
and there are many machines that have users and/or groups with
duplicate IDs. Therefore POSIX, too, is irrelevant to the question.
> 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.
Indeed you do, and that's an area Puppet is good at dealing with.
Note that already there is the concept that the login name is the key
identifier -- UIDs *for a given login* should be the same across
machines.
> However, I fully understand it is possible to have two entries in /etc/
> passwd have the same UID but different login strings.
And likewise /etc/group records. That's the point. You cannot have
duplicate user or group *names* (or if you do then the system only
recognizes the first, more or less).
> 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.
You mean like this?
user {
'foo': uid => 542, allowdupe => true;
'bar': uid => 542, allowdupe => true;
}
It should work on systems that in fact do allow duplicate UIDs.
That's not the problem you first asked about.
> 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.
Again, that's largely irrelevant. In practice, it is not safe to rely
on UIDs or GIDs to be unique, therefore Puppet cannot safely use them
to identify user or group records.
> 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.
User and group data other than ID numbers are all userland concepts in
the first place, so it is natural that that Puppet's data model for
these is matched to userland. The specific tools Puppet uses on
various systems are really not the point. Puppet goes to considerable
effort to provide a system abstraction that is internally consistent
and that is as suitable as possible across a wide variety of systems.
User and group names are the identifiers that work for that. UID and
GID just aren't suitable.
> My preference is to have it set the state to how I want it without
> having to cleanup the mess on a box.
And here we're heading back toward DWIM. Puppet provides means to
achieve each task you have brought up, just not the particular means
you would prefer it to have. You already acknowledged that you
weren't expecting a DWIM oracle. If you give Puppet a configuration
description that doesn't match what you really want, then a need for
some sort of cleanup is likely.
It is unfortunate that you didn't realize in advance that the
description you were giving didn't match what you really wanted, but
that sort of problem is commonplace for anyone learning a new system
or language. Puppet has good and valid reasons for its data model
choices, and those are part of the package deal.
> > 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.
It should be doable. Good luck.
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.
