I know puppet uses before and require metaparameters to specifically order X before Y, etc. Is there a similar to say "before doing anything else, do this" and "after doing everything else, do that"? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Unfortunately, not that I can tell. I''ve needed something like this in the past and have had to work around it in various odd ways. Hopefully, I''m wrong... T On Wed, Aug 6, 2008 at 3:24 PM, zoniguana <rjustinwilliams@gmail.com> wrote:> > I know puppet uses before and require metaparameters to specifically > order X before Y, etc. Is there a similar to say "before doing > anything else, do this" and "after doing everything else, do that"? > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trevor Vaughan wrote: | Unfortunately, not that I can tell. | | I''ve needed something like this in the past and have had to work | around it in various odd ways. | | Hopefully, I''m wrong... | | T | | On Wed, Aug 6, 2008 at 3:24 PM, zoniguana <rjustinwilliams@gmail.com> wrote: |> I know puppet uses before and require metaparameters to specifically |> order X before Y, etc. Is there a similar to say "before doing |> anything else, do this" and "after doing everything else, do that"? Depends on what you mean by "anything else" - if you mean before ALL other configuration or AFTER all other configuration then no Puppet doesn''t do that. But personally I don''t see why you''d want to do this (my opinion only). ~ I prefer the more granular ordering structure now available. In addition to require and before you can also find the subscribe and notify metaparams at: http://reductivelabs.com/trac/puppet/wiki/TypeReference#available-metaparameters Regards James Turnbull - -- Author of: * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/1590594444/) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFImigE9hTGvAxC30ARAtvyAJ9eAzjW8k6VHm+dfCapJzUmFIP42QCfeXTV VwxyquMunYF/EyV1UTBeenk=hb9D -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
2008/8/6 James Turnbull <james@lovedthanlost.net>:> Depends on what you mean by "anything else" - if you mean before ALL > other configuration or AFTER all other configuration then no Puppet > doesn''t do that. > > But personally I don''t see why you''d want to do this (my opinion only). > ~ I prefer the more granular ordering structure now available. > > In addition to require and before you can also find the subscribe and > notify metaparams at: > > http://reductivelabs.com/trac/puppet/wiki/TypeReference#available-metaparameters > > Regards > > James TurnbullAbout the only time I''ve run into this desire myself is when installing a system, kicking off puppet and having rkhunter do its prop-update before everything is installed, thus generating false alarms and generally annoying the NOC. I ended up working around it with an unless on the exec, but I did have the feeling it would be nice if there was some notion of pre - main - post within puppet. For things that need to be done beforehand I typically just run puppetd with those specific tags. This is also generally within the confines of an install process, but stuff like setting up software repositories needs to be done before installing custom packages, and having everyone remember to add the dependencies whenever they include a custom package is just a pain. .r'' --~--~---------~--~----~------------~-------~--~----~ 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 Wed, Aug 6, 2008 at 7:05 PM, RijilV <rijilv@gmail.com> wrote:> > 2008/8/6 James Turnbull <james@lovedthanlost.net>: > > Depends on what you mean by "anything else" - if you mean before ALL > > other configuration or AFTER all other configuration then no Puppet > > doesn''t do that. > > > > But personally I don''t see why you''d want to do this (my opinion only). > > ~ I prefer the more granular ordering structure now available. > > > > In addition to require and before you can also find the subscribe and > > notify metaparams at: > > > > > http://reductivelabs.com/trac/puppet/wiki/TypeReference#available-metaparameters > > > > Regards > > > > James Turnbull > > About the only time I''ve run into this desire myself is when > installing a system, kicking off puppet and having rkhunter do its > prop-update before everything is installed, thus generating false > alarms and generally annoying the NOC. I ended up working around it > with an unless on the exec, but I did have the feeling it would be > nice if there was some notion of pre - main - post within puppet. > > For things that need to be done beforehand I typically just run > puppetd with those specific tags. This is also generally within the > confines of an install process, but stuff like setting up software > repositories needs to be done before installing custom packages, and > having everyone remember to add the dependencies whenever they include > a custom package is just a pain.Couldn''t you get the desired effect by using dependency groupings? -Brian> > > .r'' > > > >-- - Brian Gupta http://opensolaris.org/os/project/nycosug/ http://www.genunix.org/wiki/index.php/OpenSolaris_New_User_FAQ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
hello,> For things that need to be done beforehand I typically just run > puppetd with those specific tags. This is also generally within the > confines of an install process, but stuff like setting up software > repositories needs to be done before installing custom packages, and > having everyone remember to add the dependencies whenever they > include > a custom package is just a pain.My machines boot into a small environment where I set up yum, push out custom facts, and finally set up puppet.conf, next time it runs it will be in the final environment and then the first-run stuff is already there and it all just work well. Its a hack and I wish there was an option to do things first and last. -- R.I.Pienaar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi,
Why cant you do all of this in one go?
Our Kickstart is doing nothing beside setting up puppet.
Than puppet runs, and fixes everything :)
The main problem with pre and post, is what happens when you have
multiple actions defined as pre or post.
Many times, something simple as
File {Require ''something''} statement can solve many
problems...
Ohad
On Thu, Aug 7, 2008 at 3:49 PM, R.I.Pienaar <rip@devco.net>
wrote:>
> hello,
>
>> For things that need to be done beforehand I typically just run
>> puppetd with those specific tags. This is also generally within the
>> confines of an install process, but stuff like setting up software
>> repositories needs to be done before installing custom packages, and
>> having everyone remember to add the dependencies whenever they
>> include
>> a custom package is just a pain.
>
> My machines boot into a small environment where I set up yum, push out
custom facts, and finally set up puppet.conf, next time it runs it will be in
the final environment and then the first-run stuff is already there and it all
just work well.
>
> Its a hack and I wish there was an option to do things first and last.
>
> --
> R.I.Pienaar
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Not to sound rude, or unappreciative, the answer being "no", the "couldn''t you do it this way?" becomes moot. I have no choice but to do it the more granular way (and, to be honest, ultimately I *would* want to do that). I was looking for a more expedient solution of "just do this before the rest and then clean up after yourself" while I worked out the ordering and immutability issues (and there is going to be a lot of that ordering). More likely, what I will end up doing is working with the file type itself to try to make it first check that a file *is* open to change and, if not, make it so, before attempting to correct said file. On Aug 7, 3:57 am, "Ohad Levy" <ohadl...@gmail.com> wrote:> Hi, > > Why cant you do all of this in one go? > > Our Kickstart is doing nothing beside setting up puppet. > Than puppet runs, and fixes everything :) > > The main problem with pre and post, is what happens when you have > multiple actions defined as pre or post. > > Many times, something simple as > > File {Require ''something''} statement can solve many problems... > > Ohad > > On Thu, Aug 7, 2008 at 3:49 PM, R.I.Pienaar <r...@devco.net> wrote: > > > hello, > > >> For things that need to be done beforehand I typically just run > >> puppetd with those specific tags. This is also generally within the > >> confines of an install process, but stuff like setting up software > >> repositories needs to be done before installing custom packages, and > >> having everyone remember to add the dependencies whenever they > >> include > >> a custom package is just a pain. > > > My machines boot into a small environment where I set up yum, push out custom facts, and finally set up puppet.conf, next time it runs it will be in the final environment and then the first-run stuff is already there and it all just work well. > > > Its a hack and I wish there was an option to do things first and last. > > > -- > > R.I.Pienaar--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
hello,> On Aug 7, 3:57 am, "Ohad Levy" <ohadl...@gmail.com> wrote: > > Hi, > > > > Why cant you do all of this in one go? > > > > Our Kickstart is doing nothing beside setting up puppet. > > Than puppet runs, and fixes everything :) > >Ditto, I use environments - puppet environments for that - not kickstart pre and posts. Knowing the yum repo and custom facts are there already makes my manifests and dependencies trees MUCH easier. Also remember custom facts and even ruby-shadow are only seen after next puppetd restart and not in the first run that puts them on the machine generally you do need 2 runs, and the first run is kind of unpredictable. Separating it out using puppet environments into a small bootstrap enviroment to set up facts, repos and puppet solves this problem. -- R.I.Pienaar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thanks I really don''t mean to sound ungrateful or rude; I appreciate all the info you folks have offered. Most of our "make sure the files are there" part is covered by our build process. What I am trying to get to is a point where, once the build is done, puppet makes sure everything is up-to-date, and keeps it that way. The hard part is making sure that puppet also is able to replace recently-changed immutable files. Because I have different recipes impacting different files that are immutable, it becomes important to have those files made mutable before any changes are made to them. The simplest and most expedient way to do this would have been to be able to run our blanket "expose it all to change" script before doing anything else file-related, and then running out "put your armor back on" script when done. That not being a possibility, I see two options: Every time I use the file type, I need to include a require and before statement, OR I extend the file type to be able to check to see if a file is immutable and, if so, correct that before doing anything else. Currently, I am running with the former, again in the interests in expedience, but, I think the long-term solution will be the latter. I just have to learn enough about extending the file type, to be able to do that. Having picked up James'' "Pulling Strings with Puppet," I should be able to learn enough to hurt myself at first, and then figure out how to heal myself with all the other resources out there. :-) On Aug 7, 8:14 am, "R.I.Pienaar" <r...@devco.net> wrote:> hello, > > > On Aug 7, 3:57 am, "Ohad Levy" <ohadl...@gmail.com> wrote: > > > Hi, > > > > Why cant you do all of this in one go? > > > > Our Kickstart is doing nothing beside setting up puppet. > > > Than puppet runs, and fixes everything :) > > Ditto, I use environments - puppet environments for that - not kickstart pre and posts. > > Knowing the yum repo and custom facts are there already makes my manifests and dependencies trees MUCH easier. > > Also remember custom facts and even ruby-shadow are only seen after next puppetd restart and not in the first run that puts them on the machine generally you do need 2 runs, and the first run is kind of unpredictable. > > Separating it out using puppet environments into a small bootstrap enviroment to set up facts, repos and puppet solves this problem. > > -- > R.I.Pienaar--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
hello,> Every time I use the file type, I need to include a require and > before statement, OR > I extend the file type to be able to check to see if a file is > immutable and, if so, correct that before doing anything else.have you thought of writing a defined type to do this in one go? something along the lines of: define immutablefile($owner=root, $group=root, $mode=644, $source) { exec{"${name}-mutable": .... do things to remove the immutable flag .... } file{"$name": owner => $owner, group => $group, mode => $mode, ensure => $ensure, source => $source, require => Exec["${name}-mutable"], } exec{"${name}-immutable": .... do things to make the file immutable .... require => File[$name] } } and to use that simply do: immutablefile{"/some/file": source => "puppet:///some/file" } You would then use immutablefile{} wherever you wish to manage such a file, not quite as simple as just using file{} but it seems a good compromise. this is a rough sample, you''d need to work on it a bit to support cleanly removing files as well etc, -- R.I.Pienaar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Correction: I have three options! That is an excellent suggestion; thank you! This would be a good opportunity to learn about extending the file type, but your suggestion certainly meets my needs, too! On Aug 7, 11:50 am, "R.I.Pienaar" <r...@devco.net> wrote:> hello, > > > Every time I use the file type, I need to include a require and > > before statement, OR > > I extend the file type to be able to check to see if a file is > > immutable and, if so, correct that before doing anything else. > > have you thought of writing a defined type to do this in one go? > > something along the lines of: > > define immutablefile($owner=root, $group=root, $mode=644, $source) { > exec{"${name}-mutable": > .... do things to remove the immutable flag .... > } > > file{"$name": > owner => $owner, > group => $group, > mode => $mode, > ensure => $ensure, > source => $source, > require => Exec["${name}-mutable"], > } > > exec{"${name}-immutable": > .... do things to make the file immutable .... > require => File[$name] > } > > } > > and to use that simply do: > > immutablefile{"/some/file": > source => "puppet:///some/file" > > } > > You would then use immutablefile{} wherever you wish to manage such a file, not quite as simple as just using file{} but it seems a good compromise. > > this is a rough sample, you''d need to work on it a bit to support cleanly removing files as well etc, > > -- > R.I.Pienaar--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
hello, ----- "zoniguana" <rjustinwilliams@gmail.com> wrote:> Correction: I have three options! > > That is an excellent suggestion; thank you! > > This would be a good opportunity to learn about extending the file > type, but your suggestion certainly meets my needs, too! >Well while making coffee I realised a flaw in this plan, it will have the effect of removing the immutable flag on each file then (possibly) putting it back for each puppet run. Not desirable I imagine, but maybe the sample gives you something to think about toward resolving the problem.> > something along the lines of: > > > > define immutablefile($owner=root, $group=root, $mode=644, $source) > { > > exec{"${name}-mutable": > > .... do things to remove the immutable flag .... > > } > > > > file{"$name": > > owner => $owner, > > group => $group, > > mode => $mode, > > ensure => $ensure, > > source => $source, > > require => Exec["${name}-mutable"], > > } > > > > exec{"${name}-immutable": > > .... do things to make the file immutable .... > > require => File[$name] > > } > > > > } > > > > and to use that simply do: > > > > immutablefile{"/some/file": > > source => "puppet:///some/file" > > > > }-- R.I.Pienaar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Still it has me off in a good direction! What I currently have is a defined makeimmutable which runs if the file is mutable, and requires file["$name"], a defined makemutable, which runs if the file is immutable, and is before File["$name"]. Only detail right now is that if I am recursively pulling down a directory, and would be replacing a protected file within, that fails. I need to find a way to "if $name is a directory, chattr -i everything in that directory. Ideally, it would only chattr the file it is going to change, but, I can deal with it chattring the contents of a directory. Getting closer and closer to a workable solution; very excited! On Aug 7, 12:08 pm, "R.I.Pienaar" <r...@devco.net> wrote:> hello, > > ----- "zoniguana" <rjustinwilli...@gmail.com> wrote: > > Correction: I have three options! > > > That is an excellent suggestion; thank you! > > > This would be a good opportunity to learn about extending the file > > type, but your suggestion certainly meets my needs, too! > > Well while making coffee I realised a flaw in this plan, it will have the effect of removing the immutable flag on each file then (possibly) putting it back for each puppet run. > > Not desirable I imagine, but maybe the sample gives you something to think about toward resolving the problem. > > > > > > something along the lines of: > > > > define immutablefile($owner=root, $group=root, $mode=644, $source) > > { > > > exec{"${name}-mutable": > > > .... do things to remove the immutable flag .... > > > } > > > > file{"$name": > > > owner => $owner, > > > group => $group, > > > mode => $mode, > > > ensure => $ensure, > > > source => $source, > > > require => Exec["${name}-mutable"], > > > } > > > > exec{"${name}-immutable": > > > .... do things to make the file immutable .... > > > require => File[$name] > > > } > > > > } > > > > and to use that simply do: > > > > immutablefile{"/some/file": > > > source => "puppet:///some/file" > > > > } > > -- > R.I.Pienaar--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Progress.... I now have the definition testing to see if a "file" is actually a directory and, if so, then recursing that directory, opening up the contents ot change, and then cleaning up after itself. So now, I am running into an interesting challenge. If I am recursing a directory in puppet, and it finds a protected file it needs to change, how can I then implement the chattr on that file only? I know puppet has the logic to see whether or not the chksum is different and overwrite a file within a recursed directory, but can I have it specifically call the makemutable/makeimmutable around that? Right now, I have makemutable and makeimmutable defined, and am using normal file types. For the file types that are dealing with protected files, those files also have makemutable running as a before, and makeimmutable running as a require for that file statement. I may end up wit a protectedfile type, just to make sure that any protected files are dealt with in a single recipe, but, if I need to do that to be able to call the logic of file to have it make mutable before copying a specific file in a directory, and then make that file immutable again, that seems a distinct possibility... On Aug 7, 2:07 pm, zoniguana <rjustinwilli...@gmail.com> wrote:> Still it has me off in a good direction! > What I currently have is a defined makeimmutable which runs if the > file is mutable, and requires file["$name"], a defined makemutable, > which runs if the file is immutable, and is before File["$name"]. > > Only detail right now is that if I am recursively pulling down a > directory, and would be replacing a protected file within, that > fails. I need to find a way to "if $name is a directory, chattr -i > everything in that directory. Ideally, it would only chattr the file > it is going to change, but, I can deal with it chattring the contents > of a directory. > > Getting closer and closer to a workable solution; very excited! > > On Aug 7, 12:08 pm, "R.I.Pienaar" <r...@devco.net> wrote: > > > hello, > > > ----- "zoniguana" <rjustinwilli...@gmail.com> wrote: > > > Correction: I have three options! > > > > That is an excellent suggestion; thank you! > > > > This would be a good opportunity to learn about extending the file > > > type, but your suggestion certainly meets my needs, too! > > > Well while making coffee I realised a flaw in this plan, it will have the effect of removing the immutable flag on each file then (possibly) putting it back for each puppet run. > > > Not desirable I imagine, but maybe the sample gives you something to think about toward resolving the problem. > > > > > something along the lines of: > > > > > define immutablefile($owner=root, $group=root, $mode=644, $source) > > > { > > > > exec{"${name}-mutable": > > > > .... do things to remove the immutable flag .... > > > > } > > > > > file{"$name": > > > > owner => $owner, > > > > group => $group, > > > > mode => $mode, > > > > ensure => $ensure, > > > > source => $source, > > > > require => Exec["${name}-mutable"], > > > > } > > > > > exec{"${name}-immutable": > > > > .... do things to make the file immutable .... > > > > require => File[$name] > > > > } > > > > > } > > > > > and to use that simply do: > > > > > immutablefile{"/some/file": > > > > source => "puppet:///some/file" > > > > > } > > > -- > > R.I.Pienaar--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
To better clarify, I know that checksum can be run against a specific file, but, when recursing a directory, while puppet seems to be able to detect a specific file in that directory needing to be replaced, can that one single file in that directory needing to be replaced trigger a makemutable of that single file, followed by a makeimmutable once it has been replaced? Or do I need to deal with specific file objects to be able to use the checksum attribute? Thanks! Justin On Aug 7, 3:27 pm, zoniguana <rjustinwilli...@gmail.com> wrote:> Progress.... I now have the definition testing to see if a "file" is > actually a directory and, if so, then recursing that directory, > opening up the contents ot change, and then cleaning up after itself. > > So now, I am running into an interesting challenge. If I am recursing > a directory in puppet, and it finds a protected file it needs to > change, how can I then implement the chattr on that file only? > > I know puppet has the logic to see whether or not the chksum is > different and overwrite a file within a recursed directory, but can I > have it specifically call the makemutable/makeimmutable around that? > > Right now, I have makemutable and makeimmutable defined, and am using > normal file types. For the file types that are dealing with protected > files, those files also have makemutable running as a before, and > makeimmutable running as a require for that file statement. > > I may end up wit a protectedfile type, just to make sure that any > protected files are dealt with in a single recipe, but, if I need to > do that to be able to call the logic of file to have it make mutable > before copying a specific file in a directory, and then make that file > immutable again, that seems a distinct possibility... > > On Aug 7, 2:07 pm, zoniguana <rjustinwilli...@gmail.com> wrote: > > > Still it has me off in a good direction! > > What I currently have is a defined makeimmutable which runs if the > > file is mutable, and requires file["$name"], a defined makemutable, > > which runs if the file is immutable, and is before File["$name"]. > > > Only detail right now is that if I am recursively pulling down a > > directory, and would be replacing a protected file within, that > > fails. I need to find a way to "if $name is a directory, chattr -i > > everything in that directory. Ideally, it would only chattr the file > > it is going to change, but, I can deal with it chattring the contents > > of a directory. > > > Getting closer and closer to a workable solution; very excited! > > > On Aug 7, 12:08 pm, "R.I.Pienaar" <r...@devco.net> wrote: > > > > hello, > > > > ----- "zoniguana" <rjustinwilli...@gmail.com> wrote: > > > > Correction: I have three options! > > > > > That is an excellent suggestion; thank you! > > > > > This would be a good opportunity to learn about extending the file > > > > type, but your suggestion certainly meets my needs, too! > > > > Well while making coffee I realised a flaw in this plan, it will have the effect of removing the immutable flag on each file then (possibly) putting it back for each puppet run. > > > > Not desirable I imagine, but maybe the sample gives you something to think about toward resolving the problem. > > > > > > something along the lines of: > > > > > > define immutablefile($owner=root, $group=root, $mode=644, $source) > > > > { > > > > > exec{"${name}-mutable": > > > > > .... do things to remove the immutable flag .... > > > > > } > > > > > > file{"$name": > > > > > owner => $owner, > > > > > group => $group, > > > > > mode => $mode, > > > > > ensure => $ensure, > > > > > source => $source, > > > > > require => Exec["${name}-mutable"], > > > > > } > > > > > > exec{"${name}-immutable": > > > > > .... do things to make the file immutable .... > > > > > require => File[$name] > > > > > } > > > > > > } > > > > > > and to use that simply do: > > > > > > immutablefile{"/some/file": > > > > > source => "puppet:///some/file" > > > > > > } > > > > -- > > > R.I.Pienaar--~--~---------~--~----~------------~-------~--~----~ 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 Aug 7, 2008, at 7:14 AM, R.I.Pienaar wrote:> > hello, > >> On Aug 7, 3:57 am, "Ohad Levy" <ohadl...@gmail.com> wrote: >>> Hi, >>> >>> Why cant you do all of this in one go? >>> >>> Our Kickstart is doing nothing beside setting up puppet. >>> Than puppet runs, and fixes everything :) >>> > > Ditto, I use environments - puppet environments for that - not > kickstart pre and posts. > > Knowing the yum repo and custom facts are there already makes my > manifests and dependencies trees MUCH easier. > > Also remember custom facts and even ruby-shadow are only seen after > next puppetd restart and not in the first run that puts them on the > machine generally you do need 2 runs, and the first run is kind of > unpredictable.If you''re using factsync, all of the fact code should be pulled down before any fact values are sent to the server, so they should be working immediately. Please file a bug on libshadow not being available until the next run. -- One of the Ten Commandments for Technicians: (7) Work thou not on energized equipment, for if thou dost, thy fellow workers will surely buy beers for thy widow and console her in other ways. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 Aug 7, 2008, at 10:39 AM, zoniguana wrote:> Every time I use the file type, I need to include a require and before > statement, OR > I extend the file type to be able to check to see if a file is > immutable and, if so, correct that before doing anything else. > > Currently, I am running with the former, again in the interests in > expedience, but, I think the long-term solution will be the latter. I > just have to learn enough about extending the file type, to be able to > do that. Having picked up James'' "Pulling Strings with Puppet," I > should be able to learn enough to hurt myself at first, and then > figure out how to heal myself with all the other resources out > there. :-)So you''re saying that Puppet isn''t modifying files that are marked non- writeable? What do you mean by immutable, just that it''s missing a write bit, or is there something else going on? That would certainly be a bug, IMO. I could also see pre- and post- metaparams that allowed you to just include shell scripts to run before and/or after doing anything to the provided resource. It''d need some thinking to make sure it''s not completely crazy, but I don''t mind the basic idea. -- Fallacies do not cease to be fallacies because they become fashions. --G. K. Chesterton --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Luke Kanies wrote:> So you''re saying that Puppet isn''t modifying files that are marked non- > writeable? What do you mean by immutable, just that it''s missing a > write bit, or is there something else going on?I presume this to mean "chattr +i"-style immutable. Frankly, I would think it a bug if puppet /did/ try to control the immutable bit by default -- the only thing I''ve used that bit for in years is as a cheap hack to convince automated management mechanisms to leave a file alone for a while. :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Charles Duffy <Charles_Duffy@messageone.com> writes:> I presume this to mean "chattr +i"-style immutable. > > Frankly, I would think it a bug if puppet /did/ try to control the > immutable bit by default -- the only thing I''ve used that bit for in > years is as a cheap hack to convince automated management mechanisms > to leave a file alone for a while. :)we were discussing using the immutable bit to signal that this file is under Puppet control the other day. in theory, it is an error that other processes edit such files, but it seems a bit too dangerous to enable globally, so I''d want it to be an optional flag to be set on a per file basis. a lot of stuff will break when confronted with this unexpected immutability (an immutable file can''t even be renamed), and you don''t want, say, RPM updates crashing when it failes to rename your config file to .rpmold... one problem for upstream inclusion of such a patch is that it''s not very portable, in fact it is not even a general feature of filesystems on Linux (it''s specific to ext2/ext3 and XFS AFAIK). -- regards, Kjetil T. Homme Linpro AS --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---