On Wed, 2007-03-07 at 14:02 +0000, John Hodrien wrote: > So if we're running fully stateless clients, how does puppet work? > > Is the answer "it doesn't"? My currently understanding of puppet is far less > than I'd like... Stateless clients have two writable areas available to them. One is scratchpad area and does not persist across reboots (implemented via tmpfs), the other is an (optional) persistent storage area.
By using bind mounts and union filesystems we're able to make selected parts of the client's readonly root writable, with the changes being backed by either the persistent or non-persistent client storage. During the boot process, after setup of the union and bind mounts, the client contacts the puppetmaster to download any configuration information appropriate for the client. The difficulty with this in a "fully stateless" environment is that the client has no way to provide a persistent identity to the puppet server. Clearly having a "fully stateless", puppet managed system is nontrivial, particularly if security is of any importance. For that reason I strongly recommend having some way to for the client to persistently store its identity, whether that be on a local disk, USB key, NFS directory, whatever. Once the client can store its key in a persistent manner, the client can easily allow the puppet master to control the client's configuration. Also note that without some form of persistent storage you can get into situations where you lose data. Consider mail or print spooling as an example. If the client reboots while mail or print jobs are in the spool directory and the client has no persistent storage, then those jobs will simply be lost into the ether. If the client has some persistent storage, then those jobs will be flushed out of the spool directory when the client comes back up. Out of curiosity, what are you trying to do with stateless? Jeff _______________________________________________ Stateless-list mailing list [email protected] http://www.redhat.com/mailman/listinfo/stateless-list
