recent olpc-update changes

[Martin Langhoff]

On Sat, Jul 11, 2009 at 12:17 AM, Daniel Drake<dsd at laptop.org> wrote:
> Thanks for your recent work on olpc-update. I'd like to propose a few
> changes though:

Thanks for the review!

> 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

Hmmm. I considered it carefully. My reasoning is as follows:

 - as soon as the server gives the lease, or answers 'STOLEN' it
stops, so it won't insist...

 - in "security-disabled" scenarios this won't trigger (if you think
it will, let's fix that bug)

 - if the lease _does_ expire, two bad things happen:
   - user gets a scary, different process
   - the "get a lease from secure initrd code" workflow _only works
wirelessly with Active Antennas_, not with Access Points. So in
99.9999% of deployments it _does not work_; hence the "try really
hard" stance.

> 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.

16K/ph requests isn't much for a webserver. And if it's an
internet-based webserver (the "central" antitheft server) it _will_
know what to answer (new lease or 'stolen') so it's just 4K requests.

And if it's the local XS, the traffic is much smaller... and it should
know what to answer to local XOs.

> 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.

Agreed. I am attacking this two ways:

 - Fix initrd to work with APs. It's a bit out of my comfort zone but
I'll eventually get it done. Help definitely welcome, and once we get
it done we can "ease off" on the extreme eagerness you criticize
above...

 - Make it easy to make a "recovery" leases.sig that has leases for
all the relevant machines, valid for a day or two (good enough to get
the machine to boot, and to get a lease via wireless). The Moodle side
is done (so good for XS-delegated leases). Now, this will generate a
large leases.sig which we fail to parse, so I am working on that.

> Also, the statistics code does work well.

That's good to know!

> Instead, I would like to go back to the mechanism in my patch where the

As I mentioned, that's more realistic once the initrd can associate to
an AP-based wireless and get its lease there.

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

There is a proper parser for sig01 and sig02 in the bitfrost libs.
Refactoring the "correct" parser to expose a "parse it and just tell
me expiry" is a bit of a mission.

I didn't see a clear way to get your parser to deal with sig01 and
sig02 "elegantly".

All we need is a quick parser. We're after a simple value, not
validation. The sig there has already been validated. The regex I
implemented is fairly precise (no chance of mismatch with sig01/sig02
formats), and very efficient in programmer and cpu time.

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

If you have the time, fantastic.

If you're refactoring the bitfrostparser, btw, it'd be interesting to
doublecheck that using -O doesn't make the code vulnerable. All those
asserts do get bypassed with -O, and I'm not sure if the code still
ensures correctness without them.

> 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?

I tried several ways. I settled on that order because

 - We care mainly about setting the hwclock - if we crash / restart
right there, the truth is in the hwclock :-)

 - For consistency with the initrd code (activate.py) I wanted to do
it in a way that busybox and "standard" hwclock/date could handle. The
busybox version is quite a bit more limited, and IIRC there was a
problem setting hwclock from system date, something about hwclock
getting confused about the date format it got when reading the system
time.

You could read that second reason the other way around: I first got it
running in the initrd (in activate.py) which took a bit of fiddling.
Then I checked that standard hwclock acted consistent with busybox and
copied the code verbatim.

> The rest looks great :)

Thanks! (is there a rest? maybe the whitespace I trimmed? ;-) )

Let's get lease-requests working on an AP-controlled network. Once
that works, then we can relax the request eagerness if desired. And
hell, maybe even time to refactor bitfrost.



m
-- 
 martin.langhoff at gmail.com
 martin at 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