XS Blueprints:Lease and update server: Difference between revisions

From OLPC
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 4: Line 4:


Lease and activation services are a key role of the XS. They are key enablers at the school and in the warehouse where the XOs are prepared for deployment.
Lease and activation services are a key role of the XS. They are key enablers at the school and in the warehouse where the XOs are prepared for deployment.

'''Note: This blueprint has been implemented. See [[XS-activation]] for notes on how to use it.'''


=Scenarios=
=Scenarios=
Line 9: Line 11:
* Tama is a field technician, he's visiting a rural school without internet. He has a new OS build to install on the existing laptops and 20 new laptops to hand out with serial numbers that the existing XS doesn't have leases for.
* Tama is a field technician, he's visiting a rural school without internet. He has a new OS build to install on the existing laptops and 20 new laptops to hand out with serial numbers that the existing XS doesn't have leases for.
* Lee is a field technician. He is deploying an XS to a school that did not have one earlier - so the XOs had very long leases, which now need to be shortened.
* Lee is a field technician. He is deploying an XS to a school that did not have one earlier - so the XOs had very long leases, which now need to be shortened.
* Teacher Catalina travelled to town and got leases and an OS image on a USB stick. The XS at his school is slow -- she wonders whether anything is happening with the USB stick.
* Teacher Catalina travelled to town and got leases and an OS image on a USB stick. The XS at her school is slow -- she wonders whether anything is happening with the USB stick.
* Jocinta is a NOC sysadmin and wants to get all the XSs out there with the new leases for a XO shipment that is being handed out, new blacklist (a few machines have been misplaced) and updated XO OS images. She has to prepare an update for the internet-connected XSs, and a usb img for the non-connected ones.
* Jocinta is a NOC sysadmin and wants to get all the XSs out there with the new leases for a XO shipment that is being handed out, new blacklist (a few machines have been misplaced) and updated XO OS images. She has to prepare an update for the internet-connected XSs, and a usb img for the non-connected ones.
* Ludmilla and Jim are technicians at the warehouse in Wellingtonia-- they have 5K XOs to activate and update. They want to use a temporary machine - perhaps one of the XOs even - as lease and update server.
* Ludmilla and Jim are technicians at the warehouse in Wellingtonia-- they have 5K XOs to activate and update. They want to use a temporary machine - perhaps one of the XOs even - as lease and update server.
Line 15: Line 17:
* First day at school in Oz is a bit more complicated -- wireless network signal is WPA encrypted or perhaps the wireless antenna is broken, flaky, saturated. Teacher wants to prepare an "unlocker" usb stick to pass around.
* First day at school in Oz is a bit more complicated -- wireless network signal is WPA encrypted or perhaps the wireless antenna is broken, flaky, saturated. Teacher wants to prepare an "unlocker" usb stick to pass around.


* See also the requirements definition [Feature_roadmap#Activation_lease_security]
* See also the requirements definition [[Feature_roadmap#Activation_lease_security]]


=Implementation Notes=
=Implementation Notes=


⚫
==XO side==
After talking with Wad, we broke the activation/lease server scenario down to


* OFW: delegation support is a nice-to-have (but unlikely to happen soon).
Warehouse scenario


Leases/OATC checks against XS in 2 places: initrd and olpc-update-query.
* Initial activation
** FW client - by Mitch - probably looks for a pre-set ESSID and dns name
** Known to work in Mitch's lab
* Wireless-based reflash
** For perf reasons you really want to do it via multicast with a bumped multicast rate. We can
*** document how to bump the MC rate on APs
*** document how to bump the MC rate on AAs (script it if we have a "turn into reflash server" script)
** Needs XOs to be booted off a USB stick with a forth script to trigger the "reflash from network"
** Worked -- at least once -- via multicast


Initrd:
In school


* Trivial proto port 191
* Lease renewal, blacklists
* 'STOLEN' response is taken "unwrapped", but is transient
⚫
* olpc-update (done!)
* '''Fix''': hardcoded XS url in init, differs from activate.py -> service announcement (if we have dns at this stage!)


⚫
olpc-update-query:


* '''Fix''': hardcoded XS url -> svc announcement
⚫
==XO side==
* '''Review/dev''': frequency is weird, can we simplify it?
* '''Dev''': checks only for update
** add 'lease' support (dsd patches)
** add 'stolen' support (&& touch /security/.private/stolen)
* '''Test/review''': Bitfrost delegated keys support seems to be complete - test!


Also:
...

* '''Review/dev''': do we need an "I don't know you" response from the server?
* '''Fix/dev''': Large JSON files problem in initrd. We need a stream parser for this :-)


==XS side==
==XS side==


Main areas of work
...

* DNS-SD'ish svc announcement
* Service on port 191
* OATC server - taking code from oats-lite
* Moodle UIs
* Data updates from NOC, report to NOC

=== DNS-SD svc announcement ===

* Publish via BIND or similar

=== OATC server ===

* Base on oats-lite
* Dev - Port to mod_python
* Dev - Add 'stolen'
* Dev - read from imported "canonical" data + local data (from Moodle)
* Dev - sign/create new leases dynamically if we have delegation certs
* Dev - "I don't know you" responses?
* Dev - Moodle-readable logs
* Dev - must handle: first degree leases/OATC and delegated leases/OATC

=== Port 191 ===

* '''Dev''': integrate with OATC server

=== Moodle ===

* Dev - add-to-blacklist UI.
** From user-profile page, and from "request log" pages
** "remove from blacklist"?
* Log views showing
** All leases we have
** Leases requested & served, sorted by request timestamp
** Highlight "requested buy don't have" and "requested but in blacklist"
* Recover tool for teachers:
** "Download lease for this user" from profile page - to laptops having trouble unlocking
** "Download (short) leases for all the school" for mass-unlocking

=== Data updates from NOC, report to NOC ===

* Read new leases/delegations/stolen data from USB stick or dropbox
* Write log of lease requests to USB stick or dropbox

=== Other ===

* add support for dropbox directories
* idmgr: port to mod_python as well?

== NOC team tools ==

This is composed of bios-crypto and related tools, and provides tools for the NOC workflow

* Tool to create a list of new XS keys against a list
* Tool to create delegation certs for each XS - inputs: CSV file listing XO/XS mapping, XS pubkeys


=Test plans and user walkthrough=
=Test plans and user walkthrough=

Latest revision as of 20:50, 27 January 2011


Lease and activation services are a key role of the XS. They are key enablers at the school and in the warehouse where the XOs are prepared for deployment.

Note: This blueprint has been implemented. See XS-activation for notes on how to use it.

Scenarios

  • Tama is a field technician, he's visiting a rural school without internet. He has a new OS build to install on the existing laptops and 20 new laptops to hand out with serial numbers that the existing XS doesn't have leases for.
  • Lee is a field technician. He is deploying an XS to a school that did not have one earlier - so the XOs had very long leases, which now need to be shortened.
  • Teacher Catalina travelled to town and got leases and an OS image on a USB stick. The XS at her school is slow -- she wonders whether anything is happening with the USB stick.
  • Jocinta is a NOC sysadmin and wants to get all the XSs out there with the new leases for a XO shipment that is being handed out, new blacklist (a few machines have been misplaced) and updated XO OS images. She has to prepare an update for the internet-connected XSs, and a usb img for the non-connected ones.
  • Ludmilla and Jim are technicians at the warehouse in Wellingtonia-- they have 5K XOs to activate and update. They want to use a temporary machine - perhaps one of the XOs even - as lease and update server.
  • In Zoolandia it is the first day of school after summer holidays -- kids are returning to school and those who haven't visited school in the holidays have their XOs locked. The wireless signal in the Zoolandia schools is unencrypted.
  • First day at school in Oz is a bit more complicated -- wireless network signal is WPA encrypted or perhaps the wireless antenna is broken, flaky, saturated. Teacher wants to prepare an "unlocker" usb stick to pass around.

Implementation Notes

XO side

  • OFW: delegation support is a nice-to-have (but unlikely to happen soon).

Leases/OATC checks against XS in 2 places: initrd and olpc-update-query.

Initrd:

  • Trivial proto port 191
  • 'STOLEN' response is taken "unwrapped", but is transient
  • Fix: hardcoded XS url in init, differs from activate.py -> service announcement (if we have dns at this stage!)

olpc-update-query:

  • Fix: hardcoded XS url -> svc announcement
  • Review/dev: frequency is weird, can we simplify it?
  • Dev: checks only for update
    • add 'lease' support (dsd patches)
    • add 'stolen' support (&& touch /security/.private/stolen)
  • Test/review: Bitfrost delegated keys support seems to be complete - test!

Also:

  • Review/dev: do we need an "I don't know you" response from the server?
  • Fix/dev: Large JSON files problem in initrd. We need a stream parser for this :-)

XS side

Main areas of work

  • DNS-SD'ish svc announcement
  • Service on port 191
  • OATC server - taking code from oats-lite
  • Moodle UIs
  • Data updates from NOC, report to NOC

DNS-SD svc announcement

  • Publish via BIND or similar

OATC server

  • Base on oats-lite
  • Dev - Port to mod_python
  • Dev - Add 'stolen'
  • Dev - read from imported "canonical" data + local data (from Moodle)
  • Dev - sign/create new leases dynamically if we have delegation certs
  • Dev - "I don't know you" responses?
  • Dev - Moodle-readable logs
  • Dev - must handle: first degree leases/OATC and delegated leases/OATC

Port 191

  • Dev: integrate with OATC server

Moodle

  • Dev - add-to-blacklist UI.
    • From user-profile page, and from "request log" pages
    • "remove from blacklist"?
  • Log views showing
    • All leases we have
    • Leases requested & served, sorted by request timestamp
    • Highlight "requested buy don't have" and "requested but in blacklist"
  • Recover tool for teachers:
    • "Download lease for this user" from profile page - to laptops having trouble unlocking
    • "Download (short) leases for all the school" for mass-unlocking

Data updates from NOC, report to NOC

  • Read new leases/delegations/stolen data from USB stick or dropbox
  • Write log of lease requests to USB stick or dropbox

Other

  • add support for dropbox directories
  • idmgr: port to mod_python as well?

NOC team tools

This is composed of bios-crypto and related tools, and provides tools for the NOC workflow

  • Tool to create a list of new XS keys against a list
  • Tool to create delegation certs for each XS - inputs: CSV file listing XO/XS mapping, XS pubkeys

Test plans and user walkthrough

...

TODOs and future work

...

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=XS_Blueprints:Lease_and_update_server&oldid=252097"