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. 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. Second, it required some manual intervention and foreknowledge of the problem. 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. 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). 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? Thanks in advance. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/jbV8X9pds-wJ. 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.
Hi, On 06/07/2012 03:29 PM, Jistan Idiot wrote:> 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.I don''t believe that puppet is the right tool for this job. If I were in your shoes, I''d use puppet to deploy a script that takes care of the logistics behind the task at hand, have it run, then get rid of it once you''re clear. HTH, Felix -- 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.
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. > 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. > > Second, it required some manual intervention and foreknowledge of the > problem. 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. 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). > > 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? > > Thanks in advance.-- 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.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 06/08/2012 09:06 AM, jcbollinger wrote:> > 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. >> 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. >> >> Second, it required some manual intervention and foreknowledge of the >> problem. 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. 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). >> >> 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? >> >> Thanks in advance. >>I''ve had to do this. a good approach is to write a script that writes a script. Then you can adjust and re-run the generated script if the results are not what you like. You can even undo the changes if you plan ahead a little. set up a little sandbox, and work in that. It takes a little thought and testing, but is not hard if you know how to write subroutines in shell or some other language. --vagn -- 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.