"Stateless Linux" project

[Alexander Holt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Havoc Pennington wrote:

> Red Hat engineering is starting a new project we're calling "stateless
> Linux" ...

Good stuff.  The "ideal properties" of an OS (recreating state
bit-for-bit on new hardware, modifying groups of machines in a single
step): absolutely.  Further, I'd say, it should be straightforward to
rapidly modify single machines (or groups) for specialized purposes.

To me, this emphasizes is the need for smart configuration management
technology.  Thin/cached/fat clients: largely orthogonal.  Home
directory syncing/backup strategies: almost entirely orthogonal.  What
we want are good ways to keep large numbers of diverse machines
configured as required -- once we have that, implementing specific
policies is mostly secondary.

As the document says, it's enough to reconstruct all client state from a
central location.  John Hearns and Josh England have already pointed out
that there are substantial mechanisms around for doing a good chunk of
this.  I'm not familiar with oneSIS <http://onesis.sf.net/> beyond
reading the documentation, but can maybe briefly describe how LCFG
<http://www.lcfg.org/> (and to a large extent, Quattor
<http://www.quattor.org/>) do things.

LCFG can be used to control any category of machine.  It's in use at
Edinburgh University's School of Informatics to manage around 1000
nodes, comprising desktops, laptops, servers & cluster machines.  To
each node you add a collection of small init-like scripts, called
components, responsible for controlling daemons and config files.  You
don't need a read-only root.  Components read a per-node "profile"
telling them, eg, what the current mail hub is.  The mail component is
responsible for creating/modifying the local MTA's config file so that
it specifies that mail hub -- and if there's a daemon, (re)starting it
as appropriate.  (Compare with oneSIS where, say, /etc/mail/sendmail.cf
would be linked to the per-node/group/cluster master copy via a RAM disk
- -- if I've got it right.)

The per-node profile -- much like a long list of key-value pairs -- is
compiled centrally from a declarative description of what each node
should look like.  This description permits machine grouping and
prototypes via a #include-type mechanism.  So it's easy to make small
per-machine or per-node tweaks.  The same description is used to specify
the complete RPM list for each node (all non-config files on nodes come
from RPMs).  Profiles are distributed to nodes by HTTP(S).  A node gets
a UDP notification when its profile has changed, or can just poll the
config server.  There's also a way to make controlled changes to the
local profile without the need to talk to the config server -- eg, on a
laptop when it moves between networks.  And nodes can be built entirely
automatically from bare metal (but no magical solution to bootstrapping
host keys in, eg, a Kerberos environment).

Couple of other thoughts:

(*) Mobility -- and disconnected operation -- is an important
    architectural constraint.  (For instance, the current Edinburgh LCFG
    deployment integrates laptops & desktops, and ends up replicating
    DNS & LDAP servers on *all* nodes.)

(*) The central location that stores client state doesn't ultimately
    have to be a central location.  It could be that intended client
    state is assembled from various kinds of config data distributed
    around the net -- perhaps via peer-to-peer or service discovery type
    mechanisms -- leading to improved resilience & autonomy.  This is
    just another take on "dynamic/automatic configuration", I guess.

Lex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1

iD8DBQFBUxZrZnhMljHa7tgRAoZOAJ9EJ5Cx68/Orfct1b8amat/vya8AACfX2mg
ajEbcygyypPGLMzgtQD7Aug=
=vocE
-----END PGP SIGNATURE-----