cdist-backup/cdist.mdwn

## TO DOC

Before initial release, document:

   - how to add package backends
   - how to write a minimal host manifest
   - create library with all functions (and their parameters)
      - cdist_package
      - cdist_file
      - cdist_dir

   - only do necessary work
      - install packages only if not existent
      - copy file only if different

   - how to write a module
      - module function autoloading via *.sh
      - module "manifest"?
         - create functions in *.sh
         - name functions "modulename_function"
            module hellow
            function kitty
            => hellow_kitty
      - you are advised (not forced) to put files
         to a subdirectory named "files"


## Testing cdist

cdist-build-explorer| ssh localhost

set -e
git clone git://git.schottelius.org/cdist
cd cdist
export PATH=$PATH:$(pwd -P)/bin 
cdist-build-explorer | ssh localhost


## Architecture

 - User write shell scripts, which are run on the server
 - Shell scripts call cdist functions
 - cdist functions generate cconfig, which can be verified
 - if verified, generate "command file" to execute on the client
   - client only sees the commands
   - no special requirements on the client

## next: cdist-deploy-to

   - sync conf/{lib/,modules,host/$name}

## Introduction

cdist configures your system. It is similar to
[cfengine](http://www.cfengine.org/) and
[puppet](http://www.puppetlabs.com/).
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?

 0. Create a host specification (/etc/cdist/hosts/**hostname**)
 0. Add functionalilty to add
 0. Run ***cdist-apply***


## 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
   - [PORTABILITY] clients for every unix
      - mostly ruby + facter in puppet

### Other
   - 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
   - detect impossible/unsafe things:
      - creating a file twice
      - installing and removing a package
      - and report location of occurence
         - parse afterwards?

--------------------------------------------------------------------------------
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
   - real / meaningful error messages

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


--------------------------------------------------------------------------------
Architecture

   

--------------------------------------------------------------------------------
Implementation

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