Deployment Platform/1.2/Todo: Difference between revisions

(7 intermediate revisions by 2 users not shown)

Line 1:

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

* Monitoring support. If connectivity is good, then no ~~questions~~, 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. ~~The way~~ 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.

* 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 ==

Line 10:

Line 15:

* 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 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 ==

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

Line 22:

Line 31:

* as much as possible a plug&play solution for SSK based school servers

== ~~(?) Initial Smart Objects support~~ ==

== Testing ==

* 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 ==

@@ Line 1: / Line 1: @@
+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 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
-* Monitoring support. If connectivity is good, then no questions, 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. The way 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.
+* 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 ==
@@ Line 10: / Line 15: @@
 * 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 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 ==
 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 ==
@@ Line 22: / Line 31: @@
 * as much as possible a plug&play solution for SSK based school servers
-== (?) Initial Smart Objects support ==
+== Testing ==
+* 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 ==