help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Locking for temporary ad-hoc changes?


From: Wil Cooley
Subject: RE: Locking for temporary ad-hoc changes?
Date: Fri, 04 Nov 2005 13:46:13 -0800

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

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]