Stateless Linux Strikes Client Balance

 
 
By Jason Brooks  |  Posted 2004-10-04 Email Print this article Print
 
 
 
 
 
 
 

Red Hat's Stateless Linux scheme aims to centrally manage all users, whether they are connected or not.

There's no question that tight, centralized management of desktop systems can deliver companies shortened deployment time, simpler system patching and more predictable performance. Featurewise, thin clients fit the centralized management bill by locating the operating system and all user data on a shared server, but this model isn't always feasible. For instance, thin clients rely on constant network connectivity, so the model breaks down for mobile users.

Red Hat Inc. recently announced a project to provide a centralized management solution for connected and disconnected users that provides administrators with tight control over the systems they manage, using the same tools for connected and disconnected users.

The project, called Stateless Linux, strikes a balance between thin and fat clients. Applications run locally, taking advantage of the processing power that already is well-distributed across most companies desktop computers and eliminates the need to buy additional server hardware to handle thin-client processing workloads. (Go to listman.redhat.com/archives/fedora-devel-list/2004-September/msg00575.html.)

However, the root directory of a Stateless Linux client-which contains the operating system and systemwide configuration files-is mounted at boot time as read-only, so the system remains fixed as its administrator configured it.

For a fixed workstation with reliable network connectivity, an administrator could deploy a Stateless Linux system to run in a diskless manner, booting over the network via PXE (Preboot Execution Environment), connecting to shared-root and user-specific home partitions stored on a server.

In a disconnected situation, such as that for a laptop user, administrators can deploy Stateless Linux systems to operate in a cached mode, in which the machine operates from its local storage, but files and user-specific settings from the home directory are synchronized to the network when the user reconnects.

Stateless Linux is still in the prototype phase and will first appear in Red Hat's community-supported Fedora distribution before it makes its way into the company's commercial products.

Click here to read Labs review of Fedora Core 2.

However, Red Hat released packages and a nice how-to document along with its Stateless Linux announcement, so eWEEK Labs was able to try it out. We found the system is still a bit rough around the edges, but companies now running or considering running Linux on a portion of their desktops would do well to check it out for themselves.

We tested Stateless Linux with two systems running Fedora Core 3 Test 2-one to create and serve the prototype installation that we'd push out to our test clients and another to serve as a model for that system.

Once our prototype system was configured on our server, we could update and otherwise modify the system using the chroot utility and Fedora's included software update tools. We then used a graphical tool included among Red Hat's Stateless Linux packages to freeze the prototype into a snapshot that was ready for us to deploy.

We configured an LDAP directory to store information about our prototype system and the MAC (media access control) addresses of the machines to which we'd push out that prototype. From there, we could boot over the network into a snapshot we'd created or use a modified version of the standard Fedora boot image to create a cached client.

Stateless Linux systems deployed in cached client form contain two root partitions: one mounted as read-only, which contains the operating system and applications; and another that sits in reserve to synchronize with changes made to the snapshot. If a system's assigned snapshot changes, the client will swap to the changed root partition upon rebooting.

We could create a live CD version of our snapshot, which worked the same way as bootable CD-based Linux distributions such as Knoppix. The live CD option would be a good way to test a system configuration on different hardware. A live CD would also be a good fit for letting users test a configuration on their machine without disturbing the operating system and without requiring the network access needed by the diskless configuration.

Senior Analyst Jason Brooks can be reached at jason_brooks@ziffdavis.com.

Check out eWEEK.coms Linux & Open Source Center at http://linux.eweek.com for the latest open-source news, reviews and analysis.

Be sure to add our eWEEK.com Linux news feed to your RSS newsreader or My Yahoo page

 
 
 
 
As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. Jason's coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at jbrooks@eweek.com.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...

 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel