On Thu, 2004-09-23 at 11:31, Alexander Holt wrote: > LCFG can be used to control any category of machine. > [....] > (*) Mobility -- and disconnected operation -- is an important > architectural constraint. [....] > > (*) The central location that stores client state doesn't ultimately > have to be a central location. [....] LCFG does indeed sound like a highly capable configuration deployment engine (how does it compare with cfengine, in your opinion?). I believe there are several key differences, however, between the approach that a configuration deployment engine uses, and the approach that oneSIS takes. Any configuration engine (LCFG and cfengine it seems at least) centrally manage clients by shipping/creating configuration files to each client, which can then act independently from the server. Each client potentially has its own singular configuration, and every client potentially differs from every other. With oneSIS, every client is always bit-for-bit identical with every other client. Independent configuration is done by editing the config files for the particular node/class (ie: /etc/fstab.myclass), making administration of a large group of machines a natural extension of administering a single machine without the need for a configuration language. When the rootFS is guaranteed to be bit-for-bit identical, every (diskful) node can in turn serve its root image to any number of other client nodes. This can be used to create a hierarchical tree where every node remains bit-for-bit identical with the server it synchronizes from, and each (diskful) node can operate stand-alone, disconnected from the network. Any diskful node can mount its root filesystem read-write if desired, with the knowledge that any local changes will be lost if it fully synchronizes itself with its master (bi-directional sync is a no-no). Every node is exactly identical, with the node's configuration determined at boot-time. This means any node can essentially 'become' any other node simply by rebooting (though there are plans to extend this to allow run-time re-configuration). The most striking benefit though, in my opinion, is the ability to boot any machine 'diskless' into the exact same environment as the diskful nodes. Client machines don't even need to have a disk to boot into the system. However, a client node with a local disk (a laptop for instance), can boot into a diskless environment without affecting its own local OS installation in any way. This would be desirable for those who don't like to have others control the OS on their machine. The user can afterwards reboot back into his/her own local OS and resume life like normal. Everything is completely stateless. When collaborating with visitors with their own laptops, a single root image can be exported for everyone to run in (diskless) for the duration of the collaboration, and then they can return to their own OS setup by rebooting from their local disk. Alternatively, any single machine can deploy (or just copy) the image to a local disk, move it anywhere, and export it to an number of client nodes in turn. There are several other benefits of diskless operation (ie: instantaneous updates) that make it very attractive. oneSIS only handles the management/deployment of a master root image. The behavior of the machine is near-indistinguishable from a normal Fedora installation. It is simple in design, and IMO astoundingly easy to administer a oneSIS system (everything is identical!). The bootstrap mechanisms in place (initrd generation from a template) provide a framework for creating unique (key-based/Kerberos ?) methods for authenticating client nodes if desired. The probably not suited for every conceivable environment, in all I believe oneSIS can be an excellent starting point to accomplish the goals of the "Stateless Linux" project. -JE ----------------------------------------------- Josh England Sandia National Laboratory, Livermore, CA Visualization and Scientific Computing email: jjengla@xxxxxxxxxx phone: (925) 294-2076
