2014-03-30 03:10:52 +00:00
|
|
|
This is a work in progress configuration management system using Haskell
|
|
|
|
and Git.
|
|
|
|
|
2014-03-30 06:46:05 +00:00
|
|
|
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.
|
2014-03-30 03:10:52 +00:00
|
|
|
|
2014-03-30 06:44:40 +00:00
|
|
|
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,
|
2014-03-31 01:06:24 +00:00
|
|
|
and compile and run propellor. This can be done by a cron job, or
|
|
|
|
something can ssh in and run it.
|
2014-03-30 03:10:52 +00:00
|
|
|
|
2014-03-31 03:59:07 +00:00
|
|
|
Properties are defined using Haskell. Edit config.hs to get started.
|
2014-03-30 06:50:04 +00:00
|
|
|
|
2014-03-31 03:37:54 +00:00
|
|
|
There is no special language as used in puppet, chef, ansible, etc.. just
|
2014-03-30 06:50:04 +00:00
|
|
|
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.
|
2014-03-30 03:10:52 +00:00
|
|
|
|
|
|
|
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,
|
2014-03-30 06:46:05 +00:00
|
|
|
and so it's easy to factor out things like classes of hosts as desired.
|
2014-03-30 03:10:52 +00:00
|
|
|
|
2014-03-30 23:10:32 +00:00
|
|
|
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
|
2014-03-31 01:01:18 +00:00
|
|
|
in such a file, use: propellor --set $host $field
|
2014-03-31 01:06:24 +00:00
|
|
|
The field name will be something like 'Password "root"'; see PrivData.hs
|
2014-03-30 23:10:32 +00:00
|
|
|
for available fields.
|
|
|
|
|
2014-03-31 15:06:46 +00:00
|
|
|
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.
|
|
|
|
|
2014-03-30 03:10:52 +00:00
|
|
|
[1] http://reclass.pantsfullofunix.net/
|