FAQ
Oops, sorry for the no-added-content post. What I meant to say was:
On Jun 7, 8:29 am, Jistan Idiot wrote:
So I discovered yesterday that if puppet changes the gid of a group it
doesn't go through the file system and update them with the new correct gid
(at least this was the case on RHEL5 and client puppet v2.6.16 and
puppetmaster 2.7.12).  Now I thought that it might be possible to have
puppet execute something like find  /home/ -group <old_gid> | xargs chgrp
groupname.  However it isn't quite that simple.  First it needs to be run
after the change, so I had to put it in a new stage that runs after main.

Or you could have just used a 'notify' on the Group or a 'subscribe'
on the Exec. If you also put "refreshonly => true" on the Exec then
that would have the additional advantage that the Exec would run only
when Puppet actually changed something about the group. Run stages
basically just declare many resource relationships in a compact way,
but typically you need only a few of the implied relationships. That
sometimes causes genuine problems. Whenever feasible, therefore, you
should declare the specific relationships you need instead of using
stages.

After that everything was all good.

I have some issues with this solution.  First the find takes forever to
run.  I'm not sure there's any way around this.

It depends on how precise you want to be. If you need to go file by
file then you're probably stuck. On the other hand, perhaps you could
use a shortcut such as this:

find /home/* -maxdepth 0 -group <old_gid> -exec chgrp -R groupname {}
\;

The idea there is to look just at the gids of the homedirs, and do a
recursive chgrp on the ones with the old gid. That should be about as
fast as can be, but it will ignore files under homedirs assigned to
different groups, and it will change file gids other than the intended
ones if they are under a homedir assigned to the affected group.
Perhaps you can live with those caveats. There could be alternative
ways to tune it depending on which assumptions / constraints you are
willing to apply.

Second, it required some manual intervention and foreknowledge of the
problem.

Indeed, that is the nature of Puppet. It configures the system with
the resources you specify to it. It is not a script engine.

What if I don't know someone had manually created a group with
the wrong gid?   I was thinking maybe creating a custom function that could
be called whenever there's a refresh on a group and use the old and new
gids to run the command.

You could wrap all your Group declarations in a custom defined type,
such as

mymodule::group($ensure => 'present', $gid, $members => undef, $system
=> false) {
group { $name:
ensure => $ensure,
gid => $gid,
members => $members,
system => $system
}

if ! $system {
exec { "fix_${name}_gids":
command => 'find /home/* -maxdepth 0 -group <old_gid> -exec
chgrp -R groupname {} \;'
refreshonly => true,
subscribe => Group["${name}"]
}
}
}

Note that that will run the exec on *any* change to the associated
group, however, not just on a gid change. Note also that the exec
isn't safe against duplicate gids and gid swapping.

Hopefully someone can show me how to do this as I
haven't figured it out (and not sure it is a good way to do this).

If you want to capture just gid changes, then the only good way to do
it in Puppet is to write a custom provider for the Group type, and
specify it explicitly on your group resources via the 'provider'
parameter. That way you could also dispense with the wrapper and
Exec, and just write the desired behavior into the provider. Even
then, however, this will affect only groups that you actually declare
in your manifests.

Finally, I don't think this is going to work for the next thing I want to
tackle.  I have a group of websevers that I'm going to start managing with
puppet.  The uids and gids are not consistent across them.  I'm going to
want puppet to fix that since there are way too many to do manually.

For example:

groupname  old_gid new_gid
groupA         1572    1863
groupB         1861    1572
groupC         1863    1861

I'm thinking that would just be a horrible nightmare with what I did
before.  In this example all the old 1572 items would be 1863 when the fix
for groupC is run. Is there some way to fix this problem?

Puppet identifies groups by name, not gid, so the group changes don't
look like a big problem themselves, provided that your tools allow
duplicate gids (at least optionally; only needed transiently):

group {
'groupA': gid => 1863, allowdupe => true;
'groupB': gid => 1572, allowdupe => true;
'groupC': gid => 1861, allowdupe => true;
}

Changing gids on the filesystem, on the other hand, is much trickier.
You need to identify all the changes to be made before you make any of
them, because once you start making the changes you'll no longer be
able to tell from the files themselves which still need changed and
which don't. You could still code something like this into a
provider, if you're careful, but it looks awfully heavy.


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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 5 | next ›
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJun 7, '12 at 1:29p
activeJun 8, '12 at 6:10p
posts5
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase