Does anyone know if it''s possible to do the following: Given the directory structure: /foo/bar /foo/bar/<bunch of stuff> Is it possible to set /foo/bar to, say 555, and all stuff below to 440 or the directory equivalent? Thanks, Trevor
Well, I sort of answered my question. If I use /foo/bar/ as one entry and /foo/bar as another, then it seems to work. Unfortunately this throws an error in terms of "Already the parent of file [/foo/bar]". Hmm..... On 7/10/07, Trevor Vaughan <peiriannydd@gmail.com> wrote:> Does anyone know if it''s possible to do the following: > > Given the directory structure: > > /foo/bar > /foo/bar/<bunch of stuff> > > Is it possible to set /foo/bar to, say 555, and all stuff below to 440 > or the directory equivalent? > > Thanks, > > Trevor >
On Jul 10, 2007, at 4:41 PM, Trevor Vaughan wrote:> Well, I sort of answered my question. > > If I use /foo/bar/ as one entry and /foo/bar as another, then it > seems to work. > > Unfortunately this throws an error in terms of "Already the parent of > file [/foo/bar]".What you''re looking for isn''t really possible at this point. The fact that the language doens''t consider those two paths equivalent is kind of a language bug, maybe, I think. If we had globbing, then it would work, but that''s a long-requested feature that I haven''t felt was so critical that it really needed to be done. With resource generation (using the generate() and/or eval_generate() methods) this really shouldn''t be that hard, if some enterprising individual would like to make this all work. -- A motion to adjourn is always in order. --Robert Heinlein --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
This doesn''t strictly solve Trevor''s issue, but how about if the file type had a ''dirmode'' option, that if set overrode the ''mode'' value for any directories in recursive file calls? The alternative would be to have a ''umask'' option I guess, but i''m not sure about how this would map to the (eventual) windows port. Either of these would allow for directories to have different permissions than files, and more importantly will stop puppet setting execute permission on files in a recursive call, which I think is quite dangerous. I''m happy to implement this btw. mike Luke Kanies wrote:> On Jul 10, 2007, at 4:41 PM, Trevor Vaughan wrote: > > >> Well, I sort of answered my question. >> >> If I use /foo/bar/ as one entry and /foo/bar as another, then it >> seems to work. >> >> Unfortunately this throws an error in terms of "Already the parent of >> file [/foo/bar]". >> > > What you''re looking for isn''t really possible at this point. The > fact that the language doens''t consider those two paths equivalent is > kind of a language bug, maybe, I think. > > If we had globbing, then it would work, but that''s a long-requested > feature that I haven''t felt was so critical that it really needed to > be done. With resource generation (using the generate() and/or > eval_generate() methods) this really shouldn''t be that hard, if some > enterprising individual would like to make this all work. > > -- > A motion to adjourn is always in order. > --Robert Heinlein > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
--On July 10, 2007 11:36:03 PM -0500 Luke Kanies <luke@madstop.com> wrote:>> Unfortunately this throws an error in terms of "Already the parent of >> file [/foo/bar]". > > What you''re looking for isn''t really possible at this point. The > fact that the language doens''t consider those two paths equivalent is > kind of a language bug, maybe, I think. > > If we had globbing, then it would work, but that''s a long-requested > feature that I haven''t felt was so critical that it really needed to > be done. With resource generation (using the generate() and/or > eval_generate() methods) this really shouldn''t be that hard, if some > enterprising individual would like to make this all work.We are actually sort of interested in doing this as well. Can you elaborate on how you see the generate() solving this problem?
On Jul 11, 2007, at 8:31 AM, Digant C Kasundra wrote:> We are actually sort of interested in doing this as well. Can you > elaborate on how you see the generate() solving this problem?Basically, generate() allows one resource to create other resources, so for file globbing, you''d specify a resource with a globbed name and it wouldn''t manage anything at all -- all it would do is generate other resources that matched the glob. Those resources would then get managed. -- I never think of the future. It comes soon enough. --Albert Einstein --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Jul 11, 2007, at 4:56 AM, Mike Pountney wrote:> > > This doesn''t strictly solve Trevor''s issue, but how about if the file > type had a ''dirmode'' option, that if set overrode the ''mode'' value for > any directories in recursive file calls? > > The alternative would be to have a ''umask'' option I guess, but i''m not > sure about how this would map to the (eventual) windows port. > > Either of these would allow for directories to have different > permissions than files, and more importantly will stop puppet setting > execute permission on files in a recursive call, which I think is > quite > dangerous. > > I''m happy to implement this btw.I expect this is a sufficient feature. I know Cfengine had it and people seemed to like it. Note, though, that Puppet will automatically add execute permissions to any directory with read permissions, so you can at least safely have your files be, say, 644 and your directories 755. -- Aizu''s Second Law: What changes the world is communication, not information. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 11 July 2007, Luke Kanies wrote:> On Jul 11, 2007, at 8:31 AM, Digant C Kasundra wrote: > > We are actually sort of interested in doing this as well. Can you > > elaborate on how you see the generate() solving this problem? > > Basically, generate() allows one resource to create other resources, > so for file globbing, you''d specify a resource with a globbed name > and it wouldn''t manage anything at all -- all it would do is generate > other resources that matched the glob. Those resources would then > get managed.Just to make it expicit: Luke, you''re not talking about the generate() function which can be used in manifests to use output from external scripts? Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGlQXk/Pp1N6Uzh0URAsFOAJ4vKq8JbwKggIl3F1lhVGmRiw4eKwCcDKou cZ1rZHqIc0bqRYpcGU/5vVA=G59x -----END PGP SIGNATURE-----
On Jul 11, 2007, at 11:31 AM, David Schmitt wrote:> Just to make it expicit: Luke, you''re not talking about the generate() > function which can be used in manifests to use output from external > scripts?Indeed, no. That''s in the parser, and this is in the transaction. There are two special methods you can define on resources that are called during the transaction evaluation: generate() and eval_generate(). generate() is called before the transaction ever starts, which means that resulting resources can be used in relationships, and eval_generate() is called right before the resource itself is evaluated, which means resulting resources cannot be in relationships (actually, generated resources effectively inherit relationships from the generating resource). File recursion uses eval_generate -- for every file found during recursion, a new file resource is generated. We have to use eval_generate instead of generate() because the files might have been created earlier in the transaction. -- Take the utmost trouble to find the right thing to say, and then say it with the utmost levity. -- George Bernard Shaw --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On July 11, 2007 12:00:32 PM -0500 Luke Kanies <luke@madstop.com> wrote:>> Just to make it expicit: Luke, you''re not talking about the generate() >> function which can be used in manifests to use output from external >> scripts? > > Indeed, no. That''s in the parser, and this is in the transaction.Ah, okay. That makes more sense to me. That''s why I wasn''t sure how generate would help with globbing. Now I get it.
Mike, Unfortunately, this doesn''t quite cover what I want to do either. Basically, I want to be able to differentiate the following two commands: - Do something to directory X - Do something to everything under directory X, but not directory X I think that what would fix it is an addendum mode to recurse. Right now, you can do recurse (true|false). What I want is recurse (true|false|sub) where sub only acts on things below the directory and allows the directory to be re-bound as an individual item. Does that make sense? Thanks, Trevor On 7/11/07, Mike Pountney <Mike.Pountney@semantico.com> wrote:> > > This doesn''t strictly solve Trevor''s issue, but how about if the file > type had a ''dirmode'' option, that if set overrode the ''mode'' value for > any directories in recursive file calls? > > The alternative would be to have a ''umask'' option I guess, but i''m not > sure about how this would map to the (eventual) windows port. > > Either of these would allow for directories to have different > permissions than files, and more importantly will stop puppet setting > execute permission on files in a recursive call, which I think is quite > dangerous. > > I''m happy to implement this btw. > > mike > > > > Luke Kanies wrote: > > On Jul 10, 2007, at 4:41 PM, Trevor Vaughan wrote: > > > > > >> Well, I sort of answered my question. > >> > >> If I use /foo/bar/ as one entry and /foo/bar as another, then it > >> seems to work. > >> > >> Unfortunately this throws an error in terms of "Already the parent of > >> file [/foo/bar]". > >> > > > > What you''re looking for isn''t really possible at this point. The > > fact that the language doens''t consider those two paths equivalent is > > kind of a language bug, maybe, I think. > > > > If we had globbing, then it would work, but that''s a long-requested > > feature that I haven''t felt was so critical that it really needed to > > be done. With resource generation (using the generate() and/or > > eval_generate() methods) this really shouldn''t be that hard, if some > > enterprising individual would like to make this all work. > > > > -- > > A motion to adjourn is always in order. > > --Robert Heinlein > > --------------------------------------------------------------------- > > 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 >
Trevor Vaughan wrote:> Basically, I want to be able to differentiate the following two commands: > > - Do something to directory X > - Do something to everything under directory X, but not directory X > > I think that what would fix it is an addendum mode to recurse. Right > now, you can do recurse (true|false). What I want is recurse > (true|false|sub) where sub only acts on things below the directory and > allows the directory to be re-bound as an individual item. > >Understood. I''ll still provide a patch for the ''dirmode'' option though, as this is a separate problem with the current recurse functionality that I need a solution to, eg: 1. make all files in directory mode ''0640'' 2. make all dirs in the directory mode ''2750''. I guess Luke''s comment about the directory name is something to consider though:>> Luke Kanies wrote: >> >>>> Well, I sort of answered my question. >>>> >>>> If I use /foo/bar/ as one entry and /foo/bar as another, then it >>>> seems to work. >>>> >>>> Unfortunately this throws an error in terms of "Already the parent of >>>> file [/foo/bar]". >>>> >>>> >>> What you''re looking for isn''t really possible at this point. The >>> fact that the language doens''t consider those two paths equivalent is >>> kind of a language bug, maybe, I think. >>> >>>I personally would not consider ''dir'' and ''dir/'' to be equivalent. Think in rsync terms, where ''dir'' means ''the directory'' and ''dir/'' means ''the contents of the directory''. What is the general opinion of this? It seems like making this a core feature of the File type would fix Trevor''s problem, but what other types would such a notation impact?
On Jul 12, 2007, at 11:16 AM, Trevor Vaughan wrote:> Mike, > > Unfortunately, this doesn''t quite cover what I want to do either. > > Basically, I want to be able to differentiate the following two > commands: > > - Do something to directory X > - Do something to everything under directory X, but not directory X > > I think that what would fix it is an addendum mode to recurse. Right > now, you can do recurse (true|false). What I want is recurse > (true|false|sub) where sub only acts on things below the directory and > allows the directory to be re-bound as an individual item. > > Does that make sense?The only way that this would work in Puppet at the moment is if you added support for globbing. Otherwise you''re trying to specify a directory twice: once with recursion and once without. Globbing would give you that ability, and I don''t think anything else will. -- If computers get too powerful, we can organize them into a committee -- that will do them in. -- Bradley''s Bromide --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Jul 12, 2007, at 11:36 AM, Mike Pountney wrote:> I personally would not consider ''dir'' and ''dir/'' to be equivalent. > Think > in rsync terms, where ''dir'' means ''the directory'' and ''dir/'' means > ''the > contents of the directory''.Call me non-standard, but I''ll shoot myself before i cansider dir and dir/ to be different. Really. I cannot complain loudly enough about that aspect of tools like rsync; I constantly have to add ''/.'' to every single recursive rsync command I ever do, otherwise I end up with directories in the wrong place. I assume this is intuitive to someone, but it certainly isn''t to me. Fundamentally, you''re talking about recursion vs. nonrecursion; acting like directories aren''t directories by adding a / on the end is just going to make things more confusing, in my opinion, and unless the entire weight of the community is against me, I''m unwilling to accept a patch that provided this.> What is the general opinion of this? It seems like making this a core > feature of the File type would fix Trevor''s problem, but what other > types would such a notation impact?It wouldn''t affect any other types, because nothing else even supports recursion, much less using / to indicate whether recursion should happen. -- Hegel was right when he said that we learn from history that man can never learn anything from history. -- George Bernard Shaw --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 12 July 2007, Luke Kanies wrote:> On Jul 12, 2007, at 11:36 AM, Mike Pountney wrote: > > I personally would not consider ''dir'' and ''dir/'' to be equivalent. > > Think > > in rsync terms, where ''dir'' means ''the directory'' and ''dir/'' means > > ''the > > contents of the directory''. > > Call me non-standard, but I''ll shoot myself before i cansider dir and > dir/ to be different. Really. > > I cannot complain loudly enough about that aspect of tools like > rsync; I constantly have to add ''/.'' to every single recursive rsync > command I ever do, otherwise I end up with directories in the wrong > place. I assume this is intuitive to someone, but it certainly isn''t > to me. > > Fundamentally, you''re talking about recursion vs. nonrecursion; > acting like directories aren''t directories by adding a / on the end > is just going to make things more confusing, in my opinion, and > unless the entire weight of the community is against me, I''m > unwilling to accept a patch that provided this.I know that pain from rsync and would also prefer to stay away from _that_! Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGlmNA/Pp1N6Uzh0URAhkHAKCSeMWL+NT+GXjxb4f6Z1rEqEUqFQCgipTH +Hzz44I/ZBGCVVd7aoSwlt8=37uA -----END PGP SIGNATURE-----
Hmm...I do think that dir vs dir/ is intuitive and I''m not an avid rsync user. Another case where this makes a difference is on unlink. unlink "blah/" gives a not a directory error while unlink "blah" works fine since the symlink is a file not a directory. Would it be possible to make "blah" and "blah/" differ so that we could use them, but also allow for the ''recurse => sub'' option which effectively translates to "blah" not "blah/". This would seem to work inline with the rest of the options so far and would make us all happy with working with either the "/" or "sub" mode. Just a thought. Thanks, Trevor On 7/12/07, Luke Kanies <luke@madstop.com> wrote:> On Jul 12, 2007, at 11:36 AM, Mike Pountney wrote: > > I personally would not consider ''dir'' and ''dir/'' to be equivalent. > > Think > > in rsync terms, where ''dir'' means ''the directory'' and ''dir/'' means > > ''the > > contents of the directory''. > > Call me non-standard, but I''ll shoot myself before i cansider dir and > dir/ to be different. Really. > > I cannot complain loudly enough about that aspect of tools like > rsync; I constantly have to add ''/.'' to every single recursive rsync > command I ever do, otherwise I end up with directories in the wrong > place. I assume this is intuitive to someone, but it certainly isn''t > to me. > > Fundamentally, you''re talking about recursion vs. nonrecursion; > acting like directories aren''t directories by adding a / on the end > is just going to make things more confusing, in my opinion, and > unless the entire weight of the community is against me, I''m > unwilling to accept a patch that provided this. > > > What is the general opinion of this? It seems like making this a core > > feature of the File type would fix Trevor''s problem, but what other > > types would such a notation impact? > > It wouldn''t affect any other types, because nothing else even > supports recursion, much less using / to indicate whether recursion > should happen. > > -- > Hegel was right when he said that we learn from history that man can > never learn anything from history. -- George Bernard Shaw > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
On Jul 12, 2007, at 12:25 PM, Trevor Vaughan wrote:> Hmm...I do think that dir vs dir/ is intuitive and I''m not an avid > rsync user. > > Another case where this makes a difference is on unlink. > > unlink "blah/" gives a not a directory error while unlink "blah" works > fine since the symlink is a file not a directory.I still find this inane and unintuitive. Heck, I had been an admin for at least 7 years before I even knew this.> Would it be possible to make "blah" and "blah/" differ so that we > could use them, but also allow for the ''recurse => sub'' option which > effectively translates to "blah" not "blah/". This would seem to work > inline with the rest of the options so far and would make us all happy > with working with either the "/" or "sub" mode.Yes, it would be possible, but I''m quite against it. Again, I think it''s insanely unintuitive, and I''d only be willing to go along with this if significant portions of the community thought it were a good idea. I think globbing is a much better and much more intuitive solution. -- Brand''s Shortcut: The only way to predict the future is to make sure it stays exactly the same as the present. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
So, with globbing, I would use: "dir": mode => 750 and "dir/*": mode => 640 This sounds good too, I just want to make sure it would work. As a side effect would this also handle cases like: "dir/foo*.txt": owner => fooman and "dir/bar*.txt": owner => barman ? Thanks! Trevor On 7/12/07, Luke Kanies <luke@madstop.com> wrote:> On Jul 12, 2007, at 12:25 PM, Trevor Vaughan wrote: > > > Hmm...I do think that dir vs dir/ is intuitive and I''m not an avid > > rsync user. > > > > Another case where this makes a difference is on unlink. > > > > unlink "blah/" gives a not a directory error while unlink "blah" works > > fine since the symlink is a file not a directory. > > I still find this inane and unintuitive. Heck, I had been an admin > for at least 7 years before I even knew this. > > > Would it be possible to make "blah" and "blah/" differ so that we > > could use them, but also allow for the ''recurse => sub'' option which > > effectively translates to "blah" not "blah/". This would seem to work > > inline with the rest of the options so far and would make us all happy > > with working with either the "/" or "sub" mode. > > Yes, it would be possible, but I''m quite against it. Again, I think > it''s insanely unintuitive, and I''d only be willing to go along with > this if significant portions of the community thought it were a good > idea. > > I think globbing is a much better and much more intuitive solution. > > -- > Brand''s Shortcut: > The only way to predict the future is to make sure it stays > exactly the same as the present. > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
On Jul 12, 2007, at 3:14 PM, Trevor Vaughan wrote:> So, with globbing, I would use: > > "dir": mode => 750 > > and > > "dir/*": mode => 640Yep.> This sounds good too, I just want to make sure it would work. > > As a side effect would this also handle cases like: > > "dir/foo*.txt": owner => fooman > > and > > "dir/bar*.txt": owner => barmanAnd yep. The only real complication is matching everything in the directory except the directory itself; I expect that glob support would just need to always skip matching . and .., but that''s an implementation detail we can handle later. -- At my lemonade stand I used to give the first glass away free and charge five dollars for the second glass. The refill contained the antidote. -- Emo Phillips --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com