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 . Similar software Ansible, like cdist, uses an agentless push model to configure nodes. However, Ansible requires Python for some types of targets, 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. References External links source code cdist mailinglist cdist on freecode Configuration management Free software programmed in Python 2010 software Linux configuration utilities MacOS Linux package management-related software Unix package management-related software