Intro to Automating System Administration with Cfengine 3

As an organization adds more and more hosts, both physical and virtual, its system administrators must spend more and more time ensuring that all hosts comply with policy. This results in an explosive demand in staff resources. Organizations can often find themselves constantly falling behind, never able to finish projects on time or neglecting less visible infrastructure in order to deliver other highly visible projects.

If you’re completely new to Cfengine, you might want to check out a bit of background articles before you dive into complex configuration scripts.

• Gentlemen, Start your Cfengine
• Managing Servers with Cfengine

Otherwise, let’s get started.

Cfengine allows system administrators to control servers from a central location. Administrators are able to make a single manual change and have that change automatically deployed to all desired hosts across the network. Cfengine continuously ensures that these changes are applied. This can save an organization time and money.

Cfengine has been around since 1993. It now on version 3. Cfengine is open source but also has a professional services company. Cfengine also has a commercial version which offers additional features.

In practice, Cfengine runs at periodic intervals. After each run, we can expect the system to be at the desired configured state or to move closer to it. A single run does not guarantee 100% implementation of policy as there might be dependencies. For example, let’s say you have policies that SNMP package needs to be installed and SNMP daemon needs to be up and accepting connections. One the first pass, Cfengine may install the SNMP package, on the next pass, it will start the daemon. Cfengine can report the percentage of its promises that it was able to keep.

Cfengine is a powerful and sophisticated tool compromising of 7 programs. However, you don’t need to know all 7 to start using Cfengine. You only need two: cf-agent and cf-execd.

Special Agent cf-agent is your field operative. This is what actually makes changes on a system.

Continuing our secret agent analogy, cf-execd is the handler. It fires off cf-agent and collects and collates its output, emailing it or sending to syslog.

Another component worth immediate mention is cf-serverd. Cf-serverd is able to share files, including Cfengine policies. It allows you to make a policy change in one place and have all your nodes automatically pick up the new policy from cf-serverd.

Alternatively, all your nodes can run cf-serverd to receive requests to execute their own local copy of the policy. If you want to tell all your nodes to do something, put it in the shared policy file, have the nodes download it (if they are configured to do so), and then “poke” them with cf-runagent which connects to cf-serverd and requests it execute cf-agent with its current policy. This is an implementation of a policy “push” in an environment of voluntary cooperation.

Cfengine’s work space directory is /var/cfengine when running as root, or ~/.cfagent when running as a mortal user.

At the time of this writing very few Linux or UNIX distributions have pre-made Cfengine version 3 package ready for installation. As such you must be prepared to do it yourself.

The source tar ball is available at the Cfengine website.

cd ~/src
wget http://www.cfengine.org/tarballs/cfengine-3.0.4.tar.gz

Naturally you’ll need the standard tools for building a C program including a C compiler and a make program, such as GNU Make. You’ll also need:

• OpenSSL
• BerkeleyDB
• flex
• bison
• Perl Compatible Regular Expressions or PCRE library.

If your distribution uses RPM’s you may need to install the ‘devel’ RPM’s such as ‘openssl-devel’.

Cfengine will run on virtually any UNIX platform. The commercial version even offers native Windows binaries. In this example we’ll be using a Linux host. First configure the make file.

neil@ettin:~/src/cfengine-3.0.4$ ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
...
DONE: Configuration done. Run make/gmake to build cfengine.

Now run make. The default install prefix is /usr/local. You can change it if you like, ./configure –help will give you information how to change the prefix. Before you decide see the installation section below.

neil@ettin:~/src/cfengine-3.0.4$ make -j5
Making all in pub
make[1]: Entering directory `/home/neil/src/cfengine-3.0.4/pub'
make[1]: Entering directory `/home/neil/src/cfengine-3.0.4'
...
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/home/neil/src/cfengine-3.0.4'

Now check the build by running ‘make check’. You could also use the ‘-j’ option here.

neil@ettin:~/src/cfengine-3.0.4$ make check
Making check in pub
make[1]: Entering directory `/home/neil/src/cfengine-3.0.4/pub'
....
make[1]: Leaving directory `/home/neil/src/cfengine-3.0.4'

If there are no errors (exit status 0) you should be ready for one more test. Next, test to see that PCRE regular expression support is compiled into the binary. This is a good check as it is hard to tell from configure whether or not this was successful.

neil@ettin:~/src/cfengine-3.0.4$ src/cf-promises -x
----------------------------------------------------------
Cfengine 3 - Performing level 2 self-diagnostic (dialogue)
----------------------------------------------------------

1. Test variable scanning
2. Testing promise duplication and expansion
3. Testing variable expansion
4. Testing regular expression engine
 -> Regex engine is the Perl Compatible Regular Expression library
 -> Regular expression compilation - ok
 -> Regular expression extraction - ok 15 - 31
 -> Regular expression extraction - ok
 -> FullTextMatch - ok 2
 -> BlockTextMatch - ok
 -> BlockTextMatch - ok
5. Testing promise attribute completeness
 !! files promise makes no intention about system state
I: Promise is made internally by cfengine
 -> All non-listed items are accounted for