On Apr 17, 6:25 am, jcbollinger <john.bollin...@stjude.org> wrote:
> On Apr 16, 10:03 pm, Steve Roberts <strob...@strobe.net> wrote:
> > I thought one of the key ideas for puppet was the ability to define a
> > manifest and puppet would make the machine look like that manifest.
>
> That is correct. Another key idea, however, is that Puppet does not
> manage resources that are not declared in the target node's
> manifests. Yet another is that it avoids doing unusual things without
> specific instruction to do so. Occasionally two or more of these
> clash.
I follow you and I get it can be a hard problem to get "right"
> In this case, you need to recognize that Puppet identifies groups (and
> users) by their names, just as the OS's tools do. Indeed, the only
> other alternative, gid (uid) is unsuitable because the OS does not
> require it to be unique. When you change the name of one of a Group
> declaration in one of your manifests, therefore, that doesn't
> correspond to changing the name field of an existing group record on
> the client. Instead, it corresponds to managing an entirely different
> group, leaving the other unmanaged.
I follow it is using the useradd utils to manage things andso refs by
name.
> > I checked the group resource documentation and didn't see an option to
> > say 'force' or something.
>
> It is spelled "allowdupe", but it would be better to clean up the mess
> than to make a bigger one. Add this to your manifest to do so:
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.
> group { 'txuser':
> ensure => 'absent',
> before => Group['tuser']
> }
Yes for this specific case it would do it. and I actually have a tiny
manifest to do just that as I was checking the behavior of this test
case.
> > I'm thinking would also be a problem if someone locally edited /etc/
> > passwd and /etc/group the manifest would also fail.
>
> That is possible. That general class of problems is one of many
> reasons to avoid sharing management responsibilities for any given set
> of resources among multiple agents (including humans). If it does
> happen, then the failure is probably good, because it signals admins
> that there is something they need to investigate.
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.
> 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 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.
