forked from ungleich-public/cdist
move manpages
Signed-off-by: Steven Armstrong <steven@icarus.ethz.ch>
This commit is contained in:
Steven Armstrong
parent
19ddd092eb
commit
d27afe3528
30 changed files with 0 additions and 0 deletions
72
doc/man/man7/cdist-best-practice.text
Normal file
72
doc/man/man7/cdist-best-practice.text
Normal file
|
|
@ -0,0 +1,72 @@
|
|||
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
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
|
||||
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
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
- cdist(7)
|
||||
|
||||
|
||||
COPYING
|
||||
-------
|
||||
Copyright \(C) 2011 Nico Schottelius. Free use of this software is
|
||||
granted under the terms of the GNU General Public License version 3 (GPLv3).
|
||||
68
doc/man/man7/cdist-explorer.text
Normal file
68
doc/man/man7/cdist-explorer.text
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
cdist-explorer(7)
|
||||
=================
|
||||
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
|
||||
host. The aim of the explorer is to give hints to types on how to act on the
|
||||
target system. An explorer outputs the result to stdout, which is usually
|
||||
a one liner, but may be empty or multi line especially in the case of
|
||||
type explorers.
|
||||
|
||||
There are general explorers, which are run in an early stage, and
|
||||
type explorers. Both work almost exactly the same way, with the difference
|
||||
that the values of the general explorers are stored in a general location and
|
||||
the type specific below the object.
|
||||
|
||||
Explorers can reuse other explorers on the target system by calling
|
||||
$__explorer/<explorer_name> (general and type explorer) or
|
||||
$__type_explorer/<explorer name> (type explorer).
|
||||
|
||||
In case of significant errors, the explorer may exit non-zero and return an
|
||||
error message on stderr, which will cause the cdist run to abort.
|
||||
|
||||
You can also use stderr for debugging purposes while developing a new
|
||||
explorer.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
A very simple explorer may look like this:
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
hostname
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
Which is in practise the "hostname" explorer.
|
||||
|
||||
A type explorer, which could check for the status of a package may look like this:
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
if [ -f "$__object/parameter/name" ]; then
|
||||
name="$(cat "$__object/parameter/name")"
|
||||
else
|
||||
name="$__object_id"
|
||||
fi
|
||||
|
||||
# Except dpkg failing, if package is not known / installed
|
||||
dpkg -s "$name" 2>/dev/null || exit 0
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
- cdist(7)
|
||||
- cdist-reference(7)
|
||||
- cdist-stages(7)
|
||||
|
||||
|
||||
COPYING
|
||||
-------
|
||||
Copyright \(C) 2010-2011 Nico Schottelius. Free use of this software is
|
||||
granted under the terms of the GNU General Public License version 3 (GPLv3).
|
||||
73
doc/man/man7/cdist-hacker.text
Normal file
73
doc/man/man7/cdist-hacker.text
Normal file
|
|
@ -0,0 +1,73 @@
|
|||
cdist-hacker(7)
|
||||
===============
|
||||
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
|
||||
get into the usable configuration mangament system, cdist.
|
||||
|
||||
The first thing to know is probably that cdist is brought to
|
||||
you by people who care about how code looks like and who think
|
||||
twice before merging or implementing a feature: Less features
|
||||
with good usability are far better than the opposite.
|
||||
|
||||
|
||||
UNDERSTANDING CDIST INTERNALS
|
||||
-----------------------------
|
||||
IF you are interested in how cdist internally works, you can open
|
||||
bin/cdist-config and bin/cdist-deploy-to in your favorite editor and
|
||||
read the scripts bin/cdist-deploy-to calls. The magnificent HACKERS_README
|
||||
may be of great help as well.
|
||||
|
||||
|
||||
CODING CONVENTIONS (CORE)
|
||||
-------------------------
|
||||
- All variables exported by cdist are prefixed with a double underscore (__)
|
||||
- All cdist-internal variables are prefixed with __cdist_ and are generally not exported.
|
||||
|
||||
|
||||
HOW TO SUBMIT STUFF FOR INCLUSION INTO UPSTREAM CDIST
|
||||
-----------------------------------------------------
|
||||
If you did some cool changes to cdist, which you value as a benefit for
|
||||
everybody using cdist, you're welcome to propose inclusion into upstream.
|
||||
|
||||
There are though some requirements to ensure your changes don't break others
|
||||
work nor kill the authors brain:
|
||||
|
||||
- Code submission must be done via git
|
||||
- Code to be included should be branched of the upstream "master" branch
|
||||
- Exception: Bugfixes to a version branch
|
||||
- Code submissions must be in your master branch
|
||||
- Exception: If you only want a comment on your code, but not an inclusion.
|
||||
- Do not add conf/manifest/init - This file should only be touched in your
|
||||
private branch!
|
||||
|
||||
As soon as your work meets these requirements, you can contact me
|
||||
(IRC, Mailinglist, Phone, RFC 1149) and I'll check your code before
|
||||
including it.
|
||||
|
||||
|
||||
HOW TO SUBMIT A NEW TYPE
|
||||
------------------------
|
||||
Submitting a type works as described above, with the additional requirement
|
||||
that a corresponding manpage named man.text in asciidoc format with
|
||||
the manpage-name "cdist-type__NAME" is included in the type directory
|
||||
AND asciidoc is able to compile it.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
- cdist(7)
|
||||
|
||||
|
||||
COPYING
|
||||
-------
|
||||
Copyright \(C) 2011 Nico Schottelius. Free use of this software is
|
||||
granted under the terms of the GNU General Public License version 3 (GPLv3).
|
||||
81
doc/man/man7/cdist-manifest.text
Normal file
81
doc/man/man7/cdist-manifest.text
Normal file
|
|
@ -0,0 +1,81 @@
|
|||
cdist-manifest(7)
|
||||
=================
|
||||
Nico Schottelius <nico-cdist--@--schottelius.org>
|
||||
|
||||
|
||||
NAME
|
||||
----
|
||||
cdist-manifest - Define types to be used
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Manifests exist to define which configurations should be applied to a specific
|
||||
host as well as to define which configurations should be applied within a
|
||||
type. Manifests are executed locally and the resulting objects are stored in
|
||||
an internal database.
|
||||
|
||||
The same object can be redefined in multiple different manifests as long as
|
||||
the parameters are exactly the same.
|
||||
|
||||
In general, manifests are used to define which types are used depending
|
||||
on given conditions.
|
||||
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
The initial manifest may for instance contain the following code:
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
# Always create this file, so other sysadmins know cdist is used.
|
||||
__file /etc/cdist-configured --type file
|
||||
|
||||
case "$__target_host" in
|
||||
my.server.name)
|
||||
__file /root/bin/ --type directory
|
||||
__file /etc/issue.net --type file --source "$__manifest/issue.net
|
||||
;;
|
||||
esac
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
The manifest of the type "nologin" may look like this:
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
__file /etc/nologin --type file --source "$__type/files/default.nologin"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
DEPENDENCIES
|
||||
------------
|
||||
If you want to describe that something requires something else, just
|
||||
setup the variable "require" to contain the requirements. Multiple
|
||||
requirements can be added white space seperated.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
# No dependency
|
||||
__file /etc/cdist-configured
|
||||
|
||||
# Require above object
|
||||
require="__file/etc/cdist-configured" __link /tmp/cdist-testfile \
|
||||
--source /etc/cdist-configured --type symbolic
|
||||
|
||||
# Require two objects
|
||||
require="__file/etc/cdist-configured __link/tmp/cdist-testfile" \
|
||||
__file /tmp/cdist-another-testfile
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
- cdist-manifest-run(1)
|
||||
- cdist-manifest-run-all(1)
|
||||
- cdist-manifest-run-init(1)
|
||||
- cdist-type(7)
|
||||
|
||||
|
||||
COPYING
|
||||
-------
|
||||
Copyright \(C) 2010-2011 Nico Schottelius. Free use of this software is
|
||||
granted under the terms of the GNU General Public License version 3 (GPLv3).
|
||||
140
doc/man/man7/cdist-stages.text
Normal file
140
doc/man/man7/cdist-stages.text
Normal file
|
|
@ -0,0 +1,140 @@
|
|||
cdist-stages(7)
|
||||
===============
|
||||
Nico Schottelius <nico-cdist--@--schottelius.org>, Steven Armstrong <steven-dist--@--armstrong.cc>
|
||||
|
||||
|
||||
NAME
|
||||
----
|
||||
cdist-stages - Stages used during configuration deployment
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Starting the execution of deployment with cdist-deploy-to(1), cdist passes
|
||||
through different stages, each can be triggered and debugged on its own.
|
||||
Reading the source of the cdist-deploy-to and cdist-object-run-all executables
|
||||
shows the scripts responsible for each stage.
|
||||
|
||||
|
||||
STAGE 0: INTERNAL PREPERATION
|
||||
-----------------------------
|
||||
Before running the user facing stages, cdist prepares the target host
|
||||
to contain cdist binaries and creates a clean environment for the
|
||||
configuration run.
|
||||
|
||||
Related documentation:
|
||||
- Source of cdist-deploy-to
|
||||
|
||||
|
||||
STAGE 1: TARGET INFORMATION RETRIEVAL
|
||||
--------------------------------------
|
||||
In this stage information is collected about the target host using so called
|
||||
explorers. Every existing explorer is run on the target and the output of all
|
||||
explorers are copied back into the local cache. The results can be used by
|
||||
manifests and types.
|
||||
|
||||
Related documentation:
|
||||
- cdist-explorer-run-global(1)
|
||||
- cdist-remote-explorer-run(1)
|
||||
- cdist-explorer(7)
|
||||
|
||||
|
||||
STAGE 2: RUN THE INITIAL MANIFEST
|
||||
---------------------------------
|
||||
The initial manifest, which should be used for mappings of hosts to types,
|
||||
is executed. This stage creates objects in a cconfig database that contains
|
||||
the objects as defined in the manifest for the specific host. In this stage,
|
||||
no conflicts may occur, i.e. no object of the same type with the same id may
|
||||
be created.
|
||||
|
||||
Related documentation:
|
||||
- cdist-manifest-run-init(1)
|
||||
- cdist-manifest-run(1)
|
||||
- cdist-manifest(7)
|
||||
|
||||
|
||||
STAGE 3: OBJECT INFORMATION RETRIEVAL
|
||||
-------------------------------------
|
||||
Every object is checked whether its type has explorers and if so, these are
|
||||
transfered to the target host and executed. The results are transfered back
|
||||
and can be used in the following stages to decide what changes need to made
|
||||
on the target to implement the desired state.
|
||||
|
||||
Related documentation:
|
||||
- cdist-object-explorer-run(1)
|
||||
- cdist-remote-explorer-run(1)
|
||||
- cdist-type(7)
|
||||
- cdist-explorer(7)
|
||||
|
||||
|
||||
STAGE 4: RUN THE OBJECT MANIFEST
|
||||
--------------------------------
|
||||
Every object is checked whether its type has a manifest file. If the type has
|
||||
a manifest file and it is executable, it will be executed. The manifest script
|
||||
may generate and change the created objects. In other words, one type can reuse
|
||||
other types.
|
||||
|
||||
For instance the object __apache/www.test.ch is of type __apache, which may
|
||||
contain a manifest script, which creates new objects of type __file.
|
||||
|
||||
The newly created objects are merged back into the existing tree. No conflicts
|
||||
may occur during the merge. A conflict would mean that two different objects
|
||||
try to create the same object, which indicates a broken configuration.
|
||||
|
||||
Related documentation:
|
||||
- cdist-object-manifest-run(1)
|
||||
- cdist-manifest-run(1)
|
||||
- cdist-type(7)
|
||||
|
||||
|
||||
STAGE 5: CODE GENERATION
|
||||
------------------------
|
||||
In this stage for every created objects its type is checked whether it has a
|
||||
gencode script. If the type has a gencode script and it is executable it will
|
||||
be executed. This executable should create code to be executed on the target
|
||||
on stdout. If the gencode executable fails, it must print diagnostic messages
|
||||
on stderr and exit non-zero.
|
||||
|
||||
Related documentation:
|
||||
- cdist-object-gencode-run(1)
|
||||
- cdist-object-gencode(1)
|
||||
- cdist-type(7)
|
||||
|
||||
|
||||
STAGE 6: CODE EXECUTION
|
||||
-----------------------
|
||||
For every object the resulting code from the previous stage is transferred to
|
||||
the target host and executed there to apply the configuration changes.
|
||||
|
||||
Related documentation:
|
||||
- cdist-object-code-run(1)
|
||||
- cdist-code-run(1)
|
||||
|
||||
|
||||
STAGE 7: CACHE
|
||||
--------------
|
||||
The cache stores the information from the current run for later use.
|
||||
|
||||
Related documentation:
|
||||
- cdist-cache(1)
|
||||
|
||||
|
||||
SUMMARY
|
||||
-------
|
||||
If, and only if, all the stages complete without an errors, the configuration
|
||||
will be applied to the target. Each stage can also be run individually, though
|
||||
dependencies for each stage must be fulfilled and thus the stages must be run
|
||||
in correct order.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
- cdist(7)
|
||||
- cdist-deploy-to(1)
|
||||
- cdist-reference(7)
|
||||
|
||||
|
||||
COPYING
|
||||
-------
|
||||
Copyright \(C) 2010-2011 Nico Schottelius, Steven Armstrong. Free use of this software is
|
||||
granted under the terms of the GNU General Public License version 3 (GPLv3).
|
||||
214
doc/man/man7/cdist-type.text
Normal file
214
doc/man/man7/cdist-type.text
Normal file
|
|
@ -0,0 +1,214 @@
|
|||
cdist-type(7)
|
||||
=============
|
||||
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)
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Types are the main component of cdist and define functionality. If you
|
||||
use cdist, you'll write a type for every functionality you would like
|
||||
to use.
|
||||
|
||||
|
||||
HOW TO USE A TYPE
|
||||
-----------------
|
||||
You can use types from the initial manifest or the type manifest like a
|
||||
normal command:
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
# Creates empty file /etc/cdist-configured
|
||||
__file /etc/cdist-configured --type file
|
||||
|
||||
# Ensure tree is installed
|
||||
__package tree --state installed
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
Internally cdist-type-emulator(1) will be called from cdist-manifest-run(1) to
|
||||
save the given parameters into a cconfig database, so they can be accessed by
|
||||
the manifest and gencode scripts of the type (see below).
|
||||
|
||||
A list of supported types can be found in the cdist-reference(7) manpage.
|
||||
|
||||
SINGLETON TYPES
|
||||
---------------
|
||||
If a type is flagged as a singleton, it may me used only once. This
|
||||
is useful for types which can be used only once on a system. If a type
|
||||
can only be used once, it does not take an
|
||||
|
||||
Example:
|
||||
--------------------------------------------------------------------------------
|
||||
# __issue type manages /etc/issue
|
||||
__issue
|
||||
|
||||
# Probably your own type - singletons may use parameters
|
||||
__myfancysingleton --colour green
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
|
||||
|
||||
HOW TO WRITE A NEW TYPE
|
||||
-----------------------
|
||||
A type consists of
|
||||
|
||||
- parameter (optional)
|
||||
- manifest (optional)
|
||||
- singleton (optional)
|
||||
- explorer (optional)
|
||||
- gencode (optional)
|
||||
|
||||
Types are stored below conf/type/. Their name should always be prefixed with
|
||||
two underscores (__) to prevent collisions with other binaries in $PATH.
|
||||
|
||||
To begin a new type from a template, execute "cdist-type-template __NAME"
|
||||
and cd conf/type/__NAME.
|
||||
|
||||
|
||||
DEFINING PARAMETERS
|
||||
-------------------
|
||||
Every type consists of optional and required parameters, which must
|
||||
be created in a newline seperated file in parameters/required and
|
||||
parameters/optional. If either or both missing, the type will have
|
||||
no required, no optional or no parameters at all.
|
||||
|
||||
Example:
|
||||
--------------------------------------------------------------------------------
|
||||
echo servername >> conf/type/__nginx_vhost/parameter/required
|
||||
echo logdirectory >> conf/type/__nginx_vhost/parameter/optional
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
|
||||
WRITING THE MANIFEST
|
||||
--------------------
|
||||
In the manifest of a type you can use other types, so your type extends
|
||||
their functionality. A good example is the __package type, which in
|
||||
a shortened version looks like this:
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
os="$(cat "$__global/explorer/os")"
|
||||
case "$os" in
|
||||
archlinux) type="pacman" ;;
|
||||
debian|ubuntu) type="apt" ;;
|
||||
gentoo) type="emerge" ;;
|
||||
*)
|
||||
echo "Don't know how to manage packages on: $os" >&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
__package_$type "$@"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
As you can see, the type can reference different environment variables,
|
||||
which are documented in cdist-environment-variables(7).
|
||||
|
||||
Always ensure the manifest is executable, otherwise cdist will not be able
|
||||
to execute it.
|
||||
|
||||
|
||||
SINGLETON - ONLY INSTANCE ONLY
|
||||
------------------------------
|
||||
If you want to ensure that a type can only be used once per target, you can
|
||||
mark it as a singleton: Just create the (empty) file "singleton" in your type
|
||||
directory. This will also change the way your type must be called:
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
__YOURTYPE --parameter value
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
As you can see, the ID is omitted, because it does not make any sense, if your
|
||||
type can be used only once.
|
||||
|
||||
|
||||
THE TYPE EXPLORERS
|
||||
------------------
|
||||
If a type needs to explore specific details, it can provide type specific
|
||||
explorers, which will be executed on the target for every created object.
|
||||
|
||||
The explorers are stored under the "explorer" directory below the type.
|
||||
It could for instance contain code to check the md5sum of a file on the
|
||||
client, like this (shortened version from real type __file):
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
if [ -f "$__object/parameter/destination" ]; then
|
||||
destination="$(cat "$__object/parameter/destination")"
|
||||
else
|
||||
destination="/$__object_id"
|
||||
fi
|
||||
|
||||
if [ -e "$destination" ]; then
|
||||
md5sum < "$destination"
|
||||
fi
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
|
||||
WRITING THE GENCODE SCRIPT
|
||||
--------------------------
|
||||
There are two gencode scripts: gencode-local and gencode-remote.
|
||||
The output of gencode-local is executed locally, whereas
|
||||
the output of gencode-remote is executed on the target.
|
||||
|
||||
The gencode script can make use of the parameters, the global explorers
|
||||
and the type specific explorers. The output (stdout) of this script is
|
||||
saved by cdist and will be executed on the target.
|
||||
|
||||
If the gencode script encounters an error, it should print diagnostic
|
||||
messages to stderr and exit non-zero. If you need to debug the gencode
|
||||
script, you can write to stderr:
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
# Debug output to stderr
|
||||
echo "My fancy debug line" >&2
|
||||
|
||||
# Output to be saved by cdist for execution on the target
|
||||
echo "touch /etc/cdist-configured"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
|
||||
HINTS FOR TYPEWRITERS
|
||||
----------------------
|
||||
It must be assumed that the target is pretty dumb and thus does not have high
|
||||
level tools like ruby installed. If a type requires specific tools to be present
|
||||
on the target, there must be another type that provides this tool and the first
|
||||
type should create an object of the specific type.
|
||||
|
||||
If your type wants to save temporay data, that may be used by other types
|
||||
later on (for instance __file), you can save them in the subdirectory
|
||||
"files" below $__object (but you must create it yourself). cdist will not touch
|
||||
this directory.
|
||||
|
||||
If your type contains static files, it's also recommened to place them in
|
||||
a folder named "files" within the type (again, because cdist guarantees to
|
||||
never ever touch this folder).
|
||||
|
||||
HOW TO INCLUDE A TYPE INTO UPSTREAM CDIST
|
||||
-----------------------------------------
|
||||
If you think your type may be useful for others, ensure it works with the
|
||||
current master branch of cdist and submit the git url containing the type for
|
||||
inclusion to the mailinglist **cdist at cdist -- at -- l.schottelius.org**.
|
||||
|
||||
Ensure a corresponding manpage named man.text in asciidoc format with
|
||||
the manpage-name "cdist-type__NAME" is included in the type directory.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
- cdist-manifest-run(1)
|
||||
- cdist-stages(7)
|
||||
|
||||
|
||||
COPYING
|
||||
-------
|
||||
Copyright \(C) 2011 Nico Schottelius. Free use of this software is
|
||||
granted under the terms of the GNU General Public License version 3 (GPLv3).
|
||||
49
doc/man/man7/cdist.text
Normal file
49
doc/man/man7/cdist.text
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
cdist(7)
|
||||
========
|
||||
Nico Schottelius <nico-cdist--@--schottelius.org>
|
||||
|
||||
|
||||
NAME
|
||||
----
|
||||
cdist - Configuration management system
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Cdist is a usable configuration management system.
|
||||
The easiest way to get started with cdist is to initialise
|
||||
the environment and run cdist-quickstart:
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
eval `./bin/cdist-env` && cdist-quickstart
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
Cdist configurations are written in the shell scripting language.
|
||||
The mapping of configurations to hosts is defined in so called manifests,
|
||||
logical units of functionality are called "types" in cdist jargon.
|
||||
Cdist ships with some types included. You can use or change them, create new
|
||||
ones or even submit your types for inclusion into cdist.
|
||||
|
||||
The main command is cdist-deploy-to, which runs several stages to push
|
||||
configurations to a host. If you want to deeply understand cdist, reading
|
||||
the source of cdist-deploy-to is recommended.
|
||||
Cdist currently uses the push approach (a server pushes out the
|
||||
configuration to the clients), but future version will also support the
|
||||
pull mechanism (client requests configuration).
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
- Website: http://www.nico.schottelius.org/cdist/[]
|
||||
- cdist-best-practise(7)
|
||||
- cdist-deploy-to(1)
|
||||
- cdist-hacker(7)
|
||||
- cdist-manifest(7)
|
||||
- cdist-quickstart(1)
|
||||
- cdist-type(7)
|
||||
|
||||
|
||||
COPYING
|
||||
-------
|
||||
Copyright \(C) 2010-2011 Nico Schottelius. Free use of this software is
|
||||
granted under the terms of the GNU General Public License version 3 (GPLv3).
|
||||
Loading…
Add table
Add a link
Reference in a new issue