recent olpc-update changes

[Daniel Drake]

Hi Martin,

Thanks for your recent work on olpc-update. I'd like to propose a few
changes though:


1. I think that checking for new leases every 15 minutes when expiry is
near is too much. It will simply put too much load on any server that
has to handle a lot of laptops when there are no new leases on it (for
whatever reason). For a 4000 laptop deployment you're looking at 16,000
requests per hour or more. Remember that some of these servers may be
internet-based, in which case it takes several seconds of socket
tear-up/tear-down.

All deployments using this security will need an alternative lease
delivery mechanism anyway for the times when a laptop is reinstalled, or
when it has not been turned on for a week, etc. This should not be too
common, but it will not be overly uncommon either, and it's one of the
things that even if it only happens occasionally in a deployment
scenario, it's so so painful that you're going to need a solid system to
fix it.

Also, the statistics code does work well. I did quite a bit of testing
of this in Paraguay. If the server has said that laptops should checks
for updates every day, and you leave your laptop off for 2 days, next
time you turn it on it's very likely to check immediately for a new
lease. And if that doesn't happen, it's even more likely to do so 15
minutes later, etc.

Instead, I would like to go back to the mechanism in my patch where the
probability is modestly raised as lease expiry approaches. If
deployments wish to make checks a lot more frequent, their OATS server
can specify this. Realistically, even my probability increase will not
be needed - if we assume kids use their laptops once per week, and that
deployments will offer new leases on the server at least 1 week in
advance of expiry, then the existing code will do a very fine job of
phoning home as soon as the laptop is turned on.


2. Why did you rip out my "parse the leases properly" code (for
determining the lease expiry date) and replace it with something
uglier? :)

I plan to reimplement this, exposing a proper interface from the
bitfrost modules rather than just exposing the internals like I did
before.


3. For time setting, the more sensible option is to set the system clock
using "date" and then sync it to hardware using hwclock. Or is there a
reason that you did it the other way around?



The rest looks great :)

Thanks,
Daniel