Stateless Linux is not a deployment model. It is not any single technology. It's a new way of thinking about how a system is supposed to run and be managed.
To be stateless, a system should be able to be replaced at any time, whether it's running diskless or with local storage. Hard drive crash? Just resync your remote image to a new drive, and you're good to go. Server goes offline? Start a new virtual instance running your OS image off of your network storage.
Moreover, it's about being able to run multiple machines from identical OS metadata. Instead of managing each machine independently, the single copy of the OS metadata is managed.
For more information, you might want to view the Red Hat Summit presentation .
Mailing Lists
The place to discuss Stateless Linux is stateless-list . Discussion can also take place on fedora-devel-list .
Usage Cases
Many usage cases can benefit from a stateless approach:
- Server usage: a farm of machines instantiated and updated via a single copy of OS metadata
- Virtual server usage: same as above, but they don't even need to be physical machines
- Corporate desktops with local storage - stateless images are instantiated to a local disk from shared OS meta and run from there. This includes desktops (local swap, read-only root, and network homedirs) and laptops (local swap, read-only root, and local homedirs that need synced back to centralized network storage for backups.
- Thin clients using NFS root, with or without local storage for swap, scratchpad, etc.
- LiveCDs - a live CD is by definition stateless
Component technologies
Currently we're working on stateless enablers, that allow administrators to deploy machines according to a stateless model.
We have changes that affect how the OS runs its root filesystem:
- Read-only root support - all the system partitions are mounted read-only
- Root can be on a local disk, NFS, NFS loopback or iSCSI
- Temporary areas can be on a local disk, tmpfs or NFS storage
- Files/directories which must be writable for proper operation are either bind mounted or provided via unionfs backed by the temporary storage areas
- Any of these can be deployed with Xen to be used in a virtual environment
- Persistent state (such as SSH keys) is managed by
puppet. Effectively this allows the master copy of persistent state to live and be managed on the server and be cached on the stateless client.
We have changes that make it easier for multiple different computers to run a single OS image:
- Automatic hardware configuration that loads all relevant modules at boot
- Automatic configuration of X, including monitor and input devices
- Network and printer configuration for desktops that doesn't need the root password
We're also looking at certain areas for the future:
- The ability to have a network-based image automatically synced to a local disk to enable disconnected mode.
- The ability to sync local disk back to the server (/home for disconnected laptops)
- The ability to use local disk as a persistent cache for network filesystems.
- The ability to update clients by modification of shared OS metadata
How do I test and deploy stateless images?
See HOWTO.
Not currently covered
Things we specifically aren't targeting:
- configuration and management tools for images
- changes to applications configuration mechanisms for getting configuration data (such as switching app configuration from local files to LDAP)
- stateless-specific provisioning tools
The current working assumption that anything we would do in this space:
- would be rushed and incomplete in the time needed to make FC6
- would not work with current or future management tools without changes
- would not integrate well into users' current management frameworks
Hence, these spaces are best left to development in the context of the future management system. What we're concentrating on for FC7 is the basic infrastructure.
FAQs
1. How do I make my app work with stateless?
Generally, if it avoids writing to the root filesystem, it should be OK. For configuration, we're doing configuration on the raw source images themselves (whether via chroot, via booting the image in Xen, or various other methods); this means that config files should be OK, as long as you're not expecting the client systems to write to them.
2. What architectures are targeted for this?
- Initially: x86, x86_64
- Additional arches if time permits: ppc
Server architecture only matters in that if you are modifying a (for example) i386 stateless image, whether by chroot() or Xen, you will need to do this from an architecture that can run i386 binaries.
3. How does this interact with SELinux?
SELinux should work without any significant modifications, provided the underlying filesystems support it. (This is not currently the case for NFS, or for the various filesystems used by LiveCDs.)