Platform Team/Server Kit/sugar-server

Summary

The core Sugar Server Kit component.

The singular program requires only Python, and obvious dependencies like coreutils, to allow all its services to function properly. It provides basic sugar related services, and uses one CLI tool to manage all its functionality.

Functionality

Registry

During the sugar-server work, all its components have access to a registry, an analog of database to keep information about registered users or activated machines. The registry is file based, i.e., every item is being kept in one file (in JSON notation) in registry-dir directory.

There are two subdirectories, i.e., "tables":

• users, for registered users, and
• machines, for machines that requested activation leases on bootstrap.

Registry items might contains following keys:

• uuid, a hash value of the pubkey treated as unique and short user's identity;
• serial, serial number of hardware Sugar user is running on, e.g., serial number of a XO laptop;
• pubkey, SSH public key, this is the exact line that needs to be placed as-is to ~/.ssh/authorized_keys file; note that OLPC XS operates with striped version of public keys.

UUID per Sugar user

Sugar-server treats UUID values as unique identities of particular Sugar users, i.e., not unique identities of particular hardware that Sugar users run on (like OLPC XS does). UUID values are being calculated from users' pubkey, in the same way as JID values in Sugar Shell. If people need to keep access to their personal data, uploaded to the server, they need to keep private key, from ~/.sugar/default/owner.key file, e.g., while hardware migration or software reinstalling.

Services

The list of services that sugar-server provides. Each service has a described interface to understand how it interact with clients. The counterpart for these interfaces is the sugar-client with a Client API it provides for clients, e.g., Sugar Shell.

If particular service supports RESTfull interface, the HTTP server is started on host with httpd-port port. The content of requests and replies is being transfered using dictionaries in JSON notation.

The resulting dictionary on success, will contain predefined keys:

• success: OK;

The resulting dictionary on fails, will contain:

• success: ERR;
• error, error message.

id

Provide Sugar users registration on a school server. After being registered, Sugar on users side will setup interaction with a school server. See sugar-client project for details from client point of view.

Interface:

GET /client/status?uuid=UUID

Get information about client's status on a server.

The resulting dictionary, contains:

• registered, if False, client needs to process [re]registration.

POST /client/register

Process registration on the server.

The input dictionary, contains:

• uuid
• nickname
• serial
• pubkey

The resulting dictionary, contains:

• config a dictionary of values that are mapped 1:1 as configuration options of the sugar-client utility. See sugar-client's configuration for details;
• OLPC XS backwards compatibility keys that are not being processed by sugar-client: backupurl, jabberserver, backuppath.

Requirements:

• Current Sugar Shell code calls only XML-RPC method suing hard coded http://schoolserver:8080/ url. This restriction can be avoided using sugar-client.

Backward compatibility:

dict register(str serial, str nickname, str uuid, str pubkey)

To support OLPC's XS clients, RPC function to serve registration requests. The resulting data is the same as for RESTfull registration interface. The XML-RPM service will be listening 8080 port on the --host host.

backup

Process backup and restore for students' Journals. The service is accepting RESTfull requests that clients send before starting backup process. If server accepts requests, clients start Rsync'ing Journal data via SSH. The Rsync url needs to be gotten while registration via Id service and will be used without any modification on the client side, i.e., the process is fully server driven.

Interface:

GET /client/backup?uuid=UUID

Check if client can start transfering Journal files using.

The resulting dictionary, contains:

• accepted, if True, clients can start backup process.

Requirements:

• The root configuration option should point to the home directory of system user that starts sugar-server process. That needs because clients will SSH to this user to do Rsync backups.

Backward compatibility:

Note, this backup functionality does not compatible with client tools that work with OLPC XS. The problem is that these tools construct backup url on a client side (using only server host name from backup url given after registration on a server) with relying that every client has its own system user on a server side. That doesn't work with new backup functionality where there is only one system user on a server side and authorisation happens on SSH level (using command option in ~/.ssh/authorized_keys file).

activation

This service is intended to process anti-thief requests XO laptops send to the server during the boot process.

Interface:

GET /client/lease?serial=SERIAL

Get OLPC anti-thief lease for specified XO's serial number.o

The resulting dictionary, contains:

• lease, lease content

Requirements:

• Current XO's bootstrap code uses TCP interface with having the following numbers hard coded:
  • host needs to be 172.18.0.1,
  • activation-port needs to be 191,
  • XOs use 172.18.96.1 as a gateway while connecting to 172.18.0.1.

Backward compatibility:

Service is also listening --activation-port port on the --host host to process TCP requests used by XO's bootstrapping code. If sent data starts from serial number, the service will reply with:

• STOLEN text if serial number is stated as stolen;
• lease content found for serial number;
• UNKNOWN for errors.

keyring

Keyring service is needed to work with activation one. It signs delegated leases for activation requests if pre-existed leases weren't found.

Interface:

There is no public interface, the service is being used internally by sugar-server.

Caveats

Security issue with backups after re-flashing XOs

The usecase:

• a XO registered on a school server;
• processed several Journal backups there;
• got re-flashed with not keeping client side identities, like Sugar profile private key;
• the XO wants to restore Journal content from previous backups, but from school server point of view, it is regular registration request from new XO that provide the same serial number that existing registration uses.

Since this usecase is common for the current XO deployments, sugar-server will process a workaround with permitting such re-registration to let people do restore after re-flashing, even if private key is lost. This will happen only for XO laptops, for the rest case, workflow is regular.

Configuration

By default, configuration occurs based on several sources (sorted by applied order):

• /etc/sugar-server.conf system-wide configuration file,
• ~/.config/sugar-server/config user-wide configuration file,
• sugar-server's command-line arguments.

Configuration files contain option names equal to command-line arguments. To get the current configuration, call:

sugar-server config

See sugar-server-templates sources for an example.

Getting involved

• Report on bugs.
• Read the HACKING file to know how to contribute with code.

Resources

• Sources.