forked from ungleich-public/cdist
		
	
		
			
				
	
	
		
			164 lines
		
	
	
	
		
			5.7 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			164 lines
		
	
	
	
		
			5.7 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
cdist-manifest(7)
 | 
						|
=================
 | 
						|
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 orientated programming languages.
 | 
						|
An object is represented by the combination of
 | 
						|
**type + slash + object name**: **__file/etc/cdist-configured** is an
 | 
						|
object of the type ***__file*** with the name ***etc/cdist-configured***.
 | 
						|
 | 
						|
All available types can be found in the **conf/type/** directory,
 | 
						|
use **ls conf/type** to get the list of available types. If you have
 | 
						|
setup the MANPATH correctly, you can use **man cdist-reference** to access
 | 
						|
the reference with pointers to the manpages.
 | 
						|
 | 
						|
 | 
						|
Types in manifests are used like normal command line tools. Let's have a look
 | 
						|
at an example:
 | 
						|
--------------------------------------------------------------------------------
 | 
						|
# Create object of type __package with the parameter state = removed
 | 
						|
__package apache2 --state removed
 | 
						|
 | 
						|
# Same with the __directory type
 | 
						|
 __directory /tmp/cdist --state present
 | 
						|
--------------------------------------------------------------------------------
 | 
						|
 | 
						|
These two lines create objects, which will later be used to realise the 
 | 
						|
configuration on the target host.
 | 
						|
 | 
						|
Manifests are executed locally as a shell script using **/bin/sh -e**.
 | 
						|
The resulting objects are stored in an internal database.
 | 
						|
 | 
						|
The same object can be redefined in multiple different manifests as long as
 | 
						|
the parameters are exactly the same.
 | 
						|
 | 
						|
In general, manifests are used to define which types are used depending
 | 
						|
on given conditions.
 | 
						|
 | 
						|
 | 
						|
INITIAL AND TYPE MANIFESTS
 | 
						|
--------------------------
 | 
						|
Cdist knows about two types of manifests: The initial manifest and type
 | 
						|
manifests. The initial manifest is used to define, which configurations
 | 
						|
to apply to which hosts. The type manifests are used to create objects
 | 
						|
from types. More about manifests in types can be found in cdist-type(7).
 | 
						|
 | 
						|
 | 
						|
DEFINE STATE IN THE INITIAL MANIFEST
 | 
						|
------------------------------------
 | 
						|
The **initial manifest** is the entry point for cdist to find out, which
 | 
						|
**objects** to configure on the selected host.
 | 
						|
Cdist searches for the initial manifest at **conf/manifest/init**.
 | 
						|
 | 
						|
Within this initial manifest, you define, which objects should be
 | 
						|
created on which host. To distinguish between hosts, you can use the
 | 
						|
environment variable **__target_host**. Let's have a look at a simple
 | 
						|
example:
 | 
						|
 | 
						|
--------------------------------------------------------------------------------
 | 
						|
__cdistmarker
 | 
						|
 | 
						|
case "$__target_host" in
 | 
						|
   localhost)
 | 
						|
        __directory /home/services/kvm-vm --parents yes
 | 
						|
   ;;
 | 
						|
esac
 | 
						|
--------------------------------------------------------------------------------
 | 
						|
 | 
						|
This manifest says: Independent of the host, always use the type 
 | 
						|
***__cdistmarker***, which creates the file **/etc/cdist-configured**,
 | 
						|
with the timestamp as content.
 | 
						|
The directory ***/home/services/kvm-vm***, including all parent directories, 
 | 
						|
is only created on the host ***localhost***.
 | 
						|
 | 
						|
As you can see, there is no magic involved, the manifest is simple shell code that
 | 
						|
utilises cdist types. Every available type can be executed like a normal 
 | 
						|
command.
 | 
						|
 | 
						|
 | 
						|
SPLITTING UP THE INITIAL MANIFEST
 | 
						|
---------------------------------
 | 
						|
If you want to split up your initial manifest, you can create other shell
 | 
						|
scripts in **conf/manifest/** and include them in **conf/manifest/init**.
 | 
						|
Cdist provides the environment variable ***__manifest*** to reference to
 | 
						|
the directory containing the initial manifest (see cdist-reference(7)).
 | 
						|
 | 
						|
The following example would include every file with a **.sh** suffix:
 | 
						|
 | 
						|
--------------------------------------------------------------------------------
 | 
						|
# Include *.sh
 | 
						|
for manifest in $__manifest/*.sh; do
 | 
						|
    # And source scripts into our shell environment
 | 
						|
    . "$manifest"
 | 
						|
done
 | 
						|
--------------------------------------------------------------------------------
 | 
						|
 | 
						|
 | 
						|
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
 | 
						|
 | 
						|
 | 
						|
--------------------------------------------------------------------------------
 | 
						|
 | 
						|
All objects that are created in a type manifest are automatically required
 | 
						|
from the type that is calling them. This is called "autorequirement" in
 | 
						|
cdist jargon.
 | 
						|
 | 
						|
 | 
						|
EXAMPLES
 | 
						|
--------
 | 
						|
The initial manifest may for instance contain the following code:
 | 
						|
 | 
						|
--------------------------------------------------------------------------------
 | 
						|
# Always create this file, so other sysadmins know cdist is used.
 | 
						|
__file /etc/cdist-configured --type file
 | 
						|
 | 
						|
case "$__target_host" in
 | 
						|
   my.server.name)
 | 
						|
      __file /root/bin/ --type directory
 | 
						|
      __file /etc/issue.net --type file --source "$__manifest/issue.net
 | 
						|
   ;;
 | 
						|
esac
 | 
						|
--------------------------------------------------------------------------------
 | 
						|
 | 
						|
The manifest of the type "nologin" may look like this:
 | 
						|
 | 
						|
--------------------------------------------------------------------------------
 | 
						|
__file /etc/nologin --type file --source "$__type/files/default.nologin"
 | 
						|
--------------------------------------------------------------------------------
 | 
						|
 | 
						|
 | 
						|
SEE ALSO
 | 
						|
--------
 | 
						|
- cdist-tutorial(7)
 | 
						|
- cdist-type(7)
 | 
						|
 | 
						|
 | 
						|
COPYING
 | 
						|
-------
 | 
						|
Copyright \(C) 2010-2012 Nico Schottelius. Free use of this software is
 | 
						|
granted under the terms of the GNU General Public License version 3 (GPLv3).
 |