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.
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 firstname.lastname@example.org.