Upgrades and image manifests

[Dan Williams]

On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote:
> Hi, 
> 
> My name is Alexander Larsson, and I just started working on the field
> upgrade system of the olpc laptops. I have some ideas I'd like to
> explain and get feedback on.

One more thing :)

I'm sure you know, but something people haven't brought up in the whole
updates discussion yet is the whole picture.  It's not just about the
mechanical process of getting updates from point A to point B, since
that completely forgets the users who's XO we're trying to update.

It's critical to give some user visibility into the update process.
While the tool needs to be resilient against users moving around and
downloads timing out, the user also needs the _ability_ to see what the
tool is doing, even if the UI or the user don't always want to or care.

Sugar may want to notify the user when an update starts so the user
knows why their machine is now slower, and why their WLAN light is
always on.

We should have at least the ability to do the Sidekick thing and allow
the user to postpone certain updates, but after a week it gets applied
automatically.

We may want to show the progress of the update, to give users visibility
into the process and when to expect it to get done.

We need to notify the user than an update is done, and we would suggest
that they reboot (possibly based on a metadata flag in the manifest for
"suggest-reboot=yes").

The update daemon must provide a fair amount read-only status
information before and during the update process to allow the GUI bits
the flexibility to present that information to the user in the way it
sees fit.

In the ideal world, that means a D-Bus service that sends signals at
various stages and has methods Sugar can call to get more information
about the update process.  However, that links in more libraries and
adds vulnerability window to a critical piece of the system.  So in that
sense, even though a D-Bus server model is a very good one from an API
point of view, perhaps the most responsible method would be simple text
files that Sugar can inotify and get the required information.

Oh, and we should probably rate-limit or connection-limit the local HTTP
server that's serving updates so we don't hammer one particular XO.
This could mean putting an _advisory_ "try-me=true/false" flag in the
mDNS advertisement that we switch depending on the current connection
load.  The server would obviously still boot users if there were too
many connections, but at least using the 'try-me' gives other laptops
more information about whether they should try to connect right away, or
try a different XO that may advertise the same blob.

Have you thought about what information the mDNS record would advertise?
In the best case, it's as large of a UDP packet as we can push out.  And
since we can probably deal easily with packets up to the wireless MTU
(which is something > 2000 bytes), there's more room than the
traditional 512 byte UDP packet.  However, the space in the mDNS
announcement is not unlimited, so I don't think we could put the entire
blob list in there :)  There's certainly enough room to put a build
number, HTTP server port number, manifest hash, etc.

Dan

> The olpc uses a full-image system, as opposed to the per-package
> versioning scheme of deb or rpms. So, an upgrade consists of replacing
> your system files with a full copy of a later (or earlier) version of
> the system image. We want to support both upgrading from a central
> server or from another laptop, and we want to minimize the data we have
> to download for an upgrade.
> 
> To support this we create a manifest that describes each image, and we
> save a copy of the current image manifest installed on the laptop. The
> manifest format is very similar to the git "tree" object, and describes
> each file by listing name, metadata and sha1 hash value of the contents.
> 
> Here is a small example:
> ---------------------
> link 777 500:500 foo bar
> blob 664 500:500 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 changed.txt
> blob 664 500:500 65ef9261ad6cfaa8403f2fa66d8edfada1445e5a common
> blob 664 500:500 f660633c832712eba3c6edd39151987e46bc3f87 image1.txt
> blob 711 500:500 empty logfs.pdf
> dir 775 500:500 subdir1
> blob 664 500:500 empty subdir1/file1.txt
> blob 664 500:500 7448d8798a4380162d4b56f9b452e2f6f9e24e7a subdir1/file2.txt
> -------------------
> 
> Given a manifest for the current image and a manifest for the image to
> upgrade to it is very simple and cheap to calculate what changes you
> need to make to transform the image (on the client), and what sha1 blobs
> you need to download. You can then download the file blobs from whatever
> source you have (they are self-verifying, since they are named by the
> sha1 hash of the content) and do the upgrade.
> 
> It is very simple to host the blobs. We just put them all in a directory
> named by sha1 and export that with a http server. One can also host
> multiple versions of an image in the same directory, while minimizing
> the space used for common data. (Possibly one might want to gzip the
> blobs too.)
> 
> I've written some code (attached) to generate and manipulate manifests
> like these. There are three tools:
> 
> * generate-manifest: This generates a manifest files given a path to a
> directory containing the image tree. You can also make it populate a
> directory of sha1-named blobs by giving it a blob directory with -b.
> 
> * diff-manifest: Gives a simple visual diff between two manifests. If
> you pass it -b it will instead give a list of all blobs required to
> update between the two manifests.
> 
> * upgrade-manifest: Updates an image from one manifest to another, given
> a path of a directory with the required blobs.
> 
> Using these tools I upgraded from
> olpc-redhat-stream-development-build-406-20070507_2141-devel_ext3-tree
> to olpc-redhat-stream-development-build-406-20070507_2157-ext3-tree in a
> directory on my development machine, so it seems to work so far.
> 
> For finding and downloading updates I was thinking of using avahi to
> publish the image id + version, and then downloading the data and
> manifests using http. That way that clients can detect machines around
> them with later versions and auto-download (and apply automatically or
> later). The individual laptops can publish the version of the image they
> are using, and a school server can publish several versions. From the
> point of view of the individual laptop searching for upgrades they will
> look the same. Of course, we'd have to sign the manifests with some key
> to make sure you can't just auto-upgrade any machine to a rouge image.
> 
> Now over to the questions I have:
> 
> I'd like to put this code in a repository somewhere. Where should I put
> it?
> 
> Does OLPC use selinux or xattrs? Because if so we have to extend the
> manifest format.
> 
> We need a library to do http downloads. I see we're shipping libcurl on
> the laptop. Is it ok to use this library? 
> (We also need a very simple http sever that maps sha1 -> file in system
> image for laptop-to-laptop upgrades, but I think we can do that without
> using a library.)
> 
> Is using avahi/mDNS on the mesh network ok?
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel