propellor/README

70 lines
3.0 KiB
Plaintext
Raw Normal View History

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-31 19:40:16 +00:00
Propellor lives in a git repository. You'll typically want to have
the repository checked out on a laptop, in order to make changes and push
them out to hosts. Each host will also have a clone of the repository,
and in that clone "make" can be used to build and run propellor.
This can be done by a cron job (which propellor can set up),
or a remote host can be triggered to update by running propellor
on your laptop: propellor --spin $host
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.
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-31 16:06:04 +00:00
## bootstrapping and private data
2014-03-30 23:10:32 +00:00
To bootstrap propellor on a new host, use: propellor --spin $host
2014-03-31 19:40:16 +00:00
That clones the local git repository to the remote host (securely over ssh
and without needing any central server!), if it doesn't already have
a clone.
The repository on the remote host will have its origin set to the local git
repository's remote.origin.url (or remote.deploy.url if available).
This way, when propellor is run on the remote host, it can contact
whatever central git repository you're using.
2014-03-30 23:10:32 +00:00
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 16:06:04 +00:00
## using git://... securely
2014-03-31 19:40:16 +00:00
It's often easiest for a remote host to use a git:// or http://
url to its origin repository, rather than ssh://. So, to avoid a MITM
2014-03-31 16:06:04 +00:00
attack, propellor checks that the top commit in the git repository is gpg
2014-03-31 19:40:16 +00:00
signed by a trusted gpg key, and refuses to deploy it otherwise.
2014-03-31 16:06:04 +00:00
This is only done when privdata/keyring.gpg exists. To set it up:
gpg --gen-key # only if you don't already have a gpg key
propellor --add-key $MYKEYID
2014-03-31 15:06:46 +00:00
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/