cdist

<h2 id="development">Development</h2>
<p>cdist development started in 2010 at <a href="/facts/ETH_Zurich/IxHAFGUU">ETH Zurich</a> and
is actively being developed<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> and is maintained primarily by Nico Schottelius and
Steven Armstrong.<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a>
cdist is being used at various companies in Switzerland (such as <a href="/facts/ETH_Zurich/IxHAFGUU">ETH Zurich</a><a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> and The OMA Browser project),<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a> the US, Germany and France.
</p>
<h2 id="features">Features</h2>
<p>cdist is a zero dependency configuration management system: It requires only ssh and a bourne-compatible shell on target hosts, which are provided by default on most <a href="/facts/Unix-like/YAKrAxzd">Unix-like</a> machines.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> Because of this, cdist can be used to bootstrap other configuration management systems.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a>
</p>
<h2 id="installation-and-configuration">Installation and configuration</h2>
<p>cdist is not typically installed as a package (like .deb or .rpm), but rather via <a href="/facts/Git_(software)/U5Ty9QmQ">git</a>.
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.<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a>
</p><p>The main components of cdist are so called types, which bundle functionality.<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a>
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.
</p>
<h2 id="architecture">Architecture</h2>
<p>cdist is split into two components:
</p>
<ul><li>The core</li>
<li>The configuration scripts</li></ul>
<h3>Core</h3>
<p>Cdist's core handles reading configuration and communicating with remote hosts. Like Ansible, cdist uses a "push" model to apply configuration changes: A cdist process on the "host" machine connects to any number of remote nodes via SSH and then performs configuration updates on those nodes. Cdist can configure multiple hosts in parallel to reduce the time spent configuring.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a>
</p>
<h3>Configuration</h3>
<p>The configuration scripts define how the targets shall be configured. They are typically written in <a href="/facts/Bourne_Shell/wUCh3Qkl">Bourne Shell</a> and consists of
</p>
<ul><li>The initial manifest, an <a href="/facts/Entry_point/nN52vHKb">entry point</a> where all configuration runs begin. This script typically uses information about the target node, such as its hostname and operating system, to call other, more specific scripts which perform the actual configuration.</li>
<li>Global Explorers, small scripts which glean information about the target system (such as operating system, init system, and hostname)</li>
<li>Types, which describe reusable chunks of configuration. Types are instantiated in manifests and are the only way to actually run code on the target machines. The name "type" is meant as an analog to "class" in an object-oriented language, because a type can be turned into multiple "objects" depending on what parameters are passed to it.<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a> For instance, the __file type can be turned into multiple "objects", each one representing the creation of a certain file. Ansible's "roles" are the equivalent of cdist's types. Types can have many components:
<ul><li>Object ID: When a type is turned into an object, it is passed a unique object ID. The same type cannot be instantiated twice with the same ID. This ID is not random like a UUID, but rather is some unique identifier that is meaningful in relation to the type. For example, the __file type's ID is the absolute path to the file.</li>
<li>Parameters: Many types cannot be fully described by the object ID, and take additional information in the form of parameters. The __file type takes a group parameter which specifies to which Unix group should own the file.</li>
<li>Explorers: In addition to the global explorers described above, types sometimes have their own explorers that collect type-specific information from the remote machine. The __file type uses explorers to determine whether the file being created already exists. It sometimes uses this information to skip creation of the file.</li>
<li>Manifest: A type manifest can instantiate other types, making code re-use easy.</li>
<li>Gencode Scripts: The gencode-remote script is the main way to actually update the configuration of target nodes. gencode-remote runs on the local machine, but its <a href="/facts/Standard_output/r92M7Wd4">standard output</a> is sent to the remote machine and executed as a shell script. There is also a less frequently used gencode-local script which outputs code to be run locally.</li></ul></li></ul>
<p>Shell is the <a href="/facts/De_facto/3Du6WQKh">de facto</a> language for writing cdist configuration scripts, but most of the scripts can be written in any language if they contain a suitable <a href="/facts/Shebang_(Unix)/brtu1F1o">shebang line</a>. Shell scripting is favored because of how simple it is to access environment variables, read files, and execute system commands.
</p>
<h2 id="configuration-language">Configuration language</h2>
<p>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").
</p><p>cdist reads its configuration from the initial manifest (conf/manifest/init), in which hosts are mapped to
types:
</p>
case "$__target_host" in
    myhostname)
        __package zsh --state present
        __addifnosuchline /tmp/cdist-welcome --line "Welcome to cdist"
    ;;
esac

<p>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:
</p>
# 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

<p>Dependencies are expressed by setting up the require environment variable:
</p>
      __directory /tmp/foobar
      require="__directory//tmp/foobar" __file /tmp/foobar/baz

<p>Access to paths and files within types is given by environment variables like $__object.
</p>
<h2 id="similar-software">Similar software</h2>
<p><a href="/facts/Ansible_(software)/g8nwgwBG">Ansible</a>, like cdist, uses an agentless push model to configure nodes.<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a> However, Ansible requires <a href="/facts/Python_(programming_language)/YbuGqofa">Python</a> for some types of targets,<a class="footnote-ref" id="fnref:13" href="#fn:13"><sup>13</sup></a> whereas cdist does not. Ansible makes a distinction between roles, written in a declarative YAML-based language, and modules, written in Python. Cdist only has "types" which serve the purposes of both modules and roles and are mostly written in Bourne Shell. Cdist's approach might be preferable because Shell is familiar to many system administrators who have never used a configuration management system before, but Ansible's declarative language is arguably more readable and appropriate.
</p>

<h2 id="external-links">External links</h2>
<ul><li><a href="https://www.cdi.st/">Official website</a></li>
<li><a href="https://code.ungleich.ch/ungleich-public/cdist">source code</a></li>
<li><a href="https://web.archive.org/web/20111121044650/http://l.schottelius.org/mailman/listinfo/cdist">cdist mailinglist</a></li>
<li><a href="https://web.archive.org/web/20120603063209/http://freecode.com/projects/cdist">cdist on freecode</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>".github/README.md at df2f84b694afee8137b97695f6424c5aec314717 · skonfig/.github". GitHub.com. <a href="https://github.com/skonfig/.github/blob/df2f84b694afee8137b97695f6424c5aec314717/profile/README.md" target="_blank">https://github.com/skonfig/.github/blob/df2f84b694afee8137b97695f6424c5aec314717/profile/README.md</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>[1][dead link‍] <a href="http://cia.vc/stats/project/cdist" target="_blank">http://cia.vc/stats/project/cdist</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
<li id="fn:3"><p>"ungleich/cdist: cdist configuration management". GitHub.com. Archived from the original on 2015-07-05. Retrieved 2016-04-10. <a href="https://github.com/telmich/cdist" target="_blank">https://github.com/telmich/cdist</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li>
<li id="fn:4"><p>"Cdist configuration management". Archived from the original on 2013-01-15. Retrieved 2012-06-08. <a href="https://archive.today/20130115205250/http://sans.ethz.ch/projects/cdist/" target="_blank">https://archive.today/20130115205250/http://sans.ethz.ch/projects/cdist/</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li>
<li id="fn:5"><p>"About the OMA Browser". Archived from the original on August 17, 2012. Retrieved June 26, 2012. <a href="https://web.archive.org/web/20120817101530/http://omabrowser.org/about.html" target="_blank">https://web.archive.org/web/20120817101530/http://omabrowser.org/about.html</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li>
<li id="fn:6"><p>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. <a href="http://www.diva-portal.org/smash/get/diva2:732615/FULLTEXT01.pdf" target="_blank">http://www.diva-portal.org/smash/get/diva2:732615/FULLTEXT01.pdf</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li>
<li id="fn:7"><p>"Google Groups". Groups.google.com. Retrieved 2016-04-10. <a href="https://groups.google.com/group/puppet-users/browse_thread/thread/e1b1ede3ad3b0a8e/98f6b2c9d78032e8" target="_blank">https://groups.google.com/group/puppet-users/browse_thread/thread/e1b1ede3ad3b0a8e/98f6b2c9d78032e8</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li>
<li id="fn:8"><p>Kruse, Christian (2016). "Automatic configuration deployment with cdist". WWWTech. Archived from the original on 22 November 2018. Retrieved 22 November 2018. <a href="https://wwwtech.de/articles/2015/feb/automatic-configuration-deployment-with-cdist" target="_blank">https://wwwtech.de/articles/2015/feb/automatic-configuration-deployment-with-cdist</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li>
<li id="fn:9"><p>"cdist-type(7)". Nico.schottelius.org. Archived from the original on 2016-03-03. Retrieved 2016-04-10. <a href="https://web.archive.org/web/20160303233448/http://www.nico.schottelius.org/software/cdist/man/latest/man7/cdist-type.html" target="_blank">https://web.archive.org/web/20160303233448/http://www.nico.schottelius.org/software/cdist/man/latest/man7/cdist-type.html</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li>
<li id="fn:10"><p>Bezroukov, Nikolai. "cdist". Softpanorama. Archived from the original on 8 July 2017. Retrieved 22 November 2018. <a href="http://www.softpanorama.org/Admin/Conf_management/cdist.shtml" target="_blank">http://www.softpanorama.org/Admin/Conf_management/cdist.shtml</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li>
<li id="fn:11"><p>"13. Manifest — cdist 4.10.6-6-g61ac4a26 documentation". www.nico.schottelius.org. Retrieved 2019-03-26. <a href="https://www.nico.schottelius.org/software/cdist/man/beta/cdist-manifest.html" target="_blank">https://www.nico.schottelius.org/software/cdist/man/beta/cdist-manifest.html</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li>
<li id="fn:12"><p>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. <a href="http://www.diva-portal.org/smash/get/diva2:732615/FULLTEXT01.pdf" target="_blank">http://www.diva-portal.org/smash/get/diva2:732615/FULLTEXT01.pdf</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li>
<li id="fn:13"><p>"Installing Ansible — Ansible Documentation". docs.ansible.com. Retrieved 13 January 2023. The managed node (the machine that Ansible is managing) does not require Ansible to be installed, but requires Python 2.7, or Python 3.5 - 3.11 to run Ansible library code. <a href="https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#managed-node-requirements" target="_blank">https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#managed-node-requirements</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></p></li>
</ol>

cdist open-in-new

cdist