cdist-design(7) =============== Nico Schottelius 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) # main tool for deployment cdist-config(1) # setup environment cdist-build(1) # coordinates build process / dummy otherwise 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 configuration cdist-link(1) # uses cconfig output, creates executable cdist-remote-exec(1) # coordinates remote execution, dummy otherwise 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) # connects to server cdist-deploy-to(1) % 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-2011 Nico Schottelius. Free use of this software is granted under the terms of the GNU General Public License version 3 (GPLv3).