On Apr 16, 10:03 pm, Steve Roberts <[email protected]> wrote:
> I'm hoping I'm just missing something simple.
>
> I ran across this in my deployment setup and have replicated in a
> simple set of manifests.  command output and the manifests below.
>
> basically start with a user/group name but it had the name was
> misspelled 'txuser'
>
> so correct it to 'tuser' but puppet errors out saying the gid is a
> dupe.
>
> 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.

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 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:

group { 'txuser':
  ensure => 'absent',
  before  => Group['tuser']
}


> 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.

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.


John

-- 
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.

Reply via email to