On Mon, Jun 1, 2009 at 5:54 PM, Caroline Meeks <carol...@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.langh...@gmail.com mar...@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel