StateEngine
===========

StateEngine is a remote state management too.  Similar in idea to
cfengine, SE was created to manage large networks of machines with
portability in mind.  Where cfengine attempts to configure a remote
client, SE attempts to bring that client into a specific, known state.
This definately includes configuration but is scalable to deploying
arbitrary Actions.

StateEngine works with these ideas and concepts.  Each client knows
a specific set of Actions which are not ment to frequently change.  This
keeps the administrator from constantly updating the installed Actions.
The StateEngine server knows about State objects.  These objects
the administrator provides.  Each object is assinged to a client or
group of clients and creates a queue of specific Actions to be deployed
to the client to transform the client into a known State.

Website: http://linuxczar.net/moin/StateEngine

All code that is part of the SE project is licensed under the GNU
General Public License version 2.

SSL
---

SE uses x509 certificates for authentication.  (Most of this code was
taking from the Fedora Build System written by Dan Williams.)  The SE
client and server all need three things.  1) A private SSL key.
2) A CA certificate that signed the private key.  3) The CA certificate
that signed the private key of the remote server/client.  The final
CA is called the Peer CA.

The most secure method is to create two CAs where one is for the server
and the other is for the client.  Create a private key for the server
and for the client and sign them with their respective CAs.  Configure
the server to use its private key and the CA cert that signed the private 
key.  Set the Peer CA to be the CA certificate that signed the client's
private key.

The client needs a similar configuration.  Using peer CAs you can safely
distribute a private SSL key, CA, and peer CA with the SE client.  The
clients will only trust the server and vice versa.  A client can not
be tricked into trusting another client.

The included python script 'certhelper.py' will generate CAs and 
normal keys in the format used by SE.


Setting Up SE
-------------

This code is in the prototype stages.  The instructions for getting SE
up and running are for running prototype code in a testing environment.
However, this should let folks get a hold of some concepts and the style
for which I am attacking this problem.

To get SE up and running first you need to create 2 sets of x509 certificates.
You'll need a CA and key/cert for the SE server and a different set for 
the Client.  Edit the sample configuration so that it points to the pem
files created by certhelper.py.  The peer_ca for the Server points to the file
containing the CA of the Client and vice versa.

From the Client section remove any old UUIDs and set the server variable to
the FQDN of where the SE server is.  

In the Server section set db to the file that will be created containing
the SQLite database.  Set configs to a path where you text based config files
for each host will be.  The db_type must be "pysqlite" as that's the
only database supported right now.

Config Files

The config files are simple text based files that hold the state configuration
for a specific host.  The file must be named the FQDN of the host it affects.
These files are read into the database when SE starts up.  Each State is
defined like this:

   StateName arg1 arg2 var1=value var2=value

Think about this pythonicly.  StateName is a function name and arg1, arg2, 
etc are arguments to the function.  If the function also takes keyword 
arguments those are specified as "var1=value" etc.

Starting SE

Change directory into the src/ directory.  To run the server run:

    python ./seadm.py --server

To start the client (in another terminal):

    python ./seadm.py --client

To start the client and have it poll the server once for Actions and then
exit:

    python ./seadm.py --client --poll


Jack Neely
jjneely at gmail.com

