One of the strenghts of cfengine is the ability to administer computers based on a set of classes, for instance all Linux boxen should be treated one way and Solaris machines another way.

The official cfengine homepage can be found at

System administrators, rejoice! Cfengine, an open source project, synchronizes systems across platforms (even Windows), corrects errors as they occur, reports on security vulnerabilities, collects statistics, and finds "strange" behavior! Changes can be made on a server and automatically rolled out to each client.

cfengine is made of a few programs:

The Author

Mark Burgess, a professor at Oslo University, has presented several papers based on his development of cfengine: Cfengine: a system configuration engine, Cfengine: a site configuration engine, Strategies for distributed resource administration using cfengine, Adaptive locks for frequently scheduled tasks with unpredictable runtimes, Automated system administration with feedback regulation, Cfengine as a component of computer immune-systems, Computer immunology, Evaluating cfengine's immunity model, Scalability of peer configuration management in partially reliable and ad hoc networks, On the theory of system administration, Configurable immunity for evolving human-computer systems, Predictable configuration management in a randomized scheduling framework, Recent Developments in Cfengine, Two dimensional time-series for anomaly detection and regulation in adaptive systems, Probabilistic anomaly detection in distributed computer networks, and Principle components and importance ranking of distributed anomalies.

This guy's not playing around. Cfengine uses some advanced computer science techniques, like "SplayTime" to randomize when clients run so that they don't all overload the server, locking to guarantee that processes don't run too often, and cryptography. Because Mark Burgess has made cfengine a critical part of his research, cfengine has a lot of flexibility and power.


You tell cfengine what you want, and cfengine makes it happen. The difficult part about setting up cfengine is learning the extensive vocabulary and reading confusing documentation. In general terms, cfengine statements look like this:


Your program won't do anything unless it has the "control" action, with an "actionsequence" variable. A cfengine program with every action defined would have an actionsequence like so:

  actionsequence = (
	mountall mountinfo
	checktimezone netconfig resolve
	unmount packages shellcommands
	editfiles addmounts
	directories links
	mailcheck mountall required
	tidy disable files
	copy processes

Basically, each action listed in the actionsequence needs its own section, defining what to do for that action. Each action's syntax is defined in the cfengine Reference guide; see <>.


Cfengine defines some "classes" for you to describe the current state of the system. Here's a sample of the defined classes on a FreeBSD 5.1 machine:

% cfagent -v | grep Classes
Defined Classes = ( any cfengine_2_1_5 cfengine_2_1 cfengine_2 Sunday Hr01 Min44 Min40_45 Q3
 Hr01_Q3 Day15 August Yr2004 freebsd jedi_starwars_example_com starwars_example_com jedi 32_bit
 freebsd_5_2_1_RELEASE_p9 i386 freebsd_i386 freebsd_i386_5_2_1_RELEASE_p9
 compiled_on_freebsd5_2_1 net_iface_fxp0 net_iface_ )

cfenvd will give you access to some crazy standard deviation metrics about how the machine's operating currently compared to the past. Pulled from Burgess's Anomaly detection with cfenvd and cfenvgraph webpage, here are some example classes:


You can also define your own classes in the "groups" action.


Here's a sample file, for you learn-by-example people:

	actionsequence = ( resolve editfiles )
	EmptyResolvConf = ( true )

    private_network = ( jedi saber )
  # any:: is assumed if not stated # primary nameserver # secondary nameserver # tertiary nameserver

    { /etc/hosts
      AppendIfNoSuchLine ' localhost.localdomain localhost'
    { /etc/hosts
      AppendIfNoSuchLine ' secret-server'

The Filesystem

All cfengine's files are stored in /var/cfengine. There are two important subdirectories:

  • inputs: your configuration files
  • ppkeys: cryptographic keys

A typical cfagent/cfenvd session will first read /var/cfengine/inputs/update.conf and then read /var/cfengine/inputs/cfagent.conf. update.conf is supposed to stay stable, so that if you screw up cfagent.conf you can still download changes from your server and do the necessary initializations to get cfagent.conf to work. The "import" class lets you further divide your configuration files.

Command Line Options

When you run cfagent, you may be frustrated to find that your configuration files aren't actually being run. cfagent is designed to work without overloading your system even if cfagent were running constantly, so it has locks. Run it as so to make sure everything's executed:

cfagent -Kq

-K ignores locks; -q turns off "splay time." Even better, add the verbose option: cfagent -Kvq.

More Information

Luke Kanies's introduction to cfengine, as seen on O'Reilly's, is an excellent starting point. Find a link to his introduction and the official cfengine documentation at <>.

Personal experience.
