best way to make puppet temporarily ignore a file?

[jb]

I'd like others to have the option to temporarily disable puppet from
modify a file or directory...something along the lines of:

./something.conf.lock

causes

./something.conf

to NOT be modified by puppet for as long the lock file exists

it'd also be nice to be able to disable an entire directory from being
modified if the file:

./PUPPET-DISABLE

is present. basically the 'unless' parameter as is present in the Exec
type...

[Paul Nasrat]

2010/1/19 jb <jeff...@gmail.com>:

> I'd like others to have the option to temporarily disable puppet from
> modify a file or directory...something along the lines of:
>
> ./something.conf.lock
>
> causes
>
> ./something.conf
>
> to NOT be modified by puppet for as long the lock file exists

We discussed the concept of a maintenance mode during PuppetCamp,
which would serve that purpose. I don't recall if there is a feature
request in redmine for it already but you might want to check.

It's quite a complex feature to implement but it's worth thinking
about the requirements and impact.

What is the underlying thing you are trying to achieve with this mechanism?

Paul

[Trevor Vaughan]

As this would generally be a manual change, I would use 'chattr +i' on
Linux systems.

Trevor

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>
>
>

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Scott Smith]

Trevor Vaughan wrote:
> As this would generally be a manual change, I would use 'chattr +i' on
> Linux systems.
>

I haven't tried, but won't this cause the client to throw an error?

-scott

[Trevor Vaughan]

Yes. But, in theory, this is a temporary measure.

If it's not, then why are you managing that file in the first place?

Trevor

[Scott Smith]

Trevor Vaughan wrote:
> Yes. But, in theory, this is a temporary measure.
>
> If it's not, then why are you managing that file in the first place?
>

I monitor puppetd errors with splunk, so this could cause someone to get
paged =(

Good idea for those of us who don't, though :)

(If I see a feature request for this, I'll definitely upvote it.)

-scott

[Nigel Kersten]

It would be reasonably trivial to subclass the File type to not apply changes if /path/to/file.notouch exists I think.

I'm really torn about this though. Do you really want puppet thinking a resource has been applied when it hasn't been? This complicates dependencies an awful lot....

We've been considering it as a short-term band-aid for some situations, where the notouch file only works for a given period of time.

 

-scott

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
nigel

[jb]

The scenario is this: developer needs, in an emergency situation, to
edit a file that is normally under puppet control (it's a conf file
for our java servlet engine). I'm not around to help out, he may not
have root.

I'd fully want/expect this to generate a puppet error, at least in my
case, though this should be an option I'd imagine. Again, basically
like 'unless' on the exec type...or 'onlyif' but with a negative
check..

> > puppet-users...@googlegroups.com<puppet-users%2Bunsubscribe@google groups.com>

[jb]

In my case the developer may not have root access

On Jan 19, 12:39 pm, Trevor Vaughan <tvaug...@onyxpoint.com> wrote:
> As this would generally be a manual change, I would use 'chattr +i' on
> Linux systems.
>
> Trevor
>
>
>
>
>
> On Tue, Jan 19, 2010 at 3:14 PM, jb <jeffb...@gmail.com> wrote:
> > I'd like others to have the option to temporarily disable puppet from
> > modify a file or directory...something along the lines of:
>
> > ./something.conf.lock
>
> > causes
>
> > ./something.conf
>
> > to NOT be modified by puppet for as long the lock file exists
>
> > it'd also be nice to be able to disable an entire directory from being
> > modified if the file:
>
> > ./PUPPET-DISABLE
>
> > is present. basically the 'unless' parameter as is present in the Exec
> > type...
>
> > --
> > You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> > To post to this group, send email to puppet...@googlegroups.com.
> > To unsubscribe from this group, send email to puppet-users...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/puppet-users?hl=en.

>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699

> tvaug...@onyxpoint.com

[Trevor Vaughan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Why not use the 'noop' metaparam?

Instead of a notouch file, how about .file.noop which would simply set
noop => 'true' for that run perhaps with an extended message about using
a noop file.

Trevor

>> puppet-users...@googlegroups.com<puppet-users%2Bunsu...@googlegroups.com>

>> .
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>>
>>
>>
>
>

- --
Trevor Vaughan
Vice President, Onyx Point, Inc.
email: tvau...@onyxpoint.com
phone: 410-541-ONYX (6699)

- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktWThYACgkQyWMIJmxwHpTJrACfT+6fZ/FFZhIEus6qHwWNyPSL
SYsAmwQEp93lG1sH0QO6M8C9W+ymcevF
=3SC5
-----END PGP SIGNATURE-----

[Ohad Levy]

what about allowing the users to modify the tag lists?
Ideally, you would need a black list tag, which a script could read and feed into puppetd command line arguments.

cheers,
Ohad

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.

To unsubscribe from this group, send email to puppet-users...@googlegroups.com.

[Eric Gerlach]

Or, perhaps this is a case for an extlookup? I'm not fully familiar with that
function yet, but my inclination is that it might fit the bill.

Cheers,

Eric

> > puppet-users...@googlegroups.com<puppet-users%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> > http://groups.google.com/group/puppet-users?hl=en.
> >
> >
> >
> >

> -- <br />
>
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.<br />
>
> To post to this group, send email to puppet...@googlegroups.com.<br />
>
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.<br />
>
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.<br />
>

--
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: eger...@feds.uwaterloo.ca