cdist is the frontend executable to the cdist configuration management.
cdist supports different as explained below. The options to the main
program are:
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
diff --git a/software/cdist/man/2.0.5/man7/cdist-bootstrap.html b/software/cdist/man/2.0.5/man7/cdist-bootstrap.html
deleted file mode 100644
index c6226f7b..00000000
--- a/software/cdist/man/2.0.5/man7/cdist-bootstrap.html
+++ /dev/null
@@ -1,77 +0,0 @@
-
-
-
This document describes the usual steps recommended for a new
-cdist setup. It is recommended that you have read and understood
-cdist-quickstart(7) before digging into this.
3. LOCATION
First of all, you should think about where to store your configuration
-database and who will be accessing or changing it. Secondly you have to
-think about where to configure your hosts from, which may be a different
-location.
For starters, having cdist (which includes the configuration database) on
-your notebook should be fine.
-Additionally an external copy of the git repository the configuration
-relies in is recommended, for use as backup as well to allow easy collaboration
-with others.
For more sophisticated setups developing cdist configurations with multiple
-people, have a look at cdist-best-practice(7).
4. SETUP WORKING DIRECTORY AND BRANCH
I assume you have a fresh copy of the cdist tree in ~/cdist, cloned from
-one of the official urls (see cdist-quickstart(7) if you don’t).
-Entering the command "git branch" should show you "* master", which indicates
-you are on the master branch.
The master branch reflects the latest development of cdist. As this is the
-development branch, it may or may not work. There are also version branches
-available, which are kept in a stable state. Let’s use git branch -r
-to list all branches:
So 2.0 is the latest version branch in this example.
-All versions (2.0.x) within one version branch (2.0) are compatible to each
-other and won’t break your configuration when updating.
It’s up to you decide on which branch you want to base your own work:
-master contains more recent changes, newer types, but may also break.
-The versions branches are stable, but thus may miss the latest features.
-Your decision can be changed later on, but may result in merge conflicts,
-which you’d have to solve.
Let’s assume you want latest stuff and select the master branch as base for
-your own work. Now it’s time to create your branch, which contains your
-local changes. I usually name it by the company/area I am working for:
-ethz-systems, localch, customerX, … But this is pretty much up to you.
In this tutorial I use the branch mycompany:
cdist% git checkout -b mycompany origin/master
-Branch mycompany set up to track remote branch master from origin.
-Switched to a new branch 'mycompany'
-cdist-user% git branch
- master
-* mycompany
From now on, you can use git as usual to commit your changes in your own branch.
5. PUBLISHING THE CONFIGURATION
Usually a development machine like a notebook should be considered
-temporary only. For this reason and to enable shareability, the configuration
-should be published to another device as early as possible. The following
-example shows how to publish the configuration to another host that is
-reachable via ssh and has git installed:
# Create bare git repository on the host named "loch"
-cdist% ssh loch "GIT_DIR=/home/nutzer/cdist git init"
-Initialized empty Git repository in /home/nutzer/cdist/
-
-# Add remote git repo to git config
-cdist% git remote add loch loch:/home/nutzer/cdist
-
-# Configure the mycompany branch to push to loch
-cdist% git config branch.mycompany.remote loch
-
-# Configure mycompany branch to push into remote master branch
-cdist% git config branch.mycompany.merge refs/heads/master
-
-# Push mycompany branch to remote branch master initially
-cdist% git push loch mycompany:refs/heads/master
Now you have setup the git repository to synchronise the mycompany
-branch with the master branch on the host loch. Thus you can commit
-as usual in your branch and push out changes by entering git push.
6. UPDATING FROM ORIGIN
Whenever you want to update your cdist installation, you can use git to do so:
# Update git repository with latest changes from origin
-cdist% git fetch origin
-
-# Update current branch with master branch from origin
-cdist% git merge origin/master
-
-# Alternative: Update current branch with 2.0 branch from origin
-cdist% git merge origin/2.0
7. SEE ALSO
-cdist(1)
-
-cdist-tutorial(7)
-
8. COPYING
Copyright (C) 2012 Nico Schottelius. Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).
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.
3. EXAMPLES
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
4. SEE ALSO
-cdist(1)
-
-cdist-reference(7)
-
-cdist-stages(7)
-
5. COPYING
Copyright (C) 2010-2012 Nico Schottelius. Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).
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.
3. REPORTING BUGS
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] " or create an issue on github.
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.
Indention is 4 spaces (welcome to the python world).
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. Use ./build man to test.
-
-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).
7. SEE ALSO
-cdist(7)
-
8. COPYING
Copyright (C) 2011-2012 Nico Schottelius. Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).
Manifests are used to define which objects to create.
-Objects are instances of types, like in object orientated programming languages.
-An object is represented by the combination of
-type + slash + object name: file/etc/cdist-configured is an
-object of the type file with the name etc/cdist-configured.
All available types can be found in the conf/type/ directory,
-use ls conf/type to get the list of available types. If you have
-setup the MANPATH correctly, you can use man cdist-reference to access
-the reference with pointers to the manpages.
Types in manifests are used like normal command line tools. Let’s have a look
-at an example:
# Create object of type __package with the parameter state = removed
-__package apache2 --state removed
-
-# Same with the __directory type
- __directory /tmp/cdist --state present
These two lines create objects, which will later be used to realise the
-configuration on the target host.
Manifests are executed locally as a shell script using /bin/sh -e.
-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.
3. INITIAL AND TYPE MANIFESTS
Cdist nows about two types of manifests: The initial manifest and type
-manifests. The initial manifest is used to define, which configurations
-to apply to which hosts. The type manifests are used to create objects
-from types. More about manifests in types can be found in cdist-type(7).
4. DEFINE STATE IN THE INITIAL MANIFEST
The initial manifest is the entry point for cdist to find out, which
-objects to configure on the selected host.
-Cdist searches for the initial manifest at conf/manifest/init.
Within this initial manifest, you define, which objects should be
-created on which host. To distinguish between hosts, you can use the
-environment variable __target_host. Let’s have a look at a simple
-example:
This manifest says: Independent of the host, always use the type
-__cdistmarker, which creates the file /etc/cdist-configured,
-with the timestamp as content.
-The directory /home/services/kvm-vm, including all parent directories,
-is only created on the host localhost.
As you can see, there is no magic involved, the manifest is simple shell code that
-utilises cdist types. Every available type can be executed like a normal
-command.
5. SPLITTING UP THE INITIAL MANIFEST
If you want to split up your initial manifest, you can create other shell
-scripts in conf/manifest/ and include them in conf/manifest/init.
-Cdist provides the environment variable __manifest to reference to
-the directory containing the initial manifest (see cdist-reference(7)).
The following example would include every file with a .sh suffix:
# Include *.sh
-for manifest in $__manifest/*.sh; do
- # And source scripts into our shell environment
- . "$manifest"
-done
6. DEPENDENCIES
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.
All objects that are created in a type manifest are automatically required
-from the type that is calling them. This is called "autorequirement" in
-cdist jargon.
7. EXAMPLES
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:
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 replace localhost with your target
-host for real life usage.
3. QUICK START - GET YOUR HANDS DIRTY NOW
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
Have a look at ssh-agent(1) and ssh-add(1) on how to cache the password for
-your public key. Usually it looks like this:
# Start agent and export variables
-eval `ssh-agent`
-
-# Add keys (requires password for every identity file)
-ssh-add
At this point you should be able to ssh root@localhost without
-re-entering the password. If something failed until here, ensure that
-all steps went successfully and you have read and understood the
-documentation.
As soon as you are able to login without password to localhost,
-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
-
-# Configure localhost in verbose mode
-./bin/cdist config -v localhost
-
-# Find out that cdist created /etc/cdist-configured
-ls -l /etc/cdist-configured
That’s it, you’ve successfully used cdist to configure your first host!
-Continue reading the next sections, to understand what you did and how
-to create a more sophisticated configuration.
4. SEE ALSO
-cdist(1)
-
-cdist-tutorial(7)
-
5. COPYING
Copyright (C) 2011-2012 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
2. EXPLORERS
The following global explorers are available:
-hostname
-
-lsb_codename
-
-lsb_description
-
-lsb_id
-
-lsb_release
-
-machine
-
-os
-
-os_version
-
3. PATHS
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 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 (required 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.
-
4. TYPES
The following types are available:
-_* (cdist-type_*(7))
-
5. OBJECTS
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)
-
6. ENVIRONMENT VARIABLES
-__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.
- Will be removed in cdist 3.x.
-
-__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
-
7. SEE ALSO
-cdist(1)
-
8. COPYING
Copyright (C) 2011-2012 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
2. DESCRIPTION
Starting the execution of deployment with cdist, cdist passes
-through different stages.
3. 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.
4. 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.
5. STAGE 3: OBJECT INFORMATION RETRIEVAL
Every object is checked whether its type has explorers and if so, these are
-executed on the target host. 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.
6. 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.
7. 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.
8. 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.
9. STAGE 7: CACHE
The cache stores the information from the current run for later use.
10. SUMMARY
If, and only if, all the stages complete without an errors, the configuration
-will be applied to the target.
11. SEE ALSO
-cdist(1)
-
-cdist-reference(7)
-
12. COPYING
Copyright (C) 2010-2012 Nico Schottelius, Steven Armstrong. Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).
This document gives you a pointer on what to read in
-which order and is thus a "guide to the right locations".
-So in case you are just starting, just "begin at the beginning"
-(Brave New World). You can see the target audience in [] brackets
-after the description.
-cdist-quickstart
-
- New to cdist? Want to get your hands dirty? Read this. [beginner]
-
-cdist-bootstrap
-
- The comprehensive guide to your first cdist installation [beginner]
-
-cdist-manifest
-
- Learn how to define which hosts get which configurations [beginner]
-
-cdist-type
-
- Understand how types are working and created [intermediate]
-
-cdist-best-practice
-
- Hints from real life experience to help you to organise cdist [intermediate]
-
-cdist-reference
-
- The type, explorers and environment variables reference [intermediate]
-
-cdist-explorer
-
- Interested in getting more information about the target system? [intermediate]
-
-cdist-stages
-
- Understand the internal workflow of cdist. [advanced]
-
-cdist-hacker
-
- README, if you want to extend or modify cdist. [hacker]
-
3. SEE ALSO
-cdist(1)
-
-cdist-type(7)
-
-cdist-best-practice(7)
-
-cdist-stages(7)
-
-Brave New World by Aldous Huxley
-
4. COPYING
Copyright (C) 2011-2012 Nico Schottelius. Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).
__TYPE --parameter value [--parameter value …] (for singletons)
3. DESCRIPTION
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.
4. HOW TO USE A TYPE
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.
5. SINGLETON TYPES
If a type is flagged as a singleton, it may be used only
-once per host. This is useful for types which can be used only once on a
-system. Singleton types do not take an object name as argument.
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 executables in $PATH.
To begin a new type, just create the directory conf/type/__NAME.
7. DEFINING PARAMETERS
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.
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. For more information about manifests see cdist-manifest(7).
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:
touch conf/type/__NAME/singleton
This will also change the way your type must be called:
__YOURTYPE --parameter value
As you can see, the object ID is omitted, because it does not make any sense,
-if your type can be used only once.
10. THE TYPE EXPLORERS
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 the 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 scripts can make use of the parameters, the global explorers
-and the type specific explorers. The output (stdout) of these script is
-saved by cdist and will be executed on the target.
If the gencode scripts encounter 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
-or open a pull request at http://github.com/telmich/cdist.
Ensure a corresponding manpage named man.text in asciidoc format with
-the manpage-name "cdist-type__NAME" is included in the type directory.
14. SEE ALSO
-cdist-explorer(7)
-
-cdist-stages(7)
-
-cdist-tutorial(7)
-
15. COPYING
Copyright (C) 2011-2012 Nico Schottelius. Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).
cdist-type__addifnosuchline - Add a line (if not existing already)
2. DESCRIPTION
This type can be used to check a file for existence of a
-specific line and adding it, if it was not found.
3. REQUIRED PARAMETERS
-line
-
- Specifies the content which shall be added if not existing.
-
4. OPTIONAL PARAMETERS
-file
-
- If supplied, use this as the destination file.
- Otherwise the object_id is used.
-
-regex
-
- If supplied, search for this regex.
- Otherwise entire line must be matched.
-
5. EXAMPLES
# 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
6. SEE ALSO
-cdist-type(7)
-
7. COPYING
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__cdistmarker - Add a timestamped cdist marker.
2. DESCRIPTION
This type is used to add a common marker file which indicates that a given
-machine is being managed by cdist. The contents of this file consist of a
-timestamp, which can be used to determine the most recent time at which cdist
-was run against the machine in question.
3. REQUIRED PARAMETERS
None.
4. OPTIONAL PARAMETERS
-destination
-
- The path and filename of the marker.
- Default: /etc/cdist-configured
-
-format
-
- The format of the timestamp. This is passed directly to system date.
- Default: -u
-
5. EXAMPLES
# Creates the marker as normal.
-__cdistmarker
-
-# Creates the marker differently.
-__cdistmarker --file /tmp/cdist_marker --format '+%s'
6. SEE ALSO
-cdist-type(7)
-
7. COPYING
Copyright (C) 2011 Daniel Maher. Free use of this software is granted under
-the terms of the GNU General Public License version 3 (GPLv3).
On Debian and alike systems debconf-set-selections(1) can be used
-to setup configuration parameters.
3. REQUIRED PARAMETERS
-file
-
- If supplied, use the given filename as input for debconf-set-selections(1)
-
4. EXAMPLES
# 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"
5. SEE ALSO
-cdist-type(7)
-
6. COPYING
Copyright (C) 2011 Nico Schottelius. Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).
This cdist type allows you to create or modify groups on the target.
3. REQUIRED PARAMETERS
None.
4. OPTIONAL PARAMETERS
-gid
-
- see groupmod(8)
-
-password
-
- see above
-
5. EXAMPLES
# 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'
6. SEE ALSO
-cdist-type(7)
-
7. COPYING
Copyright (C) 2011 Steven Armstrong. Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).
This cdist type allows you to install or uninstall packages on the target.
-It dispatches the actual work to the package system dependant types.
3. REQUIRED PARAMETERS
-state
-
- The state the package should be in, either "installed" or "removed"
-
4. OPTIONAL PARAMETERS
-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
-
5. EXAMPLES
# 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
6. SEE ALSO
-cdist-type(7)
-
7. COPYING
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 - Manage packages with apt-get
2. DESCRIPTION
apt-get is usually used on Debian and variants (like Ubuntu) to
-manage packages.
3. REQUIRED PARAMETERS
-state
-
- Either "installed" or "removed".
-
4. OPTIONAL PARAMETERS
-name
-
- If supplied, use the name and not the object id as the package name.
-
5. EXAMPLES
# 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
6. SEE ALSO
-cdist-type(7)
-
-cdist-type__package(7)
-
7. COPYING
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_yum - Manage packages with yum
2. DESCRIPTION
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".
3. REQUIRED PARAMETERS
-state
-
- Either "installed" or "removed".
-
4. OPTIONAL PARAMETERS
-name
-
- If supplied, use the name and not the object id as the package name.
-
5. EXAMPLES
# 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
6. SEE ALSO
-cdist-type(7)
-
-cdist-type__package(7)
-
7. COPYING
Copyright (C) 2011 Nico Schottelius. Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).
This cdist type allows you to create msdos paritions.
3. REQUIRED PARAMETERS
-type
-
- the partition type used in fdisk (such as 82 or 83) or "extended"
-
4. OPTIONAL PARAMETERS
-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 +.
-
5. EXAMPLES
# 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 +
6. SEE ALSO
-cdist-type(7)
-
7. COPYING
Copyright (C) 2011 Steven Armstrong. Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).
This cdist type allows you to define the state of a process.
3. REQUIRED PARAMETERS
-state
-
- State of the process: Either stopped or running.
-
4. OPTIONAL PARAMETERS
-name
-
- Process name to match on when using pgrep -f -x.
-
This is useful, if the name starts with a "/",
-because the leading slash is stripped away from
-the object id by cdist.
-stop
-
- Executable to use for stopping the process.
-
-start
-
- Executable to use for starting the process.
-
5. EXAMPLES
# 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.*"
6. SEE ALSO
-cdist-type(7)
-
7. COPYING
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 - Remove a line (if existing)
2. DESCRIPTION
This type can be used to check a file for existence of a
-specific line and removeing it, if it was found.
3. REQUIRED PARAMETERS
-line
-
- Specifies the content which shall be removed if existing.
-
4. OPTIONAL PARAMETERS
-file
-
- If supplied, use this as the destination file.
- Otherwise the object_id is used.
-
5. EXAMPLES
# 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
6. SEE ALSO
-cdist-type(7)
-
7. COPYING
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 - Sends a user’s public key to another user’s authorized_keys
2. DESCRIPTION
This type sends a rsa key. By default uses root’s key and sends it to root’s authorized_keys
3. REQUIRED PARAMETERS
None.
4. OPTIONAL PARAMETERS
-srcuser
-
-the user to take the rsa public key from
-
-dstuser
-
-the user to give the rsa public key to
-
5. EXAMPLES
#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
6. SEE ALSO
-cdist-type(7)
-
7. COPYING
Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).
This cdist type allows you to create or modify users on the target.
3. REQUIRED PARAMETERS
None.
4. OPTIONAL PARAMETERS
-comment
-
- see usermod(8)
-
-home
-
- see above
-
-gid
-
- see above
-
-groups
-
- see above
-
-password
-
- see above
-
-shell
-
- see above
-
-uid
-
- see above
-
5. EXAMPLES
# 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
6. SEE ALSO
-cdist-type(7)
-
7. COPYING
Copyright (C) 2011 Steven Armstrong. Free use of this software is
-granted under the terms of the GNU General Public License version 3 (GPLv3).