On Apr 18, 6:46 am, jcbollinger <[email protected]> wrote:
> On Apr 17, 5:04 pm,SteveRoberts<[email protected]> wrote:
>
> > On Apr 17, 6:25 am, jcbollinger <[email protected]> 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.
> > Well, I'm not worried about when the human has been told they can make
> > changes but rather when a human (or bad tool) makes a change nad it
> > slips through the cracks initially and goes boom later.
>
> 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.
thinking the .pp would have something like this in it:
user { 'tuser':
ensure => 'present',
comment => 'Test User',
gid => '400',
home => '/home/tuser',
password => '!!',
password_max_age => '99999',
password_min_age => '0',
shell => '/bin/sh',
uid => '400',
authoritative => 'true',
}
and then when applied on a machine would check for uid,gid 400 and if
either were not 'tuser' it would get replaced.
> Puppet gives the appearance of a lot of intelligence, but it has a
> long way to go before it can pass a Turing test. Until then, it's
> unreasonable to expect DWIM. :)
No not looking for DWIM. just a User class (and more importantly an
underlying provider) that has the options to do what I would like it
to do.
> > > Puppet also has a mechanism by which you can ensure that otherwise-
> > > unmanaged resources of some types are all ensured absent. That's both
> > > very powerful and very dangerous, and I advise you to avoid it at
> > > least until you have more experience with Puppet. To that end, I'm
> > > leaving it as an exercise to determine just what the mechanism is.
>
> > I may have to poke on how puppet does that. we actually do an
> > absolute /etc/passwd (and friends) in our current conf man system.
> > and yes it does have its pitfalls too.
>
> You can do that with Puppet as well, if you prefer, but you cannot
> safely mix that approach with using User and Group resources.
understood. we will be migrating from our current configuration
management to puppet. problem one area at a time. don't worry we
won't be trying to have two different confman systems trying to manage
the same resources. ick that would be a mess.
Steve
--
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.
