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: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > Naked Ape Consulting, Ltd > _______________________________________________ Help-cfengine mailing list Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine
