"Stateless Linux" project

Havoc Pennington hp at redhat.com
Mon Sep 13 20:58:52 UTC 2004

On Mon, 2004-09-13 at 21:36 +0100, Miles Sabin wrote:
> I think all my questions boil down to: looks great for the 95% of stuff 
> which stays the same, but how do you deal with the 5% of stuff which 
> varies? And can you do it in a way which is 95% less hassle than 
> treating the machines as completely separate entities?

Right, for a sufficiently low number of machines, setting up an
elaborate framework is going to be more annoying than just managing them
all separately. Though we should try to make the framework easy enough
to use that it makes sense even for a single machine, if we can.

I think there are maybe a couple answers to your question.

1) Should there be some kind of OS 'layering' (words like 'profile' 
or 'inheritance' come to mind).

This is possible today with something like RHN, which can describe a
machine install as a set of RPMs and a set of config files. Today you
can have RHN keep machines in sync directly by syncing their config
files and package lists. In the future it might make sense if RHN could
stage each profile to a file tree, and then the file tree could be
mounted diskless (or synced on a file level) by the machines that have
that profile.

There are other setups people use for this too.

A lot of customers we have really do not have package list profiles,
though; they have one "profile" for the whole company, and only vary the
machines by config file. Important caveat: part of enabling this in most
cases is to provide apps via NFS rather than installing them on each
system, so the RPM package list is just a core rather than all the apps.

But the idea is that any system on the network can run any workload
(workload = service, or even have desktop users log in). You then keep a
central mapping that assigns workloads to specific machines, but you can
change that mapping as required.

This seems like the ideal, while in one sense "profiles" feels like a

2) How can you avoid a separate 'profile' to make small changes.
This is a matter of pulling state out of the OS install and config
files. We've been approaching this by saying there's a toolbox you can
use. Here are some of the approaches in the toolbox:

 - dynamic/automatic configuration
 - look up configuration from a central place, e.g. a directory server, 
   or even a file share
 - write scripts that examine the machine and determine its desired 
   configuration based on hardware, network location, or by looking
   up configuration from a central place
 - move the configuration to be per-user rather than per-computer

So some of this can be done out of the box in the OS; for example for
desktops, NetworkManager helps address network configuration that varies
between machines. A good kudzu helps avoid hardware config in general.
etc. But you'd expect a local site to do some work as well.

Anyway, to the extent that machines can vary by workload rather than by
install profile, so there can be a single install profile, that seems

I'm kind of sleepy so sorry if this answer is sort of muddled; but I
think your questions really get to the heart of what we're trying to
solve here.


More information about the devel mailing list