[Sugar-devel] What is the vision for software update?

[Martin Langhoff]

On Mon, Jun 1, 2009 at 5:54 PM, Caroline Meeks
<caroline at solutiongrove.com> wrote:
> We are working on making software update (both activities and underlying OS)
> work for Sugar on a Stick and we aren't that clear on what the vision, spec
> and state of code is for software update on the XO.

Right -- it is a major consideration, and a very hard engineering
space. The solutions on the current XO + XS OSs work but there's
significant room for improvement. It's not easy however.

As Martin Dengler points out, we have Activities handled separately
and completely differently from the 'OS' (which covers base OS +
Sugar):

 - Activities use the .xo format. The 'upgrade server' scheme is over
http and trivial. XS serves it. There are no hooks in Sugar/XOOS to
trigger automatic activity updates from a server (local XS or
central), except right after a new OS update.

We have seen discussion in this area about "user" rpm packages
replacing .xo packages. The original rpm specification talks about
them, but it's unclear if support for it is complete. Search the
archives for abundant flamefesting on this topic :-)

 - OS upgrades avoid using rpm & anaconda, and use instead
olpc-upgrade which performs some clever tricks with rsync, mountpoints
and bind-mounts. The XS can serve the specially laid-out rsync
'images' over wireless. This can be triggered on the XO OS through the
'oatc' (antitheft) facility.

The "antitheft" protocol serves several things to the XOs, roughly:

 - am I stolen?
 - can I have a lease to keep running?
 - what's the time?
 - my os version is X, anything new for me?

All of the messages above are signed cryptographically.

It might make sense for SoaS to include most (all?) the userland code
that implements this. We've already had discussions about synthesizing
a 'uuid' and 'serial number' on non-XO machines. Perhaps it'd make
sense to add...

 - a tiny bit of abstraction in the uuid/sn reading code, so that a
deployment team that has other "known" hardware can hook up a tiny bit
of code to read the sn properly from their hardware (instead of
calling rand() )

 - docs on how to create appropriately formatted keys, install them on
the Sugar machine and use them (replacing bitfrost/leases/keys.py) so
that the clients know to trust only messages signed with the
appropriate key

This would mean that the SoaS machines can poll the server for update
instructions without risking getting a bogus upgrade instruction
pointing to a trojan OS. All the "antitheft" bits won't work (unless
further work is done) but you can reuse the code safely.


One question for SoaS is: Does it make sense to use olpc-update?
Upgrading the OS in machines' disks in the field with rpm/anaconda is
hard and extremely brittle. olpc-upgrade has some issues -- it doesn't
run any pre or post script of any rpm package -- but it wins big in
disk space requirements and robustness.

So if SoaS gets installed on the internal drive, olpc-update is a win.
This may merit a revisit when a snapshot-able FS is usable on Linux
(btrfs). For SoaS used literally on a stick, the 'upgrade path' is a
completely different world :-)

> Is this code written for the
> XS+XO or speced and not yet written or wished for but not yet speced?

Almost all the code is written, and I'm finishing parts that were
missing in the next 2~3 weeks.

hth,


m
--
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff