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

Merge branch 'master' into feature_files_export

Browse source
This commit is contained in:
Darko Poljak 2016-06-10 21:04:43 +02:00
commit e3636e6ffc
475 changed files with 10788 additions and 3878 deletions
Download patch file Download diff file Expand all files Collapse all files

511
docs/changelog
View file

@ -1,15 +1,138 @@
Changelog
---------
* Changes are always commented with their author in (braces)
* Exception: No braces means author == Nico Schottelius
4.1.0: 2016-05-27
* Documentation: Migrate to reStructuredText format and sphinx (Darko Poljak)
* Core: Add -f option to read additional hosts from file/stdin (Darko Poljak)
* Type __apt_key: Use pool.sks-keyservers.net as keyserver (Steven Armstrong)
4.0.0: 2016-05-04
* Core: Fix bug with parallel hosts operation when output path is specifed (Darko Poljak)
* Type __package_pip: Add support for running as specified user (useful for pip in venv) (Darko Poljak)
* New type: __pyvenv: Manage python virtualenv (Darko Poljak)
* Core: Add CDIST_REMOTE_COPY/EXEC env variables and multiplexing options for default scp/ssh (Darko Poljak)
* Types: Remove bashisms in scripts (Darko Poljak)
* Core: Fix bug in remote command with environment (Darko Poljak)
* Core: Fix bug in local code execution (Darko Poljak)
* Documentation: Fix spelling in manual pages (Dmitry Bogatov)
* New type: __pacman_conf: Manage pacman.conf (Dominique Roux)
* New type: __pacman_conf_integrate: cdist compatible pacman.conf (Dominique Roux)
* Type __consul: Do not install unused package unzip (Steven Armstrong)
* Type __consul: Add source & cksum for 0.5.2 (Steven Armstrong)
* Core: Support object ids '.cdist' (Nico Schottelius)
* Type __apt_norecommends: Also setup autoremove options (Dmitry Bogatov)
* Type __user_groups: Add NetBSD support (Jonathan A. Kollasch)
* Type __timezone: Add NetBSD support (Jonathan A. Kollasch)
* Type __ccollect_source: Add NetBSD support (Jonathan A. Kollasch)
* Type __directory: Add NetBSD support (Jonathan A. Kollasch)
* Type __file: Add NetBSD support (Jonathan A. Kollasch)
* Type __group: Add NetBSD support (Jonathan A. Kollasch)
* Type __consul: Add new consul versions (Nico Schottelius)
* Type __apt_ppa: Do not install legacy package python-software-properties (Steven Armstrong)
3.1.13: 2015-05-16
* Type __block: Fix support for non stdin blocks (Dominique Roux)
* Type __consul: Install package unzip (Nico Schottelius)
* Type __consul: Add source & cksum for 0.5.1 (Nico Schottelius)
* Type __consul_agent: Use systemd for Debian 8 (Nico Schottelius)
* Type __firewalld_rule: Ensure firewalld package is present (David Hürlimann)
* Type __locale: Support CentOS (David Hürlimann)
* Type __staged_file: Fix comparision operator (Nico Schottelius)
* Type __user_groups: Support old Linux versions (Daniel Heule)
3.1.12: 2015-03-19
* Core: Support object ids '.cdist' (Nico Schottelius)
* New type: __firewalld_rule (Nico Schottelius)
* Type __consul_agent: add support for acl options (Steven Armstrong)
* Type __consul_agent: add support for Debian (Nico Schottelius)
* Type __package_apt: Use default parameters (Antoine Catton)
* Type __package_luarocks: Use default parameters (Antoine Catton)
* Type __package_opkg: Use default parameters (Antoine Catton)
* Type __package_pacman: Use default parameters (Antoine Catton)
* Type __package_pip: Use default parameters (Antoine Catton)
* Type __package_pkg_freebsd: Use default parameters (Antoine Catton)
* Type __package_pkg_openbsd: Use default parameters (Antoine Catton)
* Type __package_pkgng_openbsd: Use default parameters (Antoine Catton)
3.1.11: 2015-02-27
* New type: __staged_file: Manage staged files (Steven Armstrong)
* New type: __config_file: Manage configuration files and run code on change (Steven Armstrong)
* New type: __consul: install consul (Steven Armstrong)
* New type: __consul_agent: manage the consul agent (Steven Armstrong)
* New type: __consul_check: manages consul checks (Steven Armstrong)
* New type: __consul_reload: reload consul (Steven Armstrong)
* New type: __consul_service: manages consul services (Steven Armstrong)
* New type: __consul_template: manage the consul-template service (Steven Armstrong)
* New type: __consul_template_template: manage consul-template templates (Steven Armstrong)
* New type: __consul_watch_checks: manages consul checks watches (Steven Armstrong)
* New type: __consul_watch_event: manages consul event watches (Steven Armstrong)
* New type: __consul_watch_key: manages consul key watches (Steven Armstrong)
* New type: __consul_watch_keyprefix: manages consul keyprefix watches (Steven Armstrong)
* New type: __consul_watch_nodes: manages consul nodes watches (Steven Armstrong)
* New type: __consul_watch_service: manages consul service watches (Steven Armstrong)
* New type: __consul_watch_services: manages consul services watches (Steven Armstrong)
* New Type: __rsync (Nico Schottelius)
* Type __start_on_boot: Support Ubuntu upstart (Nico Schottelius)
* Type __timezone: Added support for FreeBSD (Christian Kruse)
3.1.10: 2015-02-10
* Core: Fix too many open files bug (#343)
* Type __ssh_authorized_keys: Remove unneeded explorer (Steven Armstrong)
* Type __ssh_authorized_keys: Fix empty output bug of entry explorer (Steven Armstrong)
* Type __package_apt: Add support for --target-release (Nico Schottelius)
* Type __locale: Add support for Ubuntu (Nico Schottelius)
* Type __group: Rewrite (Steven Armstrong)
* Documentation: Fix typo in maintainer file (Stephan Kulla)
3.1.9: 2014-10-17
* Type __package_emerge: Fix handling of slotted packages (Daniel Heule)
* Type __package_apt: Use --force-confdef (Ricardo Catalinas Jiménez)
* Type __package_update_index: Decrease verbosity (Ricardo Catalinas Jiménez)
* Type __package_upgrade_all: Decrease verbosity (Ricardo Catalinas Jiménez)
3.1.8: 2014-10-01
* New Type: __package_update_index (Ricardo Catalinas Jiménez)
* New Type: __package_upgrade_all (Ricardo Catalinas Jiménez)
3.1.7: 2014-09-29
* Type __cdistmarker: Fix typo (Ricardo Catalinas Jiménez)
* Core: Bugfix: Export messaging to manifests (Ricardo Catalinas Jiménez)
* Explorer cpu_cores, cpu_sockets, memory: Add Mac OS X support (Manuel Hutter)
* Type __ssh_authorized_keys: Ensure keys are correctly added (Steven Armstrong)
* New Type: __ssh_authorized_key (Steven Armstrong)
* New Type: __package_pkgng_freebsd (Jake Guffey)
3.1.6: 2014-08-18
* New Type: __ssh_dot_ssh (Nico Schottelius)
* Type __package_yum: Support retrieving package via URL (Nico Schottelius)
* Type __hostname: Support SuSE and have CentOS use sysconfig value (Nico Schottelius)
* Type __locale: Support SuSE (Nico Schottelius)
* Type __locale: Support Archlinux (Nico Schottelius)
* Type __timezone: Support SuSE (Nico Schottelius)
* Type __file: Support MacOS X (Manuel Hutter)
* Type __iptables_apply: Add "reset" to init.d script of iptables (Nico Schottelius)
* Type __ssh_authorized_key: Use new type __ssh_dot_ssh (Nico Schottelius)
* Type __zypper_repo: Bugfix for pattern matching (Daniel Heule)
3.1.5: 2014-05-05
* Type __zypper_repo: Automatically import gpg keys (Daniel Heule)
* Type __zypper_service: Automatically import gpg keys (Daniel Heule)
3.1.4: 2014-05-04
* Core: Ensure all created files end in \n (Steven Armstrong)
* Documentation: Cleanup up, added HTML links (Tomas Pospisek)
* Explorer interfaces: Remove test output (Daniel Heule)
* Type __jail: Add messaging support (Jake Guffey)
3.1.3: 2014-04-29
* New Type: __yum_repo (Steven Armstrong)
* Type __hostname: Add support for CentOS (Nico Schottelius)
3.1.2: 2014-04-12
* Documentation: Add missing environment variables to reference
* Type __qemu_img: size is optional, if state is not present
* Documentation: Add missing environment variables to reference (Nico Schottelius)
* Type __qemu_img: size is optional, if state is not present (Nico Schottelius)
* Type __key_value: Rewrite using awk (Daniel Heule)
* New Type: __dog_vdi
* New Type: __dog_vdi (Nico Schottelius)
3.1.1: 2014-03-26
* Core: Make __object and __object_id available to code (Daniel Heule)
@ -23,11 +146,11 @@ Changelog
* Type __package_pkg_openbsd: Improve error handling (og)
3.1.0: 2014-03-19
* New Type: __rbenv
* New Type: __rbenv (Nico Schottelius)
* Type __file: Enhance OpenBSD Support (og)
* Type __git: Pass onwer/group/mode values to __directory
* Type __git: Pass onwer/group/mode values to __directory (Nico Schottelius)
* Type __iptable_rule: Fix example documentation (Antoine Catton)
* Type __key_value: Add messaging support
* Type __key_value: Add messaging support (Nico Schottelius)
* Type __package_pkg_openbsd: Allow to change PKG_PATH (og)
* Type __ssh_authorized_keys: Allow managing existing keys (Steven Armstrong)
* Type __user: Enhance OpenBSD Support (og)
@ -35,7 +158,7 @@ Changelog
3.0.9: 2014-02-14
* Core: Ignore order dependencies if override is set (Daniel Heule)
* Core: Improve Mac OS X support for unit tests (Steven Armstrong)
* Type __locale: Error out in case of unsupported OS
* Type __locale: Error out in case of unsupported OS (Nico Schottelius)
* Type __jail: Use default parameters for state (Daniel Heule)
* Type __pf_ruleset: Use default parameters for state (Daniel Heule)
* Type __postgres_database: Use default parameters for state (Daniel Heule)
@ -59,7 +182,7 @@ Changelog
* New Type: __apt_key_uri (Steven Armstrong)
* New Type: __apt_norecommends (Steven Armstrong)
* New Type: __apt_source (Steven Armstrong)
* New Type: __ccollect_source
* New Type: __ccollect_source (Nico Schottelius)
* Type __git: Use default parameters (Daniel Heule)
* Type __jail: Use default parameters (Daniel Heule)
* Type __package_yum: Use default parameters (Daniel Heule)
@ -69,24 +192,24 @@ Changelog
3.0.5: 2014-02-05
* Core: Introduce override concept (Daniel Heule)
* Type __process: Make --state absent work (Steven Armstrong)
* Documentation: Update documentation for environment variables
* Documentation: Update documentation for environment variables (Nico Schottelius)
3.0.4: 2014-01-29
* Core: Ignore install types in config mode
* Documentation: Update reference (files path in object space)
* Documentation: Update best practise: Replaces templates/ with files/
* Core: Ignore install types in config mode (Nico Schottelius)
* Documentation: Update reference (files path in object space) (Nico Schottelius)
* Documentation: Update best practise: Replaces templates/ with files/ (Nico Schottelius)
* Type __apt_ppa: Install required software (Steven Armstrong)
* Type __debconf_set_selections: Support --file - to read from stdin
* Type __debconf_set_selections: Support --file - to read from stdin (Nico Schottelius)
* Type __jail: Fix jaildir parameter handling (Jake Guffey)
3.0.3: 2014-01-22
* Core: Enhance error message when requirement is missing object id
* Core: Enhance error message when requirement is missing object id (Nico Schottelius)
* Core: Add environment variable to select shell for executing scripts (Daniel Heule)
* Explorer hostname: Return host name by using uname -n
* Explorer hostname: Return host name by using uname -n (Nico Schottelius)
* New Type: __hostname (Steven Armstrong)
* Type __cdist: Use default paremeters (Daniel Heule)
* Type __key_value: Use default paremeters (Daniel Heule)
* Type __line: Use printf instead of echo for printing user input
* Type __line: Use printf instead of echo for printing user input (Nico Schottelius)
* Type __qemu_img: Use default paremeters (Daniel Heule)
* Type __zypper_repo: Use default paremeters (Daniel Heule)
* Type __zypper_service: Use default paremeters (Daniel Heule)
@ -100,16 +223,16 @@ Changelog
3.0.1: 2014-01-14
* Core: Copy only files, not directories (Steven Armstrong)
* Core: Allow hostnames to start with /
* Type __line: Remove unecessary backslash escape
* Core: Allow hostnames to start with / (Nico Schottelius)
* Type __line: Remove unecessary backslash escape (Nico Schottelius)
* Type __directory: Add messaging support (Daniel Heule)
* Type __directory: Do not generate code if mode is 0xxx (Daniel Heule)
* Type __package: Fix typo in optional parameter ptype (Daniel Heule)
* Type __start_on_boot: Fix for SuSE's chkconfig (Daniel Heule)
3.0.0: 2013-12-24
* Core: Added messaging support
* Core: Removed unused "changed" attribute of objects
* Core: Added messaging support (Nico Schottelius)
* Core: Removed unused "changed" attribute of objects (Nico Schottelius)
* Core: Support default values for multiple parameters (Steven Armstrong)
* Core: Ensure Object Parameter file contains \n (Steven Armstrong)
* New Type: __zypper_repo (Daniel Heule)
@ -119,8 +242,8 @@ Changelog
* Type __cron: Add support for raw lines (Daniel Heule)
* Type __cron: Suppress stderr output from crontab (Daniel Heule)
* Type __cron: Fix quoting issue (Daniel Heule)
* Type __file: Do not generate code if mode is 0xxx
* Type __iptables_rule: Use default parameter
* Type __file: Do not generate code if mode is 0xxx (Nico Schottelius)
* Type __iptables_rule: Use default parameter (Nico Schottelius)
* Type __key_value: Fix quoting issue (Steven Armstrong)
* Type __package: Use state --present by default (Steven Armstrong)
* Type __package_zypper: Support non packages as well (Daniel Heule)
@ -128,7 +251,7 @@ Changelog
* Type __postfix_*: Depend on __postfix Type (Steven Armstrong)
* Type __postfix_postconf: Enable support for SuSE (Daniel Heule)
* Type __postfix: Enable support for SuSE (Daniel Heule)
* Type __start_on_boot: Use default parameter state
* Type __start_on_boot: Use default parameter state (Nico Schottelius)
* Type __start_on_boot: Add support for gentoo (Daniel Heule)
* Type __user: Add support for state parameter (Daniel Heule)
* Type __user: Add support for system users (Daniel Heule)
@ -140,19 +263,19 @@ Changelog
* Type __file: Only remove file when state is absent (Steven Armstrong)
* Type __link: Only remove link when state is absent (Steven Armstrong)
* Type __directory: Only remove directory when state is absent (Steven Armstrong)
* Type __directory: Fix newly introduced quoting issue
* Type __directory: Fix newly introduced quoting issue (Nico Schottelius)
* Type __package_zypper: Fix explorer and parameter issue (Daniel Heule)
* Core: Fix backtrace when cache cannot be deleted
* Core: Fix backtrace when cache cannot be deleted (Nico Schottelius)
2.3.6: 2013-11-25
* New Type: __locale
* Type __line: Ensure special characters are not interpreted
* New Type: __locale (Nico Schottelius)
* Type __line: Ensure special characters are not interpreted (Nico Schottelius)
2.3.5: 2013-10-10
* Core: Unit test fix for remote_copy (Steven Armstrong)
* Documentation: Updated manpages of __package and __file (Alex Greif)
* Documentation: Add more examples to cdist-manifest (Dan Levin)
* Type __package_apt: Do not install recommends by default
* Type __package_apt: Do not install recommends by default (Nico Schottelius)
2.3.4: 2013-10-03
* Core: Add missing bits to support dry run (Steven Armstrong)
@ -170,51 +293,51 @@ Changelog
* Type __start_on_boot: Bugfix for systemd (Steven Armstrong)
2.3.2: 2013-09-05
* Build: Ensure tests don't change attributes of non-test files
* Core: Fix typo in argument parser
* Build: Ensure tests don't change attributes of non-test files (Nico Schottelius)
* Core: Fix typo in argument parser (Nico Schottelius)
* Core: Code cleanup: Remove old install code (Steven Armstrong)
* Core: Improve error message when using non-existing type in requirement
* New Type: __iptables_rule
* New Type: __iptables_apply
* Type __cdist: Also create home directory
* Type __cdist: Add support for --shell parameter
* Type __motd: Regenerate motd on Debian and Ubuntu
* Core: Improve error message when using non-existing type in requirement (Nico Schottelius)
* New Type: __iptables_rule (Nico Schottelius)
* New Type: __iptables_apply (Nico Schottelius)
* Type __cdist: Also create home directory (Nico Schottelius)
* Type __cdist: Add support for --shell parameter (Nico Schottelius)
* Type __motd: Regenerate motd on Debian and Ubuntu (Nico Schottelius)
2.3.1: 2013-08-28
* Core: Support relative paths for configuration directories
* Core: Code cleanup (removed context class, added log class)
* Documentation: Add more best practises
* Documentation: Add troubleshooting chapter
* Core: Support relative paths for configuration directories (Nico Schottelius)
* Core: Code cleanup (removed context class, added log class) (Nico Schottelius)
* Documentation: Add more best practises (Nico Schottelius)
* Documentation: Add troubleshooting chapter (Nico Schottelius)
* Type __key_value: Fix quoting problem (Steven Armstrong)
2.3.0: 2013-08-12
* Core: Added support for cdist shell
* Documentation: Improved some manpages
* Core: Added support for cdist shell (Nico Schottelius)
* Documentation: Improved some manpages (Nico Schottelius)
2.2.0: 2013-07-12
* Build: Cleanup the Makefile
* Type __package_opkg: Use shortcut version
* Build: Cleanup the Makefile (Nico Schottelius)
* Type __package_opkg: Use shortcut version (Nico Schottelius)
* Core: Remove old pseudo object id "singleton" (Steven Armstrong)
2.1.2: 2013-07-09
* Build: Change clean-dist target to "distclean"
* Build: Change clean-dist target to "distclean" (Nico Schottelius)
* Build: Moved a lot of build logic into Makefile for dependency resolution
* Core: Make global explorers available to initial manifest (Arkaitz Jimenez)
* Core: Change execution order to run object as one unit
* Core: Change execution order to run object as one unit (Nico Schottelius)
* Documentation: Improved documentation (Tomáš Pospíšek)
* New Remote Example: Add support for sudo operations (Chase James)
* New Type: __update_alternatives
* New Type: __cdist
* New Type: __update_alternatives (Nico Schottelius)
* New Type: __cdist (Nico Schottelius)
* Type __apt_ppa: Fix comparison operator (Tyler Akins)
* Type __start_on_boot: Archlinux changed to use systemd - adapt type
* Type __start_on_boot: Archlinux changed to use systemd - adapt type (Nico Schottelius)
* Type __git: Missing quotes added (Chase James)
* Type __postgres_database: Make state parameter optional (Chase James)
* Type __postgres_role: Make state parameter optional, fix password bug (Chase James)
* Type __process: Make state parameter optional
* Type __cron: Simplyfied and syntax change
* Type __process: Make state parameter optional (Nico Schottelius)
* Type __cron: Simplyfied and syntax change (Nico Schottelius)
2.1.1: 2013-04-08
* Core: Use dynamic dependency resolver to allow indirect self dependencies
* Core: Use dynamic dependency resolver to allow indirect self dependencies (Nico Schottelius)
* Core: Remove umask call - protect /var/lib/cdist only (Arkaitz Jimenez)
* Explorer os: Added Slackware support (Eivind Uggedal)
* Type __git: Support mode and fix owner/group settings (contradict)
@ -224,90 +347,90 @@ Changelog
* Type __user: Add support for creating user home (Arkaitz Jimenez)
2.1.0: 2012-12-09
* Core: Ensure global explorers are executable
* Core: Ensure global explorers are executable (Nico Schottelius)
* Core: Ensure type explorers are executable (Steven Armstrong)
* New Type: __git
* New Type: __git (Nico Schottelius)
* New Type: __ssh_authorized_keys (Steven Armstrong)
* New Type: __user_groups (Steven Armstrong)
* Type __rvm_gemset: Change parameter "default" to be boolean
* Type __rvm_gemset: Change parameter "default" to be boolean (Nico Schottelius)
* Type __user: Remove --groups support (now provided by __user_groups)
* Type __apt_ppa: Bugfix: Installeded ppa detection (Steven Armstrong)
* Type __jail: Change optional parameter "started" to boolean "stopped" parameter,
change optional parameter "devfs-enable" to boolean "devfs-disable" parameter and
change optional parameter "onboot" to boolean.
* Type __package_pip: Bugfix: Installeded the package, not pyro
* Remove Type __ssh_authorized_key: Superseeded by __ssh_authorized_keys
change optional parameter "onboot" to boolean. (Nico Schottelius)
* Type __package_pip: Bugfix: Installeded the package, not pyro (Nico Schottelius)
* Remove Type __ssh_authorized_key: Superseeded by __ssh_authorized_keys (Nico Schottelius)
* Support for CDIST_PATH (Steven Armstrong)
2.1.0pre8: 2012-11-15
* Type cleanup: __apt_ppa, __apt_ppa_update_index, __file,
__ssh_authorized_key, __timezone, all install types (Steven Armstrong)
* Types: Remove all parameter changing code
* Type __rvm_ruby: Change parameter "default" to be boolean
* Documentation: Web documentation clean up
* Types: Remove all parameter changing code (Nico Schottelius)
* Type __rvm_ruby: Change parameter "default" to be boolean (Nico Schottelius)
* Documentation: Web documentation clean up (Nico Schottelius)
2.1.0pre7: 2012-11-07
* Core: All unit tests restored back to working
* Core: Print error message when missing the initial manifest
* Core: All unit tests restored back to working (Nico Schottelius)
* Core: Print error message when missing the initial manifest (Nico Schottelius)
2.1.0pre6: 2012-11-05
* New Example: Turn remote calls into local calls (used for unittesting)
* Core: Export PYTHONPATH, it's also needed by emulator
* Bugfix Type __rvm_ruby: Add clean package dependencies
* Bugfix Type __rvm_gem: Run rvm as user, not as root
* Cleanup Type __rvm, __rvm_gemset: Use shortcut version
* Bugfix __rvm_gemset: Correctly check for gemsets
* New Example: Turn remote calls into local calls (used for unittesting) (Nico Schottelius)
* Core: Export PYTHONPATH, it's also needed by emulator (Nico Schottelius)
* Bugfix Type __rvm_ruby: Add clean package dependencies (Nico Schottelius)
* Bugfix Type __rvm_gem: Run rvm as user, not as root (Nico Schottelius)
* Cleanup Type __rvm, __rvm_gemset: Use shortcut version (Nico Schottelius)
* Bugfix __rvm_gemset: Correctly check for gemsets (Nico Schottelius)
* Cleanup Type __postgres_database, __postgres_role: Reference each other
in documentation
* Cleanp Type __postgres_role: Use boolean parameters where appropriate
* Cleanp Type __postgres_role: Use shortcut version
in documentation (Nico Schottelius)
* Cleanp Type __postgres_role: Use boolean parameters where appropriate (Nico Schottelius)
* Cleanp Type __postgres_role: Use shortcut version (Nico Schottelius)
2.1.0pre5: 2012-11-01
* Core: First round of tests updated to work with multiple configuration directories
* Core: First round of tests updated to work with multiple configuration directories (Nico Schottelius)
2.1.0pre4: 2012-10-31
* Dist: PyPi: Moved cdist.py to script/cdist to avoid double import
* Core: Added support for multiple configuration directories (no documentation)
* Dist: PyPi: Moved cdist.py to script/cdist to avoid double import (Nico Schottelius)
* Core: Added support for multiple configuration directories (no documentation) (Nico Schottelius)
2.1.0pre3: 2012-10-30
* Dist: PyPi: Types and explorer included as package data
* Dist: PyPi: Types and explorer included as package data (Nico Schottelius)
2.1.0pre2: 2012-10-26
* Dist: PyPi: Add conf/ directory to distribution
* Dist: Initial support for archlinux packaging
* Dist: PyPi: Add conf/ directory to distribution (Nico Schottelius)
* Dist: Initial support for archlinux packaging (Nico Schottelius)
2.1.0pre1: 2012-10-26
* Core: Removed obsolete variable __self
* Removed type __addifnosuchline (replaced by __line)
* Removed type __removeline (replaced by __line)
* Type __directory: Parameter --parents and --recursive are now boolean
* Core: Removed obsolete variable __self (Nico Schottelius)
* Removed type __addifnosuchline (replaced by __line) (Nico Schottelius)
* Removed type __removeline (replaced by __line) (Nico Schottelius)
* Type __directory: Parameter --parents and --recursive are now boolean (Nico Schottelius)
* Type __package_apt, __package_luarocks, __package_opkg,
__package_pacman, __package_pkg_freebsd, __package_pkg_openbsd,
__package_rubygem, __package_yum, __process:
Parameter state accepts only "present" and "absent"
* Dist: Initial support for pypi packaging
Parameter state accepts only "present" and "absent" (Nico Schottelius)
* Dist: Initial support for pypi packaging (Nico Schottelius)
2.0.15: 2012-11-02
* Core: Make variable __object_name available in type explorers (Steven Armtrong)
* New Type: __qemu_img
* New Type: __line
* New Type: __qemu_img (Nico Schottelius)
* New Type: __line (Nico Schottelius)
* New Type: __pf_apply (Jake Guffey)
* New Type: __pf_ruleset (Jake Guffey)
* Bugfix Type: __rvm: Make type work if rvm is already installed
* Bugfix Type: __rvm: Make type work if rvm is already installed (Nico Schottelius)
2.0.14: 2012-09-07
* Bugfix Type: __jail: Use correct variable (Jake Guffey)
* Change Type: __jail: Parameter jailbase now optional (Jake Guffey)
* Bugfix Type: __user: Use passwd database on FreeBSD (Jake Guffey)
* Bugfix Type: __start_on_boot: Do not change parameters
* Bugfix Type: __start_on_boot: Do not change parameters (Nico Schottelius)
* Feature __user: Added support for BSDs (Sébastien Gross)
* Feature __group: Added support for FreeBSD (Jake Guffey)
* New Type: __package_zypper
* Feature Types: Initial Support for SuSE Linux
* New Type: __package_zypper (Nico Schottelius)
* Feature Types: Initial Support for SuSE Linux (Nico Schottelius)
2.0.13: 2012-06-05
* Bugfix __ssh_authorized_key: Ensure it sets proper group (contradict)
* Bugfix __addifnosuchline: Fixed quotes/interpolation bug ("a b" became "a b")
* Bugfix __addifnosuchline: Fixed quotes/interpolation bug ("a b" became "a b") (Nico Schottelius)
* New Explorer: interfaces (Sébastien Gross)
* Feature core: Support reading from stdin in types (Steven Armstrong)
* Feature core: Support multiple parameters for types (Steven Armstrong)
@ -315,24 +438,24 @@ Changelog
2.0.12: 2012-05-29
* Core: Correctly raise error on Python < 3.2 (Steven Armtrong)
* Core: Add support for --remote-exec and --remote-copy parameters
* Core: Add support for --remote-exec and --remote-copy parameters (Nico Schottelius)
* Documentation: Debian Squeeze hints (Sébastien Gross)
2.0.11: 2012-05-23
* Fix insecure file/directory creation: Use umask 077
* Fix insecure file/directory creation: Use umask 077 (Nico Schottelius)
2.0.10: 2012-05-18
* Cleanup __group: No getent gshadow in old Redhat, use groupmod -g
(Matt Coddington)
* Bugfix __package_yum: Missing cat
* Bugfix __package_yum: Missing cat (Nico Schottelius)
* Bugfix __start_on_boot: Correctly use sed and quotes (Steven Armstrong)
* Feature __file: Support for --state exists (Steven Armstrong)
* Feature core: Make variable __manifest available to type manifests
* Feature core: Make variable __manifest available to type manifests (Nico Schottelius)
* Feature core: Correct parent dependency handling (Steven Armstrong)
* Bugfix several types: Fix sed for FreeBSD (Istvan Beregszaszi)
* New Type: __jail (Jake Guffey)
* Change Type: __rvm*: --state present/absent not installed/remvoed (Evax Software)
* Bugfix Type: __cron: Hide error output from crontab
* Bugfix Type: __cron: Hide error output from crontab (Nico Schottelius)
* Various smaller bugfixes (Chris Lamb)
2.0.9: 2012-03-12
@ -346,19 +469,19 @@ Changelog
* Feature __start_on_boot: Support for OpenWRT (Giel van Schijndel)
* Feature __start_on_boot: Support for Amazon Linux (Matt Coddington)
* New Example: Use rsync to backup files (Matt Coddington)
* Feature core: Exit non-zero, if configuration failed
* Feature core: Exit non-zero, if configuration failed (Nico Schottelius)
* Documentation: Describe how to do templating (Aurélien Bondis)
2.0.8: 2012-02-20
* Bugfix core: Remove another nasty traceback when sending SIGINT (aka Ctrl-C)
* Cleanup: Better hint to source of error
* Cleanup: Do not output failing script, but path to script only
* Bugfix core: Remove another nasty traceback when sending SIGINT (aka Ctrl-C) (Nico Schottelius)
* Cleanup: Better hint to source of error (Nico Schottelius)
* Cleanup: Do not output failing script, but path to script only (Nico Schottelius)
* Cleanup: Remove support for __debug variable in manifests (Type != Core
debugging)
debugging) (Nico Schottelius)
* Cleanup: Change __package_* to support absent/present (default state
name now). The values removed/installed will be removed in cdist 2.1.
name now). The values removed/installed will be removed in cdist 2.1. (Nico Schottelius)
* Cleanup: Change __process to support absent/present (default state
name now). The values running/stopped will be removed in cdist 2.1.
name now). The values running/stopped will be removed in cdist 2.1. (Nico Schottelius)
* Feature Core: Support boolean parameters (Steven Armstrong)
2.0.7: 2012-02-13
@ -367,9 +490,9 @@ Changelog
* Bugfix __link: Properly handle existing links (Steven Armstrong)
* Bugfix __key_value: More robust implementation (Steven Armstrong)
* Bugfix __user: Fix for changing a user's group by name (Matt Coddington)
* New Type: __package_pip
* New Type: __package_pip (Nico Schottelius)
* Bugfix/Cleanup: Correctly allow Object ID to start and end with /, but
not contain //.
not contain //. (Nico Schottelius)
2.0.6: 2012-01-28
* Bugfix __apt_ppa:
@ -388,8 +511,8 @@ Changelog
2.0.5: 2012-01-18
* Bugfix __key_value: Use correct delimiters
(Steven Armstrong, Daniel Maher)
* Cleanup: Explicitly require Python >= 3.2 (do not fail implicitly)
* Documentation: (Re)write of the tutorial
* Cleanup: Explicitly require Python >= 3.2 (do not fail implicitly) (Nico Schottelius)
* Documentation: (Re)write of the tutorial (Nico Schottelius)
* Feature: __addifnosuchline supports matching on
regular expressions (Daniel Maher)
* Feature: __directory, __file, __link:
@ -398,11 +521,11 @@ Changelog
* New Type: __cdistmarker (Daniel Maher)
2.0.4: 2011-11-18
* Bugfix core: Remove traceback when sending SIGINT (aka Ctrl-C)
* Bugfix core: Remove traceback when sending SIGINT (aka Ctrl-C) (Nico Schottelius)
* Bugfix core: Accept parameters with - in the name (Steven Armstrong)
* Cleanup: __object_fq variable removed (never used)
* Cleanup: Environment variable __self DEPRECATED, use __object_name instead
* Cleanup: Environment variable __self scheduled for removal in cdist 2.1
* Cleanup: __object_fq variable removed (never used) (Nico Schottelius)
* Cleanup: Environment variable __self DEPRECATED, use __object_name instead (Nico Schottelius)
* Cleanup: Environment variable __self scheduled for removal in cdist 2.1 (Nico Schottelius)
* Documentation: Many examples for use of __remote_* (Steven Armstrong)
* Feature: Automatically require all used objects (Steven Armstrong)
* New Type: __cron (Steven Armstrong)
@ -410,28 +533,28 @@ Changelog
2.0.3: 2011-10-18
* Improved logging, added --verbose, by more quiet by default
* Bugfix __user: Correct quoting (Steven Armstrong)
* Bugfix __addifnosuchline: Falsely exited
* Bugfix requirements: Restore original require="" behaviour
* Feature requirements: Check for broken object_ids and abort
* Bugfix __addifnosuchline: Falsely exited (Nico Schottelius)
* Bugfix requirements: Restore original require="" behaviour (Nico Schottelius)
* Feature requirements: Check for broken object_ids and abort (Nico Schottelius)
* Massive refactoring and unittesting introduced (Steven Armstrong)
2.0.2: 2011-09-27
* Add support for detection of OpenWall Linux (Matthias Teege)
* Add support for __debug variable in manifests
* Bugfix core: Various issues with type emulator
* Add support for __debug variable in manifests (Nico Schottelius)
* Bugfix core: Various issues with type emulator (Nico Schottelius)
2.0.1: 2011-09-23
* Bugfix core: Always print source of error in case of exec errors
* Bugfix core: Various smaller bugs in string concatenation
* Feature: Add marker "changed" to changed objects
* Bugfix core: Always print source of error in case of exec errors (Nico Schottelius)
* Bugfix core: Various smaller bugs in string concatenation (Nico Schottelius)
* Feature: Add marker "changed" to changed objects (Nico Schottelius)
2.0.0: 2011-09-16
* New Type: __package_rubygem (Chase Allen James)
* __self replaced by __object_fq
* Rewrote cdist in Python
* __self replaced by __object_fq (Nico Schottelius)
* Rewrote cdist in Python (Nico Schottelius)
1.7.1: 2011-07-26
* Documentation: Add explorers to reference
* Documentation: Add explorers to reference (Nico Schottelius)
* Documentation: Typo cleanup (Derek Brost)
* Type __key_value: Bugfix (Steven Armstrong)
* New Type: __postgres_role (Steven Armstrong)
@ -441,42 +564,42 @@ Changelog
* Bugfix type __package_yum: Fix redhat support (Ramon Salvadó)
* Improved type __package_yum: Add centos support (Ramon Salvadó)
* New Type: __timezone (Ramon Salvadó)
* Renamed explorer: hardware_type to machine
* Core: Do not execute empty code fragments
* Renamed explorer: hardware_type to machine (Nico Schottelius)
* Core: Do not execute empty code fragments (Nico Schottelius)
1.6.2: 2011-04-19
* Core: Introduce __cdist_tmp_base_dir
* Core: Cleanup and enhance cdist-type-template
* Core: cdist-mass-deploy: Report failed cdist-deploy-to instances
* Core: Introduce __cdist_tmp_base_dir (Nico Schottelius)
* Core: Cleanup and enhance cdist-type-template (Nico Schottelius)
* Core: cdist-mass-deploy: Report failed cdist-deploy-to instances (Nico Schottelius)
* New Type: __ssh_authorized_key (Aurélien Bondis)
1.6.1: 2011-04-07
* Improved logging: Show code responsible for abort
* Improved logging: Consistently prefix with current object or core
* Bugfix: Type __debconf_set_selections used wrong contens for selection
* Bugfix: Don't fail, if cache directory is not existing
* Bugfix: __user and __group exited non-zero if no change was necessary
* New Explorer: hardware_type
* Improved logging: Show code responsible for abort (Nico Schottelius)
* Improved logging: Consistently prefix with current object or core (Nico Schottelius)
* Bugfix: Type __debconf_set_selections used wrong contens for selection (Nico Schottelius)
* Bugfix: Don't fail, if cache directory is not existing (Nico Schottelius)
* Bugfix: __user and __group exited non-zero if no change was necessary (Nico Schottelius)
* New Explorer: hardware_type (Nico Schottelius)
* New Type: __package_pkg_openbsd (Andi Brönnimann)
* New Type: __autofs_map (Steven Armstrong)
* New Type: __autofs_master (Steven Armstrong)
1.6.0: 2011-04-06
* New Type: __package_yum
* New type: __debconf_set_selections
* New explorer: os_version
* Bugfix: Type __group failed in case of __group NAME syntax
* New Type: __package_yum (Nico Schottelius)
* New type: __debconf_set_selections (Nico Schottelius)
* New explorer: os_version (Nico Schottelius)
* Bugfix: Type __group failed in case of __group NAME syntax (Nico Schottelius)
* Bugfix: __package* types: consistently name --state removed instead of
uninstalled or deinstalled
* Type __package: Added Fedora support
* Type __package_apt: Removed --preseed support
* Explorer os gained Fedora support
* Simplified types __user and __group
* New helper binary: cdist-mass-deploy
uninstalled or deinstalled (Nico Schottelius)
* Type __package: Added Fedora support (Nico Schottelius)
* Type __package_apt: Removed --preseed support (Nico Schottelius)
* Explorer os gained Fedora support (Nico Schottelius)
* Simplified types __user and __group (Nico Schottelius)
* New helper binary: cdist-mass-deploy (Nico Schottelius)
1.5.0: 2011-04-01
* Add basic cache functionality
* New type: __process
* Add basic cache functionality (Nico Schottelius)
* New type: __process (Nico Schottelius)
* Restructured execution: (Steven Armstrong)
Orientate processing on objects, resolve dependencies and
ensure correct execution order.
@ -486,77 +609,77 @@ Changelog
1.4.1: 2011-03-25
* New type: __key_value (Steven Armstrong)
* New type: __apt_ppa (Steven Armstrong)
* Documentation: Manpage generation cleanup
* Documentation: Manpage generation cleanup (Nico Schottelius)
* Documentation: Manpage fix for __apt_ppa
1.4.0: 2011-03-24
* Add --recursive to __directory
* Move cdist generated stuff to .cdist of an object
* Allow objects to be redefined
* Add --recursive to __directory (Nico Schottelius)
* Move cdist generated stuff to .cdist of an object (Nico Schottelius)
* Allow objects to be redefined (Nico Schottelius)
1.3.2: 2011-03-21
* Add --source to __motd
* Add --preseed to __package_apt
* Include HTML documentation of manpages and publish them
* Add --source to __motd (Nico Schottelius)
* Add --preseed to __package_apt (Nico Schottelius)
* Include HTML documentation of manpages and publish them (Nico Schottelius)
1.3.1: 2011-03-21
* Document: cdist-type-build-emulation
* Document: cdist-type-emulator
* Document: cdist-remote-explorer-run
* Fix dependencies in cdist-code-run
* Fix dependencies in cdist-manifest-run-all
* Add --source to __issue and fix os check
* Document: cdist-type-build-emulation (Nico Schottelius)
* Document: cdist-type-emulator (Nico Schottelius)
* Document: cdist-remote-explorer-run (Nico Schottelius)
* Fix dependencies in cdist-code-run (Nico Schottelius)
* Fix dependencies in cdist-manifest-run-all (Nico Schottelius)
* Add --source to __issue and fix os check (Nico Schottelius)
1.3.0: 2011-03-20
* Add support for local and remote code generation and execution
* Bugfix: Remove obsolete $@ call in cdist-remote-explorer-run
* Bugfix: Correct manpage for __removeline (broke manpage generation)
* Add support for local and remote code generation and execution (Nico Schottelius)
* Bugfix: Remove obsolete $@ call in cdist-remote-explorer-run (Nico Schottelius)
* Bugfix: Correct manpage for __removeline (broke manpage generation) (Nico Schottelius)
1.2.0: 2011-03-19
* Added dependencies (see cdist-type(7))
* Added dependencies (see cdist-type(7)) (Nico Schottelius)
* New type: __removeline (Daniel Roth)
* New type: __group (Steven Armstrong)
* New type: __user (Steven Armstrong)
* Documentation: cdist-run-remote
* Documentation: cdist-code-run-all
* Documentation: cdist-object-gencode
* Documentation: cdist-explorer-run-global
* Documentation: cdist-manifest-run-init
* Documentation: cdist-manifest-run-all
* Documentation: cdist-object-gencode-all
* Documentation: cdist-manifest-run
* Documentation: cdist-run-remote (Nico Schottelius)
* Documentation: cdist-code-run-all (Nico Schottelius)
* Documentation: cdist-object-gencode (Nico Schottelius)
* Documentation: cdist-explorer-run-global (Nico Schottelius)
* Documentation: cdist-manifest-run-init (Nico Schottelius)
* Documentation: cdist-manifest-run-all (Nico Schottelius)
* Documentation: cdist-object-gencode-all (Nico Schottelius)
* Documentation: cdist-manifest-run (Nico Schottelius)
1.1.0: 2011-03-16
* Replace type __file with __file, __directory, __link
* Documentation: cdist-env
* Documentation: cdist-config
* Documentation: cdist-dir
* Documentation: cdist-quickstart
* Replace type __file with __file, __directory, __link (Nico Schottelius)
* Documentation: cdist-env (Nico Schottelius)
* Documentation: cdist-config (Nico Schottelius)
* Documentation: cdist-dir (Nico Schottelius)
* Documentation: cdist-quickstart (Nico Schottelius)
1.0.4: 2011-03-15
* New type: __motd
* New type: __motd (Nico Schottelius)
* New type: __addifnosuchline (Daniel Roth)
* New type: __user
* Document type: __issue
* Document type: __package
* Document type: __package_pacman
* Document type: __package_apt
* New parameter for __file: --owner and --group
* New type: __user (Nico Schottelius)
* Document type: __issue (Nico Schottelius)
* Document type: __package (Nico Schottelius)
* Document type: __package_pacman (Nico Schottelius)
* Document type: __package_apt (Nico Schottelius)
* New parameter for __file: --owner and --group (Nico Schottelius)
1.0.3: 2011-03-11
* Update regexp used for sane characters
* Allow types without parameters
* Allow type to be singleton
* Type __file learned --type symlink
* Update regexp used for sane characters (Nico Schottelius)
* Allow types without parameters (Nico Schottelius)
* Allow type to be singleton (Nico Schottelius)
* Type __file learned --type symlink (Nico Schottelius)
1.0.2: 2011-03-09
* Add manpages: cdist-type, cdist-type__file, cdist-reference, cdist-explorer
* Make doc/man/ usable as MANPATH entry
* Add manpages: cdist-type, cdist-type__file, cdist-reference, cdist-explorer (Nico Schottelius)
* Make doc/man/ usable as MANPATH entry (Nico Schottelius)
1.0.1: 2011-03-08
* Added cdist-type-template including manpage
* Fix manpage building
* Add new manpages: cdist-stages, cdist-bin-transfer
* Added cdist-type-template including manpage (Nico Schottelius)
* Fix manpage building (Nico Schottelius)
* Add new manpages: cdist-stages, cdist-bin-transfer (Nico Schottelius)
1.0.0: 2011-03-07
* Initial release
* Initial release (Nico Schottelius)

14
docs/dev/logs/2014-05-06.object-marker Normal file
View file

@ -0,0 +1,14 @@
Change object marker from .cdist to .cdist-TEMPNAME to allow using
object ids that contain / are .cdist.
Changes required:
cdist/emulator.py:
needs to know suffix/name
tests:
allow object id named /.cdist
tests:
many
cdist/config.py:
have suffix

18
docs/dev/logs/2014-09-10.preos-keys Normal file
View file

@ -0,0 +1,18 @@
cdist preos keyramfs --keyfile --keyfile
[17:51] freiheit:vcs% mkdir preos-keys
[17:51] freiheit:vcs% mkdir -p preos-keys/root/.ssh
[17:56] freiheit:vcs%
chown root:root -R preos-keys/
chmod 0600 preos-keys/root/.ssh/authorized_keys
chmod 0700 preos-keys/root/
chmod 0700 preos-keys/root/.ssh/
[18:20:17] freiheit:/home/users/nico/.ungleich/ungleich/vcs/preos-keys# find . | cpio -H newc -o | gzip -9 > ../initramfs.cpio.gz
4 blocks
[18:21:08] freiheit:/home/users/nico/.ungleich/ungleich/vcs/preos-keys#

104
docs/dev/logs/2014-11-11.discussion Normal file
View file

@ -0,0 +1,104 @@
- logging/cache destination
local:
~/.cdist/log/by-host/$__target/host/config/YYYY/MM/DD/hhmmss/
~/.cdist/log/by-session/YYYY/MM/DD/hhmmss/$__target_host/
config/
install/
export/
remote:
/var/lib/cdist/YYYY-MM-DD-hhmmss-$sourcehost.$pid
rm old directories on remote side
- support for tags
- for partial configuration
- supports also install
- on object definition, define
- a) don't care (i.e. no tags)
- b) require tag (only if this tag is setup)
- c) require not tag (only if this tag is *not* setup)
- d) what if both given (conflicting)
- names for parameters:
- cdist config / cdist type
--if-tag / --not-if-tag / --require-tag
--not-if-tag
- logging
- command line
- stdin of cdist
- stdout/stderr/stdin of types
- new: stdout/stderr
- initial manifest
- if coming from stdin
- logging configurable
- to be discussed
- sudo remote
- cp to tmp & mv
- umask issue?
- install
- via tagged types
-
- export
- one /export script per type
- exports of type running after object's code is done
- global export should also exist after everything
- PR & merge
- change DONE status to CODE_DONE
- introduce EXPORT_DONE
- preos
- merge with debian support only
- we are open to support --os-type later
- stackable remotes
- change API for remote_exec and remote_copy
- new minor version
- PR & merge
- locking
- optional
- remote lock
- based on $(ls /var/lib/cdist/) > 0
- ideas for parallelisation
- run explorer in parallel
- type
- object
- objects without dependencies can be run in parallel
- connection test
- just implement
- multi user environment
- not really needed [at the moment]
- can be implemented by
- git branches
- setting the output dir
- python2 support with __future__
- steven votes against it
- nico does not care too much to object
- pull based
- sshd / stdin + stdout
- use Use ProxyCommand with stdin/stdout
- http://www.nico.schottelius.org/blog/openssh-6.2-add-callback-functionality-using-dynamic-remote-port-forwarding/
- cdist grant-pull-access <targethost>
- generate user
- ssh pubkeypair
- call wraper script on targethost
- it is shell!
- ssh cdistuser@controlhost
- config replay/redo/undo
- not now
- have a new discussion about handling uris

29
docs/dev/logs/2015-02-22.allow_dot_cdist Normal file
View file

@ -0,0 +1,29 @@
- locate code that references .cdist
- cdist_object.py
- need to change code that handles objects?
- setup object marker
exec/local.py
- cdist/emulator.py
- need to know the marker name
- shell.py
- test/manifest/__init__.py
- core/code.py:
- core/manifest.py:
- core/manifest.py:
- list_object_names() needs to know the marker -- used BY:
- list_objects
- cdist/test/cdist_object/__init__.py
- cdist/config.py
- cdist/test/cdist_object/__init__.py
- list_object_names
- needs to have object_marker
- or modify object code to load name
- setup a per-run random name
- local.py
- use the per-run random name
- create test
def __init__(self, cdist_type, base_path, object_marker=".cdist", object_id=''):

29
docs/dev/logs/dependency-tree-with-fruits Normal file
View file

@ -0,0 +1,29 @@
1. Manifests need type explorers to be run before
Only this way the manifest can use the values
2. Type explorers can depend on the (successful) execution of other objects
A type explorer may lookup values (ownership, size, processes, etc.)
that are depending on the code of other objects.
3. The 'require="a" b' dependency specifies only that execution of b needs to wait until a is finished
Other requirements given at another position may not be
executed before b, as cdist interprets require="a" as
"a is everything that is needed to realise b"
4. The 'require' state is thus *not* suitable to trigger reloads
A type b, which uses the require="" statement to wait for all
require="" dependencies, may be executed in an incomplete
status.
5. Depending on multiple dependencies defined at different locations requires all objects to be present
Because otherwise the dependent object cannot be sure that the
list of objects it waits for is complete.
6. If a statement requires all objects to be present, all manifests must have run already.
If all manifests have run already, also all type explorers have run already (#1).
If all type explorers have run already, some objects may have been finished completly already (#2).
7. Because of #4 and #6, we need to introduce another dependency that allows reloading after
8. Because the object could be finished already due to a 'require' dependency, we need another script
Maybe "gen-post-run-local", "gen-post-run-remote"

8
docs/dev/todo/TAKEME
View file

@ -5,10 +5,6 @@ Feel free to pick one!
CORE
----
- support default parameter
- document and add paremeters for remote-copy and remote-exec!
- remove hack, make a feature of it
- remove var=foo calls on remote side. Use -o SendEnv (yeah, see ssh_config(5))
TESTS
@ -23,9 +19,6 @@ TESTS
USER INTERFACE
--------------
- How to cleanly implement "restart service if config file changed"
-> document
- Cache
- add example how to use
- export variable $__cache
@ -45,7 +38,6 @@ TYPES
- Add testing framework (proposed by Evax Software)
- __user
add option to include --create-home
- Merge __addifnosuchline and __removeline into __line + --state present|absent
- __cron: Support --file to be used instead of user cron (probably direct support
of /etc/cron.d)

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."

129
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
@ -51,7 +49,7 @@ The following global explorers are available:
eof
(
cd ../../cdist/conf/explorer
for explorer in *; do
for explorer in $(ls * | LC_ALL=C sort); do
echo "- $explorer"
done
)
@ -60,101 +58,101 @@ 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/files/::
confdir/files/
Cdist does not care about this directory besides providing access to it.
It is thought to be a general file storage area.
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 seperate configuration mappings, if you have a lot of code in the
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::
Parameters required by type, \n seperated list.
confdir/type/<name>/parameter/required
Parameters required by type, \n separated list.
confdir/type/<name>/parameter/optional::
Parameters optionally accepted by type, \n seperated list.
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::
Boolean parameters accepted by type, \n seperated list.
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
@ -163,14 +161,15 @@ The following types are available:
eof
for type in man7/cdist-type__*.text; do
for type in $(ls man7/cdist-type__*.rst | LC_ALL=C sort); 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
@ -181,14 +180,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 excuted (either remote or local)
stdin::
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.
@ -197,44 +196,44 @@ 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
__files::
__files
Directory that contains content from the "files" subdirectories
from the configuration directories.
Available for: initial manifest, type manifest, type gencode, 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::
File to read messages from
__messages_in
File to read messages from.
Available for: initial manifest, type manifest, type gencode
__messages_out::
File to write messages
__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
@ -242,24 +241,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
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)
- \`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, '',
[], mansubdir[-1])
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/*

127
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] [-f HOSTFILE] [-i MANIFEST] [-p] [-s] [host [host ...]]
cdist shell [-h] [-d] [-v] [-s SHELL]
DESCRIPTION
@ -26,18 +26,22 @@ cdist supports different subcommands as explained below.
GENERAL
-------
All commands except the following options:
All commands accept the following options:
.. option:: -d, --debug
-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,31 @@ Configure one or more hosts
--conf-dir argument have higher precedence over those set through the
environment variable.
-i MANIFEST, --initial-manifest MANIFEST::
.. option:: -f HOSTFILE, --file HOSTFILE
Read additional hosts to operate on from specified file
or from stdin if '-' (each host on separate line).
If no host or host file is specified then, by default,
read hosts from stdin.
.. option:: -i MANIFEST, --initial-manifest MANIFEST
Path to a cdist manifest or - to read from stdin
-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,74 +103,81 @@ 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
# Configure hosts read from file loadbalancers
% cdist config -f loadbalancers
# Show Version
% cdist --version
# Display banner
cdist banner
# 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 help
% cdist --help
# Show Version
% cdist --version
--------------------------------------------------------------------------------
# Enter a shell that has access to emulated types
% cdist shell
% __git
usage: __git --source SOURCE [--state STATE] [--branch BRANCH]
[--group GROUP] [--owner OWNER] [--mode MODE] object_id
ENVIRONMENT
-----------
TMPDIR, TEMP, TMP::
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
Use this command for remote execution (should behave like ssh)
CDIST_REMOTE_COPY
Use this command for remote copy (should behave like scp)
EXIT STATUS
-----------
The following exit values shall be returned:
0::
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 accross 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).

103
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
@ -25,7 +22,7 @@ location.
For starters, having cdist (which includes the configuration database) on
your notebook should be fine.
Additionally an external copy of the git repository the configuration
relies in is recommended, for use as backup as well to allow easy collaboration
relies on is recommended, for use as backup as well as to allow easy collaboration
with others.
For more sophisticated setups developing cdist configurations with multiple
@ -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

55
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,36 +38,34 @@ 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
# Except 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
-------
Copyright \(C) 2010-2012 Nico Schottelius. Free use of this software is
Copyright \(C) 2010-2014 Nico Schottelius. Free use of this software is
granted under the terms of the GNU General Public License version 3 (GPLv3).

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)

271
docs/man/man7/cdist-manifest.rst Normal file
View file

@ -0,0 +1,271 @@
cdist-manifest(7)
=================
(Re-)Use types
Nico Schottelius <nico-cdist--@--schottelius.org>
DESCRIPTION
-----------
Manifests are used to define which objects to create.
Objects are instances of **types**, like in object oriented programming languages.
An object is represented by the combination of
**type + slash + object name**: **\__file/etc/cdist-configured** is an
object of the type **__file** with the name **etc/cdist-configured**.
All available types can be found in the **cdist/conf/type/** directory,
use **ls cdist/conf/type** to get the list of available types. If you have
setup the MANPATH correctly, you can use **man cdist-reference** to access
the reference with pointers to the manpages.
Types in manifests are used like normal command line tools. Let's have a look
at an example::
# Create object of type __package with the parameter state = absent
__package apache2 --state absent
# Same with the __directory type
__directory /tmp/cdist --state present
These two lines create objects, which will later be used to realise the
configuration on the target host.
Manifests are executed locally as a shell script using **/bin/sh -e**.
The resulting objects are stored in an internal database.
The same object can be redefined in multiple different manifests as long as
the parameters are exactly the same.
In general, manifests are used to define which types are used depending
on given conditions.
INITIAL AND TYPE MANIFESTS
--------------------------
Cdist knows about two types of manifests: The initial manifest and type
manifests. The initial manifest is used to define, which configurations
to apply to which hosts. The type manifests are used to create objects
from types. More about manifests in types can be found in cdist-type(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 expects the initial manifest at **cdist/conf/manifest/init**.
Within this initial manifest you define, which objects should be
created on which host. To distinguish between hosts, you can use the
environment variable **__target_host**. Let's have a look at a simple
example::
__cdistmarker
case "$__target_host" in
localhost)
__directory /home/services/kvm-vm --parents yes
;;
esac
This manifest says: Independent of the host, always use the type
**__cdistmarker**, which creates the file **/etc/cdist-configured**,
with the timestamp as content.
The directory **/home/services/kvm-vm**, including all parent directories,
is only created on the host **localhost**.
As you can see, there is no magic involved, the manifest is simple shell code that
utilises cdist types. Every available type can be executed like a normal
command.
SPLITTING UP THE INITIAL MANIFEST
---------------------------------
If you want to split up your initial manifest, you can create other shell
scripts in **cdist/conf/manifest/** and include them in **cdist/conf/manifest/init**.
Cdist provides the environment variable **__manifest** to reference
the directory containing the initial manifest (see cdist-reference(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 separated.
::
1 # No dependency
2 __file /etc/cdist-configured
3
4 # Require above object
5 require="__file/etc/cdist-configured" __link /tmp/cdist-testfile \
6 --source /etc/cdist-configured --type symbolic
7
8 # Require two objects
9 require="__file/etc/cdist-configured __link/tmp/cdist-testfile" \
10 __file /tmp/cdist-another-testfile
Above the "require" variable is only set for the command that is
immediately following it. Dependencies should always be declared that way.
On line 4 you can see that the instantion of a type "\__link" object needs
the object "__file/etc/cdist-configured" to be present, before it can proceed.
This also means that the "\__link" command must make sure, that either
"\__file/etc/cdist-configured" allready is present, or, if it's not, it needs
to be created. The task of cdist is to make sure, that the dependency will be
resolved appropriately and thus "\__file/etc/cdist-configured" be created
if necessary before "__link" proceeds (or to abort execution with an error).
If you really need to make all types depend on a common dependency, you can
export the "require" variable as well. But then, if you need to add extra
dependencies to a specific type, you have to make sure that you append these
to the globally already defined one.
::
# First of all, update the package index
__package_update_index
# Upgrade all the installed packages afterwards
require="__package_update_index" __package_upgrade_all
# Create a common dependency for all the next types so that they get to
# be executed only after the package upgrade has finished
export require="__package_upgrade_all"
# Ensure that lighttpd is installed after we have upgraded all the packages
__package lighttpd --state present
# Ensure that munin is installed after lighttpd is present and after all
# the packages are upgraded
require="$require __package/lighttpd" __package munin --state present
All objects that are created in a type manifest are automatically required
from the type that is calling them. This is called "autorequirement" in
cdist jargon.
You can find an more in depth description of the flow execution of manifests
in cdist-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
in the manifest by setting up the variable CDIST_ORDER_DEPENDENCY.
When cdist sees that this variable is setup, the current created object
automatically depends on the previously created object.
It essentially helps you to build up blocks of code that build upon each other
(like first creating the directory xyz than the file below the directory).
OVERRIDES
---------
In some special cases, you would like to create an already defined object
with different parameters. In normal situations this leads to an error in cdist.
If you wish, you can setup the environment variable CDIST_OVERRIDE
(any value or even empty is ok) to tell cdist, that this object override is
wanted and should be accepted.
ATTENTION: Only use this feature if you are 100% sure in which order
cdist encounters the affected objects, otherwise this results
in an undefined situation.
If CDIST_OVERRIDE and CDIST_ORDER_DEPENDENCY are set for an object,
CDIST_ORDER_DEPENDENCY will be ignored, because adding a dependency in case of
overrides would result in circular dependencies, which is an error.
EXAMPLES
--------
The initial manifest may for instance contain the following code:
.. code-block:: sh
# Always create this file, so other sysadmins know cdist is used.
__file /etc/cdist-configured
case "$__target_host" in
my.server.name)
__directory /root/bin/
__file /etc/issue.net --source "$__manifest/issue.net
;;
esac
The manifest of the type "nologin" may look like this:
.. code-block:: sh
__file /etc/nologin --source "$__type/files/default.nologin"
This example makes use of dependencies:
.. code-block:: sh
# Ensure that lighttpd is installed
__package lighttpd --state present
# Ensure that munin makes use of lighttpd instead of the default webserver
# package as decided by the package manager
require="__package/lighttpd" __package munin --state present
How to override objects:
.. code-block:: sh
# for example in the inital manifest
# create user account foobar with some hash for password
__user foobar --password 'some_fancy_hash' --home /home/foobarexample
# ... many statements and includes in the manifest later ...
# somewhere in a conditionally sourced manifest
# (e.g. for example only sourced if a special application is on the target host)
# this leads to an error ...
__user foobar --password 'some_other_hash'
# this tells cdist, that you know that this is an override and should be accepted
CDIST_OVERRIDE=yes __user foobar --password 'some_other_hash'
# it's only an override, means the parameter --home is not touched
# and stays at the original value of /home/foobarexample
Dependencies defined by execution order work as following:
.. code-block:: sh
# Tells cdist to execute all types in the order in which they are created ...
export CDIST_ORDER_DEPENDENCY=on
__sample_type 1
require="__some_type_somewhere/id" __sample_type 2
__example_type 23
# Now this types are executed in the creation order until the variable is unset
unset CDIST_ORDER_DEPENDENCY
# all now following types cdist makes the order ..
__not_in_order_type 42
# how it works :
# this lines above are translated to:
__sample_type 1
require="__some_type_somewhere/id __sample_type/1" __sample_type 2
require="__sample_type/2" __example_type 23
__not_in_order_type 42
SEE ALSO
--------
- `cdist-tutorial(7) <cdist-tutorial.html>`_
- `cdist-type(7) <cdist-type.html>`_
COPYING
-------
Copyright \(C) 2010-2014 Nico Schottelius. Free use of this software is
granted under the terms of the GNU General Public License version 3 (GPLv3).

251
docs/man/man7/cdist-manifest.text
View file

@ -1,251 +0,0 @@
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 oriented programming languages.
An object is represented by the combination of
**type + slash + object name**: **__file/etc/cdist-configured** is an
object of the type ***__file*** with the name ***etc/cdist-configured***.
All available types can be found in the **cdist/conf/type/** directory,
use **ls cdist/conf/type** to get the list of available types. If you have
setup the MANPATH correctly, you can use **man cdist-reference** to access
the reference with pointers to the manpages.
Types in manifests are used like normal command line tools. Let's have a look
at an example:
--------------------------------------------------------------------------------
# Create object of type __package with the parameter state = absent
__package apache2 --state absent
# Same with the __directory type
__directory /tmp/cdist --state present
--------------------------------------------------------------------------------
These two lines create objects, which will later be used to realise the
configuration on the target host.
Manifests are executed locally as a shell script using **/bin/sh -e**.
The resulting objects are stored in an internal database.
The same object can be redefined in multiple different manifests as long as
the parameters are exactly the same.
In general, manifests are used to define which types are used depending
on given conditions.
INITIAL AND TYPE MANIFESTS
--------------------------
Cdist knows about two types of manifests: The initial manifest and type
manifests. The initial manifest is used to define, which configurations
to apply to which hosts. The type manifests are used to create objects
from types. More about manifests in types can be found in cdist-type(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 expects the initial manifest at **cdist/conf/manifest/init**.
Within this initial manifest you define, which objects should be
created on which host. To distinguish between hosts, you can use the
environment variable **__target_host**. Let's have a look at a simple
example:
--------------------------------------------------------------------------------
__cdistmarker
case "$__target_host" in
localhost)
__directory /home/services/kvm-vm --parents yes
;;
esac
--------------------------------------------------------------------------------
This manifest says: Independent of the host, always use the type
***__cdistmarker***, which creates the file **/etc/cdist-configured**,
with the timestamp as content.
The directory ***/home/services/kvm-vm***, including all parent directories,
is only created on the host ***localhost***.
As you can see, there is no magic involved, the manifest is simple shell code that
utilises cdist types. Every available type can be executed like a normal
command.
SPLITTING UP THE INITIAL MANIFEST
---------------------------------
If you want to split up your initial manifest, you can create other shell
scripts in **cdist/conf/manifest/** and include them in **cdist/conf/manifest/init**.
Cdist provides the environment variable ***__manifest*** to reference 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 separated.
--------------------------------------------------------------------------------
# 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.
CREATE DEPENDENCIES FROM EXECUTION ORDER
-----------------------------------------
You can tell cdist to execute all types in the order in which they are created
in the manifest by setting up the variable CDIST_ORDER_DEPENDENCY.
When cdist sees that this variable is setup, the current created object
automatically depends on the previously created object.
It essentially helps you to build up blocks of code that build upon each other
(like first creating the directory xyz than the file below the directory).
THIS IS A BETA FEATURE AND MAY BE REMOVED OR CHANGED AT ANY TIME.
OVERRIDES
---------
In some special cases, you would like to create an already defined object
with different parameters. In normal situations this leads to an error in cdist.
If you whish, you can setup the environment variable CDIST_OVERRIDE
(any value or even empty is ok) to tell cdist, that this object override is
wanted and should be accepted.
ATTENTION: Only use this feature if you are 100% sure in which order
cdist encounter the affected objects, otherwhise this results
into an undefined situation.
If CDIST_OVERRIDE and CDIST_ORDER_DEPENDENCY is set for an object,
CDIST_ORDER_DEPENDENCY will be ignored, because adding a dependency in case of
overrides would result in circular dependencies, which is an error.
THIS IS A BETA FEATURE AND MAY BE REMOVED OR CHANGED AT ANY TIME.
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
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"
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
How to override objects:
--------------------------------------------------------------------------------
# for example in the inital manifest
# reate user account foobar with some hash for password
__user foobar --password 'some_fancy_hash' --home /home/foobarexample
# ... many statements and includes in the manifest later ...
# somewhere in a conditionaly sourced manifest
# (e.g. for example only sourced if a special application is on the target host)
# this leads to an error ...
__user foobar --password 'some_other_hash'
# this tells cdist, that you know that this is an override and should be accepted
CDIST_OVERRIDE=yes __user foobar --password 'some_other_hash'
# its only an override, means the parameter --home is not touched
# and stay at the original value of /home/foobarexample
--------------------------------------------------------------------------------
Dependencies defined by execution order work as following:
--------------------------------------------------------------------------------
# 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)
COPYING
-------
Copyright \(C) 2010-2014 Nico Schottelius. Free use of this software is
granted under the terms of the GNU General Public License version 3 (GPLv3).

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).

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

@ -1,72 +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
--------------------------------------------------------------------------------
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

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

232
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
@ -25,15 +24,15 @@ to use.
HOW TO USE A TYPE
-----------------
You can use types from the initial manifest or the type manifest like a
normal command:
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,82 +84,85 @@ 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
----------------
The parameters given to a type can be accessed and used in all type scripts
(e.g manifest, gencode-*, explorer/*). Note that boolean parameters are
(e.g manifest, gencode, explorer). Note that boolean parameters are
represented by file existence. File exists -> True,
file does not exist -> False
Example: (e.g. in cdist/conf/type/__nginx_vhost/manifest)
--------------------------------------------------------------------------------
# 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
@ -281,7 +285,7 @@ on the target, there must be another type that provides this tool and the first
type should create an object of the specific type.
If your type wants to save temporary data, that may be used by other types
later on (for instance __file), you can save them in the subdirectory
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.
@ -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

BIN
docs/speeches/2014-05-08_linuxtag_berlin.odp Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-05-08_linuxtag_berlin.pdf Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-05-19_cdi.st-zkb_linux_erfa.odp Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-05-19_cdi.st-zkb_linux_erfa.pdf Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-06-10_openclouddays.odp Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-06-10_openclouddays_teaser.odp Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-06-10_openclouddays_teaser.pdf Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-06-19_ucms14_cdi.st.odp Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-06-19_ucms14_cdist_cinv_bof.odp Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-11-07_sfs_linux_erfa_cdist4.odp Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-11-07_sfs_linux_erfa_cdist4.pdf Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-11-07_sfs_linux_erfa_cdist_web_prototype.odp Normal file
View file

Binary file not shown.

BIN
docs/speeches/2014-11-07_sfs_linux_erfa_cdist_web_prototype.pdf Normal file
View file

Binary file not shown.

2
docs/web/cdist/install.mdwn
View file

@ -137,7 +137,7 @@ immediately.
To install cdist, execute the following commands:
git clone git://git.schottelius.org/cdist
git clone https://github.com/telmich/cdist.git
cd cdist
export PATH=$PATH:$(pwd -P)/bin