Configs
Go to file
Joey Hess c1c7feedfb propellor spin 2014-03-31 11:06:46 -04:00
Propellor monoid 2014-03-31 10:36:45 -04:00
Utility propellor spin 2014-03-30 19:10:32 -04:00
privdata propellor spin 2014-03-31 10:52:46 -04:00
.gitignore propellor spin 2014-03-30 20:24:50 -04:00
GPL cabalized and added a wrapper program 2014-03-30 00:08:02 -04:00
Makefile propellor spin 2014-03-31 10:44:34 -04:00
Propellor.hs monoid 2014-03-31 10:36:45 -04:00
README propellor spin 2014-03-31 11:06:46 -04:00
Setup.hs fix 2014-03-30 23:39:07 -04:00
TODO cleanup 2014-03-31 00:03:40 -04:00
config.hs propellor spin 2014-03-31 10:52:46 -04:00
propellor.cabal propellor spin 2014-03-31 01:29:47 -04:00

README

This is a work in progress configuration management system using Haskell
and Git.

Propellor enures that the system it's run in satisfies a list of
properties, taking action as necessary when a property is not yet met.

The design is intentionally very minimal.

Propellor lives in a git repository, and so to set it up it's cloned
to a system, and "make" can be used to pull down any new changes,
and compile and run propellor. This can be done by a cron job, or
something can ssh in and run it.

Properties are defined using Haskell. Edit config.hs to get started.

There is no special language as used in puppet, chef, ansible, etc.. just
the full power of Haskell. Hopefully that power can be put to good use in
making declarative properties that are powerful, nicely idempotent, and
easy to adapt to a system's special needs.

Also avoided is any form of node classification. Ie, which hosts are part
of which classes and share which configuration. It might be nice to use
reclass[1], but then again a host is configured using simply haskell code,
and so it's easy to factor out things like classes of hosts as desired.

To bootstrap propellor on a new host, use: propellor --spin $host
This looks up the git repository's remote.origin.url (or remote.deploy.url
if available) and logs into the host, clones the url (if not already
done), and sets up and runs propellor in /usr/local/propellor

Private data such as passwords, ssh private keys, etc should not be checked
into a propellor git repository in the clear, unless you want to restrict
access to the repository. Which would probably involve a separate fork 
for each host and be annoying. 

Instead, propellor --spin $host looks for a privdata/$host.gpg file and
if found decrypts it and sends it to the host using ssh. To set a field
in such a file, use: propellor --set $host $field
The field name will be something like 'Password "root"'; see PrivData.hs
for available fields.

It's often easiest to deploy propellor to a host by cloning a git://
or http:// repository. To avoid a MITM attack, propellor checks
that the top commit in the git repository is gpg signed by a
trusted key, and refuses to deploy it otherwise. This is only done if
privdata/keyring.gpg exists. To generate it, make a gpg key and
run something like:

The keyring.gpg can be checked into git, but to ensure that it's
used from the beginning when bootstrapping, propellor --spin
transfers it to the host using ssh.

[1] http://reclass.pantsfullofunix.net/