I''m not sure if this is the way things are supposed to happen but, when I specify a directory with recursion and md5 checksums, the directory itself is checksummed and assumed to have changed. Of course, if anything in the directory changed, the directory checksum will change. What I would like to do is to manipulate all of the files in a directory, but ignore the directory itself. I''ve tried a name of "dir/*" and a source of "puppet://dir/*" but the file retrieval system doesn''t seem to support wildcards. Any suggestions? It''s getting to the point that I''m using find so much that I might as well have gone with cfengine. Thanks, Trevor _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jan 23, 2007, at 8:38 AM, Trevor Vaughan wrote:> I''m not sure if this is the way things are supposed to happen but, > when I specify a directory with recursion and md5 checksums, the > directory itself is checksummed and assumed to have changed.Yep, because the directory actually has changed.> Of course, if anything in the directory changed, the directory > checksum will change. > > What I would like to do is to manipulate all of the files in a > directory, but ignore the directory itself.Why?> I''ve tried a name of "dir/*" and a source of "puppet://dir/*" but > the file retrieval system doesn''t seem to support wildcards.That is correct, filed as enhancement request #48[1]. This functionality could actually be provided now (but could not have before 0.22), but I''ve not had the time to do so.> Any suggestions?Why do you require this behaviour? Without knowing that, it''s hard to say how to get what you want.> It''s getting to the point that I''m using find so much that I might > as well have gone with cfengine.It seems like you''ve approached Puppet as though it''s a direct replacement for cfengine, which is not the case. You do have to rethink some of the basics, and there is intentionally not a complete feature overlap. How exactly are you using find? Puppet is definitely not optimized for pure file handling -- the whole point of using it is that you use its higher-level resources like ''user'' and ''host'', rather than just directly manipulating files. If all you do is move files around, it might be easier for you to use cfengine. I would guess, though, that you could rethink your configuration in a way that''s a bit more Puppet-friendly and be happier. 1 - https://reductivelabs.com/cgi-bin/puppet.cgi/ticket/48 -- It is well to remember that the entire universe, with one trifling exception, is composed of others. --John Andrew Holmes --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke, Thanks for getting back to me and I apologize if I sounded a bit short, I''ve been trying things that are getting frustrating, probably because I''m not using the language to its fullest potential. Anyway, what I''m trying to do is to make sure that certain system critical files exist, have the content that I want them to have, and the permissions that I want them to have. For example, the pam.d directory: /etc/pam.d should have permissions 755 but /etc/pam.d/* should have permissions 644 and certain files, well mainly system-auth, should have particular content so that overall authentication doesn''t break. If this is changed due to boneheaded admin X (possibly me), then I would like to have it automatically fixed. I know that I could write a cron job to do this, but it seems like redundant effort given the capabilities of puppet. I also realized that I could just copy the files, and leave off the mode File attribute and it would be fine but that seems a bit silly when I only really want to copy a couple of files at most. Does that make sense? Thanks, Trevor On 1/23/07, Luke Kanies <luke@madstop.com> wrote:> > On Jan 23, 2007, at 8:38 AM, Trevor Vaughan wrote: > > > I''m not sure if this is the way things are supposed to happen but, > > when I specify a directory with recursion and md5 checksums, the > > directory itself is checksummed and assumed to have changed. > > Yep, because the directory actually has changed. > > > Of course, if anything in the directory changed, the directory > > checksum will change. > > > > What I would like to do is to manipulate all of the files in a > > directory, but ignore the directory itself. > > Why? > > > I''ve tried a name of "dir/*" and a source of "puppet://dir/*" but > > the file retrieval system doesn''t seem to support wildcards. > > That is correct, filed as enhancement request #48[1]. This > functionality could actually be provided now (but could not have > before 0.22), but I''ve not had the time to do so. > > > Any suggestions? > > Why do you require this behaviour? Without knowing that, it''s hard > to say how to get what you want. > > > It''s getting to the point that I''m using find so much that I might > > as well have gone with cfengine. > > It seems like you''ve approached Puppet as though it''s a direct > replacement for cfengine, which is not the case. You do have to > rethink some of the basics, and there is intentionally not a complete > feature overlap. > > How exactly are you using find? > > Puppet is definitely not optimized for pure file handling -- the > whole point of using it is that you use its higher-level resources > like ''user'' and ''host'', rather than just directly manipulating > files. If all you do is move files around, it might be easier for > you to use cfengine. I would guess, though, that you could rethink > your configuration in a way that''s a bit more Puppet-friendly and be > happier. > > 1 - https://reductivelabs.com/cgi-bin/puppet.cgi/ticket/48 > > -- > It is well to remember that the entire universe, with one trifling > exception, is composed of others. --John Andrew Holmes > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jan 23, 2007, at 9:11 AM, Trevor Vaughan wrote:> Luke, > > Thanks for getting back to me and I apologize if I sounded a bit > short, I''ve been trying things that are getting frustrating, > probably because I''m not using the language to its fullest potential. > > Anyway, what I''m trying to do is to make sure that certain system > critical files exist, have the content that I want them to have, > and the permissions that I want them to have. > > For example, the pam.d directory: > > /etc/pam.d should have permissions 755 but /etc/pam.d/* should have > permissions 644 and certain files, well mainly system-auth, should > have particular content so that overall authentication doesn''t break.Puppet will automatically add execute bits to directories for every read bit. So, if you recursively set a directory to 644, the files will get 644 and the directories will get 755.> If this is changed due to boneheaded admin X (possibly me), then I > would like to have it automatically fixed.Very common.> I know that I could write a cron job to do this, but it seems like > redundant effort given the capabilities of puppet.Yep.> I also realized that I could just copy the files, and leave off the > mode File attribute and it would be fine but that seems a bit silly > when I only really want to copy a couple of files at most. > > Does that make sense?Yes, but I still don''t see why you care if the directory notices that it changed. Is there something you''re trying to do that isn''t possible because of this? Or does this result in specific behaviour you don''t want? -- Nonreciprocal Laws of Expectations: Negative expectations yield negative results. Positive expectations yield negative results. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Hmm...I had not realized about the directory automatically adding the execute bit. I suppose that the md5 sum of the directory isn''t really a big deal and it does act as a sort of minimal tripwire in the case of "someone did something in here that may be outside of the scope of puppet". However, let me change my example slightly for a possibly more clear example. Anonymous ftp server: Want directory /ftp/pub/etc to have permissions 711 but the files in /pub/etc to have permissions 644 to automatically set up, traverse-only directory structures. Thanks, Trevor On 1/23/07, Luke Kanies <luke@madstop.com> wrote:> > On Jan 23, 2007, at 9:11 AM, Trevor Vaughan wrote: > > > Luke, > > > > Thanks for getting back to me and I apologize if I sounded a bit > > short, I''ve been trying things that are getting frustrating, > > probably because I''m not using the language to its fullest potential. > > > > Anyway, what I''m trying to do is to make sure that certain system > > critical files exist, have the content that I want them to have, > > and the permissions that I want them to have. > > > > For example, the pam.d directory: > > > > /etc/pam.d should have permissions 755 but /etc/pam.d/* should have > > permissions 644 and certain files, well mainly system-auth, should > > have particular content so that overall authentication doesn''t break. > > Puppet will automatically add execute bits to directories for every > read bit. So, if you recursively set a directory to 644, the files > will get 644 and the directories will get 755. > > > If this is changed due to boneheaded admin X (possibly me), then I > > would like to have it automatically fixed. > > Very common. > > > I know that I could write a cron job to do this, but it seems like > > redundant effort given the capabilities of puppet. > > Yep. > > > I also realized that I could just copy the files, and leave off the > > mode File attribute and it would be fine but that seems a bit silly > > when I only really want to copy a couple of files at most. > > > > Does that make sense? > > Yes, but I still don''t see why you care if the directory notices that > it changed. Is there something you''re trying to do that isn''t > possible because of this? Or does this result in specific behaviour > you don''t want? > > -- > Nonreciprocal Laws of Expectations: > Negative expectations yield negative results. Positive expectations > yield negative results. > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jan 23, 2007, at 9:35 AM, Trevor Vaughan wrote:> Hmm...I had not realized about the directory automatically adding > the execute bit. > > I suppose that the md5 sum of the directory isn''t really a big deal > and it does act as a sort of minimal tripwire in the case of > "someone did something in here that may be outside of the scope of > puppet".It''s not so much for tripwire as to make sure daemons get restarted.> However, let me change my example slightly for a possibly more > clear example. > > Anonymous ftp server: > > Want directory /ftp/pub/etc to have permissions 711 but the files > in /pub/etc to have permissions 644 to automatically set up, > traverse-only directory structures.This is not currently possible using recursivion on the whole /ftp/ pub/etc directory -- you''ll need to specify each contained file separately. As I mentioned earlier, you''re the first person to ask for this, which is why I''ve never bothered to implement it. Feel free to reopen bug #4, but I can''t guarantee I''ll get it done any time soon considering how low-demand the feature is compared to other bugs or enhancements. Of course, I''d be glad to accept a patch providing it. -- Never interrupt your enemy when he is making a mistake. --Napolean Bonaparte --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
I''ll work on providing a patch as soon as I learn ruby (i.e. get my books). But, I will actually work on it eventually. Thanks! Trevor On 1/23/07, Luke Kanies <luke@madstop.com> wrote:> > On Jan 23, 2007, at 9:35 AM, Trevor Vaughan wrote: > > > Hmm...I had not realized about the directory automatically adding > > the execute bit. > > > > I suppose that the md5 sum of the directory isn''t really a big deal > > and it does act as a sort of minimal tripwire in the case of > > "someone did something in here that may be outside of the scope of > > puppet". > > It''s not so much for tripwire as to make sure daemons get restarted. > > > However, let me change my example slightly for a possibly more > > clear example. > > > > Anonymous ftp server: > > > > Want directory /ftp/pub/etc to have permissions 711 but the files > > in /pub/etc to have permissions 644 to automatically set up, > > traverse-only directory structures. > > This is not currently possible using recursivion on the whole /ftp/ > pub/etc directory -- you''ll need to specify each contained file > separately. > > As I mentioned earlier, you''re the first person to ask for this, > which is why I''ve never bothered to implement it. Feel free to > reopen bug #4, but I can''t guarantee I''ll get it done any time soon > considering how low-demand the feature is compared to other bugs or > enhancements. Of course, I''d be glad to accept a patch providing it. > > -- > Never interrupt your enemy when he is making a mistake. > --Napolean Bonaparte > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users