cdist configuration management Latest manual: Home page:
Go to file
Nico Schottelius 4fe315b1e4 doc update, manifest extension
Signed-off-by: Nico Schottelius <>
2010-09-20 02:22:49 +02:00
bin cdist-apply can install packages 2010-09-20 01:25:05 +02:00
conf doc update, manifest extension 2010-09-20 02:22:49 +02:00
doc add first manpage 2010-09-19 14:45:09 +02:00
test add cdist_package with dynamic backend selector 2010-09-20 01:02:38 +02:00
cdist.mdwn doc update, manifest extension 2010-09-20 02:22:49 +02:00
README intro => readme 2010-09-19 14:36:20 +02:00

## Introduction

cdist configures your system. It is similar to
[cfengine]( and
It is inspired by both of those tools:

 * Try to redo the great power you get
 * But leave out the bugs you also got

### Principles

cdist is unix: It's designed to reuse existing tools
and does not need high level scripting language interpreters.

### Requirements

 * A posix like shell

## How cdist works

### Exploring your system

cdist analyses the system to apply the configuration on and
selects the right backends. You can use ***cdist-explore*** to
the results of the explore functions.

### Applying the configuration

cdist looks for the configuration to apply on the local host
and applies it using ***cdist-apply***.

### Managing many hosts

Whereas ***cdist-apply*** manages one host, ***cdist-deploy***
applies the configuration on enabled hosts.

## How to use cdist?

## What do I need [from puppet?]

### Abstraction of package managers

I don't want to care about apt, rpm, yum, pacman, etc. I just
want to ensure, some package exists or does not exist.

### Common tasks already done

   - [LIBRARY] All the helper types like 
      - file
      - ssh_keys
      - package
      - service
      - user

   - [PORTABILITY] clients for every unix
      - mostly ruby + facter in puppet

   - Modules: Nice to put stuff together
      - and reuse
   - [CONDITIONS] facter is cool
   - the DSL
      - with many bugs
   - templates
   - Client/Server approach is nice to have
      - Clients only get the part of the documentation, that's
        relevant to them

what is puppet? [FOR ME]

   A configuration deployment assistant,
   a DSL that allows you define the objectives.
   A webserver with fileserver capabilities.
   A client based scheduled polling infrastructure.
What do I miss from puppet?

   - speed
   - elegance
   - clean design
   - documentation
   - the "no surprise" factor
   - easy to use "data memory" (i.e. external ressources)
   - easy integration into installation process
      - copy identity to master
   - multi master setups
   - development configurations / tests
   - editing of configuration files
      - similar to cfengine
   - replace bug squasher with bug avoidance
      - qmail did not need one either
   - push infrastructure
Simple stuff done by Unix[notm]

   - DSL: Shell!
      - gives if, else and EVEN elsif for free!
      - and case
      - and and and
      - and there's no os (solaris doesn't count) without a usable /bin/sh
      - cdist defines what you can use
         - you _can_ use os specific stuff
         - but it's ugly and you shoot into your own foot
      - "manifests" (use the same name here?) will be run/sourced
         - inheritance possible via sourcing
         - cdist-lib always preloaded
      - library == functions?
   - version control via git
   - file distribution via ssh
   - authentication via ssh
   - dumb clients, similar to manifest compile in puppet
      - clients just execute commands
   - dependencies via make?
      - how to ensure sigletons / conflicting definitions?
         file { "/a":
            ensure => present,
         file { "/a":
            ensure => absent,
   - matching on explored items, not only on host name?
      - match function in host? [optional]
   - file source:
      - relative to specification
      - or absolute




      -> called by cron?
      -> no need to reimplement scheduling
   "cdist-explore" (facter replacement)
      -> running on the client