cdist - Configuration management
cdist [-h] [-V]
cdist banner
cdist config [-h] [-d] [-V] [-c CDIST_HOME] [-i MANIFEST] [-p] [-s] host [host …]
cdist is the frontend executable to the cdist configuration management.
+cdist supports different as explained below. The options to the main
+program are:
-
+-h, --help
+
-
+ Show the help screen
+
-
+-V, --version
+
-
+ Show version and exit
+
Displays the cdist banner.
Configure a system
-
+-h, --help
+
-
+ Show the help screen
+
-
+-c CDIST_HOME, --cdist-home CDIST_HOME
+
-
+ Instead of using the parent of the bin directory as cdist home,
+ use the specified directory
+
-
+-d, --debug
+
-
+ Enable debug output
+
-
+-i MANIFEST, --initial-manifest MANIFEST
+
-
+ Path to a cdist manifest or - to read from stdin
+
-
+-p, --parallel
+
-
+ Operate on multiple hosts in parallel
+
-
+-s, --sequential
+
-
+ Operate on multiple hosts sequentially
+
# Configure ikq05.ethz.ch with debug enabled
+cdist config -d ikq05.ethz.ch
+
+# Configure hosts in parallel and use a different home directory
+cdist config -c ~/p/cdist-nutzung \
+ -p ikq02.ethz.ch ikq03.ethz.ch ikq04.ethz.ch
+
+# Display banner
+cdist banner
+
+# Show help
+cdist --help
+
+# Show Version
+cdist --version
-
+cdist(7)
+
-
+cdist-type-emulator(1)
+
-
+cdist-reference(7)
+
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-best-practice - Practices used in real environments
2. PASSWORDLESS CONNECTIONS
It is recommended to run cdist with public key authentication.
+This requires a private/public key pair and the entry
+"PermitRootLogin without-password" in the sshd server.
+See sshd_config(5) and ssh-keygen(1).
3. SPEEDING UP SSH CONNECTIONS
When connecting to a new host, the initial delay with ssh connections
+is pretty big. You can work around this by
+"sharing of multiple sessions over a single network connection"
+(quote from ssh_config(5)). The following code is suitable for
+inclusion into your ~/.ssh/config:
Host *
+ ControlPath ~/.ssh/master-%l-%r@%h:%p
+ ControlMaster auto
+ ControlPersist 10
4. MULTI MASTER OR ENVIRONMENT SETUPS
If you plan to distribute cdist among servers or use different
+environments, you can do so easily with the included version
+control git. For instance if you plan to use the typical three
+environments production, integration and development, you can
+realise this with git branches:
# Go to cdist checkout
+cd /path/to/cdist
+
+# Create branches
+git branch development
+git branch integration
+git branch production
+
+# Make use of a branch, for instance production
+git checkout production
Similar if you want to have cdist checked out at multiple machines,
+you can clone it multiple times:
machine-a % git clone git://your-git-server/cdist
+machine-b % git clone git://your-git-server/cdist
5. SEPERATING WORK BY GROUPS
If you are working with different groups on one cdist-configuration,
+you can delegate to other manifests and have the groups edit only
+their manifests. You can use the following snippet in
+conf/manifests/init:
# Include other groups
+sh -e "$__manifest/systems"
+
+sh -e "$__manifest/cbrg"
6. MAINTAINING MULTIPLE CONFIGURATIONS
When you need to manage multiple sites with cdist, like company_a, company_b
+and private for instance, you can easily use git for this purpose.
+Including a possible common base that is reused accross the different sites:
# create branches
+git branch company_a company_b common private
+
+# make stuff for company a
+git checkout company_a
+# work, commit, etc.
+
+# make stuff for company b
+git checkout company_b
+# work, commit, etc.
+
+# make stuff relevant for all sites
+git checkout common
+# work, commit, etc.
+
+# change to private and include latest common stuff
+git checkout private
+git merge common
The following .git/config is taken from a a real world scenario:
# Track upstream, merge from time to time
+[remote "upstream"]
+ url = git://git.schottelius.org/cdist
+ fetch = +refs/heads/*:refs/remotes/upstream/*
+
+# Same as upstream, but works when being offline
+[remote "local"]
+ fetch = +refs/heads/*:refs/remotes/local/*
+ url = /home/users/nico/p/cdist
+
+# Remote containing various ETH internal branches
+[remote "eth"]
+ url = sans.ethz.ch:/home/services/sans/git/cdist-eth
+ fetch = +refs/heads/*:refs/remotes/eth/*
+
+# Public remote that contains my private changes to cdist upstream
+[remote "nico"]
+ url = git.schottelius.org:/home/services/git/cdist-nico
+ fetch = +refs/heads/*:refs/remotes/nico/*
+
+# The "nico" branch will be synced with the remote nico, branch master
+[branch "nico"]
+ remote = nico
+ merge = refs/heads/master
+
+# ETH stable contains rock solid configurations used in various places
+[branch "eth-stable"]
+ remote = eth
+ merge = refs/heads/stable
Have a look at git-remote(1) to adjust the remote configuration, which allows
+you to push certain branches to certain remotes.
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-explorer - Explore the target systems
Explorer are small shell scripts, which will be executed on the target
+host. The aim of the explorer is to give hints to types on how to act on the
+target system. An explorer outputs the result to stdout, which is usually
+a one liner, but may be empty or multi line especially in the case of
+type explorers.
There are general explorers, which are run in an early stage, and
+type explorers. Both work almost exactly the same way, with the difference
+that the values of the general explorers are stored in a general location and
+the type specific below the object.
Explorers can reuse other explorers on the target system by calling
+$explorer/<explorer_name> (general and type explorer) or
+$type_explorer/<explorer name> (type explorer).
In case of significant errors, the explorer may exit non-zero and return an
+error message on stderr, which will cause cdist to abort.
You can also use stderr for debugging purposes while developing a new
+explorer.
A very simple explorer may look like this:
hostname
Which is in practise the "hostname" explorer.
A type explorer, which could check for the status of a package may look like this:
if [ -f "$__object/parameter/name" ]; then
+ name="$(cat "$__object/parameter/name")"
+else
+ name="$__object_id"
+fi
+
+# Except dpkg failing, if package is not known / installed
+dpkg -s "$name" 2>/dev/null || exit 0
-
+cdist(7)
+
-
+cdist-reference(7)
+
-
+cdist-stages(7)
+
Copyright (C) 2010-2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-hacker - How to get (stuff) into cdist
Welcome dear hacker! I invite you to a tour of pointers to
+get into the usable configuration mangament system, cdist.
The first thing to know is probably that cdist is brought to
+you by people who care about how code looks like and who think
+twice before merging or implementing a feature: Less features
+with good usability are far better than the opposite.
If you believe you’ve found a bug and verified that it is
+in the latest version, drop a mail to the cdist mailing list,
+subject prefixed with "[BUG] ".
4. CODING CONVENTIONS (EVERYWHERE)
If something should be better done or needs to fixed, add the word FIXME
+nearby, so grepping for FIXME gives all positions that need to be fixed.
5. HOW TO SUBMIT STUFF FOR INCLUSION INTO UPSTREAM CDIST
If you did some cool changes to cdist, which you value as a benefit for
+everybody using cdist, you’re welcome to propose inclusion into upstream.
There are though some requirements to ensure your changes don’t break others
+work nor kill the authors brain:
-
+All files should contain the usual header (Author, Copying, etc.)
+
-
+Code submission must be done via git
+
-
+Do not add conf/manifest/init - This file should only be touched in your
+ private branch!
+
-
+Code to be included should be branched of the upstream "master" branch
+
-
+Exception: Bugfixes to a version branch
+
-
+On a merge request, always name the branch I should pull from
+
-
+Always ensure all manpages build: ./build.sh man
+
-
+If you developed more than one feature, consider submitting them in
+ seperate branches. This way one feature can already be included, even if
+ the other needs to be improved.
+
As soon as your work meets these requirements, you can contact me
+(IRC, Mailinglist, Phone, RFC 1149) and I’ll check your code before
+including it.
6. HOW TO SUBMIT A NEW TYPE
Submitting a type works as described above, with the additional requirement
+that a corresponding manpage named man.text in asciidoc format with
+the manpage-name "cdist-type__NAME" is included in the type directory
+AND asciidoc is able to compile it (i.e. do NOT have to many "=" in the second
+line).
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-manifest - Define types to be used
Manifests exist to define which configurations should be applied to a specific
+host as well as to define which configurations should be applied within a
+type. Manifests are executed locally and the resulting objects are stored in
+an internal database.
The same object can be redefined in multiple different manifests as long as
+the parameters are exactly the same.
In general, manifests are used to define which types are used depending
+on given conditions.
The initial manifest may for instance contain the following code:
# Always create this file, so other sysadmins know cdist is used.
+__file /etc/cdist-configured --type file
+
+case "$__target_host" in
+ my.server.name)
+ __file /root/bin/ --type directory
+ __file /etc/issue.net --type file --source "$__manifest/issue.net
+ ;;
+esac
The manifest of the type "nologin" may look like this:
__file /etc/nologin --type file --source "$__type/files/default.nologin"
If you want to describe that something requires something else, just
+setup the variable "require" to contain the requirements. Multiple
+requirements can be added white space seperated.
# No dependency
+__file /etc/cdist-configured
+
+# Require above object
+require="__file/etc/cdist-configured" __link /tmp/cdist-testfile \
+ --source /etc/cdist-configured --type symbolic
+
+# Require two objects
+require="__file/etc/cdist-configured __link/tmp/cdist-testfile" \
+ __file /tmp/cdist-another-testfile
-
+cdist-manifest-run(1)
+
-
+cdist-manifest-run-init(1)
+
-
+cdist-type(7)
+
Copyright (C) 2010-2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-reference - Variable, path and type reference for cdist
The following global explores are available:
-
+hostname
+
-
+lsb_codename
+
-
+lsb_description
+
-
+lsb_id
+
-
+lsb_release
+
-
+machine
+
-
+os
+
-
+os_version
+
If not specified otherwise, all paths are relative to the checkout directory.
-
+conf/
+
-
+ Contains the (static) configuration like manifests, types and explorers.
+
-
+conf/manifest/init
+
-
+ This is the central entry point used by cdist-manifest-init(1).
+ It is an executable (+x bit set) shell script that can use
+ values from the explorers to decide which configuration to create
+ for the specified target host.
+ It should be primary used to define mapping from configurations to hosts.
+
-
+conf/manifest/*
+
-
+ All other files in this directory are not directly used by cdist, but you
+ can seperate configuration mappings, if you have a lot of code in the
+ manifest/init file. This may also be very helpful to have different admins
+ maintain different groups of hosts.
+
-
+conf/explorer/<name>
+
-
+ Contains explorers to be run on the target hosts, see cdist-explorer(7).
+
-
+conf/type/
+
-
+ Contains all available types, which are used to provide
+ some kind of functionality. See cdist-type(7).
+
-
+conf/type/<name>/
+
+ Home of the type <name>.
+
This directory is referenced by the variable __type (see below).
-
+conf/type/<name>/man.text
+
-
+ Manpage in Asciidoc format (nequired for inclusion into upstream)
+
-
+conf/type/<name>/manifest
+
-
+ Used to generate additional objects from a type.
+
-
+conf/type/<name>/gencode-local
+
-
+ Used to generate code to be executed on the server.
+
-
+conf/type/<name>/gencode-remote
+
-
+ Used to generate code to be executed on the client.
+
-
+conf/type/<name>/parameters/required
+
-
+ Parameters required by type, \n seperated list.
+
-
+conf/type/<name>/parameters/optional
+
-
+ Parameters optionally accepted by type, \n seperated list.
+
-
+conf/type/<name>/explorer
+
-
+ Location of the type specific explorers.
+ This directory is referenced by the variable __type_explorer (see below).
+ See cdist-explorer(7).
+
-
+out/
+
-
+ This directory contains output of cdist and is usually located
+ in a temporary directory and thus will be removed after the run.
+ This directory is referenced by the variable __global (see below).
+
-
+out/explorer
+
-
+ Output of general explorers.
+
-
+out/object
+
-
+ Objects created for the host.
+
-
+out/object/<object>
+
-
+ Contains all object specific information.
+ This directory is referenced by the variable __object (see below).
+
-
+out/object/<object>/explorers
+
-
+ Output of type specific explorers, per object.
+
-
+tmp_dir
+
-
+ A tempdir and a tempfile is used by cdist internally,
+ which will be removed when the scripts end automatically.
+
The following types are available:
For object to object communication and tests, the following paths are
+usable within a object directory:
-
+changed
+
-
+ This empty file exists in an object directory, if the object has
+ code to be excuted (either remote or local)
+
-
+__explorer
+
-
+ Directory that contains all global explorers.
+ Available for: explorer
+
-
+__manifest
+
-
+ Directory that contains the initial manifest.
+ Available for: initial manifest
+
-
+__global
+
-
+ Directory that contains generic output like explorer.
+ Available for: initial manifest, type manifest, type gencode
+
-
+__object
+
-
+ Directory that contains the current object.
+ Available for: type manifest, type explorer, type gencode
+
-
+__object_id
+
-
+ The type unique object id.
+ Available for: type manifest, type explorer, type gencode
+
-
+__self
+
-
+ DEPRECATED: Same as object_name, do not use anymore, use object_name instead.
+
-
+__object_name
+
-
+ The full qualified name of the current object.
+ Available for: type manifest, type explorer, type gencode
+
-
+__target_host
+
-
+ The host we are deploying to.
+ Available for: initial manifest, type manifest, type gencode
+
-
+__type
+
-
+ Path to the current type.
+ Available for: type manifest, type gencode
+
-
+__type_explorer
+
-
+ Directory that contains the type explorers.
+ Available for: type explorer
+
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-stages - Stages used during configuration deployment
Starting the execution of deployment with cdist-deploy-to(1), cdist passes
+through different stages, each can be triggered and debugged on its own.
+Reading the source of the cdist-deploy-to executable shows the scripts
+responsible for each stage.
3. STAGE 0: INTERNAL PREPERATION
Before running the user facing stages, cdist prepares the target host
+to contain cdist binaries and creates a clean environment for the
+configuration run.
Related documentation:
+ - Source of cdist-deploy-to
4. STAGE 1: TARGET INFORMATION RETRIEVAL
In this stage information is collected about the target host using so called
+explorers. Every existing explorer is run on the target and the output of all
+explorers are copied back into the local cache. The results can be used by
+manifests and types.
5. STAGE 2: RUN THE INITIAL MANIFEST
The initial manifest, which should be used for mappings of hosts to types,
+is executed. This stage creates objects in a cconfig database that contains
+the objects as defined in the manifest for the specific host. In this stage,
+no conflicts may occur, i.e. no object of the same type with the same id may
+be created.
6. STAGE 3: OBJECT INFORMATION RETRIEVAL
Every object is checked whether its type has explorers and if so, these are
+transfered to the target host and executed. The results are transfered back
+and can be used in the following stages to decide what changes need to be made
+on the target to implement the desired state.
7. STAGE 4: RUN THE OBJECT MANIFEST
Every object is checked whether its type has a executable manifest. The
+manifest script may generate and change the created objects. In other words,
+one type can reuse other types.
For instance the object apache/www.test.ch is of type apache, which may
+contain a manifest script, which creates new objects of type __file.
The newly created objects are merged back into the existing tree. No conflicts
+may occur during the merge. A conflict would mean that two different objects
+try to create the same object, which indicates a broken configuration.
8. STAGE 5: CODE GENERATION
In this stage for every created object its type is checked for executable
+gencode scripts. The gencode scripts generate the code to be executed on the
+target on stdout. If the gencode executables fail, they must print diagnostic
+messages on stderr and exit non-zero.
9. STAGE 6: CODE EXECUTION
For every object the resulting code from the previous stage is transferred to
+the target host and executed there to apply the configuration changes.
The cache stores the information from the current run for later use.
If, and only if, all the stages complete without an errors, the configuration
+will be applied to the target. Each stage can also be run individually, though
+dependencies for each stage must be fulfilled and thus the stages must be run
+in correct order.
-
+cdist(1)
+
-
+cdist(7)
+
-
+cdist-reference(7)
+
Copyright (C) 2010-2011 Nico Schottelius, Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-tutorial - a guided introduction into cdist
2. PREPARING YOUR MACHINE / SETUP
-
+ensure sshd is running on the target host:
+
ssh target_host
-
+ensure you can login as root
+
ssh root@target host
-
+ensure login as root works without keys
+(see ssh… manpage)
+
cdist will do a lot of requests to the target
+host, thus you’ll have to enter your password
+many times, if you don’t do this :-)
-
+speedup processing with ControlMaster option of
+ssh
+
3. YOUR FIRST CONFIGURATION
4. DEFINE STATE IN THE INITAL MANIFEST
The initial manifest is used to map
+configurations to a host.
5. USING SOME BASIC TYPES
what is a type, how to use it,
6. CREATING YOUR FIRST OWN TYPE
<with object id? or signleton here already>
7. USE A TYPE TO BUNDLE FUNCTIONALITY
-
+__debug
+
-
+ If this variable is setup, cdist runs in debug mode.
+ You can use this information, to only output stuff in debug
+ mode as well.
+ Available for: initial manifest, type manifest, gencode, code
+
This tutorial is aimed at people learning cdist and shows
+typical approaches as well as gives an easy start into
+the world of configuration management.
This tutorial assumes you are configuring localhost, because
+it is always available. Just repace localhost with your target
+host for real life usage.
For those who just want to configure a system with the
+cdist configuration management and do not need (or want)
+to understand everything.
Cdist uses ssh for communication and transportation
+and usually logs into the target host as the
+root user. So you need to configure the ssh server
+of the target host to allow root logins: Edit
+the file /etc/ssh/sshd_config and add one of the following
+lines:
# Allow login only via public key
+PermitRootLogin without-password
+
+# Allow login via password and public key
+PermitRootLogin yes
As cdist uses ssh intensively, it is recommended to setup authentication
+with public keys:
# Generate pubkey pair as a normal user
+ssh-keygen
+
+# Copy pubkey over to target host
+ssh-copy-id root@localhost
As soon as you are able to login without passwort to the target host,
+we can use cdist, to configure it. You can copy and paste the following
+code into your shell to get started and configure localhost:
# Get cdist
+git clone git://git.schottelius.org/cdist
+
+# Create manifest (maps configuration to host(s)
+cd cdist
+echo '__file /etc/cdist-configured' > conf/manifest/init
+chmod 0700 conf/manifest/init
+
+# Configure localhost
+./bin/cdist config localhost
+
+# Find out that cdist created /etc/cdist-configured
+ls -l /etc/cdist-configured
The file conf/manifest/init is usually the entry point for cdist,
+to find out what to configure on which host. All manifests are
+essentially shell scripts. Every manifest can use the types known to
+cdist, which are usually underline prefixed (__).
cdist(1), cdist-type(7), cdist-stages(7)
cdist-type - Functionality bundled
__TYPE ID --parameter value [--parameter value …]
__TYPE --parameter value [--parameter value …] (for singletons)
Types are the main component of cdist and define functionality. If you
+use cdist, you’ll write a type for every functionality you would like
+to use.
You can use types from the initial manifest or the type manifest like a
+normal command:
# Creates empty file /etc/cdist-configured
+__file /etc/cdist-configured --type file
+
+# Ensure tree is installed
+__package tree --state installed
A list of supported types can be found in the cdist-reference(7) manpage.
If a type is flagged as a singleton, it may me used only once. This
+is useful for types which can be used only once on a system. If a type
+can only be used once, it does not take an
Example:
# __issue type manages /etc/issue
+__issue
+
+# Probably your own type - singletons may use parameters
+__myfancysingleton --colour green
6. HOW TO WRITE A NEW TYPE
A type consists of
-
+parameter (optional)
+
-
+manifest (optional)
+
-
+singleton (optional)
+
-
+explorer (optional)
+
-
+gencode (optional)
+
Types are stored below conf/type/. Their name should always be prefixed with
+two underscores (__) to prevent collisions with other binaries in $PATH.
To begin a new type from a template, execute "cdist-type-template NAME"
+and cd conf/type/NAME.
Every type consists of optional and required parameters, which must
+be created in a newline seperated file in parameters/required and
+parameters/optional. If either or both missing, the type will have
+no required, no optional or no parameters at all.
Example:
echo servername >> conf/type/__nginx_vhost/parameter/required
+echo logdirectory >> conf/type/__nginx_vhost/parameter/optional
In the manifest of a type you can use other types, so your type extends
+their functionality. A good example is the __package type, which in
+a shortened version looks like this:
os="$(cat "$__global/explorer/os")"
+case "$os" in
+ archlinux) type="pacman" ;;
+ debian|ubuntu) type="apt" ;;
+ gentoo) type="emerge" ;;
+ *)
+ echo "Don't know how to manage packages on: $os" >&2
+ exit 1
+ ;;
+esac
+
+__package_$type "$@"
As you can see, the type can reference different environment variables,
+which are documented in cdist-reference(7).
Always ensure the manifest is executable, otherwise cdist will not be able
+to execute it.
9. SINGLETON - ONLY INSTANCE ONLY
If you want to ensure that a type can only be used once per target, you can
+mark it as a singleton: Just create the (empty) file "singleton" in your type
+directory. This will also change the way your type must be called:
__YOURTYPE --parameter value
As you can see, the ID is omitted, because it does not make any sense, if your
+type can be used only once.
If a type needs to explore specific details, it can provide type specific
+explorers, which will be executed on the target for every created object.
The explorers are stored under the "explorer" directory below the type.
+It could for instance contain code to check the md5sum of a file on the
+client, like this (shortened version from real type __file):
if [ -f "$__object/parameter/destination" ]; then
+ destination="$(cat "$__object/parameter/destination")"
+else
+ destination="/$__object_id"
+fi
+
+if [ -e "$destination" ]; then
+ md5sum < "$destination"
+fi
11. WRITING THE GENCODE SCRIPT
There are two gencode scripts: gencode-local and gencode-remote.
+The output of gencode-local is executed locally, whereas
+the output of gencode-remote is executed on the target.
The gencode script can make use of the parameters, the global explorers
+and the type specific explorers. The output (stdout) of this script is
+saved by cdist and will be executed on the target.
If the gencode script encounters an error, it should print diagnostic
+messages to stderr and exit non-zero. If you need to debug the gencode
+script, you can write to stderr:
# Debug output to stderr
+echo "My fancy debug line" >&2
+
+# Output to be saved by cdist for execution on the target
+echo "touch /etc/cdist-configured"
12. HINTS FOR TYPEWRITERS
It must be assumed that the target is pretty dumb and thus does not have high
+level tools like ruby installed. If a type requires specific tools to be present
+on the target, there must be another type that provides this tool and the first
+type should create an object of the specific type.
If your type wants to save temporary data, that may be used by other types
+later on (for instance file), you can save them in the subdirectory
+"files" below $object (but you must create it yourself). cdist will not touch
+this directory.
If your type contains static files, it’s also recommended to place them in
+a folder named "files" within the type (again, because cdist guarantees to
+never ever touch this folder).
13. HOW TO INCLUDE A TYPE INTO UPSTREAM CDIST
If you think your type may be useful for others, ensure it works with the
+current master branch of cdist and submit the git url containing the type for
+inclusion to the mailinglist cdist at cdist — at — l.schottelius.org.
Ensure a corresponding manpage named man.text in asciidoc format with
+the manpage-name "cdist-type__NAME" is included in the type directory.
-
+cdist-manifest-run(1)
+
-
+cdist-stages(7)
+
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__addifnosuchline(7)
cdist-type__addifnosuchline - Add a line (if not existing already)
This type can be used to check a file for existence of a
+specific line and adding it, if it was not found.
-
+line
+
-
+ Specifies the content which shall be added if not existing.
+
-
+file
+
-
+ If supplied, use this as the destination file.
+ Otherwise the object_id is used.
+
# Creates or appends the line specifiend in "include_www" to the file "lighttpd.conf"
+__addifnosuchline www --file /etc/lighttpd.conf --line include_www
+
+# Adds the line "include_git" to the file "lighttpd.conf"
+__addifnosuchline /etc/lighttpd.conf --line include_git
Copyright (C) 2011 Daniel Roth. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__apt_ppa - Manage ppa repositories
This cdist type allows manage ubuntu ppa repositories.
-
+state
+
-
+ The state the ppa should be in, either "enabled" or "disabled".
+
# Enable a ppa repository
+__apt_ppa ppa:sans-intern/missing-bits --state enabled
+
+# Disable a ppa repository
+__apt_ppa ppa:sans-intern/missing-bits --state disabled
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__apt_update_index(7)
cdist-type__apt_update_index - update apt’s package index
This cdist type runs apt-get update whenever any apt sources have changed.
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__autofs_map(7)
cdist-type__autofs_map - Manage autofs maps
This cdist type allows you to define maps for autofs.
The object_id is used as the mount-point as described in auto.master(5).
-
+map
+
-
+ Name of the map to use. See auto.master(5).
+
-
+type
+
-
+ Type of map used for this mount point. Defaults to file.
+ See map-type in auto.master(5) for possible values.
+
-
+options
+
-
+ See auto.master(5).
+
-
+comment
+
-
+ A comment describing this map. Is added to the generated entry in
+ auto.master.
+
# Add auto mounter at /net
+__autofs_map /net --map /etc/auto.net --type program
+
+# Add auto mounter at /pub
+__autofs_map /pub --map /etc/auto.pub \
+ --type file --options nosuid,rw,bg,hard,intr --ghost
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__autofs_master(7)
cdist-type__autofs_master - Generate the auto.master file
This cdist type generates a auto.master configuration from given autofs_map
+definitions. See cdist-typeauto_map(7).
-
+header
+
-
+ Absolute path to a file used as the header for the generated auto.master
+ file.
+
# auto.master with default header
+__autofs_master
+
+# auto.master with custom header
+__autofs_master --header /path/to/header
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__cron - installs and manages cron jobs
This cdist type allows you to manage entries in a users crontab.
-
+user
+
-
+ The user who’s crontab is edited
+
-
+command
+
-
+ The command to run.
+
-
+state
+
-
+ Either present or absent. Defaults to present.
+
-
+minute
+
-
+ See crontab(5). Defaults to *
+
-
+hour
+
-
+ See crontab(5). Defaults to *
+
-
+day_of_month
+
-
+ See crontab(5). Defaults to *
+
-
+month
+
-
+ See crontab(5). Defaults to *
+
-
+day_of_week
+
-
+ See crontab(5). Defaults to *
+
# add cronjob
+__cron some-id --user root --command "/path/to/script"
+
+# remove cronjob
+__cron some-id --user root --command "/path/to/script" --state absent
-
+cdist-type(7)
+
-
+crontab(5)
+
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__debconf_set_selections(7)
cdist-type__debconf_set_selections - Setup debconf selections
On Debian and alike systems debconf-set-selections(1) can be used
+to setup configuration parameters.
-
+file
+
-
+ If supplied, use the given filename as input for debconf-set-selections(1)
+
# Setup configuration for nslcd
+__debconf_set_selections nslcd --file /path/to/file
+
+# Setup configuration for nslcd from another type
+__debconf_set_selections nslcd --file "$__type/files/preseed/nslcd"
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__directory - Create a directory
This cdist type allows you to create directories on the target.
-
+group
+
-
+ Group to chgrp to.
+
-
+mode
+
-
+ Unix permissions, suitable for chmod.
+
-
+owner
+
-
+ User to chown to.
+
-
+parents
+
-
+ Whether to create parents as well (mkdir -p behaviour). Must be yes or no.
+
-
+recursive
+
-
+ If supplied the chgrp and chown call will run recursively.
+ This does not influence the behaviour of chmod.
+ Must be yes or no.
+
# A silly example
+__directory /tmp/foobar
+
+# Ensure /etc exists correctly
+__directory /etc --owner root --group root --mode 0755
+
+# Create nfs service directory, including parents
+__directory /home/services/nfs --parents yes
+
+# Change permissions recursively
+__directory /home/services --recursive yes --owner root --group root
+
+# Setup a temp directory
+__directory /local --mode 1777
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__file - Create files
This cdist type allows you to create files on the target.
-
+group
+
-
+ Group to chgrp to.
+
-
+mode
+
-
+ Unix permissions, suitable for chmod.
+
-
+owner
+
-
+ User to chown to.
+
-
+source
+
-
+ If supplied, copy this file from the host running cdist to the target.
+ If not supplied, an empty file or directory will be created.
+
# Create /etc/cdist-configured as an empty file
+__file /etc/cdist-configured
+
+# Use __file from another type
+__file /etc/issue --source "$__type/files/archlinux"
+
+# Supply some more settings
+__file /etc/shadow --source "$__type/files/shadow" \
+ --owner root --group shadow --mode 0640
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__group - Manage groups
This cdist type allows you to create or modify groups on the target.
-
+gid
+
-
+ see groupmod(8)
+
-
+password
+
-
+ see above
+
# Create a group 'foobar' with operating system default settings
+__group foobar
+
+# Same but with a specific gid
+__group foobar --gid 1234
+
+# Same but with a gid and password
+__group foobar --gid 1234 --password 'crypted-password-string'
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__issue - Manage issue
This cdist type allows you to easily setup /etc/issue.
-
+source
+
-
+ If supplied, use this file as /etc/issue instead of default.
+
__issue
+
+# When called from another type
+__issue --source "$__type/files/myfancyissue"
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__key_value - Change property values in files
This cdist type allows you to change values in a key value based config
+file.
-
+value
+
-
+ The value for the key. Setting the value to
__NOTSET__ will remove the key
+ from the file.
+ -
+file
+
-
+ The file to operate on.
+
-
+delimiter
+
-
+ The delimiter which seperates the key from the value.
+
-
+key
+
-
+ The key to change. Defaults to object_id.
+
# Set the maximum system user id
+__key_value SYS_UID_MAX --file /etc/login.defs --value 666 --delimiter ' '
+
+# Same with fancy id
+__key_value my-fancy-id --file /etc/login.defs --key SYS_UID_MAX --value 666 \
+ --delimiter ' '
+
+# Enable packet forwarding
+__key_value net.ipv4.ip_forward --file /etc/sysctl.conf --value 1 \
+ --delimiter '='
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__link - Create links
This cdist type allows you to hard and symoblic links. The given
+object id is the destination for the link.
-
+source
+
-
+ Specifies the link source.
+
-
+type
+
-
+ Specifies the link type: Either hard or symoblic.
+
# Create hard link of /etc/shadow
+__link /root/shadow --source /etc/shadow --type hard
+
+# Relative symbolic link
+__link /etc/apache2/sites-enabled/www.test.ch \
+ --source ../sites-available/www.test.ch \
+ --type symbolic
+
+# Absolute symbolic link
+__link /opt/plone --source /home/services/plone --type symbolic
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__mkfs - build a linux file system
This cdist type is a wrapper for the mkfs command.
-
+type
+
-
+ The filesystem type to use. Same as mkfs -t.
+
-
+device
+
-
+ defaults to object_id
+
-
+options
+
-
+ file system-specific options to be passed to the mkfs command
+
-
+blocks
+
-
+ the number of blocks to be used for the file system
+
# reiserfs /dev/sda5
+__mkfs /dev/sda5 --type reiserfs
+# same thing with explicit device
+__mkfs whatever --device /dev/sda5 --type reiserfs
+
+# jfs with journal on /dev/sda2
+__mkfs /dev/sda1 --type jfs --options "-j /dev/sda2"
-
+cdist-type(7)
+
-
+mkfs(8)
+
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__motd - Manage message of the day
This cdist type allows you to easily setup /etc/motd.
-
+source
+
-
+ If supplied, copy this file from the host running cdist to the target.
+ If not supplied, a default message will be placed onto the target.
+
# Use cdist defaults
+__motd
+
+# Supply source file from a different type
+__motd --source "$__type/files/my-motd"
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__package - Manage packages
This cdist type allows you to install or uninstall packages on the target.
+It dispatches the actual work to the package system dependant types.
-
+state
+
-
+ The state the package should be in, either "installed" or "removed"
+
-
+name
+
-
+ The name of the package to install. Default is to use the object_id as the
+ package name.
+
-
+version
+
-
+ The version of the package to install. Default is to install the version
+ choosen by the local package manager.
+
-
+type
+
-
+ The package type to use. Default is determined based on the $os explorer
+ variable.
+ e.g. package_apt for Debian
+ package_emerge for Gentoo
+
# Install the package vim on the target
+__package vim --state installed
+
+# Same but install specific version
+__package vim --state installed --version 7.3.50
+
+# Force use of a specific package type
+__package vim --state installed --type __package_apt
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__package_apt(7)
cdist-type__package_apt - Manage packages with apt-get
apt-get is usually used on Debian and variants (like Ubuntu) to
+manage packages.
-
+state
+
-
+ Either "installed" or "removed".
+
-
+name
+
-
+ If supplied, use the name and not the object id as the package name.
+
# Ensure zsh in installed
+__package_apt zsh --state installed
+
+# In case you only want *a* webserver, but don't care which one
+__package_apt webserver --state installed --name nginx
+
+# Remove obsolete package
+__package_apt puppet --state removed
-
+cdist-type(7)
+
-
+cdist-type__package(7)
+
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__package_pacman(7)
cdist-type__package_pacman - Manage packages with pacman
Pacman is usually used on the Archlinux distribution to manage
+packages.
-
+state
+
-
+ Either "installed" or "removed".
+
-
+name
+
-
+ If supplied, use the name and not the object id as the package name.
+
# Ensure zsh in installed
+__package_pacman zsh --state installed
+
+# If you don't want to follow pythonX packages, but always use python
+__package_pacman python --state installed --name python2
+
+# Remove obsolete package
+__package_pacman puppet --state removed
-
+cdist-type(7)
+
-
+cdist-type__package(7)
+
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__package_pkg(7)
cdist-type__package_pkg_openbsd - Manage OpenBSD packages
This type is usually used on OpenBSD to manage packages.
-
+state
+
-
+ Either "installed" or "removed".
+
-
+name
+
-
+ If supplied, use the name and not the object id as the package name.
+
-
+flavor
+
-
+ If supplied, use to avoid ambiguity.
+
# Ensure zsh is installed
+__package_pkg_openbsd zsh --state installed
+
+# Ensure vim is installed, use flavor no_x11
+__package_pkg_openbsd vim --state installed --flavor no_x11
+
+# If you don't want to follow pythonX packages, but always use python
+__package_pkg_openbsd python --state installed --name python2
+
+# Remove obsolete package
+__package_pkg_openbsd puppet --state removed
-
+cdist-type(7)
+
-
+cdist-type__package(7)
+
Copyright (C) 2011 Andi Brönnimann. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__package_rubygem(7)
cdist-type__package_rubygem - Manage rubygem packages
Rubygems is the default package management system for the Ruby programming language.
-
+state
+
-
+ Either "installed" or "removed".
+
-
+name
+
-
+ If supplied, use the name and not the object id as the package name.
+
# Ensure sinatra is installed
+__package_rubygem sinatra --state installed
+
+# Remove package
+__package_rubygem rails --state removed
-
+cdist-type(7)
+
-
+cdist-type__package(7)
+
Copyright (C) 2011 Chase Allen James. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__package_yum(7)
cdist-type__package_yum - Manage packages with yum
Yum is usually used on the Fedora distribution to manage packages.
+If you specify an unknown package, yum will display the
+slightly confusing error message "Error: Nothing to do".
-
+state
+
-
+ Either "installed" or "removed".
+
-
+name
+
-
+ If supplied, use the name and not the object id as the package name.
+
# Ensure zsh in installed
+__package_yum zsh --state installed
+
+# If you don't want to follow pythonX packages, but always use python
+__package_yum python --state installed --name python2
+
+# Remove obsolete package
+__package_yum puppet --state removed
-
+cdist-type(7)
+
-
+cdist-type__package(7)
+
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__partition_msdos(7)
cdist-type__partition_msdos - creates msdos partitions
This cdist type allows you to create msdos paritions.
-
+type
+
-
+ the partition type used in fdisk (such as 82 or 83) or "extended"
+
-
+partition
+
-
+ defaults to object_id
+
-
+bootable
+
-
+ mark partition as bootable, true or false, defaults to false
+
-
+size
+
-
+ the size of the partition (such as 32M or 15G, whole numbers
+ only), + for remaining space, or n% for percentage of remaining
+ (these should only be used after all specific partition sizes are
+ specified). Defaults to +.
+
# 128MB, linux, bootable
+__partition_msdos /dev/sda1 --type 83 --size 128M --bootable true
+# 512MB, swap
+__partition_msdos /dev/sda2 --type 82 --size 512M
+# 100GB, extended
+__partition_msdos /dev/sda3 --type extended --size 100G
+# 10GB, linux
+__partition_msdos /dev/sda5 --type 83 --size 10G
+# 50% of the free space of the extended partition, linux
+__partition_msdos /dev/sda6 --type 83 --size 50%
+# rest of the extended partition, linux
+__partition_msdos /dev/sda7 --type 83 --size +
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__partition_msdos_apply(7)
cdist-type__partition_msdos_apply - Apply dos partition settings
Create the partitions defined with __partition_msdos
-
+cdist-type(7)
+
-
+cdist-type__partition_msdos_apply(7)
+
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__postgres_database(7)
cdist-type__postgres_database - create/drop postgres databases
This cdist type allows you to create or drop postgres databases.
-
+state
+
-
+ either present or absent
+
-
+owner
+
-
+ the role owning this database
+
__postgres_database mydbname --state present --owner mydbusername
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__postgres_role(7)
cdist-type__postgres_role - manage postgres roles
This cdist type allows you to create or drop postgres roles.
-
+state
+
-
+ either present or absent
+
All optional parameter map directly to the corresponding postgres createrole
+parameters.
-
+password
+,
+login
+,
+createdb
+,
+createrole
+,
+superuser
+,
+inherit
+
-
+EXAMPLES
+
__postgres_role myrole --state present
__postgres_role myrole --state present --password secret
__postgres_role admin --state present --password very-secret --superuser true
__postgres_role dbcustomer --state present --password bla --createdb true
SEE ALSO
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__process - Start or stop process
This cdist type allows you to define the state of a process.
-
+state
+
-
+ State of the process: Either stopped or running.
+
-
+name
+
-
+ Process name to match on when using pgrep -f -x.
+
-
+stop
+
-
+ Executable to use for stopping the process.
+
-
+start
+
-
+ Executable to use for starting the process.
+
# Start if not running
+__process /usr/sbin/syslog-ng --state running
+
+# Start if not running with a different binary
+__process /usr/sbin/nginx --state running --start "/etc/rc.d/nginx start"
+
+# Stop the process using kill (the type default) - DO NOT USE THIS
+__process /usr/sbin/sshd --state stopped
+
+# Stop the process using /etc/rc.d/sshd stop - THIS ONE NOT AS WELL
+__process /usr/sbin/sshd --state stopped --stop "/etc/rc.d/sshd stop"
+
+# Ensure cups is running, which runs with -C ...:
+__process cups --start "/etc/rc.d/cups start" --state running \
+ --name "/usr/sbin/cupsd -C /etc/cups/cupsd.conf"
+
+# Ensure rpc.statd is running (which usually runs with -L) using a regexp
+__process rpcstatd --state running --start "/etc/init.d/statd start" \
+ --name "rpc.statd.*"
Copyright (C) 2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__removeline(7)
cdist-type__removeline - Remove a line (if existing)
This type can be used to check a file for existence of a
+specific line and removeing it, if it was found.
-
+line
+
-
+ Specifies the content which shall be removed if existing.
+
-
+file
+
-
+ If supplied, use this as the destination file.
+ Otherwise the object_id is used.
+
# Removes the line specifiend in "include_www" from the file "lighttpd.conf"
+__removeline www --file /etc/lighttpd.conf --line include_www
+
+# Removes the line "include_git" from the file "lighttpd.conf"
+__removeline /etc/lighttpd.conf --line include_git
Copyright (C) 2011 Daniel Roth. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__ssh_authorized_key(7)
Aurélien Bondis - aurelien.bondis AT gmail DOT com
cdist-type__ssh_authorized_key - Sends a user’s public key to another user’s authorized_keys
This type sends a rsa key. By default uses root’s key and sends it to root’s authorized_keys
-
+srcuser
+
-
+the user to take the rsa public key from
+
-
+dstuser
+
-
+the user to give the rsa public key to
+
#deploy root's public key
+__ssh_authorized_key admin
+#deploy bob's public key to alice's authorized_keys
+__ssh_authorized_key --srcuser bob --dstuser alice
Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
Ramon Salvadó - rsalvado at gnuine dot com
cdist-type__timezone - Allows to configure the desired localtime timezone.
This type creates a symlink (/etc/localtime) to the selected timezone
+(which should be available in /usr/share/zoneinfo).
#Set up Europe/Andorra as our timezone.
+__timezone Europe/Andorra
+
+#Set up US/Central as our timezone.
+__timezone US/Central
Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__user - Manage users
This cdist type allows you to create or modify users on the target.
-
+comment
+
-
+ see usermod(8)
+
-
+home
+
-
+ see above
+
-
+gid
+
-
+ see above
+
-
+groups
+
-
+ see above
+
-
+password
+
-
+ see above
+
-
+shell
+
-
+ see above
+
-
+uid
+
-
+ see above
+
# Create user account for foobar with operating system default settings
+__user foobar
+
+# Same but with a different shell
+__user foobar --shell /bin/zsh
+
+# Set explicit uid and home
+__user foobar --uid 1001 --shell /bin/zsh --home /home/foobar
Copyright (C) 2011 Steven Armstrong. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist - Configuration management system
Cdist is a usable configuration management system.
+The easiest way to get started with cdist is to initialise
+the environment and run cdist-quickstart:
eval `./bin/cdist-env` && cdist-quickstart
Cdist configurations are written in the shell scripting language.
+The mapping of configurations to hosts is defined in so called manifests,
+logical units of functionality are called "types" in cdist jargon.
+Cdist ships with some types included. You can use or change them, create new
+ones or even submit your types for inclusion into cdist.
The main command is cdist-deploy-to, which runs several stages to push
+configurations to a host. If you want to deeply understand cdist, reading
+the source of cdist-deploy-to is recommended.
+Cdist currently uses the push approach (a server pushes out the
+configuration to the clients), but future version will also support the
+pull mechanism (client requests configuration).
Copyright (C) 2010-2011 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).