Just a small braindump... With my experience on deployments I'm finding that customizing and adding more functionality/content to the XS is not a one-time thing, it's something that happens more and more over time.
For this reason, the kickstart-based method of XS customization does not feel so great for field usage, at least to me. (plus this method has its own quirks, especially in F9). You're restricted to making customizations at install time. For example in La Rioja we've already closed in on a "final ISO" but they already know they are going to be adding more functionality within the next few weeks - including a web filter and a content library. And we're left with the options of making the changes manually on each already-deployed XS (perhaps scripting some of it) or simply reinstalling the whole XS on each iteration - neither of which are particularly appealing. When I was in Paraguay we took a different approach - we scripted all the customizations using Puppet, without touching the XS iso. http://www.puppetlabs.com/ The installation process is then: 1. Install XS as normal 2. Set hostname 3. yum install puppet and exchange keys with local puppet server 4. Wait 10 minutes (puppet installs the customizations) 5. Turn off and ship XS to school The big advantage that follows is that the puppet client continues to run (forever) on the XS, continually phoning home to the master puppet server in the central office, looking for updates to the configuration and applying them. So as the inevitable incremental development continues, all already-deployed XS receive the new developments. And it's one of those systems that gives you the "wow, this is both neat and complete" feeling after you spend a couple of hours with it. Thanks to the key exchange it also provides a nice secure channel for synchronizing files (e.g. activations/delegations). Personally I feel that this model makes a lot more sense than kickstart customizations since it embodies the fact that you never finish configuring your server. Of course it's not perfect: - it is connectivity-based; post-deployment customizations can't be done for unconnected schools (remains a problem as it would do with a kickstart-based approach) - another language/interpreter (Ruby) to run on the XS - no big deal, but am sure Martin will have a comment or 2 on this :) - writing Puppet configuration needs to be done with care - at least when I was in Paraguay a year ago, the file transfer channel was base64 encoded making it inappropriate for large files (e.g. synchronizing xs-activity-server) but fine for small ones (e.g. activations) - requires infrastructure in central office Daniel _______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
