Fedora Project Considering "Stateless Linux"

Havoc Pennington writes "Red Hat developers have been working on a generic framework covering all cases of sharing a single operating system install between multiple physical or virtual computers. This covers mounting the root filesystem diskless, keeping a read-only copy of it cached on a local disk, or storing it on a live CD, among other cases. Because OS configuration state is shared rather than local, the project is called 'stateless Linux.' The post to fedora-devel-list is here, and a PDF overview is here."

Re:Until they fix the license

[the_mad_poster]

Red Hat is doing quite well on bringing themselves down without anyone else's help.

Looks neat but...

[cato kaze]

I don't see the purpose. Maybe I'm just unitiated, but wouldn't a linux terminal server work better, or perhaps some other solution. This in particular doesn't look that amazing, but I could be wrong. Does anyone out there have specific uses for this? (TFA won't load for me, so I'm going on what I see)

NFS Mount?

[Tony Hoyle]

Haven't Unix machine been doing this for years as NFS mounts? The first sun machines I used (sunos 4.1) has just a single install of the OS and two machines sharing a read only mount.

LTSP

[Eberlin]

Stateless installs? Sounds a bit like the terminal server project. I smell thin clients...are they going into fashion again?

Thin clients WOULD be a blessing, I imagine. Single configuration, one update, all the "personal files" in a server somewhere -- makes for easy updating and backing up. Also keeps hardware requirements down...which [buzzword warning] "helps lower TCO and increase ROI"

mainframe

[celeritas_2]

Unless i've caught a large case of the stupids, it looks like we're heading back to the days of the mainframe computer which many terminals plug into. Is this good or bad or neutral? I think this is a good way to keep corporate/school/etc computer costs down while making sysadmin jobs at least a little easier.

Re:Looks neat but...

[deragon]

Depending of your needs, its better than a thin client, because each user still has his own computer, with all the CPU power, GPU power, etc... for him/herself.

You can still have one user work and experiment on a kernel module and crash his system while another continue with her wordprocessing.

Like Clusters

[deadline]

This is similar to what clusters try and do. It is important to maintain the same OS state on all nodes. Take a look at Rocks Clusters [rocksclusters.org]. Rocks will push the same OS image out to the nodes of the cluster. There is no reason the cluster nodes could not be workstations on a desk.

Re:NFS Mount?

[nzkoz]

If you'd bother to read the white paper or howto (sure, I'm new here) you'd have read that this is more than NFS mounted roots.

It's a framework for managing the servers, cached operation, integrated authentication etc. You can use this framework to manage roaming devices like laptops, allowing automatic install images, etc. etc.

An NFS solution requires network connectivity the whole time, this doesn't.

Re:LTSP

[caseih]

While this could be used for thin clients, most of the pdf actually deals with thick clients. IE laptops who need full installs, and then sync up when part of the network.

This kind of disconnected caching would be excellent. In some ways it's a kind of uber-sync.

What fedora is experimenting will work great on thin and thick clients. I think this is an exciting development, and even for maintaining just a few machines around the house would be nice to have that kind of capability.

Also, I would say that yes, thin clients are coming back into fashion. But thick clients are here to stay also.

Re:Until they fix the license

[tempest303]

Really? Their customers (you know, the people that actually pay for the stuff?) seem to like their licensing terms just fine. [zdnet.com]

Re:I want the opposite!

[runderwo]

I have done something similar to this before. Use debootstrap to install a minimal Debian installation into my home directory, chroot into it, and then install whatever other packages I want to my heart's content. Unfortunately chroot requires root for some reason. If there was a way for a user to chroot, it would be pretty trivial to stow packages in your home directory even if they were compiled for systemwide installation.

heading off the misinterpretations

[grmoc]

First of all, I'm not associated with the project.

However, I've read what they're talking about, and here is where many people are misinterpreting:

This is not a 'thin' client in the traditional sense. The client in this case does the computations.. i.e. it actually runs the app.

In other words, the computer is not merely a display, and as such shouldn't suffer from the traditional mainframe/client shortcomings.. (you have all the CPU power you normally have)

When you think about this, think KNOPPIX and other live-cds, that is the nearest (and quite near, imho) to what they're discussing.

So... why is this different from a normal install?

A normal install has a read-write root, whereas here they're shooting for a read-only root, even if it is still on the local harddrive.

Re:This addresses a real problem...

[Anonymous Coward]

if she can take the laptop home and what not, can't you boot up knoppix and remove the root pastword (copy it first) from the file after mounting the partition. Boot back in with root access, install the driver, and then replace the root password using knoppix again?

If they ask about it (.001% chance) just say that they installed it, don't they remember?

Re:Looks neat but...

[Alien Being]

It's actually a lot closer to Solaris autoclients. [nstu.nsk.su]

Got to love stateless installs

[Trogre]

Heh. I once made a stateless distro, based on Red Hat, on a hard drive. The intention was to use it as a car ogg player.

It had / mounted read-only. /var cannot be mounted read-only (needs /var/run, etc), so I mounted it as a 16M ramdisk, the contents of which was downloaded from /var.tgz at boot time. It worked splendid. Eventually, the slowest part of the boot process was waiting for the BIOS POST to finish.

You could power down the thing whenever the hell you liked and never see fsck run.

The logical conclusion

[The Monster]

I don't see the purpose.

This is just the logical conclusion of the Linux Standards Base, including the File Hierarchy Standard [pathname.com]. Fundamental to FHS is the division of the file hierarchy according to two orthogonal criteria:
A file/directory is either

• Static (not changed except by action of the system administrator), or
• Variable (subject to change at any time

and either

• Shareable (multiple machines can have a common copy), or
• Unshareable (each machine needs a separate copy).

In an effort that is conceptually equivalent to the separation of the kernel tree into architecture-dependent and -independent subtrees for the Alpha port, which made subsequent architectures far easier, a lot of people have devoted their efforts to determining just how little of what goes into the file hierarchy really has to be unique to the machine.

The 'aha moment' comes when you think of groups of workstations with identical hardware, which are candidates for having a common image from which they can be built, and realize that you can build a relational database that correlates MAC addresses (possibly to some other locally-unique but shorter machine number) to the HW configuration. Now, conceptually all of those cookie-cutter-identical machines are a single entity for the purposes of configuration. A lot of what FHS considers 'unsharable' is now quite 'sharable' within such a HW config group.

As workstations age, the IT department brings in a couple samples of the next HW configuration, loads drivers, tests against the app suite, and when they're ready for primetime, the vendor delivers them, the MAC addresses are added to the database, the workstations boot up, find Mommy (bootp server), and Just Work. The user can log out of an old computer and into a new one, and find all his 'stuff' right where he left it. It's the only sane way to compute in an institutional environment.

Local cached copy of filesystem

[dheltzel]

This sounds like a great step forward for laptops as well as desktops that are to be "locked down".

I think there should be a more general concept of overlayed filesystems, where a FS could be mounted on top of another FS "with transparency", so that you can see all the files in the entire "stack". A standard "ls" would show 1 instance of each file, with the "highest level" FS taking precedence. A modified program might be able to see all the versions of a particular file and be able to copy one to another (if permissions allow).

If each FS could be mounted RO or RW, then you could have a local copy of everything on a CD or DVD, but make it appear writable by mounting another FS on top (either a local HD, USB pen drive, NFS mountpoint, etc). Recovering back to the original install would be just wiping out the modified files, so the underlying files are now visible.

This would be good for:
- fully functional Linux systems based of a CD or DVD
- FS snapshots for backup or testing
- intrusion detection (diff across file versions)
- version control of the entire OS image

Now, if only I were smart enough to actually write the code.

Peer OS?

[recharged95]

Could this be the start of a paradigm shift in how we view networks and distributed computing? (So far, nah).

Separate the state from the behavior with respective hardware, sounds interesting. Definitely they will need to break all the encapsulation layers built in todays modern OS and identify the patterns that represent common behavior and common state.

In the article, it makes me wonder, is it better to centralize state or behavior? For instance, centralizing state would be more efficient, but if state was local, you truly own your data (just unplug the network connection). Also, doing the reverse, well, that's pretty much near a basic terminal.

To me, it sounds like java webstart or rio without the fat OS lying underneat it (which is good).

Interesting project

[GolfBoy]

This is a very interesting project. As I understand the article, the point - long term - of the development effort is to try to get Linux (RedHat) adopted on the desktop by appealing to the TCO mentality of the IT department rather than by appealing to the desire of the end user to actually get stuff done. In other words, if the savings to IT of administering your machine centrally outweighs the benefits of you (corporate cube dweller) being able to configure your machine to your liking and use it as you see fit, then IT wins, and Linux makes an appearance on the Fortune 2000 desktop.

'Thin client' was the first attempt to dethrone MS in this way, but this approach appears much more sophisticated, and consequently much more likely to succeed. Without seeing how the whole thing plays out I really have no idea whether the approach is successful or not. But it's a really nifty shot across the MS bows.

Whether this goes anywhere or not ends up being decided by (as with most IT projects) whether the services provided by IT to the end users are adequate (in which case IT gets their way) or so obnoxiously limited that the end user cabal ends up storming the IT department with burning torches.

What? You couldn't do that before?

[Anonymous Coward]

Besides the fact that people have been doing this sort of thing for years, how about we misapropreate some more computer science terms for linux projects? I mean I thought I was going to have to be typeing in cookies into my shell or something.

So how about?

contiguous linux? For the AIM users you know
RTFM linux? Also for the AIM users you know

Or maybe the ultimate:

Goto considered harmful linux? For the masocist in all of us.

God forbid someone can acctually come up with a name.

Re:mainframe

[Martin Blank]

But what about costs? I can buy 100 workstations, monitor included, for about $65K. How much does a dual-server setup (including terminals) for 100 users cost?

Part of the problem is that while I don't trust users to keep their machines running properly, I barely trust a lot of server admins to do any better. I've seen the way a lot of servers are put together, and how often they need some really inane maintenance. It's scary. The penalty for a bad user is usually limited to affecting one or two people; the penalty for a bad admin can affect entire departments or even more.

The DRBL (Diskless Remote Boot in Linux) project

[stevenshiau]

Hi... We run a project called DRBL (Diskless Remote Boot in Linux) . The website is
http://drbl.nchc.org.tw (Traditional Chinese)
and
http://drbl.sf.net (English).
Maybe someone can have a look at that, some part of DRBL are similar to this Stateless Linux project.
DRBL runs well on RedHat, Fedora, Mandrake and Debian.
In Taiwan, more than 100 sites already downloaded and run DRBL, some of them are schools (Primary/High school/University), some of them are NPO and buisness companies.
check this:
http://drbl.nchc.org.tw/sites/98_DRBL%A8%CF %A5%CE% AA%CC%A4%C0%A7G/DRBL%A8%CF%A5%CE%AA%CC%A4%C0%A7G_2 0040820.pdf

Also, there is a program comes with DRBL called "Clonezilla". It can let people to massively clone the system image to the harddisk of client computers. The function of clonezilla is quite similar to the Symantec Ghost Corporate Edition®. For more information about clonezilla, check this:
http://clonezilla.sf.net (English)
and
http://drbl.nchc.org.tw/clonezilla .php (Traditional Chinese)

Looks like OsX

[curious.corn]

Although I've never used it, a Domain of OsX machines can mount and boot from remotely networked disk images. Also, a standalone machine (like a laptop) participating to an Apple directory will authenticate against the server providing "terminals" for domain users not present on the machine's local credential database. Domain accounts can be coupled to local accounts available when unplugged from the domain. Save for the first item I've experienced the setup and found it very simple to configure & use. The only kludge is the use of traditional UNIX perms (ugo) that doesn't quite fit the picture. Tiger should take care of that next year. I hope RH etc will make their system "drop in" compatible with the Apple solution (basically it's openldap); the only problem is that consumer i386 HW only has chesy BIOS rather than openfirmware which I think is used to simplyfy the remote booting configuration process.

It's been done...only it runs on any distro

[nagare]

We've been running linux clusters like this for years and have recently released the software for doing it. The software is called oneSIS (http://onesis.sourceforge.net/ [sourceforge.net]). This does mostly everything it looks like the fedora stateless project aims at doing:
- Read-only root NFS
- bit-for-bit identical root filesystem
- local disk cache (if desired)
- fine-grained control of independent node/role behavior
- mkinitrd (only better, IMHO)

However, it supports more than Fedora. Currently supported are redhat,fedora,suse,gentoo,and debian.

I've kept it pretty quiet so far, but I guess now might be the time to go public.

I really don't see the point

[codepunk]

I am currently running 200 workstations in a thin client environment and we really could not be happier. Not to mention that those 200 are running of a single redhat cluster with nearly 100% uptime for the year. What possible benifit am I going to get over my current environment? Our clients are a mixture of junk we got from a recycler, cdboot from a hacked slax distro or flashboot mini-itx boxes. Total maintenance time per month is measured in mere minutes. And no I am not running LTSP, to complex and I can just buy neoware boxes already configured as a redhat x terminal.