[Server-devel] Mass deployment thoughts

[Daniel Drake]

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