Difference between revisions of "Platform Team/Server Kit/sugar-server"

From Sugar Labs
Jump to navigation Jump to search
Line 17: Line 17:
 
* update native packages.
 
* update native packages.
  
−
==== Interface ====
+
Interface:
  
 
Service is listening {{Code|--id-port}} port on the {{Code|--host}} host to serve XML-RPC requests. There is only one RPC function:
 
Service is listening {{Code|--id-port}} port on the {{Code|--host}} host to serve XML-RPC requests. There is only one RPC function:
Line 42: Line 42:
 
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 {{Code|command}} option in {{Code|~/.ssh/authorized_keys}} file).
 
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 {{Code|command}} option in {{Code|~/.ssh/authorized_keys}} file).
  
−
==== Interface ====
+
Interface:
  
 
From {{Code|--httpd-port}} on {{Code|--host}} host, service is processing HTTP requests for url:
 
From {{Code|--httpd-port}} on {{Code|--host}} host, service is processing HTTP requests for url:
Line 60: Line 60:
 
This service is intended to process anti-thief requests XO laptops send to the server during the boot process.
 
This service is intended to process anti-thief requests XO laptops send to the server during the boot process.
  
−
==== Interface ====
+
Interface:
  
 
Service is listening {{Code|--activation-port}} port on the {{Code|--host}} host to process TCP requests. If sent data starts from serial number, the service will reply with:
 
Service is listening {{Code|--activation-port}} port on the {{Code|--host}} host to process TCP requests. If sent data starts from serial number, the service will reply with:
Line 72: Line 72:
 
Keyring service is needed to work with activation one. It signs delegated leases for activation requests if pre-existed leases weren't found.
 
Keyring service is needed to work with activation one. It signs delegated leases for activation requests if pre-existed leases weren't found.
  
−
==== Interface ====
+
Interface:
  
 
There is no public interface, the service is being used internally by sugar-server.
 
There is no public interface, the service is being used internally by sugar-server.

Revision as of 19:46, 1 November 2011

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.

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.

id

Provide Sugar users registration on a school server. After being registered, Sugar on users side will setup interaction with a school server, such as:

  • Setup jabber sever location,
  • url to backup or restore Journal,
  • update native packages.

Interface:

Service is listening --id-port port on the --host host to serve XML-RPC requests. There is only one RPC function: 

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

Where pubkey is a SSH DSS public key without the ssh-dss prefix.

The resulting dictionary on success, contains:

  • success: OK;
  • config key with a dictionary of values that are mapped 1:1 as configuration options of the sugar-client utility. The particular set of keys are details of implementations and processed only internally;
  • OLPC XS backwards compatibility keys that are not being processed by sugar-client: backupurl, jabberserver, backuppath.

The resulting dictionary on fails, contains:

  • success: ERR;
  • error key with error message.

backup

Process backup and restore for students' Journals. The service is listenning for HTTP requests that client send before starting backup. If server accepts requests, clients start Rsync'ing Journal data via SSH.

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

Interface:

From --httpd-port on --host host, service is processing HTTP requests for url: 

/backup/uuid/available/uuid

As a result, service returns following HTTP codes:

  • 200, if backup can be started;
  • 503, if backup cannot be started right now and client needs to retry in some time later;
  • Various error codes on fails with error message as HTML content.

If backup is available, client will start transfering Journal files using Rsync url that was gotten while registration via Id service. The Rsync url is used without any modification on the client side, i.e., the process is fully server driven.

activation

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

Interface:

Service is listening --activation-port port on the --host host to process TCP requests. 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.

Requires

  • bios-crypto
    bios-crypto client utilities are being used in anti-thief support and should be installed only if sign service is being used.
  • python-mysql
    If the rest of school server applications use MySql, it might be useful to keep sugar-server data in MySql as well. Otherwise plain text file will be used.

Configuration

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

  • /etc/sugar-server.conf system-wide configuration file,
  • ~/.local/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

Retrieved from "https://wiki.sugarlabs.org/index.php?title=Platform_Team/Server_Kit/sugar-server&oldid=70631"