From OLPC

Framework needs

• Install / upgrade / version mgmt (including DB schema versioning!)
• Must work in any domain, url, directory, etc.
• Must handle http and https use transparently.
• Config mgmt
• User management (inc "lost password", etc)
• Rights / roles / access control mgmt
• 'Noticeboard' on login
• "email all users"
• Logging of user actions
• Sane logging of errors, sane DB handling

[edit] Activation server

• MFG data import
  • Should it be only SN/UUID or the whole MFG data?
    • Deployments currently get SN/UUID - in Excel!
  • upload & queue for import split process
  • "status" of running import
  • report / log on completion
  • import is wrapped in SQL transaction: if it really goes wrong, it's rolled back
  • import identifier -- to optionally delete all imported data soon after import
  • retries?
  • updates?
• MFG data queries UI? (NTH)
• Management of which XO is in each school
  • XO SN-> School
  • XO SN-> Box SN -> School (NTH)
  • To explore: inventory needs beyond XO-to-School mapping

General

• Generate short lived "recovery activation keys" - universal / per school
• Generate and publish delegation keys for XSs
  • Handle offline XSs and online XSs separately
• Generate devkeys for technical team
• Receive devkey requests, and manage "delayed" workflow for generating them, with a chance for admins to deny the request.
• Allow marking an XO as 'STOLEN' - triggers active kill
• Serve the 'upgrade' URL in the OATs message if so configured
  • Maybe also serve the rsync service
• Protect the master keys

Cases to consider

• Workflow for "child + XO moving to a new school" (double-listed?)
• Workflow for "new XOs in a school"
• Workflow for "schooling is over, free up this XO"? Just "request your devkey" maybe?

[edit] Design notes

Now that we have delegations working well for activation keys and OATs messages, we can keep the signing machine offline, and design a workflow where we do a regular (weekly?) round of usb-disk traffic as follows:

• Read from the Activation Server
  • SN/UUID/School && each XS keys -- use to generate per-XS-delegations
  • SN/UUID of all XOs && the Activation Server keys -- use to generate OAT/Activation delegations for the Activation Server.
  • SN/UUID of devkey requests -- use to generate devkeys.
    • What happens w this cycle when we get a new XO in a School?
• Put the usb disk in the signing machine - create the needed files
• Return to the Activation Server
  • Delegations to XSs can be served via bare HTTP
  • Delegations to the AS's own keys are used
  • Devkeys to be served via HTTP

Note: we must make this work in cases where the Activation Server is only accessible via HTTP by the managers of the activation infra. Making both ends handle self-contained zipfiles (with sha1 manifests) would for example make it easier and more reliable. So include in the requirements:

• Web UI to manage requests to the signing server and responses.

...

[edit] Target OS

we'll want to package and test this...

• RHEL is so old we have to repackage/rebuild/retest dependencies
• On Fedora 11 we have all packages, but we tie clients to an upgrade treadmill
• Ubuntu LTS or Debian: repackage it all :-/