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

From Sugar Labs
Jump to navigation Jump to search
 
(12 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 will mace configuration be used in Sugar Server based deployments or not, implement configuration for all needed services:
+
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 questions, there are bunch of ready-to-use solutions like Munin, Nagious, etc. The problematic usecase is having servers that are mostly or entirely offline. The way might be collecting data on school servers and pass them to the mothership somehow via sneakernet. Options: run http://collectd.org/ daemons on school servers and provide useful uploading method
+
* 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.
  
−
== Feedback service for sugar-server ==
+
== Glucose patches ==
  
−
* Handle reports and statistic from XOs around school server to securely send to the mothership
+
* 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 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 ==
 +
 
 +
* [[Sugar_Server_Kit/sugar-client#OLPC_XS|Support]] OLPC XS school servers.
  
 
== Deployment ==
 
== Deployment ==
  
−
* as much as possible plug&play solution for SSK based school servers
+
* as much as possible a plug&play solution for SSK based school servers
 +
 
 +
== Testing ==
  
−
== (?) Initial Smart Objects support ==
+
* more system tests of SSK infra using sugaroid to cover various deployment workflows
 +
* using sugaroid bots, stress test prosody to compare with ejabberd;
  
−
[[Features/Smart_Objects]]
+
== Documentation ==
  
−
Many things to think about at first before any implementation...
+
* in-code documentation for SSK components.
  
 
== (?) Mothership ==
 
== (?) Mothership ==
  
−
* Interaction with motherships
+
* Interaction with other motherships
−
* Initial sugar-mothership implementation, only regarding to current sugar-server functionality
+
* Initial sugar-mothership implementation, regarding only the current sugar-server functionality
  
 
Need to collect more experience from XS deployments before any implementation...
 
Need to collect more experience from XS deployments before any implementation...

Latest revision as of 16: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...

Retrieved from "https://wiki.sugarlabs.org/index.php?title=Deployment_Platform/1.2/Todo&oldid=83510"