This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)(Learn how and when to remove this template message)
|Original author(s)||Nico Schottelius, Steven Armstrong|
4.10.6 / 15 February 2019
|Written in||Python, Bourne shell|
|Operating system||Linux, Unix-like|
|Type||software configuration management|
|License||GNU General Public License version 3 or later|
cdist is a free software configuration management system with is generally used to setup, configure and update software on a linux or unix-like computer system. It declares itself to adhere to the KISS principle. It manages nodes over SSH and requires only Bourne Shell to be installed on them and no agents (software required for some configuration management system to operate) are installed on nodes.
Types (pieces of code, describing intended state of node) are written in Bourne Shell. The system uses usual shell scripts and functions to express reusable descriptions of systems. The core of software, that manages ordering and executing code on nodes is written in Python, so controlling computer need to have installed Python version 3.2 or later.
cdist development started in 2010 at ETH Zurich and is actively being developed by a lot of free and open-source software contributors and maintained by the two main developers Nico Schottelius and Steven Armstrong. The major part of the discussion about cdist happens on the mailinglist and on the IRC channel #cstar in the Freenode network. cdist is being used at various companies in Switzerland (for instance at ETH Zurich and The OMA Browser project), the US, Germany and France.
cdist is a zero dependency configuration management system: It requires only ssh and a bourne-compatible shell on the target host, which is usually enabled on all Unix-like machines. Because of this, cdist can be used to bootstrap other configuration management systems.
Installation and configuration
cdist is not installed traditionally as a package (like .deb or .rpm), but installed via git. All commands are run from the created checkout. The entry point for any configuration is the shell script conf/manifest/init, which is called initial manifest in cdist terms.
The main components of cdist are so called types, which bundle functionality. The types essentially consists of a number of shell scripts to define which types a type reuses and which code is generated to be executed on the target host.
cdist is split into two components:
- The core
- The configuration
The core of cdist is implemented in Python 3 and provides the executables to configure target hosts. The core operates in a push model: It connects from the source host to the target hosts and configures the machines. For communication and file transfer SSH is being used. To allow parallel configuration of hosts, the core supports a parallel mode in which it creates a child process for every connection. This model allows cdist to scale horizontally with the available computing resources: If at a certain limit is reached and the capacity of the available CPUs has been used, adding another CPU or distributing cdist to multiple hosts allows to configure more hosts in parallel.
The configuration is written in Bourne Shell and consists of
- The initial manifest (which defines which host is assigned which types)
- Global Explorers (to gain information about the target system)
- Types (which provide all functionality and consist of a manifest, type explorers and gencode scripts)
Although all of these are written in Shell script, the order of execution in the manifests does not matter: cdist employs an idempotent configuration.
In comparison to most other configuration management software, cdist does not have any requirements on the target host besides SSH and a bourne shell. It requires Python 3.2 on the source host, though. cdist operates in push based approach, in which a server pushes configurations to the client and the clients do not poll for updates.
All user configurable parts are contained in manifests or gencode-scripts, which are shell scripts. Shell scripts were chosen, because Unix System Administrators are usually proficient in reading and writing shell scripts. Furthermore, shell is also commonly available on potential target systems, thus avoiding the need to install additional software there ("zero dependencies").
cdist reads its configuration from the initial manifest (conf/manifest/init), in which hosts are mapped to types:
case "$__target_host" in myhostname) __package zsh --state present __addifnosuchline /tmp/cdist-welcome --line "Welcome to cdist" ;; esac
When using the types in cdist, they are called like normal programs in manifests and can make use of advanced parameter parsing as well as reading from stdin:
# Provide a default file, but let the user change it __file /home/frodo/.bashrc --source "/etc/skel/.bashrc" \ --state exists \ --owner frodo --mode 0600 # Take file content from stdin __file /tmp/whatever --owner root --group root --mode 644 --source - << DONE Here goes the content for /tmp/whatever DONE
Dependencies are expressed by setting up the require environment variable:
__directory /tmp/foobar require="__directory//tmp/foobar" __file /tmp/foobar/baz
Access to paths and files within types is given by environment variables like $__object.
Ansible takes a similar approach to cdist running from a central machine to manage remote nodes, however Ansible normally requires Python on the managed target, which cdist does not. Ansible does have some methods for bootstrapping a Python install or working without it using the raw module.
- Sharma, Rishabh; Soni, Mitesh (15 March 2015). Learning Chef. Packt. pp. 10, 17–18. ISBN 978-1783285211.
- "cdist: Why we require Python 3.2 on the source host". Nico.schottelius.org. Archived from the original on 2016-03-13. Retrieved 2016-04-10.
- [dead link]
- "ungleich/cdist: cdist configuration management". GitHub.com. Archived from the original on 2015-07-05. Retrieved 2016-04-10.
- "Archived copy". Archived from the original on November 21, 2011. Retrieved June 6, 2012.CS1 maint: Archived copy as title (link)
- "Archived copy". Archived from the original on 2013-01-15. Retrieved 2012-06-08.CS1 maint: Archived copy as title (link)
- "Archived copy". Archived from the original on August 17, 2012. Retrieved June 26, 2012.CS1 maint: Archived copy as title (link)
- Torberntsson, Kim; Rydin, Ylva (June 2014). A Study of Configuration Management - Systems Solutions for Deployment and Configuration of Software in a Cloud Environment (PDF) (Thesis). Uppsala University. pp. 8, 27, 31, 42. Archived (PDF) from the original on 22 November 2018.
- "Google Groups". Groups.google.com. Retrieved 2016-04-10.
- Kruse, Christian (2016). "Automatic configuration deployment with cdist". WWWTech. Archived from the original on 22 November 2018. Retrieved 22 November 2018.
- "cdist-type(7)". Nico.schottelius.org. Archived from the original on 2016-03-03. Retrieved 2016-04-10.
- Bezroukov, Nikolai. "cdist". Softpanorama. Archived from the original on 8 July 2017. Retrieved 22 November 2018.
- "Installation Guide". Ansible. Managed Node Requirements. Archived from the original on 2018-08-04. Retrieved 22 November 2018.