"Stateless Linux" project

Josh England jjengla at sandia.gov
Thu Sep 23 21:02:16 UTC 2004


On Thu, 2004-09-23 at 11:31, Alexander Holt wrote:
> LCFG can be used to control any category of machine.
> [....]
> (*) Mobility -- and disconnected operation -- is an important
>     architectural constraint. [....]
> 
> (*) The central location that stores client state doesn't ultimately
>     have to be a central location. [....]

LCFG does indeed sound like a highly capable configuration deployment
engine (how does it compare with cfengine, in your opinion?).

I believe there are several key differences, however, between the
approach that a configuration deployment engine uses, and the approach
that oneSIS takes.  Any configuration engine (LCFG and cfengine it seems
at least) centrally manage clients by shipping/creating configuration
files to each client, which can then act independently from the server. 
Each client potentially has its own singular configuration, and every
client potentially differs from every other.  With oneSIS, every client
is always bit-for-bit identical with every other client.  Independent
configuration is done by editing the config files for the particular
node/class (ie: /etc/fstab.myclass), making administration of a large
group of machines a natural extension of administering a single machine
without the need for a configuration language.

When the rootFS is guaranteed to be bit-for-bit identical, every
(diskful) node can in turn serve its root image to any number of other
client nodes.  This can be used to create a hierarchical tree where
every node remains bit-for-bit identical with the server it synchronizes
from, and each (diskful) node can operate stand-alone, disconnected from
the network.  Any diskful node can mount its root filesystem read-write
if desired, with the knowledge that any local changes will be lost if it
fully synchronizes itself with its master (bi-directional sync is a
no-no).  Every node is exactly identical, with the node's configuration
determined at boot-time.  This means any node can essentially 'become'
any other node simply by rebooting (though there are plans to extend
this to allow run-time re-configuration).

The most striking benefit though, in my opinion, is the ability to boot
any machine 'diskless' into the exact same environment as the diskful
nodes.  Client machines don't even need to have a disk to boot into the
system.  However, a client node with a local disk (a laptop for
instance), can boot into a diskless environment without affecting its
own local OS installation in any way.  This would be desirable for those
who don't like to have others control the OS on their machine.  The user
can afterwards reboot back into his/her own local OS and resume life
like normal.  Everything is completely stateless.  When collaborating
with visitors with their own laptops, a single root image can be
exported for everyone to run in (diskless) for the duration of the
collaboration, and then they can return to their own OS setup by
rebooting from their local disk.  Alternatively, any single machine can
deploy (or just copy) the image to a local disk, move it anywhere, and
export it to an number of client nodes in turn.  There are several other
benefits of diskless operation (ie: instantaneous updates) that make it
very attractive.

oneSIS only handles the management/deployment of a master root image. 
The behavior of the machine is near-indistinguishable from a normal
Fedora installation.  It is simple in design, and IMO astoundingly easy
to administer a oneSIS system (everything is identical!).  The bootstrap
mechanisms in place (initrd generation from a template) provide a
framework for creating unique (key-based/Kerberos ?) methods for
authenticating client nodes if desired.  The probably not suited for
every conceivable environment, in all I believe oneSIS can be an
excellent starting point to accomplish the goals of the "Stateless
Linux" project.

-JE

-----------------------------------------------
Josh England
Sandia National Laboratory, Livermore, CA
Visualization and Scientific Computing
email: jjengla at sandia.gov
phone: (925) 294-2076






More information about the fedora-devel-list mailing list