Re: bootstrapping cfengine.

[Luke A. Kanies]

On Wed, 12 Nov 2003, Russell Davies wrote:

> I'm currently in the process of deciding how to install cfengine on
> my machines, it seems that simply compiling on the relevant target system
> then stashing the binaries somewhere for redistribution to future similar
> targets, isn't suffcient since the binaries have other package dependencies
> (openssl, berkeleydb).

Static linking is your friend, especially when it comes to your core
management tools.  Really.

> This means that I have to solve the problem of general file/package
> distribution before I even start -- but my intentions were to do this
> using cfengine itself, having it look after file distribution to remote
> hosts (of which there may be many). This seems to be an ugly circular
> dependence.

This is the shortest process I've been able to come up with, and I'll talk
about automating it afterwards:

client: Get binaries on system (cfagent, cfservd, cfkey)
client: Get server's key on the system, named appropriately
client: copy at least minimal configs to host
client: Run cfkey
client: start cfservd [1]
server: use a cfengine script to pull client's key [2]
client: run cfagent for the first time

1> You have to set cfservd to allow at least the cfengine server to copy
the local cfengine public key.  The reason you _must_ have the server's
public key is that even using trust at least one end of the connection
must have the other machine's public key (at least, as far as i can tell).
Since the server's public key is established, set that up, and allow the
server to connect to the client to pull the client's public key.

Ironically, a successful connection on the part of the server will set up
the key correctly, but I go ahead and use cfservd to make the key
available anyway. :)

2> This just needs to be a short script to copy the key to
/var/cfengine/ppkeys/root-<ip>.pub.  But as I mentioned, any successful
connection will do the same thing, so the important thing is just to make
a successful connection.  The central server has to be configured to trust
the client's cfservd process, and the client has to have the central
server's key.  With that setup, it should allwork.

Now that each machine has the other's public key, just run cfagent and the
client (as long as you've got update.conf), and it should all work fine
from there.  If you haven't statically linked, this is a much bigger pain,
so I _really_ recommend static links.

As to automating this process, I built a short makefile which basically
copies all of the pieces (the binaries, the latest configs from the
central repository, and the server's public key) along with an install
script into an executable, self-extracting shell archive.  That way I can
just distribute that single (7 MB or so) file to all my machines, run it
as root, and then I'm basically ready to go.  It's a straightforward
setup, but I am just into the testing phase so I can't give much feedback,
although it seems to work so far.

I might be able to share the makefile and such; I'll look into it.  They
really are very easy, though.  The only complicated thing is you have to
run the self-extracting archive/installer, then run the keygrabber on the
server, and _then_ run cfagent on the client.  Until the client's key is
on the server, things don't work.

This should work well for existing systems and new ones.

Good luck!

-- 
If a `religion' is defined to be a system of ideas that contains
unprovable statements, then Godel taught us that mathematics is not
only a religion, it is the only religion that can prove itself to be
one.            -- John Barrow