Autoinstallation/customization functionality.

C. Scott Ananian cscott at
Tue Feb 12 19:12:50 EST 2008

Here's a brain dump of functionality for deployments (like, perhaps,
Peru) which would like to customize their builds on a large scale.
I'm assuming that the cheapest way to do this in the extremely short
term is by inserting a USB key into each machine and have some things

 a) autoinstallation of library bundles.   relatively safe; can have
different USB keys w/ different bundles for different grades, etc.  We
assume that school deployments (at this point) have access to at least
one USB key.  (not unreasonable for the short term.) ( )

 b) autoinstallation of activities. a little less safe, but activity
isolation makes it reasonable, especially for near-term deployments.

 c) autoinstallation of dev keys / activiation keys.  always safe,
required if we deploy limited-time activation leases. ( )

If you're going to install these things on 500 machines in a school,
having to mouse through the journal is probably unacceptable.  Some
implementation ideas:

 a) there's a callback function after devices are mounted, which can
easily be used to run post-mount hooks to do quick+dirty

 b) Content should live in /home or /security so it persists across updates

 c) Installing large content bundles via the journal may be
impractical if you have to store multiple copies of the content (one
as .xol, one unpacked) ( )

Michael and I have been brainstorming mechanisms for automatically
customizing a build with RPMs, intended for *developers* (not
schools!).   See .  My personal use
case: I want to create a 'joyride' stream which will automatically
ensure my laptop is always running the latest joyride, but ensure that
git and emacs are always installed.
                         ( )

More information about the Devel mailing list