cdist configuration management Latest manual: Home page:
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Go to file
Nico Schottelius e054d0c22c module loader implemented
Signed-off-by: Nico Schottelius <>
13 years ago
bin module loader implemented 13 years ago
conf module loader implemented 13 years ago
doc add first manpage 13 years ago
test module loader implemented 13 years ago
README intro => readme 13 years ago
cdist.mdwn doc update, manifest extension 13 years ago


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