tom/cdist
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

docs/man -> docs/src and update Makefile and build-helper.

Browse source
This commit is contained in:
Darko Poljak 2016-06-30 15:05:26 +02:00
commit 0d64d6a5b6
30 changed files with 28 additions and 31 deletions
Download patch file Download diff file Expand all files Collapse all files

237
docs/src/Makefile Normal file
View file

@ -0,0 +1,237 @@
# Makefile for Sphinx documentation
#
# You can set these variables from the command line.
SPHINXOPTS =
SPHINXBUILD = sphinx-build
PAPER =
BUILDDIR = ../dist
# for cache, etc.
_BUILDDIR = _build
# User-friendly check for sphinx-build
ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don\'t have Sphinx installed, grab it from http://sphinx-doc.org/)
endif
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
PAPEROPT_letter = -D latex_paper_size=letter
ALLSPHINXOPTS = -d $(_BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
# the i18n builder cannot share the environment and doctrees with the others
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
.PHONY: help
help:
@echo "Please use \`make <target>' where <target> is one of"
@echo " html to make standalone HTML files"
@echo " dirhtml to make HTML files named index.html in directories"
@echo " singlehtml to make a single large HTML file"
@echo " pickle to make pickle files"
@echo " json to make JSON files"
@echo " htmlhelp to make HTML files and a HTML help project"
@echo " qthelp to make HTML files and a qthelp project"
@echo " applehelp to make an Apple Help Book"
@echo " devhelp to make HTML files and a Devhelp project"
@echo " epub to make an epub"
@echo " epub3 to make an epub3"
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
@echo " latexpdf to make LaTeX files and run them through pdflatex"
@echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
@echo " text to make text files"
@echo " man to make manual pages"
@echo " texinfo to make Texinfo files"
@echo " info to make Texinfo files and run them through makeinfo"
@echo " gettext to make PO message catalogs"
@echo " changes to make an overview of all changed/added/deprecated items"
@echo " xml to make Docutils-native XML files"
@echo " pseudoxml to make pseudoxml-XML files for display purposes"
@echo " linkcheck to check all external links for integrity"
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
@echo " coverage to run coverage check of the documentation (if enabled)"
@echo " dummy to check syntax errors of document sources"
.PHONY: clean
clean:
rm -rf $(BUILDDIR)/*
rm -rf $(_BUILDDIR)/*
.PHONY: html
html:
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
.PHONY: dirhtml
dirhtml:
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
.PHONY: singlehtml
singlehtml:
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
@echo
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
.PHONY: pickle
pickle:
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
@echo
@echo "Build finished; now you can process the pickle files."
.PHONY: json
json:
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
@echo
@echo "Build finished; now you can process the JSON files."
.PHONY: htmlhelp
htmlhelp:
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
@echo
@echo "Build finished; now you can run HTML Help Workshop with the" \
".hhp project file in $(BUILDDIR)/htmlhelp."
.PHONY: qthelp
qthelp:
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
@echo
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
".qhcp project file in $(BUILDDIR)/qthelp, like this:"
@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/cdist-docs.qhcp"
@echo "To view the help file:"
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/cdist-docs.qhc"
.PHONY: applehelp
applehelp:
$(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
@echo
@echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
@echo "N.B. You won't be able to view it unless you put it in" \
"~/Library/Documentation/Help or install it in your application" \
"bundle."
.PHONY: devhelp
devhelp:
$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
@echo
@echo "Build finished."
@echo "To view the help file:"
@echo "# mkdir -p $$HOME/.local/share/devhelp/cdist-docs"
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/cdist-docs"
@echo "# devhelp"
.PHONY: epub
epub:
$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
@echo
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
.PHONY: epub3
epub3:
$(SPHINXBUILD) -b epub3 $(ALLSPHINXOPTS) $(BUILDDIR)/epub3
@echo
@echo "Build finished. The epub3 file is in $(BUILDDIR)/epub3."
.PHONY: latex
latex:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
@echo "Run \`make' in that directory to run these through (pdf)latex" \
"(use \`make latexpdf' here to do that automatically)."
.PHONY: latexpdf
latexpdf:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo "Running LaTeX files through pdflatex..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
.PHONY: latexpdfja
latexpdfja:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo "Running LaTeX files through platex and dvipdfmx..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
.PHONY: text
text:
$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
@echo
@echo "Build finished. The text files are in $(BUILDDIR)/text."
.PHONY: man
man:
$(SPHINXBUILD) -b cman $(ALLSPHINXOPTS) $(BUILDDIR)/man
mkdir -p $(BUILDDIR)/man/man1
mkdir -p $(BUILDDIR)/man/man7
mv -f $(BUILDDIR)/man/*.1 $(BUILDDIR)/man/man1/
mv -f $(BUILDDIR)/man/*.7 $(BUILDDIR)/man/man7/
@echo
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
.PHONY: texinfo
texinfo:
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo
@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
@echo "Run \`make' in that directory to run these through makeinfo" \
"(use \`make info' here to do that automatically)."
.PHONY: info
info:
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo "Running Texinfo files through makeinfo..."
make -C $(BUILDDIR)/texinfo info
@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
.PHONY: gettext
gettext:
$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
@echo
@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
.PHONY: changes
changes:
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
@echo
@echo "The overview file is in $(BUILDDIR)/changes."
.PHONY: linkcheck
linkcheck:
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
@echo
@echo "Link check complete; look for any errors in the above output " \
"or in $(BUILDDIR)/linkcheck/output.txt."
.PHONY: doctest
doctest:
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
@echo "Testing of doctests in the sources finished, look at the " \
"results in $(BUILDDIR)/doctest/output.txt."
.PHONY: coverage
coverage:
$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
@echo "Testing of coverage in the sources finished, look at the " \
"results in $(BUILDDIR)/coverage/python.txt."
.PHONY: xml
xml:
$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
@echo
@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
.PHONY: pseudoxml
pseudoxml:
$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
@echo
@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
.PHONY: dummy
dummy:
$(SPHINXBUILD) -b dummy $(ALLSPHINXOPTS) $(BUILDDIR)/dummy
@echo
@echo "Build finished. Dummy builder generates no files."

223
docs/src/cdist-best-practice.rst Normal file
View file

@ -0,0 +1,223 @@
Best practice
=============
Practices used in real environments
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).
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
Speeding up shell execution
----------------------------
On the source host, ensure that /bin/sh is *not* bash: bash is quite slow for
script execution. Instead, you could use dash after installing it::
ln -sf /bin/dash /bin/sh
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
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"
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 across 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
Multiple developers with different trust
----------------------------------------
If you are working in an environment that requires different people to
work on the same configuration, but having different privileges, you can
implement this scenario with a gateway host and sudo:
- Create a dedicated user (for instance **cdist**)
- Setup the ssh-pubkey for this user that has the right to configure all hosts
- Create a wrapper to update the cdist configuration in ~cdist/cdist
- Allow every developer to execute this script via sudo as the user cdist
- Allow run of cdist as user cdist on specific hosts on a per user/group base
- f.i. nico ALL=(ALL) NOPASSWD: /home/cdist/bin/cdist config hostabc
For more details consult sudoers(5)
Templating
----------
* create directory files/ in your type (convention)
* create the template as an executable file like files/basic.conf.sh, it will output text using shell variables for the values
.. code-block:: sh
#!/bin/sh
# in the template, use cat << eof (here document) to output the text
# and use standard shell variables in the template
# output everything in the template script to stdout
cat << EOF
server {
listen 80;
server_name $SERVERNAME;
root $ROOT;
access_log /var/log/nginx/$SERVERNAME_access.log
error_log /var/log/nginx/$SERVERNAME_error.log
}
EOF
* in the manifest, export the relevant variables and add the following lines in your manifest:
.. code-block:: console
# export variables needed for the template
export SERVERNAME='test"
export ROOT='/var/www/test'
# render the template
mkdir -p "$__object/files"
"$__type/files/basic.conf.sh" > "$__object/files/basic.conf"
# send the rendered template
__file /etc/nginx/sites-available/test.conf \
--state present
--source "$__object/files/basic.conf"
Testing a new type
------------------
If you want to test a new type on a node, you can tell cdist to only use an
object of this type: Use the '--initial-manifest' parameter
with - (stdin) as argument and feed object into stdin
of cdist:
.. code-block:: sh
# Singleton type without parameter
echo __ungleich_munin_server | cdist --initial-manifest - munin.panter.ch
# Singleton type with parameter
echo __ungleich_munin_node --allow 1.2.3.4 | \
cdist --initial-manifest - rails-19.panter.ch
# Normal type
echo __file /tmp/stdintest --mode 0644 | \
cdist --initial-manifest - cdist-dev-01.ungleich.ch
Other content in cdist repository
---------------------------------
Usually the cdist repository contains all configuration
items. Sometimes you may have additional resources that
you would like to store in your central configuration
repositiory (like password files from KeepassX,
Libreoffice diagrams, etc.).
It is recommended to use a subfolder named "non-cdist"
in the repository for such content: It allows you to
easily distinguish what is used by cdist and what not
and also to store all important files in one
repository.

118
docs/src/cdist-bootstrap.rst Normal file
View file

@ -0,0 +1,118 @@
Bootstrap
=========
This document describes the usual steps recommended for a new
cdist setup. It is recommended that you have read and understood
`cdist quickstart <cdist-quickstart.html>`_ before digging into this.
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 on is recommended, for use as backup as well as to allow easy collaboration
with others.
For more sophisticated setups developing cdist configurations with multiple
people, have a look at `cdist best practice <cdist-best-practice.html>`_.
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 <cdist-quickstart.html>`_ 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::
cdist% git branch -r
origin/1.0
origin/1.1
origin/1.2
origin/1.3
origin/1.4
origin/1.5
origin/1.6
origin/1.7
origin/2.0
origin/HEAD -> origin/master
origin/archive_shell_function_approach
origin/master
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 to decide which branch you want to base your own work on:
master contains more recent changes, newer types, but may also break.
The version branches are stable, but may lack the latest features.
Your decision can be changed later on, but may result in merge conflicts,
which you will need 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.
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**.
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

54
docs/src/cdist-explorer.rst Normal file
View file

@ -0,0 +1,54 @@
Explorer
========
Description
-----------
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.
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:
.. code-block:: sh
if [ -f "$__object/parameter/name" ]; then
name="$(cat "$__object/parameter/name")"
else
name="$__object_id"
fi
# Expect dpkg failing, if package is not known / installed
dpkg -s "$name" 2>/dev/null || exit 0

48
docs/src/cdist-features.rst Normal file
View file

@ -0,0 +1,48 @@
Features
========
But cdist ticks differently, here is the feature set that makes it unique:
Simplicity
There is only one type to extend cdist called **type**
Design
+ Type and core cleanly seperated
+ Sticks completly to the KISS (keep it simple and stupid) paradigma
+ Meaningful error messages - do not lose time debugging error messages
+ Consistency in behaviour, naming and documentation
+ No surprise factor: Only do what is obviously clear, no magic
+ Define target state, do not focus on methods or scripts
+ Push architecture: Instantly apply your changes
Small core
cdist's core is very small - less code, less bugs
Fast development
Focus on straightforwardness of type creation is a main development objective
Batteries included: A lot of requirements can be solved using standard types
Modern Programming Language
cdist is written in Python
Requirements, Scalability
No central server needed, cdist operates in push mode and can be run from any computer
Requirements, Scalability, Upgrade
cdist only needs to be updated on the master, not on the target hosts
Requirements, Security
Uses well-know `SSH <http://www.openssh.com/>`_ as transport protocol
Requirements, Simplicity
Requires only shell and SSH server on the target
UNIX
Reuse of existing tools like cat, find, mv, ...
UNIX, familar environment, documentation
Is available as manpages and HTML
UNIX, simplicity, familar environment
cdist is configured in POSIX shell

146
docs/src/cdist-hacker.rst Normal file
View file

@ -0,0 +1,146 @@
Hacking
=======
Welcome
-------
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.
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.
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).
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 cdist/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
separate 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, write a mail
for inclusion to the mailinglist **cdist at cdist -- at -- l.schottelius.org**
or open a pull request at http://github.com/telmich/cdist.
How to submit a new type
------------------------
For detailled information about types, see `cdist type <cdist-type.html>`_.
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).
Warning: Submitting "exec" or "run" types that simply echo their parameter in
**gencode** will not be accepted, because they are of no use. Every type can output
code and thus such a type introduces redundant functionality that is given by
core cdist already.
Example git workflow
---------------------
The following workflow works fine for most developers
.. code-block:: sh
# get latest upstream master branch
git clone https://github.com/telmich/cdist.git
# update if already existing
cd cdist; git fetch -v; git merge origin/master
# create a new branch for your feature/bugfix
cd cdist # if you haven't done before
git checkout -b documentation_cleanup
# *hack*
*hack*
# clone the cdist repository on github if you haven't done so
# configure your repo to know about your clone (only once)
git remote add github git@github.com:YOURUSERNAME/cdist.git
# push the new branch to github
git push github documentation_cleanup
# (or everything)
git push --mirror github
# create a pull request at github (use a browser)
# *fixthingsbecausequalityassurancefoundissuesinourpatch*
*hack*
# push code to github again
git push ... # like above
# add comment that everything should be green now (use a browser)
# go back to master branch
git checkout master
# update master branch that includes your changes now
git fetch -v origin
git diff master..origin/master
git merge origin/master
If at any point you want to go back to the original master branch, you can
use **git stash** to stash your changes away::
.. code-block:: sh
# assume you are on documentation_cleanup
git stash
# change to master and update to most recent upstream version
git checkout master
git fetch -v origin
git merge origin/master
Similar when you want to develop another new feature, you go back
to the master branch and create another branch based on it::
.. code-block:: sh
# change to master and update to most recent upstream version
git checkout master
git fetch -v origin
git merge origin/master
git checkout -b another_feature
(you can repeat the code above for as many features as you want to develop
in parallel)

116
docs/src/cdist-install.rst Normal file
View file

@ -0,0 +1,116 @@
How to install cdist
====================
Requirements
-------------
Source Host
~~~~~~~~~~~
This is the machine you use to configure the target hosts.
* /bin/sh: A posix like shell (for instance bash, dash, zsh)
* Python >= 3.2
* SSH client
* sphinx (for building html docs and/or the manpages)
Target Hosts
~~~~~~~~~~~~
* /bin/sh: A posix like shell (for instance bash, dash, zsh)
* SSH server
Install cdist
-------------
You can install cdist either from git or as a python package.
From git
~~~~~~~~
Cloning cdist from git gives you the advantage of having
a version control in place for development of your own stuff
immediately.
To install cdist, execute the following commands:
.. code-block:: sh
git clone https://github.com/ungleich/cdist.git
cd cdist
export PATH=$PATH:$(pwd -P)/bin
Available versions in git
^^^^^^^^^^^^^^^^^^^^^^^^^
* The active development takes place in the **master** branch
* The released versions can be found in the tags
Other branches may be available for features or bugfixes, but they
may vanish at any point. To select a specific branch use
.. code-block:: sh
# Generic code
git checkout -b <localbranchname> origin/<branchname>
So for instance if you want to use and stay with version 4.1, you can use
.. code-block:: sh
git checkout -b 4.1 origin/4.1
Git mirrors
^^^^^^^^^^^
If the main site is down, you can acquire cdist from one of the following sites:
* git://github.com/telmich/cdist.git `github <https://github.com/telmich/cdist>`_
* git://git.code.sf.net/p/cdist/code `sourceforge <https://sourceforge.net/p/cdist/code>`_
Building and using manpages
^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you want to build and use the manpages, run:
.. code-block:: sh
make man
export MANPATH=$MANPATH:$(pwd -P)/docs/dist/man
Or you can move manpages from docs/dist/man directory to some
other directory and add it to MANPATH.
You can also build manpages for types in your ~/.cdist directory:
.. code-block:: sh
make dotman
Built manpages are now in docs/dist/man directory. If you have
some other custom .cdist directory, e.g. /opt/cdist then use:
.. code-block:: sh
DOT_CDIST_PATH=/opt/cdist make dotman
Building and using HTML documentation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you want to build and use HTML documentation, run:
.. code-block:: sh
make html
Now you can access docs/dist/html/index.html.
Python package
~~~~~~~~~~~~~~
Cdist is available as a python package at
`PyPi <http://pypi.python.org/pypi/cdist/>`_. You can install it using
.. code-block:: sh
pip install cdist

15
docs/src/cdist-intro.rst Normal file
View file

@ -0,0 +1,15 @@
cdist - usable configuration management
=======================================
.. image:: cdist-logo.png
:alt: cdist-logo
cdist is a usable configuration management system.
It adheres to the KISS principle and
is being used in small up to enterprise grade environments.
cdist is an alternative to other configuration management systems like
* `bcfg2 <http://trac.mcs.anl.gov/projects/bcfg2>`_
* `chef <http://wiki.opscode.com/display/chef/>`_
* `cfengine <http://www.cfengine.org/>`_
* `puppet <http://www.puppetlabs.com/>`_.

BIN
docs/src/cdist-logo.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 1.5 KiB

255
docs/src/cdist-manifest.rst Normal file
View file

@ -0,0 +1,255 @@
Manifest
========
Description
-----------
Manifests are used to define which objects to create.
Objects are instances of **types**, like in object oriented 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 **cdist/conf/type/** directory,
use **ls cdist/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 = absent
__package apache2 --state absent
# 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.
Initial and type manifests
--------------------------
Cdist knows 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 <cdist-type.html>`_.
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 expects the initial manifest at **cdist/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::
__cdistmarker
case "$__target_host" in
localhost)
__directory /home/services/kvm-vm --parents yes
;;
esac
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.
Splitting up the initial manifest
---------------------------------
If you want to split up your initial manifest, you can create other shell
scripts in **cdist/conf/manifest/** and include them in **cdist/conf/manifest/init**.
Cdist provides the environment variable **__manifest** to reference
the directory containing the initial manifest (see `cdist reference <cdist-reference.html>`_).
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
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 separated.
::
1 # No dependency
2 __file /etc/cdist-configured
3
4 # Require above object
5 require="__file/etc/cdist-configured" __link /tmp/cdist-testfile \
6 --source /etc/cdist-configured --type symbolic
7
8 # Require two objects
9 require="__file/etc/cdist-configured __link/tmp/cdist-testfile" \
10 __file /tmp/cdist-another-testfile
Above the "require" variable is only set for the command that is
immediately following it. Dependencies should always be declared that way.
On line 4 you can see that the instantion of a type "\__link" object needs
the object "__file/etc/cdist-configured" to be present, before it can proceed.
This also means that the "\__link" command must make sure, that either
"\__file/etc/cdist-configured" allready is present, or, if it's not, it needs
to be created. The task of cdist is to make sure, that the dependency will be
resolved appropriately and thus "\__file/etc/cdist-configured" be created
if necessary before "__link" proceeds (or to abort execution with an error).
If you really need to make all types depend on a common dependency, you can
export the "require" variable as well. But then, if you need to add extra
dependencies to a specific type, you have to make sure that you append these
to the globally already defined one.
::
# First of all, update the package index
__package_update_index
# Upgrade all the installed packages afterwards
require="__package_update_index" __package_upgrade_all
# Create a common dependency for all the next types so that they get to
# be executed only after the package upgrade has finished
export require="__package_upgrade_all"
# Ensure that lighttpd is installed after we have upgraded all the packages
__package lighttpd --state present
# Ensure that munin is installed after lighttpd is present and after all
# the packages are upgraded
require="$require __package/lighttpd" __package munin --state present
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.
You can find an more in depth description of the flow execution of manifests
in `cdist execution stages <cdist-stages.html>`_ and of how types work in `cdist type <cdist-type.html>`_.
Create dependencies from execution order
-----------------------------------------
You can tell cdist to execute all types in the order in which they are created
in the manifest by setting up the variable CDIST_ORDER_DEPENDENCY.
When cdist sees that this variable is setup, the current created object
automatically depends on the previously created object.
It essentially helps you to build up blocks of code that build upon each other
(like first creating the directory xyz than the file below the directory).
Overrides
---------
In some special cases, you would like to create an already defined object
with different parameters. In normal situations this leads to an error in cdist.
If you wish, you can setup the environment variable CDIST_OVERRIDE
(any value or even empty is ok) to tell cdist, that this object override is
wanted and should be accepted.
ATTENTION: Only use this feature if you are 100% sure in which order
cdist encounters the affected objects, otherwise this results
in an undefined situation.
If CDIST_OVERRIDE and CDIST_ORDER_DEPENDENCY are set for an object,
CDIST_ORDER_DEPENDENCY will be ignored, because adding a dependency in case of
overrides would result in circular dependencies, which is an error.
Examples
--------
The initial manifest may for instance contain the following code:
.. code-block:: sh
# Always create this file, so other sysadmins know cdist is used.
__file /etc/cdist-configured
case "$__target_host" in
my.server.name)
__directory /root/bin/
__file /etc/issue.net --source "$__manifest/issue.net
;;
esac
The manifest of the type "nologin" may look like this:
.. code-block:: sh
__file /etc/nologin --source "$__type/files/default.nologin"
This example makes use of dependencies:
.. code-block:: sh
# Ensure that lighttpd is installed
__package lighttpd --state present
# Ensure that munin makes use of lighttpd instead of the default webserver
# package as decided by the package manager
require="__package/lighttpd" __package munin --state present
How to override objects:
.. code-block:: sh
# for example in the inital manifest
# create user account foobar with some hash for password
__user foobar --password 'some_fancy_hash' --home /home/foobarexample
# ... many statements and includes in the manifest later ...
# somewhere in a conditionally sourced manifest
# (e.g. for example only sourced if a special application is on the target host)
# this leads to an error ...
__user foobar --password 'some_other_hash'
# this tells cdist, that you know that this is an override and should be accepted
CDIST_OVERRIDE=yes __user foobar --password 'some_other_hash'
# it's only an override, means the parameter --home is not touched
# and stays at the original value of /home/foobarexample
Dependencies defined by execution order work as following:
.. code-block:: sh
# Tells cdist to execute all types in the order in which they are created ...
export CDIST_ORDER_DEPENDENCY=on
__sample_type 1
require="__some_type_somewhere/id" __sample_type 2
__example_type 23
# Now this types are executed in the creation order until the variable is unset
unset CDIST_ORDER_DEPENDENCY
# all now following types cdist makes the order ..
__not_in_order_type 42
# how it works :
# this lines above are translated to:
__sample_type 1
require="__some_type_somewhere/id __sample_type/1" __sample_type 2
require="__sample_type/2" __example_type 23
__not_in_order_type 42

94
docs/src/cdist-messaging.rst Normal file
View file

@ -0,0 +1,94 @@
Messaging
=========
Description
-----------
cdist has a simple but powerful way of allowing communication between
the initial manifest and types as well as types and types.
Whenever execution is passed from cdist to one of the
scripts described below, cdist generate 2 new temporary files
and exports the environment variables **__messages_in** and
**__messages_out** to point to them.
Before handing over the control, the content of the global message
file is copied into the file referenced by **$__messages_in**.
After cdist gained control back, the content of the file referenced
by **$__messages_out** is appended to the global message file.
This way overwriting any of the two files by accident does not
interfere with other types.
The order of execution is not defined unless you create dependencies
between the different objects (see `cdist manifest <cdist-manifest.html>`_) and thus you
can only react reliably on messages by objects that you depend on.
Availability
------------
Messaging is possible between all **local** scripts:
- initial manifest
- type/manifest
- type/gencode-local
- type/gencode-remote
Examples
--------
When you want to emit a message use:
.. code-block:: sh
echo "something" >> "$__messages_out"
When you want to react on a message use:
.. code-block:: sh
if grep -q "^__your_type/object/id:something" "$__messages_in"; then
echo "I do something else"
fi
Some real life examples:
.. code-block:: sh
# Reacting on changes from block for keepalive
if grep -q "^__block/keepalive-vrrp" "$__messages_in"; then
echo /etc/init.d/keepalived restart
fi
# Reacting on changes of configuration files
if grep -q "^__file/etc/one" $__messages_in; then
echo 'for init in /etc/init.d/opennebula*; do $init restart; done'
fi
Restart sshd on changes
.. code-block:: sh
os="$(cat "$__global/explorer/os")"
case "$os" in
centos|redhat|suse)
restart="/etc/init.d/sshd restart"
;;
debian|ubuntu)
restart="/etc/init.d/ssh restart"
;;
*)
cat << eof >&2
Unsupported os $os.
If you would like to have this type running on $os,
you can either develop the changes and send a pull
request or ask for a quote at www.ungleich.ch
eof
exit 1
;;
esac
if grep -q "^__key_value/PermitRootLogin" "$__messages_in"; then
echo $restart
fi

16
docs/src/cdist-os.rst Normal file
View file

@ -0,0 +1,16 @@
Supported Operating Systems
===========================
cdist was tested or is know to run on at least
* `Archlinux <http://www.archlinux.org/>`_
* `Debian <http://www.debian.org/>`_
* `CentOS <http://www.centos.org/>`_
* `Fedora <http://fedoraproject.org/>`_
* `FreeBSD <http://www.freebsd.org>`_
* `Gentoo <http://www.gentoo.org/>`_
* `Mac OS X <http://www.apple.com/macosx/>`_
* `OpenBSD <http://www.openbsd.org>`_
* `Redhat <http://www.redhat.com/>`_
* `Ubuntu <http://www.ubuntu.com/>`_
* `XenServer <http://www.citrix.com/xenserver/>`_

73
docs/src/cdist-quickstart.rst Normal file
View file

@ -0,0 +1,73 @@
Quickstart
==========
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.
For those who just want to configure a system with the
cdist configuration management and do not need (or want)
to understand everything.
This tutorial assumes you are configuring **localhost**, because
it is always available. Just replace **localhost** with your target
host for real life usage.
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
# Mirrors can be found on
# http://www.nico.schottelius.org/software/cdist/install/#index2h4
git clone git://git.schottelius.org/cdist
# Create manifest (maps configuration to host(s)
cd cdist
echo '__file /etc/cdist-configured' > cdist/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.

254
docs/src/cdist-reference.rst.sh Executable file
View file

@ -0,0 +1,254 @@
#!/bin/sh
#
# 2010-2014 Nico Schottelius (nico-cdist at schottelius.org)
# 2014 Daniel Heule (hda at sfs.biz)
#
# This file is part of cdist.
#
# cdist is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# cdist is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with cdist. If not, see <http://www.gnu.org/licenses/>.
#
#
# Generate manpage that lists available types
#
__cdist_pwd="$(pwd -P)"
__cdist_mydir="${0%/*}";
__cdist_abs_mydir="$(cd "$__cdist_mydir" && pwd -P)"
__cdist_myname=${0##*/};
__cdist_abs_myname="$__cdist_abs_mydir/$__cdist_myname"
filename="${__cdist_myname%.sh}"
dest="$__cdist_abs_mydir/$filename"
cd "$__cdist_abs_mydir"
exec > "$dest"
cat << eof
Reference
=========
Variable, path and type reference for cdist
Explorers
---------
The following global explorers are available:
eof
(
cd ../../cdist/conf/explorer
for explorer in $(ls * | LC_ALL=C sort); do
echo "- $explorer"
done
)
cat << eof
Paths
-----
\$HOME/.cdist
The standard cdist configuration directory relative to your home directory
This is usually the place you want to store your site specific configuration
cdist/conf/
The distribution configuration directory
This contains types and explorers to be used
confdir
Cdist will use all available configuration directories and create
a temporary confdir containing links to the real configuration directories.
This way it is possible to merge configuration directories.
By default it consists of everything in \$HOME/.cdist and cdist/conf/.
For more details see cdist(1)
confdir/manifest/init
This is the central entry point.
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.
Its intent is to used to define mapping from configurations to hosts.
confdir/manifest/*
All other files in this directory are not directly used by cdist, but you
can separate configuration mappings, if you have a lot of code in the
conf/manifest/init file. This may also be helpful to have different admins
maintain different groups of hosts.
confdir/explorer/<name>
Contains explorers to be run on the target hosts, see \`cdist explorer <cdist-explorer.html>\`_.
confdir/type/
Contains all available types, which are used to provide
some kind of functionality. See \`cdist type <cdist-type.html>\`_.
confdir/type/<name>/
Home of the type <name>.
This directory is referenced by the variable __type (see below).
confdir/type/<name>/man.rst
Manpage in reStructuredText format (required for inclusion into upstream)
confdir/type/<name>/manifest
Used to generate additional objects from a type.
confdir/type/<name>/gencode-local
Used to generate code to be executed on the source host
confdir/type/<name>/gencode-remote
Used to generate code to be executed on the target host
confdir/type/<name>/parameter/required
Parameters required by type, \n separated list.
confdir/type/<name>/parameter/optional
Parameters optionally accepted by type, \n separated list.
confdir/type/<name>/parameter/default/*
Default values for optional parameters.
Assuming an optional parameter name of 'foo', it's default value would
be read from the file confdir/type/<name>/parameter/default/foo.
confdir/type/<name>/parameter/boolean
Boolean parameters accepted by type, \n separated list.
confdir/type/<name>/explorer
Location of the type specific explorers.
This directory is referenced by the variable __type_explorer (see below).
See \`cdist explorer <cdist-explorer.html>\`_.
confdir/type/<name>/files
This directory is reserved for user data and will not be used
by cdist at any time. It can be used for storing supplementary
files (like scripts to act as a template or configuration files).
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.
Types
-----
The following types are available:
eof
# If there is no such file then ls prints error to stderr,
# so redirect stderr to /dev/null.
for type in $(ls man7/cdist-type__*.rst 2>/dev/null | LC_ALL=C sort); do
no_dir="${type#man7/}";
no_type="${no_dir#cdist-type}";
name="${no_type%.rst}";
manref="${no_dir%.rst}"
man="${manref}(7)"
echo "- $name" "(\`${man} <man7/${manref}.html>\`_)"
done
cat << eof
Objects
-------
For object to object communication and tests, the following paths are
usable within a object directory:
files
This directory is reserved for user data and will not be used
by cdist at any time. It can be used freely by the type
(for instance to store template results).
changed
This empty file exists in an object directory, if the object has
code to be executed (either remote or local)
stdin
This file exists and contains data, if data was provided on stdin
when the type was called.
Environment variables (for reading)
-----------------------------------
The following environment variables are exported by cdist:
__explorer
Directory that contains all global explorers.
Available for: initial manifest, explorer, type explorer, shell
__manifest
Directory that contains the initial manifest.
Available for: initial manifest, type manifest, shell
__global
Directory that contains generic output like explorer.
Available for: initial manifest, type manifest, type gencode, shell
__messages_in
File to read messages from.
Available for: initial manifest, type manifest, type gencode
__messages_out
File to write messages.
Available for: initial manifest, type manifest, type gencode
__object
Directory that contains the current object.
Available for: type manifest, type explorer, type gencode and code scripts
__object_id
The type unique object id.
Available for: type manifest, type explorer, type gencode and code scripts
Note: The leading and the trailing "/" will always be stripped (caused by
the filesystem database and ensured by the core).
Note: Double slashes ("//") will not be fixed and result in an error.
__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: explorer, initial manifest, type explorer, type manifest, type gencode, shell
__type
Path to the current type.
Available for: type manifest, type gencode
__type_explorer
Directory that contains the type explorers.
Available for: type explorer
Environment variables (for writing)
-----------------------------------
The following environment variables influence the behaviour of cdist:
require
Setup dependencies between objects (see \`cdist manifest <cdist-manifest.html>\`_)
CDIST_LOCAL_SHELL
Use this shell locally instead of /bin/sh to execute scripts
CDIST_REMOTE_SHELL
Use this shell remotely instead of /bin/sh to execute scripts
CDIST_OVERRIDE
Allow overwriting type parameters (see \`cdist manifest <cdist-manifest.html>\`_)
CDIST_ORDER_DEPENDENCY
Create dependencies based on the execution order (see \`cdist manifest <cdist-manifest.html>\`_)
CDIST_REMOTE_EXEC
Use this command for remote execution (should behave like ssh)
CDIST_REMOTE_COPY
Use this command for remote copy (should behave like scp)
eof

23
docs/src/cdist-remote-exec-copy.rst Normal file
View file

@ -0,0 +1,23 @@
Remote exec and copy commands
=============================
Cdist interacts with the target host in two ways:
- it executes code (__remote_exec)
- and it copies files (__remote_copy)
By default this is accomplished with ssh and scp respectively.
The default implementations used by cdist are::
__remote_exec: ssh -o User=root -q
__remote_copy: scp -o User=root -q
The user can override these defaults by providing custom implementations and
passing them to cdist with the --remote-exec and/or --remote-copy arguments.
For __remote_exec, the custom implementation must behave as if it where ssh.
For __remote_copy, it must behave like scp.
With this simple interface the user can take total control of how cdist
interacts with the target when required, while the default implementation
remains as simple as possible.

71
docs/src/cdist-stages.rst Normal file
View file

@ -0,0 +1,71 @@
Execution stages
================
Description
-----------
Starting the execution of deployment with cdist, cdist passes
through different stages.
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.
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, if it has different parameters.
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 transferred 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.
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.example.org 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.
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.
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.
Stage 7: cache
--------------
The cache stores the information from the current run for later use.
Summary
-------
If, and only if, all the stages complete without an errors, the configuration
will be applied to the target.

28
docs/src/cdist-support.rst Normal file
View file

@ -0,0 +1,28 @@
Support
-------
IRC
~~~
You can join the development ***IRC channel***
`#cstar on irc.freenode.net <irc://irc.freenode.org/#cstar>`_.
Mailing list
~~~~~~~~~~~~
Bug reports, questions, patches, etc. should be send to the
`cdist mailing list <https://groups.google.com/forum/#!forum/cdist-configuration-management>`_.
Linkedin
~~~~~~~~
If you have an account
at `Linked in <http://www.linkedin.com/>`_,
you can join the
`cdist group <http://www.linkedin.com/groups/cdist-configuration-management-3952797>`_.
Commercial support
~~~~~~~~~~~~~~~~~~
You can request commercial support for cdist from
`my company <http://www.ungleich.ch/>`_.

45
docs/src/cdist-troubleshooting.rst Normal file
View file

@ -0,0 +1,45 @@
Troubleshooting
===============
Error in manifest is not considered an error by cdist
-----------------------------------------------------
Situation: You are executing other scripts from a manifest.
This script fails, but cdist does not recognise the error.
An example script would be something like this:
.. code-block:: sh
% cat ~/.cdist/manifest/init
"$__manifest/special"
% cat ~/.cdist/manifest/special
#!/bin/sh
echo "Here is an unclean exiting script"
somecommandthatdoesnotexist
echo "I continue here although previous command failed"
We can clearly see that **somecommandthatdoesnotexist**
will fail in ~/.cdist/manifest/special. But as the custom
script is not called with the -e flag (exit on failure) of shell,
it does not lead to an error. And thus cdist sees the exit 0
code of the last echo line instead of the failing command.
All scripts executed by cdist carry the -e flag.
To prevent the above from happening, there are three solutions available,
two of which can be used in the calling script:
.. code-block:: sh
# Execute as before, but abort on failure
sh -e "$__manifest/special"
# Source the script in our namespace, runs in a set -e environment:
. "$__manifest/special"
The third solution is to include a shebang header in every script
you write to use the -e flag:
.. code-block:: sh
% cat ~/.cdist/manifest/special
#!/bin/sh -e
...

297
docs/src/cdist-type.rst Normal file
View file

@ -0,0 +1,297 @@
cdist type
==========
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.
Synopsis
--------
.. code-block:: sh
__TYPE ID --parameter value [--parameter value ...]
__TYPE --parameter value [--parameter value ...] (for singletons)
How to use a type
-----------------
You can use types from the initial manifest or the type manifest like a
normal shell command:
.. code-block:: sh
# 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 <cdist-reference.html>`_ manpage.
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:
.. code-block:: sh
# __issue type manages /etc/issue
__issue
# Probably your own type - singletons may use parameters
__myfancysingleton --colour green
How to write a new type
-----------------------
A type consists of
- parameter (optional)
- manifest (optional)
- singleton (optional)
- explorer (optional)
- gencode (optional)
Types are stored below cdist/conf/type/. Their name should always be prefixed with
two underscores (__) to prevent collisions with other executables in $PATH.
To implement a new type, create the directory **cdist/conf/type/__NAME**.
Defining parameters
-------------------
Every type consists of required, optional and boolean parameters, which must
each be declared in a newline separated file in **parameter/required**,
**parameter/required_multiple**, **parameter/optional**,
**parameter/optional_multiple** and **parameter/boolean**.
Parameters which are allowed multiple times should be listed in
required_multiple or optional_multiple respectively. All other parameters
follow the standard unix behaviour "the last given wins".
If either is missing, the type will have no required, no optional, no boolean
or no parameters at all.
Default values for optional parameters can be predefined in
**parameter/default/<name>**.
Example:
.. code-block:: sh
echo servername >> cdist/conf/type/__nginx_vhost/parameter/required
echo logdirectory >> cdist/conf/type/__nginx_vhost/parameter/optional
echo loglevel >> cdist/conf/type/__nginx_vhost/parameter/optional
mkdir cdist/conf/type/__nginx_vhost/parameter/default
echo warning > cdist/conf/type/__nginx_vhost/parameter/default/loglevel
echo server_alias >> cdist/conf/type/__nginx_vhost/parameter/optional_multiple
echo use_ssl >> cdist/conf/type/__nginx_vhost/parameter/boolean
Using parameters
----------------
The parameters given to a type can be accessed and used in all type scripts
(e.g manifest, gencode, explorer). Note that boolean parameters are
represented by file existence. File exists -> True,
file does not exist -> False
Example: (e.g. in cdist/conf/type/__nginx_vhost/manifest)
.. code-block:: sh
# required parameter
servername="$(cat "$__object/parameter/servername")"
# optional parameter
if [ -f "$__object/parameter/logdirectory" ]; then
logdirectory="$(cat "$__object/parameter/logdirectory")"
fi
# optional parameter with predefined default
loglevel="$(cat "$__object/parameter/loglevel")"
# boolean parameter
if [ -f "$__object/parameter/use_ssl" ]; then
# file exists -> True
# do some fancy ssl stuff
fi
# parameter with multiple values
if [ -f "$__object/parameter/server_alias" ]; then
for alias in $(cat "$__object/parameter/server_alias"); do
echo $alias > /some/where/usefull
done
fi
Input from stdin
----------------
Every type can access what has been written on stdin when it has been called.
The result is saved into the **stdin** file in the object directory.
Example use of a type: (e.g. in cdist/conf/type/__archlinux_hostname)
.. code-block:: sh
__file /etc/rc.conf --source - << eof
...
HOSTNAME="$__target_host"
...
eof
If you have not seen this syntax (<< eof) before, it may help you to read
about "here documents".
In the __file type, stdin is used as source for the file, if - is used for source:
.. code-block:: sh
if [ -f "$__object/parameter/source" ]; then
source="$(cat "$__object/parameter/source")"
if [ "$source" = "-" ]; then
source="$__object/stdin"
fi
....
Writing the manifest
--------------------
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:
.. code-block:: sh
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 <cdist-reference.html>`_.
Always ensure the manifest is executable, otherwise cdist will not be able
to execute it. For more information about manifests see `cdist manifest <cdist-manifest.html>`_.
Singleton - one 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:
.. code-block:: sh
touch cdist/conf/type/__NAME/singleton
This will also change the way your type must be called:
.. code-block:: sh
__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.
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):
.. code-block:: sh
if [ -f "$__object/parameter/destination" ]; then
destination="$(cat "$__object/parameter/destination")"
else
destination="/$__object_id"
fi
if [ -e "$destination" ]; then
md5sum < "$destination"
fi
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.
If the gencode scripts 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:
.. code-block:: sh
# 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"
Variable access from the generated scripts
------------------------------------------
In the generated scripts, you have access to the following cdist variables
- __object
- __object_id
but only for read operations, means there is no back copy of this
files after the script execution.
So when you generate a script with the following content, it will work:
.. code-block:: sh
if [ -f "$__object/parameter/name" ]; then
name="$(cat "$__object/parameter/name")"
else
name="$__object_id"
fi
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).
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 have a look at `cdist hacking <cdist-hacker.html>`_ on
how to submit it.

8
docs/src/cdist-types.rst Normal file
View file

@ -0,0 +1,8 @@
cdist types
===========
.. toctree::
:titlesonly:
:glob:
man7/*

188
docs/src/cdist-update.rst Normal file
View file

@ -0,0 +1,188 @@
How to update cdist
===================
Update the git installation
---------------------------
To upgrade cdist in the current branch use
.. code-block:: sh
git pull
# Also update the manpages
./build man
export MANPATH=$MANPATH:$(pwd -P)/doc/man
If you stay on a version branche (i.e. 1.0, 1.1., ...), nothing should break.
The master branch on the other hand is the development branch and may not be
working, break your setup or eat the tree in your garden.
Safely upgrading to new versions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To upgrade to **any** further cdist version, you can take the
following procedure to do a safe upgrade:
.. code-block:: sh
# Create new branch to try out the update
git checkout -b upgrade_cdist
# Get latest cdist version in git database
git fetch -v
# see what will happen on merge - replace
# master with the branch you plan to merge
git diff upgrade_cdist..origin/master
# Merge the new version
git merge origin/master
Now you can ensure all custom types work with the new version.
Assume that you need to go back to an older version during
the migration/update, you can do so as follows:
.. code-block:: sh
# commit changes
git commit -m ...
# go back to original branch
git checkout master
After that, you can go back and continue the upgrade:
.. code-block:: sh
# git checkout upgrade_cdist
Update the python package
-------------------------
To upgrade to the lastet version do
.. code-block:: sh
pip install --upgrade cdist
General update instructions
---------------------------
Updating from 3.0 to 3.1
~~~~~~~~~~~~~~~~~~~~~~~~
The type **\_\_ssh_authorized_keys** now also manages existing keys,
not only the ones added by cdist.
Updating from 2.3 to 3.0
~~~~~~~~~~~~~~~~~~~~~~~~
The **changed** attribute of objects has been removed.
Use `messaging </software/cdist/man/3.0.0/man7/cdist-messaging.html>`_ instead.
Updating from 2.2 to 2.3
~~~~~~~~~~~~~~~~~~~~~~~~
No incompatiblities.
Updating from 2.1 to 2.2
~~~~~~~~~~~~~~~~~~~~~~~~
Starting with 2.2, the syntax for requiring a singleton type changed:
Old format:
.. code-block:: sh
require="__singleton_type/singleton" ...
New format:
.. code-block:: sh
require="__singleton_type" ...
Internally the "singleton" object id was dropped to make life more easy.
You can probably fix your configuration by running the following code
snippet (currently untested, please report back if it works for you):
.. code-block:: sh
find ~/.cdist/* -type f -exec sed -i 's,/singleton,,' {} \;
Updating from 2.0 to 2.1
~~~~~~~~~~~~~~~~~~~~~~~~
Have a look at the update guide for [[2.0 to 2.1|2.0-to-2.1]].
* Type **\_\_package* and \_\_process** use --state **present** or **absent**.
The states **removed/installed** and **stopped/running** have been removed.
Support for the new states is already present in 2.0.
* Type **\_\_directory**: Parameter --parents and --recursive are now boolean
The old "yes/no" values need to be removed.
* Type **\_\_rvm_ruby**: Parameter --default is now boolean
The old "yes/no" values need to be removed.
* Type **\_\_rvm_gemset**: Parameter --default is now boolean
The old "yes/no" values need to be removed.
* Type **\_\_addifnosuchline** and **\_\_removeline** have been replaced by **\_\_line**
* The **conf** directory is now located at **cdist/conf**.
You need to migrate your types, explorers and manifests
manually to the new location.
* Replace the variable **\_\_self** by **\_\_object_name**
Support for the variable **\_\_object_name** is already present in 2.0.
* The types **\_\_autofs**, **\_\_autofs_map** and **\_\_autofs_reload** have been removed
(no maintainer, no users)
* Type **\_\_user**: Parameter --groups removed (use the new \_\_user_groups type)
* Type **\_\_ssh_authorized_key** has been replaced by more flexible type
**\_\_ssh_authorized_keys**
Updating from 1.7 to 2.0
~~~~~~~~~~~~~~~~~~~~~~~~
* Ensure python (>= 3.2) is installed on the source host
* Use "cdist config host" instead of "cdist-deploy-to host"
* Use "cdist config -p host1 host2" instead of "cdist-mass-deploy"
* Use "cdist banner" for fun
* Use **\_\_object_name** instead of **\_\_self** in manifests
Updating from 1.6 to 1.7
~~~~~~~~~~~~~~~~~~~~~~~~
* If you used the global explorer **hardware_type**, you need to change
your code to use **machine** instead.
Updating from 1.5 to 1.6
~~~~~~~~~~~~~~~~~~~~~~~~
* If you used **\_\_package_apt --preseed**, you need to use the new
type **\_\_debconf_set_selections** instead.
* The **\_\_package** types accepted either --state deinstalled or
--state uninstaaled. Starting with 1.6, it was made consistently
to --state removed.
Updating from 1.3 to 1.5
~~~~~~~~~~~~~~~~~~~~~~~~
No incompatiblities.
Updating from 1.2 to 1.3
~~~~~~~~~~~~~~~~~~~~~~~~
Rename **gencode** of every type to **gencode-remote**.
Updating from 1.1 to 1.2
~~~~~~~~~~~~~~~~~~~~~~~~
No incompatiblities.
Updating from 1.0 to 1.1
~~~~~~~~~~~~~~~~~~~~~~~~
In 1.1 the type **\_\_file** was split into **\_\_directory**, **\_\_file** and
**\_\_link**. The parameter **--type** was removed from **\_\_file**. Thus you
need to replace **\_\_file** calls in your manifests:
* Remove --type from all \_\_file calls
* If type was symlink, use \_\_link and --type symbolic
* If type was directory, use \_\_directory

72
docs/src/cdist-why.rst Normal file
View file

@ -0,0 +1,72 @@
Why should I use cdist?
=======================
There are several motivations to use cdist, these
are probably the most popular ones.
Known language
--------------
Cdist is being configured in
`shell script <https://en.wikipedia.org/wiki/Shell_script>`_.
Shell script is used by UNIX system engineers for decades.
So when cdist is introduced, your staff does not need to learn a new
`DSL <https://en.wikipedia.org/wiki/Domain-specific_language>`_
or programming language.
Powerful language
-----------------
Not only is shell scripting widely known by system engineers,
but it is also a very powerful language. Here are some features
which make daily work easy:
* Configuration can react dynamicly on explored values
* High level string manipulation (using sed, awk, grep)
* Conditional support (**if, case**)
* Loop support (**for, while**)
* Support for dependencies between cdist types
More than shell scripting
-------------------------
If you compare regular shell scripting with cdist, there is one major
difference: When using cdist types,
the results are
`idempotent <https://en.wikipedia.org/wiki/Idempotence>`_.
In practise that means it does not matter in which order you
call cdist types, the result is always the same.
Zero dependency configuration management
----------------------------------------
Cdist requires very litte on a target system. Even better,
in almost all cases all dependencies are usually fulfilled.
Cdist does not require an agent or a high level programming
languages on the target host: it will run on any host that
has a **ssh server running** and a posix compatible shell
(**/bin/sh**). Compared to other configuration management systems,
it does not require to open up an additional port.
Push based distribution
-----------------------
Cdist uses the push based model for configuration. In this
scenario, one (or more) computers connect the target hosts
and apply the configuration. That way the source host has
very little requirements: Cdist can even run on a sysadmin
notebook that is loosely connected to the network and has
limited amount of resources.
Furthermore, from a security point of view, only one machine
needs access to the target hosts. No target hosts will ever
need to connect back to the source host, which contains the
full configuration.
Highly scalable
---------------
If at some point you manage more hosts than can be handled from
a single source host, you can simply add more resources: Either
add more cores to one host or add hosts.
Cdist will utilise the given resources in parallel.

312
docs/src/conf.py Normal file
View file

@ -0,0 +1,312 @@
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
#
# cdist-docs documentation build configuration file, created by
# sphinx-quickstart on Fri May 6 21:45:28 2016.
#
# This file is execfile()d with the current directory set to its
# containing dir.
#
# Note that not all possible configuration values are present in this
# autogenerated file.
#
# All configuration values have a default; values that are commented out
# serve to show the default.
import sys
import os
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
#sys.path.insert(0, os.path.abspath('.'))
sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(os.path.realpath(__file__)), "../../")))
# -- General configuration ------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
#needs_sphinx = '1.0'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = [
'cdist.sphinxext.manpage',
'sphinx.ext.extlinks',
]
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix(es) of source filenames.
# You can specify multiple suffix as a list of string:
source_suffix = ['.rst']
# The encoding of source files.
#source_encoding = 'utf-8-sig'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = 'cdist'
#copyright = '2016, Darko Poljak'
#author = 'Darko Poljak'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
import cdist.version
version = cdist.version.VERSION
# The full version, including alpha/beta/rc tags.
release = version
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#
# This is also used if you do content translation via gettext catalogs.
# Usually you set "language" from the command line for these cases.
language = None
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
#today = ''
# Else, today_fmt is used as the format for a strftime call.
#today_fmt = '%B %d, %Y'
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
# This patterns also effect to html_static_path and html_extra_path
exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
# The reST default role (used for this markup: `text`) to use for all
# documents.
#default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
#add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
#add_module_names = True
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
#show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# A list of ignored prefixes for module index sorting.
#modindex_common_prefix = []
# If true, keep warnings as "system message" paragraphs in the built documents.
#keep_warnings = False
# If true, `todo` and `todoList` produce output, else they produce nothing.
todo_include_todos = False
# -- Options for HTML output ----------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
import sphinx_rtd_theme
html_theme = 'sphinx_rtd_theme'
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#html_theme_options = {}
# Add any paths that contain custom themes here, relative to this directory.
#html_theme_path = []
# The name for this set of Sphinx documents.
# "<project> v<release> documentation" by default.
#html_title = 'cdist-docs v0.0.1'
# A shorter title for the navigation bar. Default is the same as html_title.
#html_short_title = None
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
#html_logo = None
# The name of an image file (relative to this directory) to use as a favicon of
# the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
# html_static_path = ['_static']
# Add any extra paths that contain custom files (such as robots.txt or
# .htaccess) here, relative to this directory. These files are copied
# directly to the root of the documentation.
#html_extra_path = []
# If not None, a 'Last updated on:' timestamp is inserted at every page
# bottom, using the given strftime format.
# The empty string is equivalent to '%b %d, %Y'.
#html_last_updated_fmt = None
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
#html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
#html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
#html_additional_pages = {}
# If false, no module index is generated.
#html_domain_indices = True
# If false, no index is generated.
#html_use_index = True
# If true, the index is split into individual pages for each letter.
#html_split_index = False
# If true, links to the reST sources are added to the pages.
#html_show_sourcelink = True
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
#html_show_sphinx = True
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
#html_show_copyright = True
# If true, an OpenSearch description file will be output, and all pages will
# contain a <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# This is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = None
#html_file_suffix = ""
# Language to be used for generating the HTML full-text search index.
# Sphinx supports the following languages:
# 'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'
# 'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr', 'zh'
#html_search_language = 'en'
# A dictionary with options for the search language support, empty by default.
# 'ja' uses this config value.
# 'zh' user can custom change `jieba` dictionary path.
#html_search_options = {'type': 'default'}
# The name of a javascript file (relative to the configuration directory) that
# implements a search results scorer. If empty, the default will be used.
#html_search_scorer = 'scorer.js'
# Output file base name for HTML help builder.
htmlhelp_basename = 'cdistdoc'
# -- Options for LaTeX output ---------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#'preamble': '',
# Latex figure (float) alignment
#'figure_align': 'htbp',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
(master_doc, 'cdist.tex', 'cdist Documentation',
'Darko Poljak', 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
#latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
#latex_use_parts = False
# If true, show page references after internal links.
#latex_show_pagerefs = False
# If true, show URL addresses after external links.
#latex_show_urls = False
# Documents to append as an appendix to all manuals.
#latex_appendices = []
# If false, no module index is generated.
#latex_domain_indices = True
# -- Options for manual page output ---------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
root_mandir = os.path.dirname(os.path.realpath(__file__))
mandirs = []
for mansubdir in ('man1', 'man7'):
mandirs.append((os.path.join(root_mandir, mansubdir), mansubdir[-1]))
man_pages = []
for mandir, section in mandirs:
for root, dirs, files in os.walk(mandir):
for fname in files:
froot, fext = os.path.splitext(fname)
if fext == '.rst':
man_page = (os.path.join('man' + str(section), froot),
froot, '', [], section)
man_pages.append(man_page)
#man_pages = [
# ('cdist-type', 'cdist-type', 'cdist-type documentation',
# [author], 1),
# ('man7/cdist-type__file', 'cdist-type__file',
# '', [], 1),
# ('cdist-type__directory', 'cdist-type__directory',
# 'cdist-type__directory documentation', [author], 1),
#]
# If true, show URL addresses after external links.
#man_show_urls = False
# -- Options for Texinfo output -------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
(master_doc, 'cdist', 'cdist Documentation',
'', 'cdist', 'Configuration management system.',
'Miscellaneous'),
]
# Documents to append as an appendix to all manuals.
#texinfo_appendices = []
# If false, no module index is generated.
#texinfo_domain_indices = True
# How to display URL addresses: 'footnote', 'no', or 'inline'.
#texinfo_show_urls = 'footnote'
# If true, do not generate a @detailmenu in the "Top" node's menu.
#texinfo_no_detailmenu = False

31
docs/src/index.rst Normal file
View file

@ -0,0 +1,31 @@
Welcome to cdist documentation
==============================
Contents:
.. toctree::
:maxdepth: 2
:glob:
:numbered:
cdist-intro
cdist-why
cdist-os
cdist-install
cdist-update
cdist-support
cdist-features
cdist-quickstart
man1/cdist
cdist-bootstrap
cdist-manifest
cdist-type
cdist-types
cdist-explorer
cdist-messaging
cdist-reference
cdist-best-practice
cdist-stages
cdist-remote-exec-copy
cdist-hacker
cdist-troubleshooting

185
docs/src/man1/cdist.rst Normal file
View file

@ -0,0 +1,185 @@
cdist(1)
========
NAME
----
cdist - Usable Configuration Management
SYNOPSIS
--------
::
cdist [-h] [-d] [-v] [-V] {banner,config,shell} ...
cdist banner [-h] [-d] [-v]
cdist config [-h] [-d] [-V] [-c CONF_DIR] [-f HOSTFILE] [-i MANIFEST] [-p] [-s] [host [host ...]]
cdist shell [-h] [-d] [-v] [-s SHELL]
DESCRIPTION
-----------
cdist is the frontend executable to the cdist configuration management.
cdist supports different subcommands as explained below.
GENERAL
-------
All commands accept the following options:
.. option:: -d, --debug
Set log level to debug
.. option:: -h, --help
Show the help screen
.. option:: -v, --verbose
Set log level to info, be more verbose
.. option:: -V, --version
Show version and exit
BANNER
------
Displays the cdist banner. Useful for printing
cdist posters - a must have for every office.
CONFIG
------
Configure one or more hosts
.. option:: -h, --help
Show the help screen
.. option:: -c CONF_DIR, --conf-dir CONF_DIR
Add a configuration directory. Can be specified multiple times.
If configuration directories contain conflicting types, explorers or
manifests, then the last one found is used. Additionally this can also
be configured by setting the CDIST_PATH environment variable to a colon
delimited list of config directories. Directories given with the
--conf-dir argument have higher precedence over those set through the
environment variable.
.. option:: -f HOSTFILE, --file HOSTFILE
Read additional hosts to operate on from specified file
or from stdin if '-' (each host on separate line).
If no host or host file is specified then, by default,
read hosts from stdin.
.. option:: -i MANIFEST, --initial-manifest MANIFEST
Path to a cdist manifest or - to read from stdin
.. option:: -p, --parallel
Operate on multiple hosts in parallel
.. option:: -s, --sequential
Operate on multiple hosts sequentially
.. option:: --remote-copy REMOTE_COPY
Command to use for remote copy (should behave like scp)
.. option:: --remote-exec REMOTE_EXEC
Command to use for remote execution (should behave like ssh)
SHELL
-----
This command allows you to spawn a shell that enables access
to the types as commands. It can be thought as an
"interactive manifest" environment. See below for example
usage. Its primary use is for debugging type parameters.
.. option:: -s/--shell
Select shell to use, defaults to current shell
EXAMPLES
--------
.. code-block:: sh
# Configure ikq05.ethz.ch with debug enabled
% cdist config -d ikq05.ethz.ch
# Configure hosts in parallel and use a different configuration directory
% cdist config -c ~/p/cdist-nutzung \
-p ikq02.ethz.ch ikq03.ethz.ch ikq04.ethz.ch
# Use custom remote exec / copy commands
% cdist config --remote-exec /path/to/my/remote/exec \
--remote-copy /path/to/my/remote/copy \
-p ikq02.ethz.ch ikq03.ethz.ch ikq04.ethz.ch
# Configure hosts read from file loadbalancers
% cdist config -f loadbalancers
# Display banner
cdist banner
# Show help
% cdist --help
# Show Version
% cdist --version
# Enter a shell that has access to emulated types
% cdist shell
% __git
usage: __git --source SOURCE [--state STATE] [--branch BRANCH]
[--group GROUP] [--owner OWNER] [--mode MODE] object_id
ENVIRONMENT
-----------
TMPDIR, TEMP, TMP
Setup the base directory for the temporary directory.
See http://docs.python.org/py3k/library/tempfile.html for
more information. This is rather useful, if the standard
directory used does not allow executables.
CDIST_LOCAL_SHELL
Selects shell for local script execution, defaults to /bin/sh
CDIST_REMOTE_SHELL
Selects shell for remote scirpt execution, defaults to /bin/sh
CDIST_REMOTE_EXEC
Use this command for remote execution (should behave like ssh)
CDIST_REMOTE_COPY
Use this command for remote copy (should behave like scp)
EXIT STATUS
-----------
The following exit values shall be returned:
0
Successful completion
1
One or more host configurations failed
AUTHORS
-------
Nico Schottelius <nico-cdist--@--schottelius.org>
COPYING
-------
Copyright \(C) 2011-2013 Nico Schottelius. Free use of this software is
granted under the terms of the GNU General Public License version 3 (GPLv3).

0
docs/src/man7/.gitignore vendored Normal file
View file