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-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-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-31 23:12:27 +00:00
|
|
|
## quick start
|
2014-03-31 16:06:04 +00:00
|
|
|
|
2014-03-31 23:19:56 +00:00
|
|
|
1. Clone propellor's git repository to your laptop (or whatever).
|
|
|
|
2. Run: sudo make deps # installs build dependencies
|
|
|
|
3. Run: make build
|
|
|
|
4. If you don't have a gpg private key, generate one: gpg --gen-key
|
|
|
|
5. Run: ./propellor --add-key $KEYID
|
|
|
|
7. Pick a host and run: ./propellor --spin $HOST
|
|
|
|
8. Now you have a simple propellor deployment, but it doesn't do anything
|
|
|
|
to the host yet, besides installing propellor.
|
2014-03-30 23:10:32 +00:00
|
|
|
|
2014-03-31 23:19:56 +00:00
|
|
|
So, edit config.hs to configure the host (maybe start with a few simple
|
|
|
|
properties), and re-run step 7. Repeat until happy and move on to the
|
|
|
|
next host. :)
|
|
|
|
9. To move beyond manually running propellor --spin against hosts
|
|
|
|
when you change configuration, add a property to your hosts
|
|
|
|
like: Cron.runPropellor "30 * * * *"
|
|
|
|
|
|
|
|
Now they'll automatically update every 30 minutes, and you can
|
|
|
|
`git commit -S` and `git push` changes that affect any number of
|
|
|
|
hosts.
|
|
|
|
10. Write some neat new properties and send patches to propellor@joeyh.name!
|
2014-03-30 23:10:32 +00:00
|
|
|
|
2014-03-31 23:12:27 +00:00
|
|
|
## security
|
2014-03-30 23:10:32 +00:00
|
|
|
|
2014-03-31 23:12:27 +00:00
|
|
|
Propellor's security model is that the hosts it's used to deploy are
|
|
|
|
untrusted, and that the central git repository server is untrusted.
|
2014-03-31 23:06:50 +00:00
|
|
|
|
2014-03-31 23:12:27 +00:00
|
|
|
The only trusted machine is the laptop where you run propellor --spin
|
|
|
|
to connect to a remote host. And that one only because you have a ssh key
|
|
|
|
or login password to the host.
|
2014-03-31 23:06:50 +00:00
|
|
|
|
2014-03-31 23:12:27 +00:00
|
|
|
Since the hosts propellor deploys are not trusted by the central git
|
|
|
|
repository, they have to use git:// or http:// to pull from the central
|
|
|
|
git repository, rather than ssh://.
|
2014-03-31 16:06:04 +00:00
|
|
|
|
2014-03-31 23:12:27 +00:00
|
|
|
So, to avoid a MITM attack, propellor checks that any commit it fetched
|
|
|
|
from origin is gpg signed by a trusted gpg key, and refuses to deploy it
|
|
|
|
otherwise.
|
2014-03-31 16:06:04 +00:00
|
|
|
|
2014-03-31 23:12:27 +00:00
|
|
|
That is only done when privdata/keyring.gpg exists. To set it up:
|
2014-03-31 16:06:04 +00:00
|
|
|
|
|
|
|
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
|
|
|
|
2014-03-31 23:12:27 +00:00
|
|
|
In order to be secure from the beginning, when propellor --spin is used
|
2014-03-31 20:20:38 +00:00
|
|
|
to bootstrap propellor on a new host, it transfers the local git repositry
|
2014-03-31 23:12:27 +00:00
|
|
|
to the remote host over ssh. After that, the remote host knows the
|
|
|
|
gpg key, and will use it to verify git fetches.
|
|
|
|
|
|
|
|
Since the propoellor git repository is public, you can't store
|
|
|
|
in cleartext private data such as passwords, ssh private keys, etc.
|
|
|
|
|
|
|
|
Instead, propellor --spin $host looks for a privdata/$host.gpg file and
|
|
|
|
if found decrypts it and sends it to the remote host using ssh. This lets
|
|
|
|
a remote host know its own private data, without seeing all the rest.
|
|
|
|
|
|
|
|
To securely store private data, use: propellor --set $host $field
|
|
|
|
The field name will be something like 'Password "root"'; see PrivData.hs
|
|
|
|
for available fields.
|
2014-03-31 20:20:38 +00:00
|
|
|
|
2014-04-01 15:59:48 +00:00
|
|
|
## debugging
|
|
|
|
|
|
|
|
Set PROPELLOR_DEBUG=1 to make propellor print out all the commands it runs
|
|
|
|
and anything other debug messages Properties choose to.
|
|
|
|
|
2014-03-30 03:10:52 +00:00
|
|
|
[1] http://reclass.pantsfullofunix.net/
|