Conceptual basis

A modern operating system is not like a PC, it more like a society of PC's in which there are many independent parts which cooperate in order to achieve the whole. In many ways, modern operating systems and networks have developed together and there are many parallels. Computer networks have no choice but to use this model in order to function. Operating systems are best served by this model because it leads to a clean object orientation and a better sharing of resources. It is a fundamental mechanism by which distributed systems work.

Cfengine is a language based system written by Mark Burgess, specifically designed for testing and configuring software. You can think of cfengine as a very high level language --- much higher level than Perl or shell. A single statement can result in many hundreds of links being created, or the permissions of many hundreds of files being set. The idea of cfengine is to create a single file or set of configuration files which will describe the setup of every host on your network. Cfengine runs on every host and parses one file (or file-set), which specifies a policy for configuration of the system; the configuration of the host is checked against this model and, if necessary, any deviations are fixed.

Although intended to be a scheme for system administation to be run by the superuser, cfengine can also be used a scripting language by ordinary users. It is a handy tool for tidying your old junk files and for managing the rights and permissions of your files when collaborating with other users.

When you start out from a small network with just a few workstations, or perhaps even a single mainframe system, it is quite easy to get into the habit of `fixing' the configuration of your system manually, making links, writing scripts etc. When the size of a network increases, before you know it you have five different types of UNIX from different vendors and each type of system has to be configured in a special way. You realize also pretty soon that UNIX is not as standard as you thought and that none of your scripts work on every system without a considerable amount of hacking and testing. The number of if..then..else.. constructions in your scripts grows to be so large that you can't really see what the script is doing anymore.

For large systems with many different flavours of operating system, what is needed is a more disciplined way of making changes which is robust against reinstallation. After all, if you suddenly have to replace a damaged disk then all of your manually placed symbolic links will have to be made from scratch!

The idea behind cfengine is to focus upon a few key areas of basic system administration and provide a language which removes all of the if..then...else clutter from scripts, by providing a declarative language, so that the transparency of a configuration program is optimal and management and implementation are kept separate.

Because it is almost impossible to do everything, cfengine focusses on a few key functions which are handled rather poorly from scripts. It eliminates the need for lots of tests by allowing you to organize your network according to classes. From a single configuration file (or set of files) you specify, using classes, how your network should be configured -- and cfengine will then parse your file and carry out the instructions, warning or fixing errors as it goes.

Here are some of the primitives which can be automated:

Read more in the user manual, or in the technical papers.


Cfengine is the result of a continuing research project, started in 1993, to help solve the problems of system administration in a big network. Cfengine is a tool for building expert systems with a declarative language, and it is a workhorse-robot or agent.

Many people have contributed their experiences and wisdom to the cfengine project. I apologise for not being able to mention everyone here. Morten Hanshaugen and Hans Petter Holen made it possible to test cfengine on a variety of systems at the university of Oslo. I am grateful to Knut Borge for his experience and suggestions on many occaision. Ola Borrebaek and Richard Stallman have made key observations which have influenced the development of cfengine in important ways. Audun Tørnquist did some initial work on the `copy' feature and donated the backup help-script to the distribution. Gord Matzigkeit contributed an early autoconf setup. Andrew Ford contributed the self-documentation perl script. Ricky Ralston (Hewlett Packard) provided invaluable information on HPUX-10 and discovered a number of bugs and inaccuracies in the source code: our collaboration on making 1.3.0 the definitive system administration tool (before 1.4.0!) has been invaluable. David Masterson continues to provide me with the results of detailed tests and new auto configuration improvements. Brian White maintains the Debian linux package and has been helpful with bug reports. Rolf Ebert contributed the emacs cfengine mode file. Max Okumoto ran the source code through `insight' and found lots of accidentals. Sergio Tessaris has done lots of testing and bug tracking. I am grateful to Ann-Mari Torvatn and Len Tower for reading through and helping to improve the documentation. Finally, Demosthenes Skipitaris and I added the new adaptive locks to cfengine 1.4.0. Stuart Sharpe performed the hard work of prototyping the old K&R C code in version 1.6.0. Jørgen Kjensli and Bjørn Gustafson wrote the initial NT specific code, under Mark's supervision. Martin Andrews (netgenics) contributed many several detailed patches and performed detailed testing on NT. Denis DerSarkisian from contributed several patches for the mount protocol in 1.6.0.

If you have made a contribution which I have forgotten to mention, please jog my memory!