Merge branch 'cdist-5.0.0' into 'master'

Cdist 5.0.0

See merge request ungleich-public/cdist!775
This commit is contained in:
poljakowski 2019-05-04 11:39:52 +02:00
commit 954663475a
29 changed files with 109 additions and 1207 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

@ -1,6 +1,7 @@
#!/bin/sh
#
# 2011-2013 Nico Schottelius (nico-cdist at schottelius.org)
# 2016-2019 Darko Poljak (darko.poljak at gmail.com)
#
# This file is part of cdist.
#
@ -18,10 +19,36 @@
# along with cdist. If not, see <http://www.gnu.org/licenses/>.
#
#
# This file contains the heavy lifting found usually in the Makefile
# This file contains the heavy lifting found usually in the Makefile.
#
# vars for make
helper=$0
basedir=${0%/*}/../
# run_as is used to check how the script is called (by $0 value)
# currently supported sufixes for $0 are:
# .darko - run as darko
basename=${0##*/}
run_as=${basename#*.}
to_a=cdist-configuration-management
to_d=googlegroups.com
case "$run_as" in
darko)
from_a=darko.poljak
from_d=gmail.com
ml_name="Darko Poljak"
ml_sig_name="Darko"
;;
*)
from_a=nico.schottelius
from_d=ungleich.ch
ml_name="Nico Schottelius"
ml_sig_name="Nico"
;;
esac
# Change to checkout directory
cd "$basedir"
@ -30,6 +57,12 @@ version=$(git describe)
option=$1; shift
case "$option" in
print-make-vars)
printf "helper: ${helper}\n"
;;
print-runas)
printf "run_as: $run_as\n"
;;
changelog-changes)
if [ "$#" -eq 1 ]; then
start=$1
@ -76,33 +109,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
@ -111,19 +117,14 @@ eof
version=$1; shift
to_a=cdist
to_d=l.schottelius.org
to=${to_a}@${to_d}
from_a=nico-cdist
from_d=schottelius.org
from=${from_a}@${from_d}
(
cat << eof
From: Nico -telmich- Schottelius <$from>
From: ${ml_name} <$from>
To: cdist mailing list <$to>
Subject: cdist $version released
Subject: cdist $version has been released
Hello .*,
@ -135,15 +136,18 @@ eof
cat << eof
Cheers,
Nico
${ml_sig_name}
--
Automatisation at its best level. With cdist.
eof
) | /usr/sbin/sendmail -f "$from" "$to"
;;
) > mailinglist.tmp
if [ "$run_as" = "build-helper" ]
then
/usr/sbin/sendmail -f "$from" "$to" < mailinglist.tmp && rm -f mailinglist.tmp
fi
;;
release-git-tag)
target_version=$($0 changelog-version)
@ -240,7 +244,6 @@ eof
"https://code.ungleich.ch/api/v4/projects/${project}/repository/tags/${tag}/release" \
|| exit 1
# remove generated files (archive and asc)
if [ $# -eq 2 ]
then
@ -303,11 +306,8 @@ eof
# Generate documentation (man and html)
# First, clean old generated docs
make docs-clean
make docs
# Generate speeches (indirect check if they build)
make speeches
make helper=${helper} docs-clean
make helper=${helper} docs
#############################################################
# Everything green, let's do the release
@ -322,23 +322,27 @@ eof
fi
# Publish git changes
make pub
# publish man, speeches, website
if [ "$masterbranch" = yes ]; then
make web-release-all
if [ "$run_as" = "build-helper" ]
then
make helper=${helper} pub
else
make web-release-all-no-latest
# if we are not Nico :) then just push, no mirror
git push
# push also new branch and set up tracking
git push -u origin "${target_branch}"
fi
# Ensure that pypi release has the right version
"$0" version
# Create and publish package for pypi
make pypi-release
make helper=${helper} pypi-release
# Archlinux release is based on pypi
make archlinux-release
if [ "$run_as" = "build-helper" ]
then
# Archlinux release is based on pypi
make helper=${helper} archlinux-release
fi
# sign git tag
printf "Enter upstream repository authentication token: "
@ -346,18 +350,13 @@ eof
"$0" sign-git-release "${target_version}" "${token}"
# Announce change on ML
make ml-release
make helper=${helper} ml-release
cat << eof
Manual steps post release:
- linkedin
- hackernews
- reddit
- cdist-web
- twitter
eof
;;
test)
@ -402,7 +401,7 @@ eof
;;
shellcheck)
make shellcheck
make helper=${helper} shellcheck
printf "\\nPlease review shellcheck report.\\n"
while true
do

1
bin/build-helper.darko Symbolic link
View File

@ -0,0 +1 @@
build-helper

View File

@ -1,483 +0,0 @@
#!/bin/sh
#
# 2011-2013 Nico Schottelius (nico-cdist at schottelius.org)
# 2016 Darko Poljak (darko.poljak at gmail.com)
#
# This file is part of cdist.
#
# cdist is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# cdist is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with cdist. If not, see <http://www.gnu.org/licenses/>.
#
#
# This file contains the heavy lifting found usually in the Makefile
#
# vars for make
helper=$0
basedir=${0%/*}/../
# run_as is used to check how the script is called (by $0 value)
# currently supported sufixes for $0 are:
# .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
# Change to checkout directory
cd "$basedir"
version=$(git describe)
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"
;;
changelog-changes)
if [ "$#" -eq 1 ]; then
start=$1
else
start="[[:digit:]]"
fi
end="[[:digit:]]"
awk -F: "BEGIN { start=0 }
{
if(start == 0) {
if (\$0 ~ /^$start/) {
start = 1
}
} else {
if (\$0 ~ /^$end/) {
exit
} else {
print \$0
}
}
}" "$basedir/docs/changelog"
;;
changelog-version)
# get version from changelog
grep '^[[:digit:]]' "$basedir/docs/changelog" | head -n1 | sed 's/:.*//'
;;
check-date)
# verify date in changelog is today
date_today="$(date +%Y-%m-%d)"
date_changelog=$(grep '^[[:digit:]]' "$basedir/docs/changelog" | head -n1 | sed 's/.*: //')
if [ "$date_today" != "$date_changelog" ]; then
echo "Date in changelog is not today"
echo "Changelog: $date_changelog"
exit 1
fi
;;
check-unittest)
"$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
exit 1
fi
version=$1; shift
to=${to_a}@${to_d}
from=${from_a}@${from_d}
(
cat << eof
From: ${ml_name} <$from>
To: cdist mailing list <$to>
Subject: cdist $version released
Hello .*,
cdist $version has been released with the following changes:
eof
"$0" changelog-changes "$version"
cat << eof
Cheers,
${ml_sig_name}
--
Automatisation at its best level. With cdist.
eof
) | /usr/sbin/sendmail -f "$from" "$to"
;;
release-git-tag)
target_version=$($0 changelog-version)
if git rev-parse --verify refs/tags/$target_version 2>/dev/null; then
echo "Tag for $target_version exists, aborting"
exit 1
fi
printf "Enter tag description for ${target_version}: "
read tagmessage
# setup for signed tags:
# gpg --fulL-gen-key
# gpg --list-secret-keys --keyid-format LONG
# git config --local user.signingkey <id>
# for exporting pub key:
# gpg --armor --export <id> > pubkey.asc
# gpg --output pubkey.gpg --export <id>
# show tag with signature
# git show <tag>
# verify tag signature
# git tag -v <tag>
#
# gpg verify signature
# gpg --verify <asc-file> <file>
# gpg --no-default-keyring --keyring <pubkey.gpg> --verify <asc-file> <file>
# Ensure gpg-agent is running.
export GPG_TTY=$(tty)
gpg-agent
git tag -s "$target_version" -m "$tagmessage"
git push --tags
;;
sign-git-release)
if [ $# -lt 2 ]
then
printf "usage: $0 sign-git-release TAG TOKEN [ARCHIVE]\n"
printf " if ARCHIVE is not specified then it is created\n"
exit 1
fi
tag="$1"
if ! git rev-parse -q --verify "${tag}" >/dev/null 2>&1
then
printf "Tag \"${tag}\" not found.\n"
exit 1
fi
token="$2"
if [ $# -gt 2 ]
then
archivename="$3"
else
archivename="cdist-${tag}.tar"
git archive --prefix="cdist-${tag}/" -o "${archivename}" "${tag}" \
|| exit 1
# make sure target version is generated
"$0" target-version
tar -x -f "${archivename}" || exit 1
cp cdist/version.py "cdist-${tag}/cdist/version.py" || exit 1
tar -c -f "${archivename}" "cdist-${tag}/" || exit 1
rm -r -f "cdist-${tag}/"
gzip "${archivename}" || exit 1
archivename="${archivename}.gz"
fi
gpg --armor --detach-sign "${archivename}" || exit 1
project="ungleich-public%2Fcdist"
sed_cmd='s/^.*"markdown":"\([^"]*\)".*$/\1/'
# upload archive
response_archive=$(curl -f -X POST \
--http1.1 \
-H "PRIVATE-TOKEN: ${token}" \
-F "file=@${archivename}" \
"https://code.ungleich.ch/api/v4/projects/${project}/uploads" \
| sed "${sed_cmd}") || exit 1
# upload archive signature
response_archive_sig=$(curl -f -X POST \
--http1.1 \
-H "PRIVATE-TOKEN: ${token}" \
-F "file=@${archivename}.asc" \
"https://code.ungleich.ch/api/v4/projects/${project}/uploads" \
| sed "${sed_cmd}") || exit 1
# make release
changelog=$("$0" changelog-changes "$1" | sed 's/^[[:space:]]*//')
release_notes=$(
printf "Release %s\n\n%s\n\n%s\n\n**Changelog**\n\n%s\n" \
"${tag}" "${response_archive}" "${response_archive_sig}" "${changelog}"
)
curl -f -X POST \
-H "PRIVATE-TOKEN: ${token}" \
-F "description=${release_notes}" \
"https://code.ungleich.ch/api/v4/projects/${project}/repository/tags/${tag}/release" \
|| exit 1
# remove generated files (archive and asc)
if [ $# -eq 2 ]
then
rm -f "${archivename}"
fi
rm -f "${archivename}.asc"
;;
release)
set -e
target_version=$($0 changelog-version)
target_branch=$($0 version-branch)
echo "Beginning release process for $target_version"
# First check everything is sane
"$0" check-date
"$0" check-unittest
"$0" check-pycodestyle
"$0" shellcheck
# Generate version file to be included in packaging
"$0" target-version
# Ensure the git status is clean, else abort
if ! git diff-index --name-only --exit-code HEAD ; then
echo "Unclean tree, see files above, aborting"
exit 1
fi
# Ensure we are on the master branch
masterbranch=yes
if [ "$(git rev-parse --abbrev-ref HEAD)" != "master" ]; then
echo "Releases are happening from the master branch, aborting"
echo "Enter the magic word to release anyway"
read magicword
if [ "$magicword" = "iknowwhatido" ]; then
masterbranch=no
else
exit 1
fi
fi
if [ "$masterbranch" = yes ]; then
# Ensure version branch exists
if ! git rev-parse --verify refs/heads/$target_branch 2>/dev/null; then
git branch "$target_branch"
fi
# Merge master branch into version branch
git checkout "$target_branch"
git merge master
fi
# Verify that after the merge everything works
"$0" check-date
"$0" check-unittest
# Generate documentation (man and html)
# First, clean old generated docs
make helper=${helper} WEBDIR=${WEBDIR} docs-clean
make helper=${helper} WEBDIR=${WEBDIR} docs
# Generate speeches (indirect check if they build)
make helper=${helper} WEBDIR=${WEBDIR} speeches
#############################################################
# Everything green, let's do the release
# Tag the current commit
"$0" release-git-tag
# Also merge back the version branch
if [ "$masterbranch" = yes ]; then
git checkout master
git merge "$target_branch"
fi
# Publish git changes
case "$run_as" in
freebsd)
# if we are not Nico :) then just push, no mirror
git push
# push also new branch and set up tracking
git push -u origin "${target_branch}"
;;
*)
make helper=${helper} WEBDIR=${WEBDIR} pub
;;
esac
# Ensure that pypi release has the right version
"$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
# sign git tag
printf "Enter upstream repository authentication token: "
read token
"$0" sign-git-release "${target_version}" "${token}"
# Announce change on ML
make helper=${helper} WEBDIR=${WEBDIR} ml-release
;;
test)
export PYTHONPATH="$(pwd -P)"
if [ $# -lt 1 ]; then
python3 -m cdist.test
else
python3 -m unittest "$@"
fi
;;
test-remote)
export PYTHONPATH="$(pwd -P)"
python3 -m cdist.test.exec.remote
;;
pycodestyle|pep8)
pycodestyle "${basedir}" "${basedir}/scripts/cdist" | less
;;
check-pycodestyle)
"$0" pycodestyle
printf "\\nPlease review pycodestyle report.\\n"
while true
do
echo "Continue (yes/no)?"
any=
read any
case "$any" in
yes)
break
;;
no)
exit 1
;;
*)
echo "Please answer with 'yes' or 'no' explicitly."
;;
esac
done
;;
shellcheck)
make helper=${helper} WEBDIR=${WEBDIR} shellcheck
printf "\\nPlease review shellcheck report.\\n"
while true
do
echo "Continue (yes/no)?"
any=
read any
case "$any" in
yes)
break
;;
no)
exit 1
;;
*)
echo "Please answer with 'yes' or 'no' explicitly."
;;
esac
done
;;
version-branch)
"$0" changelog-version | cut -d. -f '1,2'
;;
version)
echo "VERSION = \"$(git describe)\"" > cdist/version.py
;;
target-version)
target_version=$($0 changelog-version)
echo "VERSION = \"${target_version}\"" > cdist/version.py
;;
*)
echo "Unknown helper target $@ - aborting"
exit 1
;;
esac

View File

@ -11,7 +11,7 @@ import cdist.configuration
BETA_COMMANDS = set(('install', 'inventory', ))
# set of beta arguments for sub-commands
BETA_ARGS = {
'config': set(('jobs', 'tag', 'all_tagged_hosts', 'use_archiving', )),
'config': set(('tag', 'all_tagged_hosts', 'use_archiving', )),
}
EPILOG = "Get cdist at http://www.nico.schottelius.org/software/cdist/"
# Parser others can reuse
@ -191,8 +191,7 @@ def get_parsers():
name="positive int"),
help=('Operate in parallel in specified maximum number of jobs. '
'Global explorers, object prepare and object run are '
'supported. Without argument CPU count is used by default. '
'Currently in beta.'),
'supported. Without argument CPU count is used by default. '),
action='store', dest='jobs',
const=multiprocessing.cpu_count())
parser['config_main'].add_argument(

View File

@ -10,6 +10,9 @@ next:
* Build: Update due to migration to code.ungleich.ch (Darko Poljak)
* Documentation: Update due to migration to code.ungleich.ch (Darko Poljak)
* Core: Detect and report dependency cycle as soon as possible (Darko Poljak)
* Core, documentation: Release -j/--jobs option, i.e. make it non-beta (Darko Poljak)
* Documentation: Update due to new cdist website (Darko Poljak)
* Build: Update due to new cdist website (Darko Poljak)
4.11.1: 2019-04-22
* Core: Improve explorer error reporting (Darko Poljak)

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

@ -12,8 +12,7 @@ The other way is to operate in parallel within one host where you specify
the number of jobs. This is enabled with :strong:`-j/--jobs` option where you
can specify the number of parallel jobs. By default,
:strong:`multiprocessing.cpu_count()` is used. For this mode global explorers,
object preparation and object run are supported and this option is still in
:strong:`beta`.
object preparation and object run are supported.
You can, of course, use those two options together. This means that each host
will be processed by its own process. Within each process cdist will operate
@ -32,11 +31,11 @@ Examples
# Configure hosts read from file hosts.file sequentially but using default
# number of parallel jobs
$ cdist config -b -j -f hosts.file
$ cdist config -j -f hosts.file
# Configure hosts read from file hosts.file in parallel using 16
# parallel jobs
$ cdist config -b -j 16 -p -f hosts.file
$ cdist config -j 16 -p -f hosts.file
Caveats

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

@ -165,7 +165,7 @@ Install command is currently in beta.
Operate in parallel in specified maximum number of
jobs. Global explorers, object prepare and object run
are supported. Without argument CPU count is used by
default. Currently in beta.
default.
**-n, --dry-run**
Do not execute code.

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]]