Comparison of open-source configuration management software

This is a comparison of free (libre) and open source configuration management software.

Basic properties

	Programming language	Software license	First public release date	Latest stable version
Arusha	Python	BSD	July 21, 2001 [1]	20050419 (April 19, 2005)
Bcfg2	Python	2-clause BSD-style	August 11, 2004 [2]	0.9.2 (February 19, 2007)
Cfengine	C	GPL	1993	2.1.22 (January 27, 2007)
ISconf	Python	GPL [3]	1998	4.2.8.222 (August 13, 2006)
LCFG	Perl	GPL	?	2007021901c (February 19, 2007)
PCfengine	Python	GPL [4]	No public release yet	No public release yet
PIKT	C	GPL [5]	Before 2000? [6]	1.18.2 (November 5, 2006)
Puppet	Ruby	GPL	August 30, 2005 [7]	0.22.1 (February 1, 2007)
Quattor	Perl	Open Source EU Data Grid software license	1.0 on April 1st, 2005 [8]	1.2 (February 7, 2007)
Radmind	C	BSD-Style license	March 26, 2002	1.7.1 (November 29, 2006)
SmartFrog	Java	LGPL	?	?

Short description

Not all tools have the same goal and the same feature set. To help distinguish between all of these software, here is an objective short description of each one.

Bcfg2

Software to manage the configuration of a large number of computers using a central configuration model and the client-server paradigm. Compared to Cfengine, the system enables reconciliation between clients' state and the central configuration specification, Detailed reports provide a way to identify unmanaged configuration on hosts. Generators enable code or template based generation of configuration files from a central data repository.

Cfengine

The veteran of open source configuration management software. Manages configuration of a large number of computers using the client-server paradigm. The server has the authoritative version of configuration: any client state which is different from the server is always reverted to the authoritative version. Configuration state is specified via a declarative language.

ISconf

Tool to execute commands and replicate files on all nodes. Unlike ClusterSSH, the nodes need not to be up; the commands will be executed when they boot. The system has no central server so commands can be launched from any node and they will replicate to all nodes.

SmartFrog

Java-based tool to deploy and configure applications distributed across multiple machines. There is no central server; you can deploy a .SF configuration file to any node and have it distributed to peer nodes according to the distribution information contained inside the deployment descriptor itself.

Discussion

Not all tools are ideal for all jobs. Here are some strong and weak points of each one.

ISconf

ISconf is controversial in its treatment of preconditions and postconditions of actions. Some tools, such as Bcfg2 and Puppet, require explicit descriptions of preconditions to hold before they apply an action, and further require an explicit description of postconditions, to be used by subsequent actions. Together, these have been called closure. Couch, Hart, Idhaw, Kallas Other tools, such as cfengine, don't make explicit the preconditions, but require their actions to be idempotent; thus an action may fail, but it keeps getting applied until some other action supplies the precondition, and then it succeeds - and keeps succeeding. These tools rely on convergence. Burgess ISconf differs in that it places no restriction on the nature of the action to be taken, nor any description of preconditions, but it requires that actions be applied to a known labeled state (e.g., a pristine OS install or system image), which after the action becomes a distinct state known only by its label; actions are always applied in identical order. This permits a theoretically perfect replicability. Traugott, Brown In practice, this model deals well with the often non-idempotent actions of package installation, but it can be expensive: actions either incorporate all the initial errors of the learning done by the sysadmin in creating a change, or the learning environment must be reimaged to a known prior state before the perfected performance of the action gets recorded; further, either any action performed with the machine whatsoever must be called an action and recorded, or actions must be accurately divided into either significant system actions and recorded, or else those concerning "only business data". An illustration of the difficulty: does a user account constitute significant system state or mere "business data"?