Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to CFEngine.
Nothing was collected or created yet.
CFEngine
View on Wikipediafrom Wikipedia
 | This article relies largely or entirely on a single source. (August 2014) |
CFEngine is a configuration management system, written by Mark Burgess. Its primary function is to provide automated configuration and maintenance of large-scale computer systems, including the unified management of servers, desktops, consumer and industrial devices, embedded network devices, mobile smartphones, and tablet computers.
Released under the terms of the GNU General Public License, CFEngine is free software.
History
[edit]The CFEngine project began in 1993 as a way for author Mark Burgess (then a post-doctoral fellow of the Royal Society at Oslo University, Norway) to get his work done by automating the management of a small group of workstations in the Department of Theoretical Physics. Burgess managed Unix workstations, scripting and fixing problems for users manually. Scripting took too much time, the flavours of Unix were significantly different, and scripts had to be maintained for multiple platforms, drowning in exception logic. After discussing the problems with a colleague, Burgess wrote the first version of CFEngine (the configuration engine) which was published as an internal report[4] and presented at the CERN computing conference. It gained significant attention from a wider community because it hid platform differences using a domain-specific language.
A year later, Burgess finished his post-doc but decided to stay in Oslo and took a job lecturing at Oslo University College. Here he realized that there was little or no research being done into configuration management, and he set about applying the principles of scientific modelling to understanding computer systems. He developed the notion of convergent operators, which remains a core of CFEngine.
In 1998 Burgess wrote "Computer Immunology", a paper at the USENIX/LISA98 conference.[5] It laid out a manifesto for creating self-healing systems, reiterated a few years later by IBM in their form of Autonomic Computing. This started a research effort which led to a major re-write, CFEngine 2, which added features for machine learning, anomaly detection and secure communications.
Between 1998 and 2004, CFEngine grew in adoption along with the popularity of Linux as a computing platform. During this time, Mark Burgess developed promise theory, a model of distributed cooperation for self-healing automation.[6][7] In 2008, after more than five years of research, CFEngine 3 was introduced, which incorporated promise theory as "a way to make CFEngine both simpler and more powerful at the same time", according to Burgess. The most significant re-write of the project to date, CFEngine 3 also integrated knowledge management and discovery mechanisms—allowing configuration management to scale to automate enterprise-class infrastructure.
In June 2008 the company CFEngine AS was formed as a collaboration between author Mark Burgess, Oslo University College and the Oslo Innovation Centre in order to support users of CFEngine. In April 2009, the company launched the first commercial version of CFEngine - CFEngine Enterprise. The Enterprise version can be downloaded for free for up to 25 agents (clients). February 2011, the company received its first round of funding, from FERD Capital.[8] The company has offices in Oslo, Norway and Mountain View, California, USA.
In 2017, the company changed its name to Northern.tech, to reflect that it is working on multiple software products, not only CFEngine.[9]
Design
[edit]One of the main ideas in CFEngine is that changes in computer configuration should be carried out in a convergent manner.[10][11] This means that each change operation made by the agent should have the character of a fixed point. Rather than describing the steps needed to make a change, CFEngine language describes the final state in which one wants to end up. The agent then ensures that the necessary steps are taken to end up in this "policy compliant state". Thus, CFEngine can be run again and again, whatever the initial state of a system, and it will end up with a predictable result. CFEngine supports the item of statistical compliance with policy, meaning that a system can never guarantee to be exactly in an ideal or desired state, rather one approaches (converges) towards the desired state by best-effort, at a rate that is determined by the ratio of the frequency of environmental change to the rate of CFEngine execution.[12]
CFEngine provides an operating system-independent interface to Unix-like host configuration. It requires some expert knowledge to deal with peculiarities of different operating systems, but has the power to perform maintenance actions across multiple hosts. CFEngine can be used on Windows hosts as well, and is widely used for managing large numbers of Unix hosts that run heterogeneous operating systems, e.g. Solaris, Linux, AIX, Tru64 and HP-UX.[citation needed]
Users
[edit]CFEngine is used in both large and small companies, as well as in many universities and governmental institutions.[citation needed] The largest reported datacenter under management of CFEngine is above a million servers, while sites as large as 40,000 machines are publicly reported (LinkedIn[13]), while sites of several thousand hosts running under CFEngine are common.[citation needed] According to statistics from CFEngine AS, probably several million computers run CFEngine around the world, and users from more than 100 countries have been registered.
Research
[edit]Shortly after its inception, CFEngine inspired a field of research into automated configuration management. The CFEngine project claims to attempt to place the problem of configuration management in a scientific framework. Its author Mark Burgess has developed a range of theoretical tools and results to talk about the problem, and has written several text books and monographs explaining them.[citation needed]
See also
[edit]
References
[edit]- ^ CFEngine Team & Community. "CFEngine 3.25.0 released". Northern.tech AS.
- ^ CFEngine Team & Community. "CFEngine 3.24.2 released". Northern.tech AS.
- ^ CFEngine Team & Community. "CFEngine 3.21.7 released". Northern.tech AS.
- ^ Burgess, Mark. "University of Oslo : Cfengine V2.0 : A network configuration tool" (PDF). Iu.hio.no. Archived from the original (PDF) on 2013-07-23. Retrieved 2013-09-08.
- ^ Burgess, Mark (December 1998). "Computer Immunology" (PDF). Usenix.org. Retrieved 2013-09-08.
- ^ Burgess, Mark; Couch, Alva (2006-11-28). "Autonomic Computing Approximated by Fixed-Point Promises, Proceedings of First IEEE International Workshop on Modelling Autonomic Communication Environments (MACE2006)" (PDF). pp. 197–222. Archived from the original (PDF) on 2012-04-25.
- ^ Hogg, Scott (July 1, 2014). "Promise Theory". Network World. Retrieved September 1, 2023.
- ^ "Cfengine Completes Series A Investment" (Press release). Oslo, Norway: PRNewswire. 2011-04-04. Retrieved 2014-08-22.
- ^ Ryd, Thomas (July 1, 2017). "Welcome to Northern.tech". Blog. Northern.tech. Retrieved 2024-07-28.
- ^ Burgess, Mark (Summer 1995). "Cfengine: a site configuration engine" (PDF). USENIX Computing Systems. 8 (3). Berkeley, CA, USA: USENIX. Retrieved 2014-08-22.
- ^ Burgess, Mark (2003-11-29). "Configurable immunity for evolving human-computer systems". Science of Computer Programming. 51 (3): 197–213. doi:10.1016/j.scico.2003.12.004.
- ^ Burgess, Mark (2003). "On the theory of system administration". Science of Computer Programming. 49 (1–3): 1–46. doi:10.1016/j.scico.2003.08.001.
- ^ "CFEngine Case Study - LinkedIn Infrastructure and Operations Automation at WebScale" (PDF). CFEngine AS. November 2014.
External links
[edit]CFEngine
View on Grokipediafrom Grokipedia
CFEngine is a lightweight, open-source configuration management system that automates the enforcement of desired system states across networks of computers, using a declarative policy language to handle configuration, compliance, and maintenance tasks.[1] Developed by British computer scientist Mark Burgess in 1993 while working at Oslo University College in Norway, it was initially created to simplify site administration in academic and large-scale environments, drawing on early concepts of autonomous agents and convergence to ensure systems self-repair toward defined policies without central orchestration.[2][3]
At its core, CFEngine operates through distributed agents installed on managed hosts, which periodically evaluate and apply policies defined in a high-level language, preventing configuration drift and enabling scalable operations for environments ranging from servers to cloud infrastructures.[4] This agent-based model, grounded in Promise Theory—a framework Burgess pioneered for modeling intentions and dependencies in distributed systems—emphasizes autonomy, lightweight execution (using mere megabytes of resources), and idempotent operations that converge systems to compliance without side effects.[5][4]
Over its evolution, CFEngine has influenced modern infrastructure-as-code practices, with major version 3 released in 2008 introducing enhanced knowledge management, machine learning for anomaly detection, and integration with CI/CD pipelines, while supporting features like patch management, security hardening, and reporting for standards such as STIG and CIS benchmarks.[2][4] The tool offers both a community edition under the GNU GPL and a commercial enterprise version with advanced dashboards and APIs, now maintained by Northern.tech, and has been adopted by organizations including LinkedIn, Pfizer, and the U.S. Department of Energy for managing hundreds of thousands of hosts reliably.[1][2] Its decentralized approach distinguishes it from more centralized tools like Puppet or Ansible, prioritizing speed, security, and resilience in heterogeneous, high-stakes settings.[4]
This structure promises that the file at
This body can then be referenced in a promise like
Introduction
Overview
CFEngine is a declarative configuration management system designed for automating the maintenance of large-scale computer systems, including servers, desktops, embedded devices, and IoT hardware.[6] It functions as a distributed agent-based tool that enables policy-based automation, ensuring systems idempotently converge to a desired state by continuously verifying and enforcing compliance with predefined policies.[7] The scope of CFEngine encompasses heterogeneous environments, supporting a wide range of platforms such as Unix-like systems (e.g., Linux, Solaris, AIX), Windows, macOS, BSD variants, embedded devices, IoT hardware, cloud infrastructures, and mainframes.[8] It scales efficiently from individual machines to enterprise deployments managing over 100,000 nodes, providing robust automation without centralized bottlenecks.[7] Written in the C programming language, CFEngine emphasizes high performance and portability across diverse architectures and operating systems.[9] Its foundational approach draws from Promise Theory, which models voluntary cooperation among autonomous agents in distributed systems.[5]Licensing and Availability
CFEngine is licensed under the GNU General Public License version 3 (GPL v3), which has governed its community edition since the release of version 3 in 2008.[10][11] This open-source license allows users to freely use, modify, and distribute the software, subject to the terms of the GPL v3, fostering community contributions to its development.[12] The software is available as free software through official repositories on GitHub and direct source code downloads from the CFEngine website.[13][14] Users can access the community edition without cost, enabling deployment on Linux systems with community-driven support.[12] Commercial support and an enterprise edition with additional features, such as enhanced APIs and dashboards, are provided by Northern.tech, the company formerly known as CFEngine AS, which rebranded in 2017 to reflect its broader portfolio of software products.[1][14] The enterprise edition operates under a separate commercial license, offering extended verification and support options.[11] LTS releases are supported for 3 years with commercial options, while non-LTS releases are supported for 6 months in the community edition.[8] As of November 2025, the latest stable releases include version 3.26.0 (released May 20, 2025, non-LTS), 3.25.0 (released January 6, 2025), 3.24.2 (LTS, updated May 15, 2025), and 3.21.7 (updated May 15, 2025), with the latter updates addressing bug fixes and dependencies.[15][16][17] Downloads, documentation, and further details are hosted on the official websites cfengine.com and northern.tech.[1][18]History
Origins
CFEngine was created in 1993 by Mark Burgess while he was at Oslo University College in Norway, emerging as a response to the growing challenges of managing distributed systems in expanding computer networks.[19] At the time, the proliferation of TCP/IP networks and affordable UNIX-like systems had led to large-scale deployments of machines, overwhelming traditional manual or script-based administration methods that proved inefficient for heterogeneous environments.[20] The primary motivation behind its development was to provide a lightweight, high-level policy language for automating configuration and maintenance tasks, particularly in resource-constrained academic settings where heavy dependencies or complex tools were impractical.[20] Burgess aimed to enable convergent maintenance—ensuring systems self-correct to a desired state—without relying on centralized control or extensive infrastructure, making it suitable for Unix-based computer labs with diverse hardware and software variations.[21] This approach addressed the need for standardization and automation in site-wide administration, reducing the burden on administrators handling hundreds of machines.[20] The initial release occurred in 1993, focusing on basic automation for Unix systems through a simple, declarative syntax that emphasized idempotent operations and minimal resource use.[19] Early testing took place at Oslo University, where it was introduced as a cross-platform tool for documenting and enforcing desired system states.[19] Early adoption occurred primarily in research and academic environments, where it was used to manage diverse computer labs by simplifying the configuration of networked Unix machines and ensuring consistency across installations. In 1995, CFEngine was released under the GNU project, facilitating broader open-source distribution.[20] By the mid-1990s, it had gained traction at over 20 sites worldwide, including university networks, demonstrating its utility in handling the administrative demands of growing computational resources without introducing additional complexity.[20]Development Milestones
Following the initial development of CFEngine, version 2.0 was released in March 2002, introducing significant enhancements in security and efficiency, including mutual authentication of all network connections using public key cryptography and a new secure file distribution server (cfservd).[22] This version also rationalized the program's structure, enabling more reliable management of distributed systems without relying on insecure protocols like rsh.[22] In 2008, CFEngine 3 was announced as a major rewrite, emphasizing advanced autonomy through the integration of Promise Theory, a conceptual framework for self-healing and intent-based configuration management.[2] The full release followed in April 2009, incorporating simplified policy definitions and improved scalability for large-scale deployments, with machine learning techniques for modeling and adapting to system behaviors added in subsequent iterations.[23] To support ongoing development and commercialization, CFEngine AS was founded in June 2008 as a collaboration involving creator Mark Burgess and partners in Norway, providing professional backing for the open-source project while expanding enterprise offerings.[24] In 2017, the company rebranded to Northern.tech, broadening its scope beyond core configuration management to encompass comprehensive IT automation and device lifecycle solutions.[25] Recent advancements include the introduction of CFEngine Build in November 2021, a command-line tool (cfbs) that facilitates the creation, sharing, and assembly of reusable policy modules to streamline collaborative policy development.[26] Development has continued with regular updates, including version 3.26.0 in May 2025 adding admin improvements such as default admin elimination, and the LTS version 3.27.0 released in November 2025, introducing audit logging and other enhancements as of November 2025.[27][17][28]Design Principles
Core Concepts
CFEngine operates on a declarative paradigm, where policies articulate the desired end states of systems rather than prescribing sequential, imperative procedures. This approach enables administrators to specify outcomes—such as ensuring specific software versions are installed or files maintain certain permissions—without detailing the exact steps to achieve them. The CFEngine policy language, a domain-specific language (DSL), facilitates this by allowing configurations to be defined in human-readable text files, typically stored on policy hubs and distributed to agents.[7] Central to CFEngine's design is the convergence principle, which ensures that system actions are idempotent, meaning repeated executions yield the same result without unintended over-corrections. Agents evaluate policies and repair deviations to align the actual state with the promised desired state, categorizing outcomes as "promise kept," "promise repaired," or "promise not kept." This self-healing mechanism promotes stability, as the system continuously verifies compliance and intervenes only when necessary, fostering a persistent convergence toward policy adherence.[7][6] CFEngine emphasizes autonomy and decentralization, allowing agents to operate independently without reliance on a central server for ongoing management. Each host interprets and enforces policies locally, enabling resilience even if connectivity to policy hubs is intermittent. Complementing this is opportunistic execution, which minimizes resource consumption by scheduling agent runs—defaulting to every five minutes but adjustable with features like execution splaying to avoid simultaneous loads. Promises serve as the fundamental building blocks for these policies, organized into bundles for modularity.[7][6]Architecture
CFEngine employs an agent-based model where the primary component, cf-agent, operates as a lightweight, autonomous process running locally on each managed host to enforce and maintain system policies. This distributed approach ensures that configuration management occurs independently on individual nodes without reliance on a centralized controller, allowing for self-healing and adaptive behavior across the infrastructure. The cf-agent, implemented in C for efficiency, periodically evaluates the system's state against defined promises and makes necessary adjustments to achieve compliance.[29][7] The operational model of CFEngine is structured around a four-phase execution cycle that supports systematic policy handling and enforcement. In the Build phase, administrators construct policy templates that define the desired system states. The Deploy phase involves distributing these policies from designated policy hubs to the agents on target hosts, typically via secure file transfers. During the Manage phase, cf-agent executes the policies locally, converging the system toward the intended configuration through iterative corrections, a process that emphasizes idempotence and minimal disruption. Finally, the Audit phase enables continuous verification, where agents report on compliance and deviations, facilitating ongoing monitoring without interrupting operations.[30][7] CFEngine's architecture is designed for fault tolerance, operating effectively even in unreliable environments by minimizing dependencies on external services or stable networks. Agents can function offline using cached policies if connectivity to hubs is lost, preventing single points of failure and enabling scalability to over 100,000 servers in large deployments. This resilience is achieved through opportunistic networking and local autonomy, ensuring that the system remains operational under varying conditions.[7][30] The framework integrates seamlessly with heterogeneous operating systems, including Unix-like systems, Windows, macOS, Linux, and BSD, using TCP/IP protocols for communication while maintaining independence from specific network topologies and process dependencies.[31] This allows cf-agent to isolate its operations on each host, handling diverse hardware and software configurations without custom adaptations for individual setups. Such portability extends to non-traditional platforms, including embedded systems, underscoring the architecture's emphasis on universality and isolation.[30][7]Implementation
Policy Language
CFEngine's policy language is a declarative domain-specific language designed for specifying the desired state of systems and infrastructure, enabling automation through high-level promises rather than imperative scripts. Policies are written in plain text files, conventionally using the.cf extension, and are typically stored in directories like /var/cfengine/inputs for execution by the CFEngine agent.[32] These files leverage bundles as the primary organizational unit, grouping related promises—declarations of intent—into modular, reusable blocks that define actions such as file management, package installation, or service configuration.[33] Promises serve as the core primitives of the language, expressing verifiable commitments about system states.[33]
The basic syntax revolves around bundle definitions, which specify an agent type (e.g., agent for enforcement) and an identifier, enclosing a series of promise types within curly braces. For instance, file management promises use the files: promise type to ensure a file's existence and content, as in the following example:
bundle agent example
{
files:
"/path/to/file"
content => "desired content";
}
bundle agent example
{
files:
"/path/to/file"
content => "desired content";
}
/path/to/file contains the specified text, creating or editing it as needed.[34] Attributes within promises, such as content =>, use the arrow operator (=>) to assign values, which can be literals, lists, or references to other elements.[33]
Key elements enhance the language's expressiveness and flexibility. Variables are defined using the vars: promise type and referenced with $(variable_name) for substitution, allowing dynamic policy adaptation based on context, such as host-specific paths.[34] Functions, like execresult("/bin/command"), execute external commands and return results for use in policies, supporting integration with system tools.[34] Classes provide conditional logic as boolean qualifiers (e.g., linux:: or custom any::), guarding promises to apply only under specific conditions like operating system or runtime state.[32] Bodies offer reusable customization blocks for promise attributes; for example:
body edit_defaults custom_backup
{
edit_backup => "timestamp";
}
body edit_defaults custom_backup
{
edit_backup => "timestamp";
}
files: "/etc/config" edit_defaults => custom_backup;, tailoring behaviors such as backups during edits.[33]
For readability and maintainability, CFEngine policies follow recommended style guidelines. Indentation uses two spaces per nesting level, starting from bundle definitions, promise types, and attributes, while curly braces for top-level blocks (bundles, bodies, promises) appear on new lines with content indented inside.[35] Naming conventions favor snake_case for identifiers (e.g., service_name), though alternatives like PascalCase are permissible, and promises are ordered either in normal agent evaluation sequence or reader-optimized logical flow, with blank lines separating promise types.[35] These practices ensure policies remain concise and human-readable, facilitating collaborative development.[35]
Deployment and Execution
CFEngine can be installed on supported platforms using pre-compiled packages or by compiling from source code. For Debian-based systems like Ubuntu, the Community Edition is available via the Advanced Package Tool (APT); administrators add the CFEngine repository to sources.list and install the cfengine-community package with commands such assudo apt update && sudo apt install cfengine-community.[36] This installs the core binaries, including cf-agent, the primary agent for policy evaluation and system changes.[29] For compilation from source, users download tarballs from the official repository and follow the build instructions in the INSTALL file, requiring prerequisites like a C compiler and libraries such as libcurl and libpcre.[14] Enterprise editions use deb or rpm packages like cfengine-nova-hub for policy servers, installed similarly via APT or YUM, followed by bootstrapping the server to itself using cf-agent --bootstrap <IP>.[37]
Policy execution begins with cf-agent, which evaluates and enforces promises defined in policy files. In standalone mode, administrators run cf-agent -Kf policy.cf to execute a specific file without locks, where -K prevents time-based locking and -f specifies the input file; verbose output can be enabled with --verbose for debugging.[32] For automated enforcement, cf-execd daemon schedules cf-agent runs every 5 minutes by default, invoking promises.cf from the /var/cfengine/inputs directory unless overridden. Policies are distributed securely across hosts using cf-serverd, a TLS-enabled daemon that serves files from /var/cfengine/masterfiles on the policy server; clients request updates via cf-agent, with access controlled by role-based promises in access control lists.[38] The inputs mechanism, defined in files like inputs.cf or def.json, lists external policy files (e.g., "promises.cf") for inclusion and automatic distribution to clients during updates.[32]
Monitoring and auditing integrate with execution to track compliance and system state. The cf-monitord daemon collects metrics through measurements promises, sampling variables like CPU load, disk usage, and network activity to establish baselines and detect anomalies, storing data in /var/cfengine/state for use in policy decisions.[39] For auditing, cf-report processes this stored data to generate human-readable outputs, such as compliance summaries or environmental graphs, merging historical observations from cf-monitord databases to verify promise fulfillment over time.[40] During execution, cf-agent achieves convergence by iteratively applying changes until the system's state matches policy intentions, ensuring idempotent enforcement.[29]