Re: how do you combine cfengine and rcs/cvs/subversion?

[ebrown]

> Hello you all,
>
> I'm wondering how those of you feeding cfengine from a revision control
system have setup their config.
>
> (Reason: I'd like to set up one before I instruct my coworkers on
cfengine
> so we do it the right way just from the beginning :) )
>
> Especially I'm not sure how to set up the checkout mechanism. Do you
regularly scheduled checkouts into cfengine's publishing directory

Have a look at Luke Kanies' modules for managing CVS repositories with
cfengine at: http://madstop.com/
(Or the article Wil points to.)

We use a simple shellcommand to check out some CVS modules, including
cfengine config files, and at the risk of  complicating update.conf, we do
it there, before the copy of cfengine configs to the clients, so that
changes are immediately propagated.

update.conf (abbreviated):
---------------------------
control:
        actionsequence   = ( shellcommands copy )
        cf_dir           = ( /var/cfengine )

shellcommands:
   packageserver::
        "/bin/sh -c 'cd /packages && /usr/bin/cvs -Q -d /var/CVS co common
cvs-module-2 cvs-module-3'" inform=false
        # (The -Q and inform=false keep feedback to a min, w/o throwing
away all errors.)

                                                                                
                                      copy:
    /packages/common/cfengine  dest=$(cf_dir)
                               r=inf
                               mode=700
                               type=binary
                               ignore=CVS
                               server=packageserver
   # ( The 'ignore=CVS' avoids CVS directories in /var/cfengine. )
---------------------------

Here the CVS server resides on the packageserver.  Else the '-d' option in
the cvs command could refer to a remote CVS repository.

A CVS loginfo trigger runs cfagent on the packageserver, via sudo.  Commit
a change to a cfengine configuration file, and it is immediately applied
on the packageserver, and applied on clients the next time cfagent runs
there.  We also use a commitinfo trigger to check cfengine syntax before
allowing commits.  (Again having the CVS repository on the packageserver
facilitates both of these steps.)

I would not recommend checking out directly into the cfinputs directory on
the cfserver(packageserver in my previous usage), (or using the cfinputs
dir on the cfserver as the master  for other clients).  And if using a
Makefile, as Jamie suggests, a first and required target should be a cvs
diff, that aborts if what is in the working directory does not match what
is in the repository.  Otherwise, it is entirely possible to rsync changes
that have not been committed.  Even with this check, it is possible to
have committed changes that have not been rsync-ed.   In a multi-player
environment, this can easily happen, and you end up putting out changes
that someone else committed but did not rsync. Imho, it is better to know
that you have to commit a change for it to become effective, and that once
committed it is effective immediately.  Our changes always go to a QA
environment first, and are rsync-ed from there to production cfservers,
(not from the CVS repository) using a Makefile.


hth,
Ed