Changes due to new website

This commit is contained in:
Darko Poljak 2019-04-23 22:39:41 +02:00 committed by Darko Poljak
parent 0ab43e2405
commit 249ac917d3
24 changed files with 62 additions and 764 deletions

1
.gitignore vendored
View file

@ -12,6 +12,7 @@ Session.vim
# Temporary
.netrwhist
*~
*.tmp
# Auto-generated tag files
tags
# Persistent undo

View file

@ -24,13 +24,6 @@ DOCS_SRC_DIR=docs/src
SPEECHDIR=docs/speeches
TYPEDIR=cdist/conf/type
WEBSRCDIR=docs/web
WEBDIR=$$HOME/vcs/www.nico.schottelius.org
WEBBLOG=$(WEBDIR)/blog
WEBBASE=$(WEBDIR)/software/cdist
WEBPAGE=$(WEBBASE).mdwn
CHANGELOG_VERSION=$(shell $(helper) changelog-version)
CHANGELOG_FILE=docs/changelog
@ -47,7 +40,6 @@ SHELLCHECK_SKIP=grep -v ': __.*is referenced but not assigned.*\[SC2154\]'
################################################################################
# Manpages
#
MAN1DSTDIR=$(DOCS_SRC_DIR)/man1
MAN7DSTDIR=$(DOCS_SRC_DIR)/man7
# Manpages #1: Types
@ -81,24 +73,6 @@ docs: man html
docs-clean:
$(SPHINXC)
# Manpages #5: release part
MANWEBDIR=$(WEBBASE)/man/$(CHANGELOG_VERSION)
HTMLBUILDDIR=docs/dist/html
docs-dist: html
rm -rf "${MANWEBDIR}"
mkdir -p "${MANWEBDIR}"
# mkdir -p "${MANWEBDIR}/man1" "${MANWEBDIR}/man7"
# cp ${MAN1DSTDIR}/*.html ${MAN1DSTDIR}/*.css ${MANWEBDIR}/man1
# cp ${MAN7DSTDIR}/*.html ${MAN7DSTDIR}/*.css ${MANWEBDIR}/man7
cp -R ${HTMLBUILDDIR}/* ${MANWEBDIR}
cd ${MANWEBDIR} && git add . && git commit -m "cdist manpages update: $(CHANGELOG_VERSION)" || true
man-latest-link: web-pub
# Fix ikiwiki, which does not like symlinks for pseudo security
ssh staticweb.ungleich.ch \
"cd /home/services/www/nico/nico.schottelius.org/www/software/cdist/man/ && rm -f latest && ln -sf "$(CHANGELOG_VERSION)" latest"
# Manpages: .cdist Types
DOT_CDIST_PATH=${HOME}/.cdist
DOTMAN7DSTDIR=$(MAN7DSTDIR)
@ -111,7 +85,6 @@ DOTMANTYPES=$(subst /man.rst,.rst,$(DOTMANTYPEPREFIX))
$(DOTMAN7DSTDIR)/cdist-type%.rst: $(DOTTYPEDIR)/%/man.rst
ln -sf "$^" $@
# Manpages #3: generic part
dotman: $(DOTMANTYPES)
$(SPHINXM)
@ -120,7 +93,6 @@ dotman: $(DOTMANTYPES)
#
SPEECHESOURCES=$(SPEECHDIR)/*.tex
SPEECHES=$(SPEECHESOURCES:.tex=.pdf)
SPEECHESWEBDIR=$(WEBBASE)/speeches
# Create speeches and ensure Toc is up-to-date
$(SPEECHDIR)/%.pdf: $(SPEECHDIR)/%.tex
@ -130,36 +102,6 @@ $(SPEECHDIR)/%.pdf: $(SPEECHDIR)/%.tex
speeches: $(SPEECHES)
speeches-dist: speeches
rm -rf "${SPEECHESWEBDIR}"
mkdir -p "${SPEECHESWEBDIR}"
cp ${SPEECHES} "${SPEECHESWEBDIR}"
cd ${SPEECHESWEBDIR} && git add . && git commit -m "cdist speeches updated" || true
################################################################################
# Website
#
BLOGFILE=$(WEBBLOG)/cdist-$(CHANGELOG_VERSION)-released.mdwn
$(BLOGFILE): $(CHANGELOG_FILE)
$(helper) blog $(CHANGELOG_VERSION) $(BLOGFILE)
web-blog: $(BLOGFILE)
web-doc:
# Go to top level, because of cdist.mdwn
rsync -av "$(WEBSRCDIR)/" "${WEBBASE}/.."
cd "${WEBBASE}/.." && git add cdist* && git commit -m "cdist doc update" cdist* || true
web-dist: web-blog web-doc
web-pub: web-dist docs-dist speeches-dist
cd "${WEBDIR}" && make pub
web-release-all: man-latest-link
web-release-all-no-latest: web-pub
################################################################################
# Release: Mailinglist
#
@ -239,6 +181,9 @@ clean:
rm -f cdist-*.tar.gz
rm -f cdist-*.tar.gz.asc
# Temp files
rm -f *.tmp
distclean: clean
rm -f cdist/version.py

3
README
View file

@ -3,4 +3,5 @@ cdist
cdist is a usable configuration management system.
For the web documentation have a look at docs/web/.
For the web documentation have a look at https://www.cdi.st/
or at docs/src for reStructuredText manual.

View file

@ -76,33 +76,6 @@ case "$option" in
"$0" test
;;
blog)
version=$1; shift
blogfile=$1; shift
dir=${blogfile%/*}
file=${blogfile##*/}
cat << eof > "$blogfile"
[[!meta title="Cdist $version released"]]
Here's a short overview about the changes found in version ${version}:
eof
$0 changelog-changes "$version" >> "$blogfile"
cat << eof >> "$blogfile"
For more information visit the [[cdist homepage|software/cdist]].
[[!tag cdist config unix]]
eof
cd "$dir"
git add "$file"
# Allow git commit to fail if there are no changes
git commit -m "cdist blog update: $version" "$blogfile" || true
;;
ml-release)
if [ $# -ne 1 ]; then
echo "$0 ml-release version" >&2
@ -324,13 +297,6 @@ eof
# Publish git changes
make pub
# publish man, speeches, website
if [ "$masterbranch" = yes ]; then
make web-release-all
else
make web-release-all-no-latest
fi
# Ensure that pypi release has the right version
"$0" version
@ -351,6 +317,7 @@ eof
cat << eof
Manual steps post release:
- cdist-web
- linkedin
- hackernews
- reddit

View file

@ -31,30 +31,13 @@ basedir=${0%/*}/../
# .freebsd - run as freebsd
basename=${0##*/}
run_as=${basename#*.}
case "$run_as" in
freebsd)
to_a=cdist-configuration-management
to_d=googlegroups.com
from_a=darko.poljak
from_d=gmail.com
ml_name="Darko Poljak"
ml_sig_name="Darko"
# vars for make
WEBDIR=../vcs/www.nico.schottelius.org
;;
*)
to_a=cdist
to_d=l.schottelius.org
from_a=nico-cdist
from_d=schottelius.org
ml_name="Nico -telmich- Schottelius"
ml_sig_name="Nico"
# vars for make
WEBDIR=$$HOME/vcs/www.nico.schottelius.org
;;
esac
to_a=cdist-configuration-management
to_d=googlegroups.com
from_a=darko.poljak
from_d=gmail.com
ml_name="Darko Poljak"
ml_sig_name="Darko"
# Change to checkout directory
cd "$basedir"
@ -66,7 +49,6 @@ option=$1; shift
case "$option" in
print-make-vars)
printf "helper: ${helper}\n"
printf "WEBDIR: ${WEBDIR}\n"
;;
print-runas)
printf "run_as: $run_as\n"
@ -117,33 +99,6 @@ case "$option" in
"$0" test
;;
blog)
version=$1; shift
blogfile=$1; shift
dir=${blogfile%/*}
file=${blogfile##*/}
cat << eof > "$blogfile"
[[!meta title="Cdist $version released"]]
Here's a short overview about the changes found in version ${version}:
eof
$0 changelog-changes "$version" >> "$blogfile"
cat << eof >> "$blogfile"
For more information visit the [[cdist homepage|software/cdist]].
[[!tag cdist config unix]]
eof
cd "$dir"
git add "$file"
# Allow git commit to fail if there are no changes
git commit -m "cdist blog update: $version" "$blogfile" || true
;;
ml-release)
if [ $# -ne 1 ]; then
echo "$0 ml-release version" >&2
@ -159,7 +114,7 @@ eof
cat << eof
From: ${ml_name} <$from>
To: cdist mailing list <$to>
Subject: cdist $version released
Subject: cdist $version has been released
Hello .*,
@ -177,7 +132,7 @@ ${ml_sig_name}
--
Automatisation at its best level. With cdist.
eof
) | /usr/sbin/sendmail -f "$from" "$to"
) > mailinglist.tmp
;;
release-git-tag)
@ -337,11 +292,11 @@ eof
# Generate documentation (man and html)
# First, clean old generated docs
make helper=${helper} WEBDIR=${WEBDIR} docs-clean
make helper=${helper} WEBDIR=${WEBDIR} docs
make helper=${helper} docs-clean
make helper=${helper} docs
# Generate speeches (indirect check if they build)
make helper=${helper} WEBDIR=${WEBDIR} speeches
make helper=${helper} speeches
#############################################################
# Everything green, let's do the release
@ -364,7 +319,7 @@ eof
git push -u origin "${target_branch}"
;;
*)
make helper=${helper} WEBDIR=${WEBDIR} pub
make helper=${helper} pub
;;
esac
@ -372,23 +327,7 @@ eof
"$0" version
# Create and publish package for pypi
make helper=${helper} WEBDIR=${WEBDIR} pypi-release
# publish man, speeches, website
if [ "$masterbranch" = yes ]; then
make helper=${helper} WEBDIR=${WEBDIR} web-release-all
else
make helper=${helper} WEBDIR=${WEBDIR} web-release-all-no-latest
fi
case "$run_as" in
freebsd)
;;
*)
# Archlinux release is based on pypi
make archlinux-release
;;
esac
make helper=${helper} pypi-release
# sign git tag
printf "Enter upstream repository authentication token: "
@ -396,7 +335,15 @@ eof
"$0" sign-git-release "${target_version}" "${token}"
# Announce change on ML
make helper=${helper} WEBDIR=${WEBDIR} ml-release
make helper=${helper} ml-release
cat << eof
Manual steps post release:
- cdist-web
- twitter
eof
;;
test)
@ -441,7 +388,7 @@ eof
;;
shellcheck)
make helper=${helper} WEBDIR=${WEBDIR} shellcheck
make helper=${helper} shellcheck
printf "\\nPlease review shellcheck report.\\n"
while true
do

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

View file

Before

Width:  |  Height:  |  Size: 1.5 KiB

After

Width:  |  Height:  |  Size: 1.5 KiB

View file

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

View file

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

View file

@ -1,11 +1,9 @@
Support
-------
IRC
~~~
You can join the development ***IRC channel***
`#cstar on irc.freenode.net <irc://irc.freenode.org/#cstar>`_.
Chat
~~~~
Chat with us: `ungleich chat <https://chat.ungleich.ch/ungleich/channels/cdist>`_.
Mailing list
~~~~~~~~~~~~
@ -25,4 +23,4 @@ Commercial support
~~~~~~~~~~~~~~~~~~
You can request commercial support for cdist from
`my company <http://www.ungleich.ch/>`_.
`ungleich <http://www.ungleich.ch/>`_.

View file

@ -1,5 +1,5 @@
How to update cdist
===================
How to upgrade cdist
====================
Update the git installation
---------------------------

View file

@ -56,7 +56,7 @@ master_doc = 'index'
# General information about the project.
project = 'cdist'
# copyright = '2016, Darko Poljak'
copyright = 'ungleich GmbH 2019'
# author = 'Darko Poljak'
# The version info for the project you're documenting, acts as replacement for
@ -138,7 +138,7 @@ html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
# html_logo = None
html_logo = '_static/cdist-logo.jpeg'
# 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)
@ -150,6 +150,7 @@ html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
# 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']
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

View file

@ -1,20 +1,23 @@
Welcome to cdist documentation
==============================
cdist - usable configuration management
=======================================
cdist is a usable configuration management system.
It adheres to the KISS principle and
is being used in small up to enterprise grade environments.
Contents:
.. toctree::
:maxdepth: 2
:maxdepth: 3
:glob:
:numbered:
:hidden:
cdist-intro
cdist-why
cdist-features
cdist-os
cdist-install
cdist-update
cdist-upgrade
cdist-support
cdist-features
cdist-quickstart
cdist-real-world
man1/cdist

View file

@ -1,21 +0,0 @@
[[!meta title="cdist - usable configuration management"]]
![cdist-logo](cdist-logo.png "cdist logo")
cdist is a usable configuration management system.
It adheres to the KISS principle and
is being used in small up to enterprise grade environments.
cdist is an alternative to other configuration management systems like
[bcfg2](http://bcfg2.org/),
[chef](https://www.chef.sh/),
[cfengine](https://cfengine.com/)
and [puppet](https://puppet.com/).
* [[Why should I use cdist?|why]]
* [[Documentation|documentation]]
* [[Supported Operating Systems|os]]
* [[Installation|install]]
* [[Update|update]]
* [[Support|support]]
[[!tag cdist unix]]

Binary file not shown.

Before

Width:  |  Height:  |  Size: 1.5 KiB

View file

@ -1,12 +0,0 @@
[[!meta title="Documentation"]]
You can browse the
[latest version of the documentation](/software/cdist/man/latest) or
have a look at [all versions](/software/cdist/man).
You can also view [speeches about cdist](/software/cdist/speeches).
Checking out beta? Find the docs here:
[beta documentation](/software/cdist/man/beta).
[[!tag cdist unix]]

View file

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

View file

@ -1,103 +0,0 @@
[[!meta title="How to install cdist"]]
[[!toc levels=3]]
## Requirements
### Source Host
This is the machine you use to configure the target hosts.
* /bin/sh: A posix like shell (for instance bash, dash, zsh)
* Python >= 3.2
* SSH client
* Asciidoc and xsltproc (for building the manpages)
### Target Hosts
* /bin/sh: A posix like shell (for instance bash, dash, zsh)
* SSH server
## Install cdist
You can install cdist either from git or as a python package.
### From git
Cloning cdist from git gives you the advantage of having
a version control in place for development of your own stuff
immediately.
To install cdist, execute the following commands:
git clone https://github.com/ungleich/cdist.git
cd cdist
export PATH=$PATH:$(pwd -P)/bin
From version 4.2.0 cdist tags and github releases are signed.
You can get GPG public key used for signing [here](/software/cdist/pgp-key-EFD2AE4EC36B6901.asc).
#### Available versions in git
* The active development takes place in the **master** branch
* The current stable version can be found in the **2.0** branch
* The upcoming stable version can be found in the **2.1** branch
Other branches may be available for features or bugfixes, but they
may vanish at any point. To select a specific branch use
# Generic code
git checkout -b <localbranchname> origin/<branchname>
So for instance if you want to use and stay with version 2.0, you can use
git checkout -b 2.0 origin/2.0
#### Git Mirrors
If the main site is down, you can acquire cdist from one of the following sites:
* git://github.com/telmich/cdist.git ([github](https://github.com/telmich/cdist))
* git://git.code.sf.net/p/cdist/code ([sourceforge](https://sourceforge.net/p/cdist/code))
#### Building and using documentation (man and html)
If you want to build and use the documentation, run:
make docs
Documentation comes in two formats, man pages and full HTML
documentation. Documentation is built into distribution's
docs/dist directory. man pages are in docs/dist/man and
HTML documentation in docs/dist/html.
If you want to use man pages, run:
export MANPATH=$MANPATH:$(pwd -P)/docs/dist/man
Or you can move manpages from docs/dist/man directory to some
other directory and add it to MANPATH.
Full HTML documentation can be accessed at docs/dist/html/index.html.
You can also build manpages for types in your ~/.cdist directory:
make dotman
Built manpages are now in docs/dist/man directory. If you have
some other custom .cdist directory, e.g. /opt/cdist then use:
DOT_CDIST_PATH=/opt/cdist make dotman
### Python Package
Cdist is available as a python package at
[PyPi](http://pypi.python.org/pypi/cdist/). You can install it using
pip install cdist
## Use cdist
[[Dig into the documentation|documentation]] to get started with cdist!
[[!tag cdist unix]]

View file

@ -1,18 +0,0 @@
[[!meta title="Supported Operating Systems"]]
cdist was tested or is know to run on at least
* [Archlinux](http://www.archlinux.org/)
* [Debian](http://www.debian.org/)
* [CentOS](http://www.centos.org/)
* [Scientific](https://www.scientificlinux.org/)
* [Fedora](http://fedoraproject.org/)
* [FreeBSD](http://www.freebsd.org)
* [Gentoo](http://www.gentoo.org/)
* [Mac OS X](http://www.apple.com/macosx/)
* [OpenBSD](http://www.openbsd.org)
* [Redhat](http://www.redhat.com/)
* [Ubuntu](http://www.ubuntu.com/)
* [XenServer](http://www.citrix.com/xenserver/)
[[!tag cdist unix]]

View file

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

View file

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

View file

@ -1,118 +0,0 @@
[[!meta title="Update Guide for 2.0 to 2.1"]]
## Introduction
When changing your installation from 2.0 to 2.1, there are
a lot of changes coming up. 2.1 is mainly a cleanup release,
which removes long time deprecated behaviour, but also makes
a lot of things more consistent and allows you to split off your types,
explorers and manifest to custom directories.
This document will guide you to a successful update.
## Preparation
As for every software and system you use in production, you should first of
all make a backup of your data. To prevent any breakage, it is
recommended to create a new git branch to do the update on:
% git checkout -b update_to_2.1
This also ensure that whenever you need to do a change in your
2.0 based tree, you can simply go back to that branch, apply the change
and configure your systems - independently of your update progress!
Next fetch the latest upstream changes, I assume that
origin refers to one of the upstream mirrors (change origin if you use
another remote name for upstream cdist):
% git fetch -v origin
## Merge the changes
Now try to merge upstream into the new branch.
% git merge origin/2.1
Fix any conflicts that may have been occurred due to local changes
and then **git add** and *git commit** those changes. This should seldom
occur and if, it's mostly for people hacking on the cdist core.
## Move "conf" directory
One of the biggest changes in cdist 2.1 is that you can have multiple
**conf** directories: Indeed, the new default behaviour of cdist is to
search for conf directories
* below the python module (cdist/conf in the source tree or in the installed location)
* at ~/.cdist/ (on conf suffix there)
So you can now choose, where to store your types.
### Integrate your conf/ back into the tree
If you choose to store your types together with the upstream types,
you can just move all your stuff below **cdist/conf**:
% git mv conf/type/* cdist/conf/type
% git mv conf/manifest/* cdist/conf/manifest
% git mv conf/explorer/* cdist/conf/explorer
% git commit -m "Re-Integrate my conf directory into cdist 2.1 tree"
### Move your conf/ directory to ~/.cdist
If you want to store your site specific
configuration outside of the cdist tree, you
can move your conf/ directory to your homedirectory ($HOME) under ~/.cdist:
% mv conf ~/.cdist
% git rm -r conf
% git commit -m "Move my conf directory to ~/.cdist"
It it still recommended to use a version control system like git in it:
% cd ~/.cdist
% git init
% git add .
% git commit -m "Create new git repository containing my cdist configuration"
## Test the migration
Some of the types shipped with upstream were changed, so you may want to test
the result by running cdist on one of your staging target hosts:
% ./bin/cdist config -v staging-host
All incompatibilities are listed on the [[cdist update page|software/cdist/update]],
so you can browse through the list and update your configuration.
## Final Cleanups
When everything is tested, there are some cleanups to be done to finalise the update.
### When continuing to keep conf/ in the tree
You can then merge back your changes into the master tree and continue to work
as normal.
### When using ~/.cdist
If you decided to move your site specific code to ~/.cdist, you can now switch your
**master** branch or version branch to upstream directly. Assumnig you are in the
cdist directory, having your previous branch checked out, you can create a clean
state using the following commands:
% upstream_branch=2.1
% current_branch=$(git rev-parse --abbrev-ref HEAD)
% git checkout -b archive_my_own_tree
% git branch -D "$current_branch"
% git checkout -b "$current_branch" "origin/$upstream_branch"
Afther these commands, your previous main branch is accessible at
**archive_my_own_tree** and your branch is now tracking upstream.
## Questions? Critics? Hints?
If you think this manual helped or misses some information, do not
hesitate to contact us on any of the usual ways (irc, mailinglist,
github issue tracker, ...).

View file

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