5,705
edits
Changes
Jump to navigation
Jump to search
Line 56:
Line 56: − ''dict'' '''register'''(''str'' serial, ''str'' nickname, ''str'' uuid, ''str'' pubkey)+ + + − + − Requirements:+ − * Current Sugar Shell code calls only XML-RPC method suing hard coded {{Code|http://schoolserver:8080/}} url. This restriction can be avoided using [[Sugar_Server_Kit/sugar-client|sugar-client]].+ − − 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 83:
Line 83: + + + + Line 97:
Line 101: − − Service is also listening {{Code|--activation-port}} port on the {{Code|--host}} host to process TCP requests used by XO's bootstrapping code. If sent data starts from serial number, the service will reply with: − − * {{Code|STOLEN}} text if serial number is stated as stolen; − * lease content found for serial number; − * {{Code|UNKNOWN}} for errors. Line 110:
Line 108: + + + + + + + +
Platform Team/Server Kit/sugar-server (view source)
Revision as of 11:40, 11 November 2011
, 11:40, 11 November 2011→Services
* [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}}.
* [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}}.
Requirements:
* Current Sugar Shell code calls only XML-RPC method suing hard coded {{Code|http://schoolserver:8080/}} url. This restriction can be avoided using [[Sugar_Server_Kit/sugar-client|sugar-client]].
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.
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 {{Code|8080}} port on the {{Code|--host}} host.
=== backup ===
=== 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.
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:
Interface:
* The {{Code|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.
* The {{Code|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 {{Code|command}} option in {{Code|~/.ssh/authorized_keys}} file).
=== activation ===
=== activation ===
* {{Code|lease}}, lease content
* {{Code|lease}}, lease content
Requirements:
Requirements:
** {{Code|activation-port}} needs to be {{Code|191}},
** {{Code|activation-port}} needs to be {{Code|191}},
** XOs use {{Code|172.18.96.1}} as a gateway while connecting to {{Code|172.18.0.1}}.
** XOs use {{Code|172.18.96.1}} as a gateway while connecting to {{Code|172.18.0.1}}.
Backward compatibility:
Service is also listening {{Code|--activation-port}} port on the {{Code|--host}} host to process TCP requests used by XO's bootstrapping code. If sent data starts from serial number, the service will reply with:
* {{Code|STOLEN}} text if serial number is stated as stolen;
* lease content found for serial number;
* {{Code|UNKNOWN}} for errors.
=== keyring ===
=== keyring ===