cdist/doc/man/cdist-design.text

cdist-design(7)
===============
Nico Schottelius <nico-cdist--@--schottelius.org>


NAME
----
cdist-design - Design ideas for cdist

DESCRIPTION
-----------

When using cdist with the push principle, the execution tree looks likes this:

--------------------------------------------------------------------------------
% server
   cdist-deploy-to(1)
      cdist-build(1)
         cdist-preprocess(1)  # fills up variables with content
            cdist-explore(1)  % client # explores client configuration
         cdist-compile(1)     # parses configuration, creates internal state in cconfig format, verifies
         cdist-link(1)        # uses cconfig output, creates executable
      cdist-remote-exec(1) # 
         cdist-transfer(1)    # transfer executable to client
         cdist-execute(1)     % client # execute resulting executable
--------------------------------------------------------------------------------

Operation on the server is run as "cdist" user.
Operation on the client is run as "root" user.

When using cdist with the pull principle (configuration triggered by client):

--------------------------------------------------------------------------------
% client
   cdist-trigger(1) <server-hostname> # connects to server
      cdist-deploy-to(1) <client-hostname> % server: see above
--------------------------------------------------------------------------------


MERGE INTO ABOVE.....
## 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.

   - 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,
         =>=>>>>>>>>>>>>>>>> via cconfig


SEE ALSO
--------
cdist(7), website: http://www.nico.schottelius.org/cdist/[]


COPYING
-------
Copyright \(C) 2010 Nico Schottelius. Free use of this software is
granted under the terms of the GNU General Public License version 3 (GPLv3).