Oops, sorry for the no-added-content post. What I meant to say was:
On Jun 7, 8:29 am, Jistan Idiot <jistanid...@gmail.com> 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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
