XO in-field upgrades
kantrn at rpi.edu
Mon Jun 25 15:56:05 EDT 2007
C. Scott Ananian wrote:
> On 6/25/07, Noah Kantrowitz <kantrn at rpi.edu> wrote:
>> It is worth noting we are not using vhashify or any of the other util
>> scripts. The rainbow daemon sets up the chroot for each activity itself.
>> We are a bit non-standard in that we are doing process-level
>> containerization, instead of a more guest-OS system like many vserver
>> users (most?).
> So we're manually copying (or hard linking?) files into the chroot on
> every process activation? Won't this wear down our flash? (Or are
> all our chroots in RAM?) How do/can we update the libraries/etc used
> by the process in the container? Are services (like the proposed
> upgrade daemon) chrooted as well? If so, how do upgraded files get
> out of the chroot?
> Could you give me a pointer to the design docs on rainbow/etc?
Design docs? We're still at the proof-of-concept phase really ;-). But
yes, each chroot needs to be generated on the fly when a new activity
starts (unless we do some funky magic with unionfs, which is probably
not a great idea). The load of a few directory hardlinks should be
minimal. Are we expecting to do online updating or will it be more of a
windows-style "shut it all down then patch"?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.laptop.org/pipermail/devel/attachments/20070625/65187e5d/attachment.pgp
More information about the Devel