Synchronizing xs-0.3 and xo-??? --- backups

[Eben Eliason]

On Mon, Apr 28, 2008 at 12:58 PM, Michael Stone <michael at laptop.org> wrote:
> On Mon, Apr 28, 2008 at 10:33:13AM -0400, Eben Eliason wrote:
>  > Well, I guess I need to know a bit more about the technical details
>  > that will be in play in this circumstance.  Since we don't have unique
>  > usernames or passwords, the only identifier for the individual and her
>  > data is her key, right?  How does one obtain her key if, for instance,
>  >  her previous machine was bricked or stolen?  And even if she has it,
>  > must we really require her to type it in?  I suspect we may,
>  > unfortunately.
>
>  Laptops are uniquely identified by their serial-number/uuid pairs. The
>  ssh keys are incidental. Ivan's proposal (correctly, in my opinion)
>  calls for backups to be associated with laptops on the XS with an
>
>               SN <-> child

OK.

>  relation. I regard the problem of associating a new laptop with an
>  existing child as a problem that can be most conveniently solved with a
>  configuration tool or UI on the XS.

So, backing up one step...this means that in any case where the
restore needs to be performed on the same laptop, we can do the
retrieval automatically by silently passing the SN from the XO to XS.
Correct?  It's only in the new-machine case that we need any user
intervention, apart from initiation and perhaps confirmation.

In the new-machine case, it seems that the association could be done
either at the XS or at the XO.  Performing it at the XO gives us one
common place to put all the UI work for restore, but means that a
child (or a teacher helping her) will need to enter an SN by hand.
Alternately, if the association is made at the XS in advance (by
who?), then the restore can work silently just as it would had this
always been the child's machine.

As a final option, we could of course check on the XS for a backup
associated with the machine's SN, and secondarily offer a UI for
entering the SN association if one doesn't exist.  This has the
benefit of handling both of the above cases silently as described...as
long as a backup is associated with the SN, regardless of how the
association was made (it could have been configured at the XS by an
admin).  There's a privacy concern, though: naturally we don't want to
immediately offer an entry field into which anyone can type any SN
(they could have read it physically from another classmates machine)
to gain access to another child's data.  Perhaps this is a reason to
only allow the association server side...

- Eben