matthijs/cdist
1
0
Fork 0
forked from ungleich-public/cdist
Code Issues Pull requests Projects Releases Wiki Activity

Write sphinx rst docs.

Browse source
This commit is contained in:
Darko Poljak 2016-05-20 08:50:56 +02:00
commit cf32b669ff
232 changed files with 4430 additions and 3696 deletions
Download patch file Download diff file Expand all files Collapse all files

230
docs/man/Makefile Normal file
View file

@ -0,0 +1,230 @@
# Makefile for Sphinx documentation
#
# You can set these variables from the command line.
SPHINXOPTS =
SPHINXBUILD = sphinx-build
PAPER =
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)/*
.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 man $(ALLSPHINXOPTS) $(BUILDDIR)/man
@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."

107
docs/man/cdist-reference.text.sh → docs/man/cdist-reference.rst.sh
View file

@ -37,11 +37,9 @@ exec > "$dest"
cat << eof
cdist-reference(7)
==================
Nico Schottelius <nico-cdist--@--schottelius.org>
Variable, path and type reference for cdist
NAME
----
cdist-reference - Variable, path and type reference for cdist
Nico Schottelius <nico-cdist--@--schottelius.org>
EXPLORERS
@ -60,97 +58,97 @@ cat << eof
PATHS
-----
\$HOME/.cdist::
\$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/::
cdist/conf/
The distribution configuration directory
This contains types and explorers to be used
confdir::
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::
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/*::
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>::
confdir/explorer/<name>
Contains explorers to be run on the target hosts, see cdist-explorer(7).
confdir/type/::
confdir/type/
Contains all available types, which are used to provide
some kind of functionality. See cdist-type(7).
confdir/type/<name>/::
confdir/type/<name>/
Home of the type <name>.
This directory is referenced by the variable __type (see below).
confdir/type/<name>/man.text::
Manpage in Asciidoc format (required for inclusion into upstream)
confdir/type/<name>/man.rst
Manpage in reStructuredText format (required for inclusion into upstream)
confdir/type/<name>/manifest::
confdir/type/<name>/manifest
Used to generate additional objects from a type.
confdir/type/<name>/gencode-local::
confdir/type/<name>/gencode-local
Used to generate code to be executed on the source host
confdir/type/<name>/gencode-remote::
confdir/type/<name>/gencode-remote
Used to generate code to be executed on the target host
confdir/type/<name>/parameter/required::
confdir/type/<name>/parameter/required
Parameters required by type, \n separated list.
confdir/type/<name>/parameter/optional::
confdir/type/<name>/parameter/optional
Parameters optionally accepted by type, \n separated list.
confdir/type/<name>/parameter/default/*::
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::
confdir/type/<name>/parameter/boolean
Boolean parameters accepted by type, \n separated list.
confdir/type/<name>/explorer::
confdir/type/<name>/explorer
Location of the type specific explorers.
This directory is referenced by the variable __type_explorer (see below).
See cdist-explorer(7).
confdir/type/<name>/files::
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/::
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::
out/explorer
Output of general explorers.
out/object::
out/object
Objects created for the host.
out/object/<object>::
out/object/<object>
Contains all object specific information.
This directory is referenced by the variable __object (see below).
out/object/<object>/explorers::
out/object/<object>/explorers
Output of type specific explorers, per object.
TYPES
@ -159,14 +157,15 @@ The following types are available:
eof
for type in man7/cdist-type__*.text; do
for type in man7/cdist-type__*.rst; do
no_dir="${type#man7/}";
no_type="${no_dir#cdist-type}";
name="${no_type%.text}";
name="${no_type%.rst}";
name_no_underline="$(echo $name | sed 's/^__/\\__/g')"
man="${no_dir%.text}(7)"
manref="${no_dir%.rst}"
man="${manref}(7)"
echo "- $name_no_underline" "($man)"
echo "- $name_no_underline" "(\`${man} <${manref}.html>\`_)"
done
cat << eof
@ -177,14 +176,14 @@ OBJECTS
For object to object communication and tests, the following paths are
usable within a object directory:
files::
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::
changed
This empty file exists in an object directory, if the object has
code to be executed (either remote or local)
stdin::
stdin
This file exists and contains data, if data was provided on stdin
when the type was called.
@ -193,40 +192,40 @@ ENVIRONMENT VARIABLES (FOR READING)
-----------------------------------
The following environment variables are exported by cdist:
__explorer::
__explorer
Directory that contains all global explorers.
Available for: initial manifest, explorer, type explorer, shell
__manifest::
__manifest
Directory that contains the initial manifest.
Available for: initial manifest, type manifest, shell
__global::
__global
Directory that contains generic output like explorer.
Available for: initial manifest, type manifest, type gencode, shell
__messages_in::
__messages_in
File to read messages from.
Available for: initial manifest, type manifest, type gencode
__messages_out::
__messages_out
File to write messages.
Available for: initial manifest, type manifest, type gencode
__object::
__object
Directory that contains the current object.
Available for: type manifest, type explorer, type gencode and code scripts
__object_id::
__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::
__object_name
The full qualified name of the current object.
Available for: type manifest, type explorer, type gencode
__target_host::
__target_host
The host we are deploying to.
Available for: explorer, initial manifest, type explorer, type manifest, type gencode, shell
__type::
__type
Path to the current type.
Available for: type manifest, type gencode
__type_explorer::
__type_explorer
Directory that contains the type explorers.
Available for: type explorer
@ -234,30 +233,30 @@ ENVIRONMENT VARIABLES (FOR WRITING)
-----------------------------------
The following environment variables influence the behaviour of cdist:
require::
require
Setup dependencies between objects (see cdist-manifest(7))
CDIST_LOCAL_SHELL::
CDIST_LOCAL_SHELL
Use this shell locally instead of /bin/sh to execute scripts
CDIST_REMOTE_SHELL::
CDIST_REMOTE_SHELL
Use this shell remotely instead of /bin/sh to execute scripts
CDIST_OVERRIDE::
CDIST_OVERRIDE
Allow overwriting type parameters (see cdist-manifest(7))
CDIST_ORDER_DEPENDENCY::
CDIST_ORDER_DEPENDENCY
Create dependencies based on the execution order (see cdist-manifest(7))
CDIST_REMOTE_EXEC::
CDIST_REMOTE_EXEC
Use this command for remote execution (should behave like ssh)
CDIST_REMOTE_COPY::
CDIST_REMOTE_COPY
Use this command for remote copy (should behave like scp)
SEE ALSO
--------
- cdist(1)
- \`cdist(1) <../man1/cdist.html>\`_
COPYING

305
docs/man/conf.py Normal file
View file

@ -0,0 +1,305 @@
#!/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('.'))
# -- 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 = []
# 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).
mandir = os.path.dirname(os.path.realpath(__file__))
man_pages = []
for mansubdir in ('man1', 'man7'):
for root, dirs, files in os.walk(os.path.join(mandir, mansubdir)):
for fname in files:
froot, fext = os.path.splitext(fname)
if fext == '.rst':
man_page = (os.path.join(mansubdir, froot), froot, '',
[], 7)
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

12
docs/man/index.rst Normal file
View file

@ -0,0 +1,12 @@
Welcome to cdist documentation
==============================
Contents:
.. toctree::
:titlesonly:
:glob:
:numbered:
man1/*
man7/*

116
docs/man/man1/cdist.text → docs/man/man1/cdist.rst
View file

@ -1,22 +1,22 @@
cdist(1)
========
Usable Configuration Management
Nico Schottelius <nico-cdist--@--schottelius.org>
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] [-i MANIFEST] [-p] [-s] host [host ...]
cdist [-h] [-d] [-v] [-V] {banner,config,shell} ...
cdist shell [-h] [-d] [-v] [-s SHELL]
cdist banner [-h] [-d] [-v]
cdist config [-h] [-d] [-V] [-c CONF_DIR] [-i MANIFEST] [-p] [-s] host [host ...]
cdist shell [-h] [-d] [-v] [-s SHELL]
DESCRIPTION
@ -28,16 +28,20 @@ GENERAL
-------
All commands accept the following options:
-d, --debug::
.. option:: -d, --debug
Set log level to debug
-h, --help::
.. option:: -h, --help
Show the help screen
-v, --verbose::
.. option:: -v, --verbose
Set log level to info, be more verbose
-V, --version::
.. option:: -V, --version
Show version and exit
@ -51,10 +55,12 @@ CONFIG
------
Configure one or more hosts
-h, --help::
.. option:: -h, --help
Show the help screen
-c CONF_DIR, --conf-dir CONF_DIR::
.. 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
@ -63,19 +69,24 @@ Configure one or more hosts
--conf-dir argument have higher precedence over those set through the
environment variable.
-i MANIFEST, --initial-manifest MANIFEST::
.. option:: -i MANIFEST, --initial-manifest MANIFEST
Path to a cdist manifest or - to read from stdin
-p, --parallel::
.. option:: -p, --parallel
Operate on multiple hosts in parallel
-s, --sequential::
.. option:: -s, --sequential
Operate on multiple hosts sequentially
--remote-copy REMOTE_COPY::
.. option:: --remote-copy REMOTE_COPY
Command to use for remote copy (should behave like scp)
--remote-exec REMOTE_EXEC::
.. option:: --remote-exec REMOTE_EXEC
Command to use for remote execution (should behave like ssh)
SHELL
@ -85,79 +96,78 @@ 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.
-s/--shell::
.. option:: -s/--shell
Select shell to use, defaults to current shell
EXAMPLES
--------
--------------------------------------------------------------------------------
# Configure ikq05.ethz.ch with debug enabled
% cdist config -d ikq05.ethz.ch
.. code-block:: sh
# 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
# Configure ikq05.ethz.ch with debug enabled
% cdist config -d ikq05.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 in parallel and use a different configuration directory
% cdist config -c ~/p/cdist-nutzung \
-p ikq02.ethz.ch ikq03.ethz.ch ikq04.ethz.ch
# Display banner
cdist banner
# 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
# Show help
% cdist --help
# Display banner
cdist banner
# Show Version
% cdist --version
# Show help
% cdist --help
# 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
# 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::
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::
CDIST_LOCAL_SHELL
Selects shell for local script execution, defaults to /bin/sh
CDIST_REMOTE_SHELL::
CDIST_REMOTE_SHELL
Selects shell for remote scirpt execution, defaults to /bin/sh
CDIST_REMOTE_EXEC::
CDIST_REMOTE_EXEC
Use this command for remote execution (should behave like ssh)
CDIST_REMOTE_COPY::
CDIST_REMOTE_COPY
Use this command for remote copy (should behave like scp)
EXIT STATUS
-----------
The following exit values shall be returned:
0::
0
Successful completion
1::
1
One or more host configurations failed
SEE ALSO
--------
- cdist(7)
- cdist-reference(7)
- `cdist-type(7) <../man7/cdist-type.html>`_
- `cdist-reference(7) <../man7/cdist-reference.html>`_
COPYING

238
docs/man/man7/cdist-best-practice.rst Normal file
View file

@ -0,0 +1,238 @@
cdist-best-practice(7)
======================
Practices used in real environments
Nico Schottelius <nico-cdist--@--schottelius.org>
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.
SEE ALSO
--------
- `cdist(1) <../man1/cdist.html>`_
- `cdist-tutorial(7) <cdist-tutorial.html>`_
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).

247
docs/man/man7/cdist-best-practice.text
View file

@ -1,247 +0,0 @@
cdist-best-practice(7)
======================
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-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
--------------------------------------------------------------------------------
#!/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:
--------------------------------------------------------------------------------
# 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:
--------------------------------------------------------------------------------
# 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.
SEE ALSO
--------
- cdist(1)
- cdist-tutorial(7)
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).

101
docs/man/man7/cdist-bootstrap.text → docs/man/man7/cdist-bootstrap.rst
View file

@ -1,13 +1,10 @@
cdist-bootstrap(7)
==================
Setup cdist environment
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-bootstrap - setup cdist environment
INTRODUCTION
------------
This document describes the usual steps recommended for a new
@ -42,23 +39,21 @@ 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:
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
--------------------------------------------------------------------------------
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
@ -75,16 +70,14 @@ 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**:
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
--------------------------------------------------------------------------------
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.
@ -95,51 +88,47 @@ 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:
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/
# 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
# 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 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
# 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
--------------------------------------------------------------------------------
# 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***.
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:
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 git repository with latest changes from origin
cdist% git fetch origin
# Update current branch with master branch from origin
cdist% git merge origin/master
# 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
--------------------------------------------------------------------------------
# Alternative: Update current branch with 2.0 branch from origin
cdist% git merge origin/2.0
SEE ALSO
--------
- cdist(1)
- cdist-tutorial(7)
- `cdist(1) <../man1/cdist.html>`_
- `cdist-tutorial(7) <cdist-tutorial.html>`_
COPYING

53
docs/man/man7/cdist-explorer.text → docs/man/man7/cdist-explorer.rst
View file

@ -1,13 +1,10 @@
cdist-explorer(7)
=================
Explore the target systems
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-explorer - Explore the target systems
DESCRIPTION
-----------
Explorer are small shell scripts, which will be executed on the target
@ -21,9 +18,17 @@ 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).
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.
@ -33,33 +38,31 @@ explorer.
EXAMPLES
--------
A very simple explorer may look like this:
A very simple explorer may look like this::
--------------------------------------------------------------------------------
hostname
--------------------------------------------------------------------------------
hostname
Which is in practise the ***hostname*** explorer.
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
.. code-block:: sh
# Expect dpkg failing, if package is not known / installed
dpkg -s "$name" 2>/dev/null || exit 0
--------------------------------------------------------------------------------
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
SEE ALSO
--------
- cdist(1)
- cdist-reference(7)
- cdist-stages(7)
- `cdist(1) <../man1/cdist.html>`_
- `cdist-reference(7) <cdist-reference.html>`_
- `cdist-stages(7) <cdist-stages.html>`_
COPYING

104
docs/man/man7/cdist-hacker.text → docs/man/man7/cdist-hacker.rst
View file

@ -1,13 +1,10 @@
cdist-hacker(7)
===============
How to get (stuff) into cdist
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-hacker - How to get (stuff) into cdist
WELCOME
-------
Welcome dear hacker! I invite you to a tour of pointers to
@ -33,6 +30,7 @@ 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
@ -46,7 +44,9 @@ work nor kill the authors brain:
- 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
@ -69,82 +69,76 @@ 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
**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:
The following workflow works fine for most developers::
--------------------------------------------------------------------------------
# get latest upstream master branch
git clone https://github.com/telmich/cdist.git
# 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
# 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
# create a new branch for your feature/bugfix
cd cdist # if you haven't done before
git checkout -b documentation_cleanup
# *hack*
*hack*
# *hack*
*hack*
# clone the cdist repository on github if you haven't done so
# 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
# 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
# push the new branch to github
git push github documentation_cleanup
# (or everything)
git push --mirror github
# (or everything)
git push --mirror github
# create a pull request at github (use a browser)
# *fixthingsbecausequalityassurancefoundissuesinourpatch*
*hack*
# create a pull request at github (use a browser)
# *fixthingsbecausequalityassurancefoundissuesinourpatch*
*hack*
# push code to github again
git push ... # like above
# push code to github again
git push ... # like above
# add comment that everything should be green now (use a browser)
# add comment that everything should be green now (use a browser)
# go back to master branch
git checkout master
# 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
--------------------------------------------------------------------------------
# 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:
use **git stash** to stash your changes away::
--------------------------------------------------------------------------------
# assume you are on documentation_cleanup
git stash
# 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
--------------------------------------------------------------------------------
# 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:
to the master branch and create another branch based on it::
--------------------------------------------------------------------------------
# change to master and update to most recent upstream version
git checkout master
git fetch -v origin
git merge origin/master
# 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
--------------------------------------------------------------------------------
git checkout -b another_feature
(you can repeat the code above for as many features as you want to develop
in parallel)
@ -152,7 +146,7 @@ in parallel)
SEE ALSO
--------
- cdist(7)
- `cdist(1) <../man1/cdist.html>`_
- git(1)
- git-checkout(1)
- git-stash(1)

220
docs/man/man7/cdist-manifest.text → docs/man/man7/cdist-manifest.rst
View file

@ -1,20 +1,17 @@
cdist-manifest(7)
=================
(Re-)Use types
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-manifest - (Re-)Use types
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***.
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
@ -23,14 +20,13 @@ 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
at an example::
# Same with the __directory type
__directory /tmp/cdist --state present
--------------------------------------------------------------------------------
# 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.
@ -62,23 +58,21 @@ 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:
example::
--------------------------------------------------------------------------------
__cdistmarker
__cdistmarker
case "$__target_host" in
localhost)
__directory /home/services/kvm-vm --parents yes
;;
esac
--------------------------------------------------------------------------------
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**,
**__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***.
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
@ -89,18 +83,16 @@ 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
Cdist provides the environment variable **__manifest** to reference
the directory containing the initial manifest (see cdist-reference(7)).
The following example would include every file with a **.sh** suffix:
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
--------------------------------------------------------------------------------
# Include *.sh
for manifest in $__manifest/*.sh; do
# And source scripts into our shell environment
. "$manifest"
done
DEPENDENCIES
@ -109,20 +101,19 @@ 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
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.
@ -141,23 +132,22 @@ 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"
# 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
# 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
@ -166,6 +156,7 @@ cdist jargon.
You can find an more in depth description of the flow execution of manifests
in cdist-stages(7) and of how types work in cdist-type(7).
CREATE DEPENDENCIES FROM EXECUTION ORDER
-----------------------------------------
You can tell cdist to execute all types in the order in which they are created
@ -193,90 +184,85 @@ 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:
--------------------------------------------------------------------------------
# Always create this file, so other sysadmins know cdist is used.
__file /etc/cdist-configured
.. code-block:: sh
case "$__target_host" in
my.server.name)
__directory /root/bin/
__file /etc/issue.net --source "$__manifest/issue.net
;;
esac
--------------------------------------------------------------------------------
# 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:
--------------------------------------------------------------------------------
__file /etc/nologin --source "$__type/files/default.nologin"
--------------------------------------------------------------------------------
.. code-block:: sh
__file /etc/nologin --source "$__type/files/default.nologin"
This example makes use of dependencies:
--------------------------------------------------------------------------------
# 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
--------------------------------------------------------------------------------
.. 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:
--------------------------------------------------------------------------------
# for example in the inital manifest
.. code-block:: sh
# create user account foobar with some hash for password
__user foobar --password 'some_fancy_hash' --home /home/foobarexample
# for example in the inital manifest
# ... 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)
# create user account foobar with some hash for password
__user foobar --password 'some_fancy_hash' --home /home/foobarexample
# this leads to an error ...
__user foobar --password 'some_other_hash'
# ... 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 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
--------------------------------------------------------------------------------
# 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
--------------------------------------------------------------------------------
# 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
SEE ALSO
--------
- cdist-tutorial(7)
- cdist-type(7)
- `cdist-tutorial(7) <cdist-tutorial.html>`_
- `cdist-type(7) <cdist-type.html>`_
COPYING

111
docs/man/man7/cdist-messaging.rst Normal file
View file

@ -0,0 +1,111 @@
cdist-messaging(7)
==================
How the initial manifest and types can communication
Nico Schottelius <nico-cdist--@--schottelius.org>
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(7)) 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
SEE ALSO
--------
- `cdist(1) <../man1/cdist.html>`_
- `cdist-manifest(7) <cdist-manifest.html>`_
- `cdist-reference(7) <cdist-reference.html>`_
- `cdist-type(7) <cdist-type.html>`_
COPYING
-------
Copyright \(C) 2013 Nico Schottelius. Free use of this software is
granted under the terms of the GNU General Public License version 3 (GPLv3).

114
docs/man/man7/cdist-messaging.text
View file

@ -1,114 +0,0 @@
cdist-messaging(7)
==================
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-messaging - How the initial manifest and types can communication
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(7)) 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:
--------------------------------------------------------------------------------
echo "something" >> "$__messages_out"
--------------------------------------------------------------------------------
When you want to react on a message use:
--------------------------------------------------------------------------------
if grep -q "^__your_type/object/id:something" "$__messages_in"; then
echo "I do something else"
fi
--------------------------------------------------------------------------------
Some real life examples:
--------------------------------------------------------------------------------
# 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
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
SEE ALSO
--------
- cdist(1)
- cdist-manifest(7)
- cdist-reference(7)
- cdist-type(7)
COPYING
-------
Copyright \(C) 2013 Nico Schottelius. Free use of this software is
granted under the terms of the GNU General Public License version 3 (GPLv3).

76
docs/man/man7/cdist-quickstart.text → docs/man/man7/cdist-quickstart.rst
View file

@ -1,13 +1,10 @@
cdist-quickstart(7)
===================
Jump in and enjoy cdist
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-quickstart - jump in and enjoy cdist
INTRODUCTION
------------
This tutorial is aimed at people learning cdist and shows
@ -31,62 +28,55 @@ 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:
lines::
--------------------------------------------------------------------------------
# Allow login only via public key
PermitRootLogin without-password
# Allow login only via public key
PermitRootLogin without-password
# Allow login via password and public key
PermitRootLogin yes
--------------------------------------------------------------------------------
# Allow login via password and public key
PermitRootLogin yes
As cdist uses ssh intensively, it is recommended to setup authentication
with public keys:
with public keys::
--------------------------------------------------------------------------------
# Generate pubkey pair as a normal user
ssh-keygen
# Generate pubkey pair as a normal user
ssh-keygen
# Copy pubkey over to target host
ssh-copy-id root@localhost
--------------------------------------------------------------------------------
# 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:
your public key. Usually it looks like this::
--------------------------------------------------------------------------------
# Start agent and export variables
eval `ssh-agent`
# Start agent and export variables
eval `ssh-agent`
# Add keys (requires password for every identity file)
ssh-add
--------------------------------------------------------------------------------
# Add keys (requires password for every identity file)
ssh-add
At this point you should be able to ***ssh root@localhost*** without
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
code into your shell to get started and configure localhost::
# Create manifest (maps configuration to host(s)
cd cdist
echo '__file /etc/cdist-configured' > cdist/conf/manifest/init
# Get cdist
# Mirrors can be found on
# http://www.nico.schottelius.org/software/cdist/install/#index2h4
git clone git://git.schottelius.org/cdist
# Configure localhost in verbose mode
./bin/cdist config -v localhost
# Create manifest (maps configuration to host(s)
cd cdist
echo '__file /etc/cdist-configured' > cdist/conf/manifest/init
# Find out that cdist created /etc/cdist-configured
ls -l /etc/cdist-configured
--------------------------------------------------------------------------------
# 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
@ -95,8 +85,8 @@ to create a more sophisticated configuration.
SEE ALSO
--------
- cdist(1)
- cdist-tutorial(7)
- `cdist(1) <../man1/cdist.html>`_
- `cdist-tutorial(7) <cdist-tutorial.html>`_
COPYING

313
docs/man/man7/cdist-reference.rst Normal file
View file

@ -0,0 +1,313 @@
cdist-reference(7)
==================
Variable, path and type reference for cdist
Nico Schottelius <nico-cdist--@--schottelius.org>
EXPLORERS
---------
The following global explorers are available:
- cpu_cores
- cpu_sockets
- hostname
- init
- interfaces
- lsb_codename
- lsb_description
- lsb_id
- lsb_release
- machine
- machine_type
- memory
- os
- os_version
- runlevel
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(7).
confdir/type/
Contains all available types, which are used to provide
some kind of functionality. See cdist-type(7).
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(7).
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:
- \__apt_key (`cdist-type__apt_key(7) <cdist-type__apt_key.html>`_)
- \__apt_key_uri (`cdist-type__apt_key_uri(7) <cdist-type__apt_key_uri.html>`_)
- \__apt_norecommends (`cdist-type__apt_norecommends(7) <cdist-type__apt_norecommends.html>`_)
- \__apt_ppa (`cdist-type__apt_ppa(7) <cdist-type__apt_ppa.html>`_)
- \__apt_source (`cdist-type__apt_source(7) <cdist-type__apt_source.html>`_)
- \__apt_update_index (`cdist-type__apt_update_index(7) <cdist-type__apt_update_index.html>`_)
- \__block (`cdist-type__block(7) <cdist-type__block.html>`_)
- \__ccollect_source (`cdist-type__ccollect_source(7) <cdist-type__ccollect_source.html>`_)
- \__cdist (`cdist-type__cdist(7) <cdist-type__cdist.html>`_)
- \__cdistmarker (`cdist-type__cdistmarker(7) <cdist-type__cdistmarker.html>`_)
- \__config_file (`cdist-type__config_file(7) <cdist-type__config_file.html>`_)
- \__consul (`cdist-type__consul(7) <cdist-type__consul.html>`_)
- \__consul_agent (`cdist-type__consul_agent(7) <cdist-type__consul_agent.html>`_)
- \__consul_check (`cdist-type__consul_check(7) <cdist-type__consul_check.html>`_)
- \__consul_reload (`cdist-type__consul_reload(7) <cdist-type__consul_reload.html>`_)
- \__consul_service (`cdist-type__consul_service(7) <cdist-type__consul_service.html>`_)
- \__consul_template (`cdist-type__consul_template(7) <cdist-type__consul_template.html>`_)
- \__consul_template_template (`cdist-type__consul_template_template(7) <cdist-type__consul_template_template.html>`_)
- \__consul_watch_checks (`cdist-type__consul_watch_checks(7) <cdist-type__consul_watch_checks.html>`_)
- \__consul_watch_event (`cdist-type__consul_watch_event(7) <cdist-type__consul_watch_event.html>`_)
- \__consul_watch_key (`cdist-type__consul_watch_key(7) <cdist-type__consul_watch_key.html>`_)
- \__consul_watch_keyprefix (`cdist-type__consul_watch_keyprefix(7) <cdist-type__consul_watch_keyprefix.html>`_)
- \__consul_watch_nodes (`cdist-type__consul_watch_nodes(7) <cdist-type__consul_watch_nodes.html>`_)
- \__consul_watch_service (`cdist-type__consul_watch_service(7) <cdist-type__consul_watch_service.html>`_)
- \__consul_watch_services (`cdist-type__consul_watch_services(7) <cdist-type__consul_watch_services.html>`_)
- \__cron (`cdist-type__cron(7) <cdist-type__cron.html>`_)
- \__debconf_set_selections (`cdist-type__debconf_set_selections(7) <cdist-type__debconf_set_selections.html>`_)
- \__directory (`cdist-type__directory(7) <cdist-type__directory.html>`_)
- \__dog_vdi (`cdist-type__dog_vdi(7) <cdist-type__dog_vdi.html>`_)
- \__file (`cdist-type__file(7) <cdist-type__file.html>`_)
- \__firewalld_rule (`cdist-type__firewalld_rule(7) <cdist-type__firewalld_rule.html>`_)
- \__git (`cdist-type__git(7) <cdist-type__git.html>`_)
- \__group (`cdist-type__group(7) <cdist-type__group.html>`_)
- \__hostname (`cdist-type__hostname(7) <cdist-type__hostname.html>`_)
- \__iptables_apply (`cdist-type__iptables_apply(7) <cdist-type__iptables_apply.html>`_)
- \__iptables_rule (`cdist-type__iptables_rule(7) <cdist-type__iptables_rule.html>`_)
- \__issue (`cdist-type__issue(7) <cdist-type__issue.html>`_)
- \__jail (`cdist-type__jail(7) <cdist-type__jail.html>`_)
- \__key_value (`cdist-type__key_value(7) <cdist-type__key_value.html>`_)
- \__line (`cdist-type__line(7) <cdist-type__line.html>`_)
- \__link (`cdist-type__link(7) <cdist-type__link.html>`_)
- \__locale (`cdist-type__locale(7) <cdist-type__locale.html>`_)
- \__motd (`cdist-type__motd(7) <cdist-type__motd.html>`_)
- \__mount (`cdist-type__mount(7) <cdist-type__mount.html>`_)
- \__mysql_database (`cdist-type__mysql_database(7) <cdist-type__mysql_database.html>`_)
- \__package (`cdist-type__package(7) <cdist-type__package.html>`_)
- \__package_apt (`cdist-type__package_apt(7) <cdist-type__package_apt.html>`_)
- \__package_emerge (`cdist-type__package_emerge(7) <cdist-type__package_emerge.html>`_)
- \__package_emerge_dependencies (`cdist-type__package_emerge_dependencies(7) <cdist-type__package_emerge_dependencies.html>`_)
- \__package_luarocks (`cdist-type__package_luarocks(7) <cdist-type__package_luarocks.html>`_)
- \__package_opkg (`cdist-type__package_opkg(7) <cdist-type__package_opkg.html>`_)
- \__package_pacman (`cdist-type__package_pacman(7) <cdist-type__package_pacman.html>`_)
- \__package_pip (`cdist-type__package_pip(7) <cdist-type__package_pip.html>`_)
- \__package_pkg_freebsd (`cdist-type__package_pkg_freebsd(7) <cdist-type__package_pkg_freebsd.html>`_)
- \__package_pkg_openbsd (`cdist-type__package_pkg_openbsd(7) <cdist-type__package_pkg_openbsd.html>`_)
- \__package_pkgng_freebsd (`cdist-type__package_pkgng_freebsd(7) <cdist-type__package_pkgng_freebsd.html>`_)
- \__package_rubygem (`cdist-type__package_rubygem(7) <cdist-type__package_rubygem.html>`_)
- \__package_update_index (`cdist-type__package_update_index(7) <cdist-type__package_update_index.html>`_)
- \__package_upgrade_all (`cdist-type__package_upgrade_all(7) <cdist-type__package_upgrade_all.html>`_)
- \__package_yum (`cdist-type__package_yum(7) <cdist-type__package_yum.html>`_)
- \__package_zypper (`cdist-type__package_zypper(7) <cdist-type__package_zypper.html>`_)
- \__pacman_conf (`cdist-type__pacman_conf(7) <cdist-type__pacman_conf.html>`_)
- \__pacman_conf_integrate (`cdist-type__pacman_conf_integrate(7) <cdist-type__pacman_conf_integrate.html>`_)
- \__pf_apply (`cdist-type__pf_apply(7) <cdist-type__pf_apply.html>`_)
- \__pf_ruleset (`cdist-type__pf_ruleset(7) <cdist-type__pf_ruleset.html>`_)
- \__postfix (`cdist-type__postfix(7) <cdist-type__postfix.html>`_)
- \__postfix_master (`cdist-type__postfix_master(7) <cdist-type__postfix_master.html>`_)
- \__postfix_postconf (`cdist-type__postfix_postconf(7) <cdist-type__postfix_postconf.html>`_)
- \__postfix_postmap (`cdist-type__postfix_postmap(7) <cdist-type__postfix_postmap.html>`_)
- \__postfix_reload (`cdist-type__postfix_reload(7) <cdist-type__postfix_reload.html>`_)
- \__postgres_database (`cdist-type__postgres_database(7) <cdist-type__postgres_database.html>`_)
- \__postgres_role (`cdist-type__postgres_role(7) <cdist-type__postgres_role.html>`_)
- \__process (`cdist-type__process(7) <cdist-type__process.html>`_)
- \__pyvenv (`cdist-type__pyvenv(7) <cdist-type__pyvenv.html>`_)
- \__qemu_img (`cdist-type__qemu_img(7) <cdist-type__qemu_img.html>`_)
- \__rbenv (`cdist-type__rbenv(7) <cdist-type__rbenv.html>`_)
- \__rsync (`cdist-type__rsync(7) <cdist-type__rsync.html>`_)
- \__rvm (`cdist-type__rvm(7) <cdist-type__rvm.html>`_)
- \__rvm_gem (`cdist-type__rvm_gem(7) <cdist-type__rvm_gem.html>`_)
- \__rvm_gemset (`cdist-type__rvm_gemset(7) <cdist-type__rvm_gemset.html>`_)
- \__rvm_ruby (`cdist-type__rvm_ruby(7) <cdist-type__rvm_ruby.html>`_)
- \__ssh_authorized_key (`cdist-type__ssh_authorized_key(7) <cdist-type__ssh_authorized_key.html>`_)
- \__ssh_authorized_keys (`cdist-type__ssh_authorized_keys(7) <cdist-type__ssh_authorized_keys.html>`_)
- \__ssh_dot_ssh (`cdist-type__ssh_dot_ssh(7) <cdist-type__ssh_dot_ssh.html>`_)
- \__staged_file (`cdist-type__staged_file(7) <cdist-type__staged_file.html>`_)
- \__start_on_boot (`cdist-type__start_on_boot(7) <cdist-type__start_on_boot.html>`_)
- \__timezone (`cdist-type__timezone(7) <cdist-type__timezone.html>`_)
- \__update_alternatives (`cdist-type__update_alternatives(7) <cdist-type__update_alternatives.html>`_)
- \__user (`cdist-type__user(7) <cdist-type__user.html>`_)
- \__user_groups (`cdist-type__user_groups(7) <cdist-type__user_groups.html>`_)
- \__yum_repo (`cdist-type__yum_repo(7) <cdist-type__yum_repo.html>`_)
- \__zypper_repo (`cdist-type__zypper_repo(7) <cdist-type__zypper_repo.html>`_)
- \__zypper_service (`cdist-type__zypper_service(7) <cdist-type__zypper_service.html>`_)
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(7))
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(7))
CDIST_ORDER_DEPENDENCY
Create dependencies based on the execution order (see cdist-manifest(7))
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)
SEE ALSO
--------
- `cdist(1) <../man1/cdist.html>`_
COPYING
-------
Copyright \(C) 2011-2014 Nico Schottelius. Free use of this software is
granted under the terms of the GNU General Public License version 3 (GPLv3).

17
docs/man/man7/cdist-remote-exec-copy.text → docs/man/man7/cdist-remote-exec-copy.rst
View file

@ -1,23 +1,22 @@
cdist-remote-exec-copy(7)
=========================
How to use remote exec and copy
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-remote-exec-copy - How to use remote exec and copy
INTRO
-----
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 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.
@ -37,7 +36,7 @@ See cdist/other/examples/remote/ for some example implementations.
SEE ALSO
--------
- cdist(7)
- `cdist(1) <../man1/cdist.html>`_
COPYING

11
docs/man/man7/cdist-stages.text → docs/man/man7/cdist-stages.rst
View file

@ -1,12 +1,9 @@
cdist-stages(7)
===============
Stages used during configuration deployment
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-stages - Stages used during configuration deployment
DESCRIPTION
-----------
Starting the execution of deployment with cdist, cdist passes
@ -79,8 +76,8 @@ will be applied to the target.
SEE ALSO
--------
- cdist(1)
- cdist-reference(7)
- `cdist(1) <../man1/cdist.html>`_
- `cdist-reference(7) <cdist-reference.html>`_
COPYING

52
docs/man/man7/cdist-troubleshooting.text → docs/man/man7/cdist-troubleshooting.rst
View file

@ -1,28 +1,25 @@
cdist-troubleshooting(7)
========================
Common problems and their solutions
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-troubleshooting - common problems and their solutions
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:
--------------------------------------------------------------------------------
% 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"
--------------------------------------------------------------------------------
.. 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
@ -33,28 +30,29 @@ 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:
--------------------------------------------------------------------------------
# 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"
--------------------------------------------------------------------------------
.. 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:
--------------------------------------------------------------------------------
% cat ~/.cdist/manifest/special
#!/bin/sh -e
...
--------------------------------------------------------------------------------
.. code-block:: sh
% cat ~/.cdist/manifest/special
#!/bin/sh -e
...
SEE ALSO
--------
- cdist(1)
- cdist-tutorial(7)
- `cdist(1) <../man1/cdist.html>`_
- `cdist-tutorial(7) <cdist-tutorial.html>`_
COPYING

33
docs/man/man7/cdist-tutorial.text → docs/man/man7/cdist-tutorial.rst
View file

@ -1,13 +1,10 @@
cdist-tutorial(7)
=================
A guided introduction into cdist
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-tutorial - a guided introduction into cdist
INTRODUCTION
------------
This document gives you a pointer on what to read in
@ -16,40 +13,40 @@ 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::
cdist-quickstart
New to cdist? Want to get your hands dirty? Read this. [beginner]
cdist-bootstrap::
cdist-bootstrap
The comprehensive guide to your first cdist installation [beginner]
cdist-manifest::
cdist-manifest
Learn how to define which hosts get which configurations [beginner]
cdist-type::
cdist-type
Understand how types are working and created [intermediate]
cdist-best-practice::
cdist-best-practice
Hints from real life experience to help you to organise cdist [intermediate]
cdist-reference::
cdist-reference
The type, explorers and environment variables reference [intermediate]
cdist-explorer::
cdist-explorer
Interested in getting more information about the target system? [intermediate]
cdist-stages::
cdist-stages
Understand the internal workflow of cdist. [advanced]
cdist-hacker::
cdist-hacker
README, if you want to extend or modify cdist. [hacker]
SEE ALSO
--------
- cdist(1)
- cdist-type(7)
- cdist-best-practice(7)
- cdist-stages(7)
- `cdist(1) <../man1/cdist.html>`_
- `cdist-type(7) <cdist-type.html>`_
- `cdist-best-practice(7) <cdist-best-practice.html>`_
- `cdist-stages(7) <cdist-stages.html>`_
- Brave New World by Aldous Huxley
COPYING

226
docs/man/man7/cdist-type.text → docs/man/man7/cdist-type.rst
View file

@ -1,18 +1,17 @@
cdist-type(7)
=============
Functionality bundled
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-type - Functionality bundled
SYNOPSIS
--------
__TYPE ID --parameter value [--parameter value ...]
__TYPE --parameter value [--parameter value ...] (for singletons)
::
__TYPE ID --parameter value [--parameter value ...]
__TYPE --parameter value [--parameter value ...] (for singletons)
DESCRIPTION
@ -27,13 +26,13 @@ HOW TO USE A TYPE
You can use types from the initial manifest or the type manifest like a
normal shell command:
--------------------------------------------------------------------------------
# Creates empty file /etc/cdist-configured
__file /etc/cdist-configured --type file
.. code-block:: sh
# Ensure tree is installed
__package tree --state installed
--------------------------------------------------------------------------------
# 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.
@ -44,14 +43,16 @@ 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
--------------------------------------------------------------------------------
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
@ -73,9 +74,9 @@ 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***.
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".
@ -83,18 +84,19 @@ 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>***.
**parameter/default/<name>**.
Example:
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
.. 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
@ -105,60 +107,62 @@ represented by file existence. File exists -> True,
file does not exist -> False
Example: (e.g. in cdist/conf/type/__nginx_vhost/manifest)
--------------------------------------------------------------------------------
# required parameter
servername="$(cat "$__object/parameter/servername")"
# optional parameter
if [ -f "$__object/parameter/logdirectory" ]; then
logdirectory="$(cat "$__object/parameter/logdirectory")"
fi
.. code-block:: sh
# optional parameter with predefined default
loglevel="$(cat "$__object/parameter/loglevel")"
# required parameter
servername="$(cat "$__object/parameter/servername")"
# boolean parameter
if [ -f "$__object/parameter/use_ssl" ]; then
# file exists -> True
# do some fancy ssl stuff
fi
# optional parameter
if [ -f "$__object/parameter/logdirectory" ]; then
logdirectory="$(cat "$__object/parameter/logdirectory")"
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
# 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.
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)
--------------------------------------------------------------------------------
__file /etc/rc.conf --source - << eof
...
HOSTNAME="$__target_host"
...
eof
--------------------------------------------------------------------------------
.. 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
@ -167,20 +171,20 @@ 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
.. code-block:: sh
__package_$type "$@"
--------------------------------------------------------------------------------
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).
@ -195,15 +199,15 @@ 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 cdist/conf/type/__NAME/singleton
--------------------------------------------------------------------------------
.. code-block:: sh
touch cdist/conf/type/__NAME/singleton
This will also change the way your type must be called:
--------------------------------------------------------------------------------
__YOURTYPE --parameter value
--------------------------------------------------------------------------------
.. 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.
@ -218,22 +222,22 @@ 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
.. code-block:: sh
if [ -e "$destination" ]; then
md5sum < "$destination"
fi
--------------------------------------------------------------------------------
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***.
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
@ -243,13 +247,13 @@ 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:
--------------------------------------------------------------------------------
# Debug output to stderr
echo "My fancy debug line" >&2
.. code-block:: sh
# Output to be saved by cdist for execution on the target
echo "touch /etc/cdist-configured"
--------------------------------------------------------------------------------
# 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
@ -264,13 +268,13 @@ files after the script execution.
So when you generate a script with the following content, it will work:
--------------------------------------------------------------------------------
if [ -f "$__object/parameter/name" ]; then
name="$(cat "$__object/parameter/name")"
else
name="$__object_id"
fi
--------------------------------------------------------------------------------
.. code-block:: sh
if [ -f "$__object/parameter/name" ]; then
name="$(cat "$__object/parameter/name")"
else
name="$__object_id"
fi
HINTS FOR TYPEWRITERS
@ -298,10 +302,10 @@ how to submit it.
SEE ALSO
--------
- cdist-explorer(7)
- cdist-hacker(7)
- cdist-stages(7)
- cdist-tutorial(7)
- `cdist-explorer(7) <cdist-explorer.html>`_
- `cdist-hacker(7) <cdist-hacker.html>`_
- `cdist-stages(7) <cdist-stages.html>`_
- `cdist-tutorial(7) <cdist-tutorial.html>`_
COPYING

1
docs/man/man7/cdist-type__apt_key.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__apt_key/man.rst

1
docs/man/man7/cdist-type__apt_key_uri.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__apt_key_uri/man.rst

1
docs/man/man7/cdist-type__apt_norecommends.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__apt_norecommends/man.rst

1
docs/man/man7/cdist-type__apt_ppa.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__apt_ppa/man.rst

1
docs/man/man7/cdist-type__apt_source.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__apt_source/man.rst

1
docs/man/man7/cdist-type__apt_update_index.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__apt_update_index/man.rst

1
docs/man/man7/cdist-type__block.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__block/man.rst

1
docs/man/man7/cdist-type__ccollect_source.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__ccollect_source/man.rst

1
docs/man/man7/cdist-type__cdist.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__cdist/man.rst

1
docs/man/man7/cdist-type__cdistmarker.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__cdistmarker/man.rst

1
docs/man/man7/cdist-type__config_file.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__config_file/man.rst

1
docs/man/man7/cdist-type__consul.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul/man.rst

1
docs/man/man7/cdist-type__consul_agent.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_agent/man.rst

1
docs/man/man7/cdist-type__consul_check.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_check/man.rst

1
docs/man/man7/cdist-type__consul_reload.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_reload/man.rst

1
docs/man/man7/cdist-type__consul_service.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_service/man.rst

1
docs/man/man7/cdist-type__consul_template.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_template/man.rst

1
docs/man/man7/cdist-type__consul_template_template.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_template_template/man.rst

1
docs/man/man7/cdist-type__consul_watch_checks.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_watch_checks/man.rst

1
docs/man/man7/cdist-type__consul_watch_event.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_watch_event/man.rst

1
docs/man/man7/cdist-type__consul_watch_key.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_watch_key/man.rst

1
docs/man/man7/cdist-type__consul_watch_keyprefix.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_watch_keyprefix/man.rst

1
docs/man/man7/cdist-type__consul_watch_nodes.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_watch_nodes/man.rst

1
docs/man/man7/cdist-type__consul_watch_service.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_watch_service/man.rst

1
docs/man/man7/cdist-type__consul_watch_services.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__consul_watch_services/man.rst

1
docs/man/man7/cdist-type__cron.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__cron/man.rst

1
docs/man/man7/cdist-type__debconf_set_selections.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__debconf_set_selections/man.rst

1
docs/man/man7/cdist-type__directory.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__directory/man.rst

1
docs/man/man7/cdist-type__dog_vdi.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__dog_vdi/man.rst

1
docs/man/man7/cdist-type__file.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__file/man.rst

1
docs/man/man7/cdist-type__firewalld_rule.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__firewalld_rule/man.rst

1
docs/man/man7/cdist-type__git.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__git/man.rst

1
docs/man/man7/cdist-type__group.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__group/man.rst

1
docs/man/man7/cdist-type__hostname.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__hostname/man.rst

1
docs/man/man7/cdist-type__iptables_apply.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__iptables_apply/man.rst

1
docs/man/man7/cdist-type__iptables_rule.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__iptables_rule/man.rst

1
docs/man/man7/cdist-type__issue.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__issue/man.rst

1
docs/man/man7/cdist-type__jail.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__jail/man.rst

1
docs/man/man7/cdist-type__key_value.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__key_value/man.rst

1
docs/man/man7/cdist-type__line.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__line/man.rst

1
docs/man/man7/cdist-type__link.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__link/man.rst

1
docs/man/man7/cdist-type__locale.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__locale/man.rst

1
docs/man/man7/cdist-type__motd.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__motd/man.rst

1
docs/man/man7/cdist-type__mount.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__mount/man.rst

1
docs/man/man7/cdist-type__mysql_database.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__mysql_database/man.rst

1
docs/man/man7/cdist-type__package.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package/man.rst

1
docs/man/man7/cdist-type__package_apt.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_apt/man.rst

1
docs/man/man7/cdist-type__package_emerge.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_emerge/man.rst

1
docs/man/man7/cdist-type__package_emerge_dependencies.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_emerge_dependencies/man.rst

1
docs/man/man7/cdist-type__package_luarocks.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_luarocks/man.rst

1
docs/man/man7/cdist-type__package_opkg.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_opkg/man.rst

1
docs/man/man7/cdist-type__package_pacman.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_pacman/man.rst

1
docs/man/man7/cdist-type__package_pip.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_pip/man.rst

1
docs/man/man7/cdist-type__package_pkg_freebsd.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_pkg_freebsd/man.rst

1
docs/man/man7/cdist-type__package_pkg_openbsd.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_pkg_openbsd/man.rst

1
docs/man/man7/cdist-type__package_pkgng_freebsd.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_pkgng_freebsd/man.rst

1
docs/man/man7/cdist-type__package_rubygem.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_rubygem/man.rst

1
docs/man/man7/cdist-type__package_update_index.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_update_index/man.rst

1
docs/man/man7/cdist-type__package_upgrade_all.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_upgrade_all/man.rst

1
docs/man/man7/cdist-type__package_yum.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_yum/man.rst

1
docs/man/man7/cdist-type__package_zypper.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__package_zypper/man.rst

1
docs/man/man7/cdist-type__pacman_conf.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__pacman_conf/man.rst

1
docs/man/man7/cdist-type__pacman_conf_integrate.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__pacman_conf_integrate/man.rst

1
docs/man/man7/cdist-type__pf_apply.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__pf_apply/man.rst

1
docs/man/man7/cdist-type__pf_ruleset.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__pf_ruleset/man.rst

1
docs/man/man7/cdist-type__postfix.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__postfix/man.rst

1
docs/man/man7/cdist-type__postfix_master.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__postfix_master/man.rst

1
docs/man/man7/cdist-type__postfix_postconf.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__postfix_postconf/man.rst

1
docs/man/man7/cdist-type__postfix_postmap.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__postfix_postmap/man.rst

1
docs/man/man7/cdist-type__postfix_reload.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__postfix_reload/man.rst

1
docs/man/man7/cdist-type__postgres_database.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__postgres_database/man.rst

1
docs/man/man7/cdist-type__postgres_role.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__postgres_role/man.rst

1
docs/man/man7/cdist-type__process.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__process/man.rst

1
docs/man/man7/cdist-type__pyvenv.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__pyvenv/man.rst

1
docs/man/man7/cdist-type__qemu_img.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__qemu_img/man.rst

1
docs/man/man7/cdist-type__rbenv.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__rbenv/man.rst

1
docs/man/man7/cdist-type__rsync.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__rsync/man.rst

1
docs/man/man7/cdist-type__rvm.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__rvm/man.rst

1
docs/man/man7/cdist-type__rvm_gem.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__rvm_gem/man.rst

1
docs/man/man7/cdist-type__rvm_gemset.rst Symbolic link
View file

@ -0,0 +1 @@
../../../cdist/conf/type/__rvm_gemset/man.rst

Some files were not shown because too many files have changed in this diff Show more