[Top][All Lists]

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

Re: Locking for temporary ad-hoc changes?

From: christian pearce
Subject: Re: Locking for temporary ad-hoc changes?
Date: Tue, 15 Nov 2005 22:21:55 -0500

Along the lines of making Cfengine bail if you are working on
something is what I propose.  But there are a few ways we can go about
it.  The quick and dirty is to make Cfengine some how stop doing what
it is doing all together.  What have we seen:

* Kill it, and this presume it isn't running from cron to restart.
* Have a wrapper script that checks for a file.
* Or if you properly architected your cfengine config which separates
the architecture from the policy.  (Maybe I will get a chance to
expand on this in an article)  Essentially all your policy should
either run based on belonging to a group.  If the group is true it
imports a file.  Lets take a look at an example:

address@hidden:~/.cfagent/inputs$ tail *
==> cfagent.conf <==

   actionsequence = ( shellcommands )


==> cf.local-wideload <==

   sudo = ( -${fqhost} )

==> <==

   cf_local_server = (
FileExists(/home/pearcec/.cfagent/inputs/cf.local-${fqhost}) )

   sudo = ( any )
   ssh = ( any )




==> cf.content <==



==> cf.ssh <==

   "/bin/echo ssh"

==> cf.sudo <==

   "/bin/echo sudo"
CFINPUTS=/home/pearcec/.cfagent/inputs/ cfagent -qI -f cfagent.conf -K
cfengine:: Executing script /bin/echo ssh...(timeout=0,uid=-1,gid=-1)
cfengine::/bin/echo ssh: ssh
cfengine:: Finished script /bin/echo ssh

So with this architecture.  You can put:

no_content = ( -${fqhost} )

in the cf.local-${fqhost} file.  Which turns off all policy (i.e., the
content) as a local modification to the execution of cfengine.  Or you
can choose which group you want to turn off locally.  Wil in your
example you might want to have group called apache.  And when you are
editing the file turn off the apache policy.  When you are done remove
the local modification.

See in you case you want to stop cfengine by preventing it from doing
what you are specifically concerned with.  In this case the apache
conf.  The way I look at it is I want Cfengine to stop with a distinct
set of policy.

On 11/3/05, Wil Cooley <address@hidden> wrote:
> One situation I come across all too often is the need to make ad-hoc
> changes on a system before pushing them through Subversion and back into
> proper place through cfengine.  Apache config files, for example,
> sometimes take a few tries to get just right.  My setups are not big or
> sophisticated enough to have real test servers, which is fine for the
> most part.
> What happens is that I'm editing my config file and cfagent makes its
> scheduled run, notices the file is changed and the replaces it.  I tend,
> as a result, to suspend my editor session while making changes so if it
> happens I can resume and rewrite my changed version.  What seems like it
> would be fairly straightforward to implement would be a user-initiated
> locking mechanism, so that a locked file would not be updated but an
> alert generated that the file was wrong date/checksum/etc.  Something
> like this:
> # cflock /etc/httpd/conf.d/foo.conf
> # vi /etc/httpd/conf.d/foo.conf
> # cflock -u /etc/httpd/conf.d/foo.conf
> (Maybe a 'cflock -l' to list locks would be useful too.)
> Of course, getting these changes back to my repo is also on my wishlist,
> but much bigger and less straightforward.
> Wil
> --
> Wil Cooley <address@hidden>
> Naked Ape Consulting, Ltd
> Version: GnuPG v1.4.1 (GNU/Linux)
> iD8DBQBDal9FJpn3uYWUEaoRAnNVAJ9A5X6oDI/fPmNCsQ2VvnwwT0peKgCdEkLq
> aKn7cBZ2O5GRT8FCthHSztw=
> =ZWZs
> _______________________________________________
> Help-cfengine mailing list
> address@hidden

Christian Pearce

reply via email to

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