cdist-config - Read basic cdist configuration
Cdist-config is sourced by cdist programs and provides hints on where to find
-types, manifests, etc. Generally speaking, it’s just usable from within the
-core and is only of interest for cdist-developers.
The following list contains environment variables that are known
-to be changed by users in various situations. To change the variable,
-use your current shell and export it, so all cdist-binaries know about it.
-
-__cdist_tmp_base_dir
-
-
- Normally this points to /tmp. In case /tmp is not suitable for
- cdist (i.e. has noexec flag setup) you can change this variable
- to point to a better location.
-
If /tmp has the noexec flag, you can use $HOME/.tmp for instance:
export __cdist_tmp_base_dir=$HOME/.tmp
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-env - Setup environment for using cdist
cdist-env outputs two strings suitable for usage in your current shell,
-so you can use cdist from the checkout. cdist-env essentially helps you
-to easily setup PATH and MANPATH.
If you’ve multiple checkouts of cdist and run cdist-env from the various
-checkouts, a new run will prepend the last directory, thus ensures you
-can run it multiple times and does what one expects.
For use in bourne shell variants (like dash, bash, ksh) as well as
-in csh variants (csh, tcsh):
eval `./bin/cdist-env`
For bourne shell, there is also a shorter version:
. ./bin/cdist-env
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-quickstart - Make use of cinit in 5 minutes
cdist-quickstart is an interactive guide to cdist. It should be one
-of the first tools you use when you begin with cdist.
To use cdist-quickstart, add the bin directory to your PATH, execute
-cdist-quickstart and enjoy cdist:
# Bourne shell example
-export PATH=$(pwd -P)/bin:$PATH
-
-# Alternatively, usable for csh and bsh, set's up PATH and MANPATH
-eval `./bin/cdist-env`
-
-# Let's go!
-cdist-quickstart
-
-cdist(7)
-
-
-cdist-env(1)
-
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-type-emulator - Emulate type and record parameters and dependencies
cdist-type-emulator [TYPE ARGS]
cdist-type-emulator is normally called through a link to it of the
-name of a specifc type. It saves the given parameters into
-a parameters directory and the requirements into a require file.
It checks whether the parameters are valid:
-
-are required parameter given?
-
-
-are all other required parameters specified as optional?
-
Your manifest may contain stuff like this:
__addifnosuchline /tmp/linetest --line "test"
-
-__motd
In both cases, cdist-type-emulator is called instead of a real type.
-In the first case, the object id "/tmp/linetest" is recorded and the
-parameter "line" stored with the content "test".
In the second case, __motd must be decleared as a singleton, as the
-object id is missing.
-
-cdist(7)
-
-
-cdist-type-build-emulation(1)
-
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 - 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 the cdist run 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. UNDERSTANDING CDIST INTERNALS
IF you are interested in how cdist internally works, you can open
-bin/cdist-config and bin/cdist-deploy-to in your favorite editor and
-read the scripts bin/cdist-deploy-to calls. The magnificent HACKERS_README
-may be of great help as well.
5. 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.
6. CODING CONVENTIONS (CORE)
-
-All variables exported by cdist are prefixed with a double underscore (__)
-
-
-All cdist-internal variables are prefixed with _cdist and are generally not exported.
-
7. 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
-
-
-Code submissions should be in your master branch
-
-
-Other branches are fine as well, but you need to tell me which branch
- your work is in!
-
-
-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.
8. 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
-
-
-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.
- See cdist-config(1).
-
The following types are available:
-
-__addifnosuchline (cdist-type__addifnosuchline(7))
-
-
-__apt_ppa (cdist-type__apt_ppa(7))
-
-
-__apt_update_index (cdist-type__apt_update_index(7))
-
-
-__autofs_map (cdist-type__autofs_map(7))
-
-
-__autofs_master (cdist-type__autofs_master(7))
-
-
-__debconf_set_selections (cdist-type__debconf_set_selections(7))
-
-
-__directory (cdist-type__directory(7))
-
-
-__file (cdist-type__file(7))
-
-
-__group (cdist-type__group(7))
-
-
-__issue (cdist-type__issue(7))
-
-
-__key_value (cdist-type__key_value(7))
-
-
-__link (cdist-type__link(7))
-
-
-__motd (cdist-type__motd(7))
-
-
-__package_apt (cdist-type__package_apt(7))
-
-
-__package_pacman (cdist-type__package_pacman(7))
-
-
-__package_pkg_openbsd (cdist-type__package_pkg_openbsd(7))
-
-
-__package_rubygem (cdist-type__package_rubygem(7))
-
-
-__package (cdist-type__package(7))
-
-
-__package_yum (cdist-type__package_yum(7))
-
-
-__partition_msdos_apply (cdist-type__partition_msdos_apply(7))
-
-
-__partition_msdos (cdist-type__partition_msdos(7))
-
-
-__postgres_database (cdist-type__postgres_database(7))
-
-
-__postgres_role (cdist-type__postgres_role(7))
-
-
-__process (cdist-type__process(7))
-
-
-__removeline (cdist-type__removeline(7))
-
-
-__ssh_authorized_key (cdist-type__ssh_authorized_key(7))
-
-
-__timezone (cdist-type__timezone(7))
-
-
-__user (cdist-type__user(7))
-
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
-
-
-__object_fq
-
-
- 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
-
-
-__target_user
-
-
- User to use for authentication on remote host.
- Currently static in core.
-
-
-__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.
Related documentation:
- - cdist-explorer-run-global(1)
- - cdist-remote-explorer-run(1)
- - cdist-explorer(7)
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.
Related documentation:
- - cdist-manifest-run-init(1)
- - cdist-manifest-run(1)
- - cdist-manifest(7)
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.
Related documentation:
- - cdist-object-explorer-run(1)
- - cdist-remote-explorer-run(1)
- - cdist-type(7)
- - cdist-explorer(7)
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.
Related documentation:
- - cdist-object-manifest-run(1)
- - cdist-manifest-run(1)
- - cdist-type(7)
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.
Related documentation:
- - cdist-object-gencode-run(1)
- - cdist-object-gencode(1)
- - cdist-type(7)
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.
Related documentation:
- - cdist-object-code-run(1)
- - cdist-code-run(1)
The cache stores the information from the current run for later use.
Related documentation:
- - cdist-cache(1)
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(7)
-
-
-cdist-deploy-to(1)
-
-
-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
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
Internally cdist-type-emulator(1) will be called from cdist-manifest-run(1) to
-save the given parameters into a cconfig database, so they can be accessed by
-the manifest and gencode scripts of the type (see below).
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-environment-variables(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__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__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
-# extended
-__partition_msdos /dev/sda3 --type extended --size 100G
-# 10GB, linux
-__partition_msdos /dev/sda5 --type 83 --size 10G
-# 50% of free space, linux
-__partition_msdos /dev/sda6 --type 83 --size 50%
-# rest of disk, linux
-__partition_msdos /dev/sda7 --type 83 --size +
-# same thing as
-__partition_msdos /dev/sda7 --type 83
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"
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).