Line 37: |
Line 37: |
| | | |
| === backup === | | === 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 client side and authorisation happens on SSH level (using {{Code|command}} option in {{Code|~/.ssh/authorized_keys}} file). |
| + | |
| + | ==== Interface ==== |
| + | |
| + | From {{Code|--httpd-port}} on {{Code|--host}} host, service is processing HTTP requests for url: |
| + | |
| + | /backup/uuid/available/''uuid'' |
| + | |
| + | As a result, service returns following HTTP codes: |
| + | |
| + | * {{Code|200}}, if backup can be started; |
| + | * {{Code|503}}, if backup cannot be started right now and client needs to retry in some time later; |
| + | * Various error code on fails with error message as HTML content. |
| + | |
| + | If backup is available, client will start transfering Journal files using Rsync url taht was gotten while registration via Id service. The particular details are not an object of public interface and depends on sugar-client and backup service implementation, but process is fully server driven. |
| | | |
| === activation === | | === activation === |