Difference between revisions of "Deployment Platform/1.2/Todo"
< Deployment Platform | 1.2
Jump to navigation
Jump to search
m (moved Deployemnt Platform/1.2/Todo to Deployment Platform/1.2/Todo) |
|||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | The major tasks: | ||
| + | |||
| + | * Gathering statistics, | ||
| + | * Server on an XO. | ||
| + | |||
== More sugar-server-templates templates == | == More sugar-server-templates templates == | ||
| − | Depending on whether mace configuration will be used in Sugar Server based deployments or not, implement | + | Depending on whether mace configuration will be used in Sugar Server based deployments or not, implement configurations for all needed services: |
* Content filter. Options are: Dans Guardian (MinD fork?), SquidCache, OpenDNS | * Content filter. Options are: Dans Guardian (MinD fork?), SquidCache, OpenDNS | ||
| − | * Monitoring support. If connectivity is good, then no | + | * Monitoring support. If connectivity is good, then, no question, there are a bunch of ready-to-use solutions like Munin, Nagious, etc. The problematic use case is having servers that are mostly or entirely offline. A solution might be collecting data on school servers and passing them to the mothership somehow via sneakernet. Options: run http://collectd.org/ daemons on school servers and provide a useful uploading method. |
== Glucose patches == | == Glucose patches == | ||
| Line 10: | Line 15: | ||
* Provide shell patches to use [[Sugar_Server_Kit/Client_API|Client API]]. | * Provide shell patches to use [[Sugar_Server_Kit/Client_API|Client API]]. | ||
| − | == [[ | + | == [[Platform_Team/Usage_Statistics|Usage statistics]] == |
| − | Handle reports and statistics from XOs around a school server and securely send such to the mothership. This feature might be useful from pedagogical point of view, e.g., what activity is being used most of all. | + | Handle reports and statistics from XOs around a school server, and securely send such to the mothership. This feature might be useful from a pedagogical point of view, e.g., what activity is being used most of all. |
== Avoid compromised school servers == | == Avoid compromised school servers == | ||
| Line 26: | Line 31: | ||
* as much as possible a plug&play solution for SSK based school servers | * as much as possible a plug&play solution for SSK based school servers | ||
| − | == | + | == Testing == |
| + | |||
| + | * more system tests of SSK infra using sugaroid to cover various deployment workflows | ||
| + | * using sugaroid bots, stress test prosody to compare with ejabberd; | ||
| − | + | == Documentation == | |
| − | + | * in-code documentation for SSK components. | |
== (?) Mothership == | == (?) Mothership == | ||
Latest revision as of 15:27, 8 October 2012
The major tasks:
- Gathering statistics,
- Server on an XO.
More sugar-server-templates templates
Depending on whether mace configuration will be used in Sugar Server based deployments or not, implement configurations for all needed services:
- Content filter. Options are: Dans Guardian (MinD fork?), SquidCache, OpenDNS
- Monitoring support. If connectivity is good, then, no question, there are a bunch of ready-to-use solutions like Munin, Nagious, etc. The problematic use case is having servers that are mostly or entirely offline. A solution might be collecting data on school servers and passing them to the mothership somehow via sneakernet. Options: run http://collectd.org/ daemons on school servers and provide a useful uploading method.
Glucose patches
- Provide shell patches to use Client API.
Usage statistics
Handle reports and statistics from XOs around a school server, and securely send such to the mothership. This feature might be useful from a pedagogical point of view, e.g., what activity is being used most of all.
Avoid compromised school servers
Switch to HTTPS for sugar-server RESTfull API to check its certificate on sugar-client side to make sure that client is not interacting with a fake server.
sugar-client
- Support OLPC XS school servers.
Deployment
- as much as possible a plug&play solution for SSK based school servers
Testing
- more system tests of SSK infra using sugaroid to cover various deployment workflows
- using sugaroid bots, stress test prosody to compare with ejabberd;
Documentation
- in-code documentation for SSK components.
(?) Mothership
- Interaction with other motherships
- Initial sugar-mothership implementation, regarding only the current sugar-server functionality
Need to collect more experience from XS deployments before any implementation...