RE: Locking for temporary ad-hoc changes?

[Martin, Jason H]

At a high level, you could have some flag file for the host that
disables CFEngine temporarily. IE, if /tmp/CFEDISABLED exists then abort
processing of certain rules.

-JM

> -----Original Message-----
> From: 
> help-cfengine-bounces+jason.h.martin=cingular.com@gnu.org 
> [mailto:help-cfengine-bounces+jason.h.martin=cingular.com@gnu.
> org] On Behalf Of Wil Cooley
> Sent: Friday, November 04, 2005 1:46 PM
> To: Mark Burgess
> Cc: help-cfengine@gnu.org
> Subject: RE: Locking for temporary ad-hoc changes?
> 
> 
> On Fri, 2005-11-04 at 08:51 +0100, Mark Burgess wrote:
> > I have scaned but I'm not sure that I understand this 
> discussion. Can 
> > you spell out the conclusions for me?
> 
> My request is for an admin-initiated locking mechanism, so 
> that making changes which require several tries to get right 
> can be done more smoothly.  My example was Apache config 
> files, which sometimes require several tries to get right 
> (think fancy stuff with mod_rewrite, for example).  Current 
> cycle is one of these:
> 
> 1. Work on cfserver or working directory in SCM:
>     until correct:
>       edit config file
>       commit to repository
>       manually run cfagent on target host
>       test config file
> 
> In this case running cfagent adds a large and frustrating 
> latency between edit/test.  I tend to try to use this method, 
> but works best for minor changes or changes where I can 
> properly validate that everything is correct without HUPping 
> a daemon or putting into whatever environment it needs to be in.
> 
> 2. Work on target host:
>     until correct:
>         edit config file
>         check cfagent hasn't overwritten config file
>         test config file
>         check cfagent hasn't overwritten config file
>     commit to repository
>  
> This is what I do often; I know roughly when cfagent is going 
> to run and Vim is good about letting me know when the file's 
> been overwritten. Clearly, this is hackish and prone to race 
> conditions.
> 
> Another suggested approach is:
> 
> 3. Work on target host:
>     kill cfexecd
>     until correct:
>         edit config file
>         test config file
>     commit to repository
>     restart cfexecd
> 
> This works without the race conditions, except it prevents 
> cfengine from being able to do anything else while I'm 
> working on one file and is open to forgetting to restart 
> cfexecd (or requiring an external framework to ensure that 
> it's working).
> 
> The requested feature is to allow locking of files on the 
> target host to prevent modifications while locked, which 
> would permit this kind of work
> flow:
> 
> 4. Work on target host:
>     lock config file
>     until correct:
>         edit config file
>         test config file
>     commit to repository
>     unlock config file
> 
> I envisage this as being implemented by a tool which adds, 
> removes or lists locks, even if just a flat list of files in 
> /var/cfengine somewhere.  Before cfagent initiates a copy: or 
> files: change (but after it has decided to), cfagent checks 
> for the lock and sends an alert if the file is locked but 
> skips modification.
> 
> Wil
> -- 
> Wil Cooley <wcooley@nakedape.cc>
> Naked Ape Consulting, Ltd
>