Difference between revisions of "Deployment Platform/1.2/Todo"

From Sugar Labs
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 15: 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]].
  
== [[Sugar_Server_Kit/Usage_Statistics|Usage statistics]] ==
+
== [[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 a 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.

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

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

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