cdist

From Wikipedia, the free encyclopedia
Jump to: navigation, search
cdist
Original author(s) Nico Schottelius, Steven Armstrong
Initial release 2010
Stable release 3.1.6 / 18-Aug-2014
Written in Python, Bourne shell
Operating system GNU/Linux, Unix-like
Type Configuration management
License GPLv3.
Website http://www.nico.schottelius.org/software/cdist/

cdist is a configuration management system, which adheres to the KISS principle. It is being used in small up to enterprise grade environments. cdist is an alternative to other configuration management systems like CFEngine, Bcfg2, Chef and Puppet.

Its core is written in Python and the types are written in Bourne Shell. Cdist is released under the GPL. cdist has been a no. 1 topic[1] on Hacker News for some time, was mentioned twice on Reddit[2] and is being talked about on Twitter.[3]

Development[edit]

cdist development started in 2010 at ETH Zurich and is actively being developed[4] by a lot of FOSS contributors and maintained by the two main developers Nico Schottelius and Steven Armstrong.[5] The major part of the discussion about cdist happens on the mailinglist[6] and on the IRC channel #cstar in the Freenode network. cdist is being used at various companies in Switzerland (for instance at ETH Zurich[7] and The OMA Browser project[8]), the USA, Germany and France.

Features[edit]

cdist is a zero dependency configuration management system: It requires only ssh 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.[9]

Installation and Configuration[edit]

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.[10] 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.

Architecture[edit]

cdist is split into two components:

  • The core
  • The configuration

Core[edit]

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.

Configuration[edit]

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.

Comparison[edit]

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.[11] cdist operates in push based approach, in which a server pushes configurations to the client and the clients do not poll for updates.

Configuration Language[edit]

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 profound in reading and writing shell scripts.

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.

See also[edit]

References[edit]

External links[edit]