Configuration management is the term used to describe the most automated and uniform management of systems possible with standardized tools. By means of special configuration languages, you feed your tool of choice instructions designed to convert target systems to the desired state and keep them there, taking the burden of implementing system management off the system administrator's shoulders.

Installing and configuring software, starting processes and services, creating users and groups, setting file permissions – the system administrator defines all these tasks once only and then lets the tool do the work. If a system deviates from the defined standard, configuration management straightens it out again. In this way, even small teams can automate the process of managing large system landscapes.

The most frequently used automation tools of this type include the well-known solutions Puppet and Chef, as well as Ansible, SaltStack, and, to a certain extent, Terraform. CFEngine 3 is less well known, although its predecessor was considered the first of a genre.

Credit Where Credit Is Due

For a long time, system administrators wrote scripts to manage a large number of systems uniformly. CFEngine was the first to set the principle of centralized and standardized configuration in stone as a software product. As early as 1993, Mark Burgess at the University of Oslo described CFEngine as a tool that enabled the administration of numerous systems with the help of an abstraction and a kind of configuration language. Growing use eventually resulted in the far more mature version 2 in 2002, which because of its reliability is still in use in some companies today.

As with other open source projects, the CFEngine project became increasingly commercialized with wider enterprise use, leading to the formation of a support and consulting services company in 2008. One year later, CFEngine 3 [1] was released, partially abandoning backward compatibility with its predecessor and available for the first time in a community edition and in an enterprise edition that focuses on enterprise customers with features such as reporting and a web interface. However, the free version also contains all the important functions for daily configuration management. The commercial edition is made more palatable because you can try out the software and manage up to 25 systems free of charge.

Design Principles

The CFEngine design is based on several principles that run like a thread through the structure and use of the tool. The system administrator uses a declarative approach to define the desired end state of a system in a configuration language. How this is achieved is usually not given in detail. The instructions are deposited on a central system from which the computers to be configured can themselves download the latest versions (pull principle).

CFEngine automatically executes all necessary steps locally, thereby abstracting (i.e., converting) the concrete instructions for the system description at the command line. An example of a command would be something like: Make sure the Nginx web server is installed and started. The maintainer does not have to give a specific command like yum install nginx because CFEngine maintains a library of commands for each supported operating system, which it uses automatically when implementing the instructions.

Promises

The most important principle of CFEngine is the Promise Theory [2] and is intended to solve the problem of system administrators not always being sure whether a target system is currently in the desired state. When in doubt, the admin feels compelled to log in manually to view the state and correct it if necessary. After some time, repeating this time-consuming undertaking becomes a real risk: Other users could have (involuntarily) changed the system so that it no longer reliably fulfills its original purpose.

The Promise Theory model now describes how this permanent uncertainty can be resolved efficiently by equipping each system with an agent that is controlled by a central server and from which it obtains instructions, or promises . According to the creators of the software, pretty much everything in CFEngine 3 is a promise. A promise means that an autonomous system announces its intention to change itself into the desired state on the basis of the instructions received – even if, for example, the central server with the instructions cannot be reached at the moment. Of course, the promise does not contain a certainty of success, but only the intention to get as close as possible to the desired state (if necessary, after several iterations).

What sounds quite weird at first has tangible benefits. In addition to the description of the state, the system administrator can store instructions on what should happen if the desired state is not in place at the moment or cannot even be achieved in principle. In the best case, the CFEngine agent repairs the system and restores the desired state. In the worst case, it cannot sort out the system and resorts to the instructions the administrator has stored for such cases.