Cfengine3 bootstrap
Cfengine has been around for a
very long time. Its dependencies are minimal, its resources needs
minimal, its performance excellent. Version 2 of cfengine is well
documented, thoroughly discussed and described in numerous
tutorials. But v2 is also deprecated in favor of cfengine3. It so
happens v3 was a rewrite, and many things changed. There are a
few tutorials
on
v3 worth
mentioning, but they all describe deploying the policy host, and
little else.
I've been reading
"Automating
Linux and Unix System Administration" recently and the book covers
cfengine2 extensively. Authors describe a complete, extremely modular,
cfengine setup. I had problems wrapping my brain around methods for
doing the same in v3. After spending some time with
the cfengine
reference manual I finally had a solid basic policy for deploying
the policy host and clients. Which I want to share
here:
cf3-bootstrap.tar.bz2.
After installing cfengine with its workdir defined, let's say,
as /srv/cfengine, we can bootstrap the policy server:
# /usr/sbin/cf-key
# cd /srv/cfengine/
# tar -xvjf cf3-bootstrap.tar.bz2 ; rm -i $_
# cd masterfiles/
# cp /usr/share/doc/cfengine/cfengine_stdlib.cf cf-stdlib.cf
# emacs update.cf
# /usr/sbin/cf-agent --bootstrap
# /usr/sbin/cf-execd -v -F
The
cf-key will create the basic cfengine directory tree, and
will generate the hosts public and private keys (cfengine functions
somewhat like SSH in this regard). We edit the
update.cf. to
define our policy server, and its hostname. Other files will require
more edits for customization, but update bundle is all that is needed
for bootstrapping the policy host (and later pulling changes in
policy).
Method for bootstrapping a client is similar. We run
cf-key,
and we copy the
failsafe.cf and
update.cf files from
the policy host to
/srv/cfengine/inputs. Then
run
cf-agent from that directory to bootstrap, and
finally
cf-execd's initial run (which BTW configures a
cronjob for
cf-execd to be executed
periodically).
A few words about basic cfengine operation and policy. It is kept, and
modified in the
masterfiles directory. Remember, the policy
host also manages it self, which means it too copies the policy to
its
inputs directory, and it runs from there. Clients pull
the policy from the
masterfiles directory on your policy host
to their
inputs directory, from where they are acted
upon. The policy defines that our policy server runs
the
cf-serverd daemon, which acts as a file server for our
clients. First time the client contacts the server their keys will be
exchanged.
Example bundles I provided propose to keep the service configuration
files, and any other data for distribution in the
clientfiles directory. I am a long way from templating in
cfengine3, but the authors of the book I mention are willing to argue
distributing complete files is the
right way to do
things.
Now a few words about the policy I shared. I wanted a modular policy,
one that will easily scale from 3 servers to 23. Cfengine
configuration, and basic policy is in the
masterfiles
directory, I make use of the cfengine community library (distributed
with cfengine package), and I also maintain a site
specific
library.cf file. The
promises.cf file is
the main cfengine policy file, it imports all needed policy files, and
defines policies that should run on
all hosts. All
site specific policies are in the
site/
sub-directory. The main file
site.cf defines policies that
should run per host (or groups of hosts), and does nothing
else. Policies for daemons or anything else get their own file. I
included a few basic ones with examples. One with some example Apache
controls, one for editing
resolv.conf and one generic that pretends to run actions on
system users.
Where to take it from bootstrapping. First and foremost, policy should
be kept in revision control.
Git will do nicely. With several
cfengine policy hosts, controlling clusters or groups of machines, we
can think about masters of master servers. In that scenario the policy
hosts can pull their complete policies with
Git from the
master(s). Developing complex policies will take some time, but it's
worth investing your time. It will make your job better, but also be a
good prospect for the future. I don't remember seeing an ad for a
bigger shop that didn't require cfengine or
puppet
experience.