I've been thinking about automating larger deployments as well, though more
the initial install than subsequent updates. As an experiment I put
together a cobbler installation server on FC12
(https://fedorahosted.org/cobbler/) and use etherboot
(http://etherboot.org/wiki/index.php) to boot the target XS into the PXE
environment from which a default installation proceeds automatically using a
kickstart file and repos on the install server without user input.
The idea would be that for installations involving more than a few machines,
a switch could be set up such that as many machines as there are ports on
the switch can be installed at the same time by having them boot from the
install server.
The advantages I see for setting up XS servers is that the only boot media
required is for the PXE, which never changes with changes to installation
files, and it can be removed and used to boot another machine as soon as the
initial connection to the installation server is established.
The kickstart file, the repository, and any libarary files can sit on the
installation server and can even be mirrored from other repositories.
There is also integration between cobbler and puppet, though I haven't
experimented with this. Some have used cobbler to push out the puppet
client install
(http://number9.hellooperator.net/articles/2009/04/13/bootstrapping-puppet-from-cobbler),
and cobbler has strategies for integration with configuration management
systems such as puppet
(https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem).
I do still have one problem that I'm trying to solve, and that is that at
times eth0 and eth1 get reversed on the XS either during or after
installation. This can prevent the install from completing if during, or
can mess up the networking if after (the script to swap nics doesn't fix
it). When the boot nic remains eth0, the install completes, and I just have
to run the olpc script to set domain name. I'm working on adding the
copying of library files from the install server to kickstart.
Tim
>
> Message: 1
> Date: Mon, 10 May 2010 11:55:06 -0300
> From: Daniel Drake
> Subject: [Server-devel] Mass deployment thoughts
> To: XS Devel
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
