Distribuir nueva OS

De Paraguay Educa
Saltar a: navegación, buscar


Underlying technologies

  • XS-rsync for making builds available from the school server
  • Theft deterrence protocol (OATS) for advising the XOs of available updates from their school server
  • olpc-update for automated download of the update from the school server

Building the image

Construir OS details the build procedure. The required outputs of that process are:

  1. the -tree.tar.bz2 archive of the filesystem
  2. the -tree.tar.bz2.md5 checksum
  3. the .contents file

A .name file must be made, with the same prefix as the -tree.tar.bz2 and checksum. For example, create py801-2.name to go along with py801-2-tree.tar.bz2. Set the contents of the file to the same name e.g. "py801-2" in this case:

echo py801-2 > py801-2.name

To summarise, for our hypothetical py801-2 update we now have:

  1. py801-2-tree.tar.bz2 from image builder
  2. py801-2-tree.tar.bz2.md5 from image builder
  3. py801-2.contents as produced from image-builder
  4. py801-2.name consisting of the string "py801-2"

Distributing to servers

Place the 4 files for the OS update at /usr/share/puppetcontent/os on the mothership.

Every day, the puppet clients on the school servers will rsync these files and update their local OS build repositories accordingly. The OS update will then be available to XOs through olpc-update.

Advising XOs of the update

After giving sufficient time for the new build to be synchronized onto the school servers, the XO laptops must now be informed of the availability of the update. Approximately once per day, each XO queries the mothership asking for information about OS updates (and new leases). oatslite runs on the mothership and serves these requests. oatslite simply advises the clients of the availability of an OS update from their local school server, it does not actually provide the updated OS image or ensure that installation was successful.

oatslite has a configuration file describing which updates are available and the conditions in which they should be offered to clients. You need to add a new entry to the configuration file describing the new update.

First, you need to determine the unique hash of the new OS image. Probably the easiest way to do this is to copy the .contents file (from above) to an XO, and then follow the following example for py802-1.contents:

$ python
Python 2.6.2 (r262:71600, May  7 2009, 08:45:46) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from bitfrost.contents.utils import UnifiedContents
>>> UnifiedContents("py802-1.contents").contents_hash()

You also need some other information:

  • The name of the OS update, this is what you put in the .name file ("py802-1" in the example on this page)
  • The rsync:// URL of this build on the school server, which can be formed by prepending "rsync://schoolserver/build-" to the name.

This should be enough for you to configure oatslite to offer this update. See the oatslite documentation and updates-sample.cfg file for more information on how to do this. On our setup, the updates config file is at /home/oats/oatslite/updates.cfg, and here is a sample entry (to be added *below* all older versions) for the update in question.

name = py802-1
priority = normal 
update_path = rsync://schoolserver/build-py802-1

Remember to restart the oatslite service after making any configuration file changes.


  • Activities are not part of the OS image and do not get updated in this process. The closest thing to an automated activity update is the activity updater from the control panel which is easy to invoke.
    • However, we could implement an automatic activity updater as part of the OS, and then use this mechanism to automatically roll out that new OS as an update.
  • This update system works fine for minor upgrades: even though 2 OS images are stored on disk at any one time, only files that differ are stored twice (the rest are shared). However, this does not scale for large updates where many files would differ.
    • To fix this, first a more-intelligent update system needs to be implemented. After that is implemented, push a new minor OS update including the client side of the new update system. Then the new client-side update will execute, performing the major OS upgrade in whatever sensible fashion.
  • There is approximately a 16mb overhead (to the XO NAND) to every update that you push (even if only 1 file changes), due to the mass of hardlinks that olpc-update creates to implement the update system.
    • However, there are only ever 2 OS versions kept on the system at any one time (the older one is purged when a new one comes along) so this overhead is capped