Platform Team/Server Kit/sugar-server: Difference between revisions

Line 8:

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_Server_Kit/sugar-client|sugar-client]] with a [[Sugar_Server_Kit/Client_API|Client API]] it provides for clients, e.g., Sugar Shell.

If particular service supports RESTfull interface, the HTTP server is started on {{Code|host}} with {{Code|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:

* {{Code|success: OK}};

The resulting dictionary on fails, will contain:

* {{Code|success: ERR}};

* {{Code|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~~, such as:~~

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

* Setup jabber sever location,

Interface:

* url to backup or restore Journal,

* update native packages.

~~Interface~~:

GET '''/client/status'''?uuid=''UUID''

Get information about client's status on a server.

The resulting dictionary, contains:

* {{Code|stamp}}, client needs to keep this value to detect the moment when it needs to process re-registration on a server, i.e., when the next {{Code|stamp}} will be different to previously kept one;

POST '''/client/register'''

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

Process registration on the server.

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

The input dictionary, contains:

~~Where~~ {{Code|pubkey}} is a SSH DSS public key without the {{Code|ssh-dss }} prefix.

* {{Code|uuid}}, required user UUID;

* {{Code|nickname}}, optional client nick name;

* {{Code|serial}}, optional serial number of user's hardware;

* {{Code|pubkey}}, required only if user wants to process Journal backup, a SSH DSS public key without the {{Code|ssh-dss }} prefix.

The resulting dictionary ~~on success~~, contains:

The resulting dictionary, contains:

* {{Code|success: OK}};

* {{Code|config}} a dictionary of values that are mapped 1:1 as configuration options of the [[Sugar_Server_Kit/sugar-client|sugar-client]] utility. The particular set of keys are details of implementations and processed only internally;

* {{Code|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;

* [http://wiki.laptop.org/go/School_server OLPC XS] backwards compatibility keys that are not being processed by sugar-client: {{Code|backupurl}}, {{Code|jabberserver}}, {{Code|backuppath}}.

~~The resulting dictionary on fails~~, ~~contains:~~

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

* {{Code|~~success: ERR~~}};

Backward compatibility, with OLPC's XS, RPC function to serve registration requests. The resulting data is the same as for RESTfull registration interface. The XML-RPM service will be listening {{Code|8080}} port on the {{Code|--host}} host.

* {{Code|~~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.

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.

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

Line 44:

Line 62:

Interface:

~~From {{Code|--httpd-port}} on {{Code|--host}} host, service is processing HTTP requests for url:~~

GET '''/client/backup'''?uuid=''UUID''

/backup/uuid~~/available/~~''~~uuid~~''

~~As a result, service returns following HTTP codes:~~

Check if client can start transfering Journal files using.

* {{Code|200}}, ~~if backup can be started;~~

The resulting dictionary, contains:

* {{Code|403}}, registration was not processed;

* {{Code|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~~.

* {{Code|accepted}}, if {{Code|True}}, clients can start backup process.

=== activation ===

@@ Line 8: / Line 8: @@
 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_Server_Kit/sugar-client|sugar-client]] with a [[Sugar_Server_Kit/Client_API|Client API]] it provides for clients, e.g., Sugar Shell.
+If particular service supports RESTfull interface, the HTTP server is started on {{Code|host}} with {{Code|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:
+* {{Code|success: OK}};
+The resulting dictionary on fails, will contain:
+* {{Code|success: ERR}};
+* {{Code|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, such as:
+Provide Sugar users registration on a school server. After being registered, Sugar on users side will setup interaction with a school server. See [[Sugar_Server_Kit/sugar-client|sugar-client]] project for details from client point of view.
-* Setup jabber sever location,
+Interface:
-* url to backup or restore Journal,
-* update native packages.
-Interface:
+ GET '''/client/status'''?uuid=''UUID''
+Get information about client's status on a server.
+The resulting dictionary, contains:
+* {{Code|stamp}}, client needs to keep this value to detect the moment when it needs to process re-registration on a server, i.e., when the next {{Code|stamp}} will be different to previously kept one;
+ POST '''/client/register'''
-Service is listening {{Code|--id-port}} port on the {{Code|--host}} host to serve XML-RPC requests. There is only one RPC function:
+Process registration on the server.
- ''dict'' '''register'''(''str'' serial, ''str'' nickname, ''str'' uuid, ''str'' pubkey)
+The input dictionary, contains:
-Where {{Code|pubkey}} is a SSH DSS public key without the {{Code|ssh-dss }} prefix.
+* {{Code|uuid}}, required user UUID;
+* {{Code|nickname}}, optional client nick name;
+* {{Code|serial}}, optional serial number of user's hardware;
+* {{Code|pubkey}}, required only if user wants to process Journal backup, a SSH DSS public key without the {{Code|ssh-dss }} prefix.
-The resulting dictionary on success, contains:
+The resulting dictionary, contains:
-* {{Code|success: OK}};
+* {{Code|config}} a dictionary of values that are mapped 1:1 as configuration options of the [[Sugar_Server_Kit/sugar-client|sugar-client]] utility. The particular set of keys are details of implementations and processed only internally;
-* {{Code|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;
 * [http://wiki.laptop.org/go/School_server OLPC XS] backwards compatibility keys that are not being processed by sugar-client: {{Code|backupurl}}, {{Code|jabberserver}}, {{Code|backuppath}}.
-The resulting dictionary on fails, contains:
+ ''dict'' '''register'''(''str'' serial, ''str'' nickname, ''str'' uuid, ''str'' pubkey)
-* {{Code|success: ERR}};
+Backward compatibility, with OLPC's XS, RPC function to serve registration requests. The resulting data is the same as for RESTfull registration interface. The XML-RPM service will be listening {{Code|8080}} port on the {{Code|--host}} host.
-* {{Code|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.
+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.
 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).
@@ Line 44: / Line 62: @@
 Interface:
-From {{Code|--httpd-port}} on {{Code|--host}} host, service is processing HTTP requests for url:
+  GET '''/client/backup'''?uuid=''UUID''
-  /backup/uuid/available/''uuid''
-As a result, service returns following HTTP codes:
+Check if client can start transfering Journal files using.
-* {{Code|200}}, if backup can be started;
+The resulting dictionary, contains:
-* {{Code|403}}, registration was not processed;
-* {{Code|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.
+* {{Code|accepted}}, if {{Code|True}}, clients can start backup process.
 === activation ===