[Server-devel] xs-activation and OS update info

[Daniel Drake]

Hi,

Here's a patch that makes xs-activation server OS update information
based on what it has available in xs-rsync.

I had to add one significant piece of glue: since the OATS
conversation only deals in terms of version hashes (not version
numbers), the XS needs some extra source of info to know that one
particular OS version is newer than another. I did this by creating
/etc/xs-activation-updates.cfg, a sample configuration file with
explanation is attached. This is code from oatslite which is deployed
in paraguay.

Please consider for inclusion.

Daniel
-------------- next part --------------
# a file with the format indicated below will be used by xs-activation to
# figure out when to advise a client of an OS update

# this file lists all of the known OS releases in the deployment, in age order
# oldest first, newest last (the order is very important).
# The entries below are just examples.

# Here's an entry for the release that was installed on the laptops when they
# were deployed. Even though we'll never advise an update to this version,
# xs-activation still needs to know that it is OLDER than any updates that you
# list below, so this must be put at the top.
[bbcd2c7ef7dc30e68f06a28ddaa23120fb587808d397e46f5b0970095d3d99c6]
name = os73

# one classroom in this school was deployed later, with a slightly newer OS
# version. we have to list this one too. listing these "old" OS versions is
# very important, even though we have no intention to store these OS versions
# on the XS: if the XS does not have any record of the sofware version being
# run on an XO then it will *never* offer any OS updates. this is because
# the XS cannot possibly know whether the "unknown" XO OS version is newer
# or older than the OS versions that are stored on the XS.
[68bfd9142727e2aafa038863debeb0c12ae4116beff15e39fd181e8afb3e37ea]
name = os74

# finally, below, we add an entry for the newest OS version which we want to
# offer as an update to the versions above. for this to happen, you must
# load this OS into XS-rsync in addition to adding the entry below.

# the name of each section is a unique hash that represents this OS release.
# it's a bit like a checksum of the whole filesystem.
# To determine the hash for a given OS build, run this script on an XO that
# is running the build in question: 
# http://dev.laptop.org/~dsd/20090521/versionhash.py
[4700589ea9599e94840c53ccb6aabe93c3673c4ea7baa8cc52848816c69c85fa]
# NAME
# This field is what bridges xs-activation to xs-rsync. xs-activation will
# peek into xs-rsync's xobuilds store, and if it finds one with this exact name,
# then it will be offered as an update.
#
# for the entries where we are simply providing information about which version
# is newer than another (e.g. os73 and os74 entries above), the "name" field
# is optional, since we don't plan to load these builds into XS-rsync. however,
# it's a good idea to include it anyway, for the sake of readability. otherwise
# you might come back in 4 weeks time and have forgotten that 68bfd9142727..
# is the version hash for the os named "os74"
#
# so, this entry will cause xs-activation to consider offering os77 as an
# update if it can find /library/xs-rsync/pub/builds/os77
name = os77

# PRIORITY
# low = never applied automatically, only when requested manually
# normal = upgraded automatically and applied when the user reboots
# high = upgraded automatically and system automatically reboots to apply update
#        immediately
#
# this field is optional and is only ever used when xs-activation is able to
# offer this OS as an update (i.e. it is newer than the OS running on the XO,
# and it has been loaded into XS-rsync). the default is "normal" if unspecified.
priority = normal 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xs-activation-os-updates.patch
Type: application/octet-stream
Size: 77181 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/server-devel/attachments/20091025/f8071e57/attachment-0001.obj