Difference between revisions of "School Server Wish List"

From Sugar Labs
Jump to navigation Jump to search
(Created page with "'''School Server Wish List''' This is a first attempt to organize my thoughts based on the XS Wish List. It attempts to organize the wish list roughly along the lines of the cu...")
 
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
'''School Server Wish List'''
+
<noinclude>[[Category:School Server]]
 +
[[Category:Wish list]]</noinclude>
  
 
This is a first attempt to organize my thoughts based on the XS Wish List. It attempts to organize  
 
This is a first attempt to organize my thoughts based on the XS Wish List. It attempts to organize  
Line 13: Line 14:
  
 
'''XS in 25 words or less'''
 
'''XS in 25 words or less'''
−
 
−
 
  
 
XS is a LAMP stack.  
 
XS is a LAMP stack.  
Line 20: Line 19:
 
'''Build Options'''
 
'''Build Options'''
  
−
The current intent is to use SUSE Open Build System to all a deployment to select  
+
The current intent is to use SUSE Open Build System to allow a deployment to select the
 
architecture (i386, X_64) and packaging (Fedora, Debian) at build time. Whichever of these options is chosen  
 
architecture (i386, X_64) and packaging (Fedora, Debian) at build time. Whichever of these options is chosen  
 
obviously affects the XC build.  
 
obviously affects the XC build.  
  
−
The overall functionality similar to XS-0.6 with some changes and addtions discussed below.
+
The overall functionality is similar to XS-0.6 with some changes and additions discussed below.
  
 
'''Base system'''
 
'''Base system'''
  
−
Fedora: 15
+
*Fedora: 15
−
Apache:
+
*Apache:
−
MySQL:
+
*MySQL:
−
PHP:
+
*PHP:
  
  
Line 37: Line 36:
  
  
−
Python 2.?
+
*Python 2.x
−
Python 3.?
+
*Python 3.x
  
 
including python-devel to support 'python setup.py install'
 
including python-devel to support 'python setup.py install'
  
−
Note: my take is that Python 2. must be supported because the packages in XC do not currently support Python 3.
 
 
Python 2 is probably required and Python 3 a build option.
 
Python 2 is probably required and Python 3 a build option.
  
Line 49: Line 47:
 
This is not a complete list but some examples include:
 
This is not a complete list but some examples include:
  
−
idmgr - registration of XOs
+
*idmgr - registration of XOs
−
Journal backup and restore
+
*Journal backup and restore
−
XO lease-activation
+
*XO lease-activation
  
−
'''Network'''
+
'''XS configuration'''
  
−
Currently each component of XS is configured as it is added. It might be nice to configuration clearly separated so that it is easy to see what to do for local customization.
+
Currently each component of XS is configured as it is added. It might be nice to configuration clearly separated so that it is easy to see what to do for local customization. This is particularly important for the network setup.
  
−
This is particularly important for the network setup.
+
'''Network'''
  
 
The default is that an XS install configures the baseboard (RJ45) port for the LAN (172.18.0.1). A separate script
 
The default is that an XS install configures the baseboard (RJ45) port for the LAN (172.18.0.1). A separate script
−
such as netsetup.sh should be available to configure the WAN network.
+
such as netsetup.sh should be available to configure the WAN network. This script should not be required unless the schoolserver has a WAN connection. It would be easier if the script were a file on the XS install key rather than a file in the XS build. This would make it possible for a deployment to edit the script without modifying the XS build.
  
 
The network install and/or the netsetup.sh script should support access by the schoolserver using a gsm network.
 
The network install and/or the netsetup.sh script should support access by the schoolserver using a gsm network.
Line 78: Line 76:
 
'''Basic Self Tests'''
 
'''Basic Self Tests'''
  
−
XS is componsed of stable production upstream packages. The sugar-specific packages may need some  
+
XS is composed of stable production upstream packages. The sugar-specific packages may need some  
−
sort of self-test; howver, at the end of the day these are developer tests.  
+
sort of self-test; however, at the end of the day these are developer tests.
 +
 
 +
The questions in deployment are 'is the XS build ok' and 'has it been correctly installed on a specific
 +
server'.  
  
−
The question in the deployment is the XS build ok and has it been correctly installed on a specific
+
In Nepal, this is satisfied by  
−
server. In Nepal, this is satisfied by  
+
#mkusbinstall works,  
−
(1) mkusbinstall works,  
+
#the install works, and  
−
(2) the install works, and  
+
#it is possible to access the server from an XO via SSH.
−
(3) it is possible to access the server from an XO via SSH.
 
  
−
It would be desirable to have the second ethernet port before netsetup.sh configured for a direct SSH connection  
+
It would be desirable to have the second ethernet port configured in XS for a direct SSH connection  
 
(patch cable) to test problems with the LAN network and router configuration (easily the most common problems  
 
(patch cable) to test problems with the LAN network and router configuration (easily the most common problems  
 
are httpd not started or the router not configured correctly).
 
are httpd not started or the router not configured correctly).
 +
 +
There should be a netsetup.sh script to configure the WAN network (second port). This should only have to be run when the school server has a connection to the internet. Currently this script is in the XS build. It would be easier for a support person to find and use if it were on the XS usb drive as a separate file. This way it could be edited on an XO.
  
 
"It would be great to have basic self
 
"It would be great to have basic self
Line 108: Line 110:
 
IMO this is a 'holy grail'. Anyone who has used Microsoft diagnostic wizards knows the frustration and uselessness of trying to anticipate and provide automated corrections of problems.  
 
IMO this is a 'holy grail'. Anyone who has used Microsoft diagnostic wizards knows the frustration and uselessness of trying to anticipate and provide automated corrections of problems.  
  
−
XS has proven very stable. In a normal school evnvironment new releases are probably only needed (or desired) one
+
XS has proven very stable. In a normal school evvironment new releases are probably only needed (or desired) one
 
time per year, prior to the start of the new school year. This suggests that the critical requirement is extensive testing of the build prior to deployment.
 
time per year, prior to the start of the new school year. This suggests that the critical requirement is extensive testing of the build prior to deployment.
  
−
New packages:
+
'''New packages:'''
  
 
*systemd: a replacement for SysVinit and Upstart that acts as a system
 
*systemd: a replacement for SysVinit and Upstart that acts as a system
Line 124: Line 126:
 
forwarding enabled on the Internet gateway, eases accessing the
 
forwarding enabled on the Internet gateway, eases accessing the
 
schoolserver from anywhere on the Internet.
 
schoolserver from anywhere on the Internet.
−
 
−
*MySQL: a relational database server, and a de-facto backend for many
 
−
services. Also it would be good to ditch PostgreSQL for Moodle. MySQL
 
−
management is easy than PostgreSQL and there is more documentation,
 
−
community support and human resource for MySQL.
 
−
 
−
*PHP with required extensions: a powerful server-side HTML embedded
 
−
scripting language. OLE Nepal?s digital library ?E-Pustakalaya? runs
 
−
on PHP and MySQL. Also we might need some PHP extensions like
 
−
php-mysql, php-gd, php-xml.
 
−
 
−
*Python 2.x and Python 3.x: an interpreted, interactive,
 
−
object-oriented, extensible programming language. Python 2.x should be
 
−
included for backward compatibility as many python scripts and
 
−
applications still use the 2.x version. Python 3.x should be included
 
−
for forward compatibility ? more apps would be coded in 3.x version in
 
−
coming days.
 
  
 
*Expect: a Unix automation and testing tool and used to automate
 
*Expect: a Unix automation and testing tool and used to automate
Line 152: Line 137:
 
framework).
 
framework).
  
−
*Java: Adding a Java Runtime Environment (JRE) would add support for
+
'''< OLPC'''
−
running java based applications (e.g. Tomcat, Fedora Commons, etc.)
+
 
−
tzdata and extensions: Adding timezone data and its wrapper libraries
+
There are two scenarios. One, a student with a defective laptop gets a replacement. The records on the schoolserver need to be updated to reflect the change. Two, students are in two shifts. The afternoon shift on Monday is the morning shift on Tuesday. In this case two students, one in each shift, could share a laptop (0.5 LPC). In Rwanda this would have allowed 100,000 laptops to service 200,000 students. This requires (1) a login to identify the student using the laptop, (2) two datastores - with a symbolic link at login, and (3) A and B backup folders on the school server.
−
in various languages will help the support for timezone data in
+
 
−
applications hosted on XS (e.g. SchoolTool needs pytz).
+
'''XC in 25 words or less'''
 +
XC provides all of the software and content required in the school server but not included in XS.
 +
 
 +
'''Library'''
 +
 
 +
In Nepal this is Pustakalaya (www.pustakalaya.org). It is supported by Java, Fedora Commons and Fez. This installation is in XC.
 +
 
 +
There is a project to develop a library based on Django. This would be an alternate in XC.
 +
 
 +
'''Wiki4Schools'''
 +
 
 +
XC in Nepal includes the Wiki4Schools (2008 version - which apparently is the most recent). This is based on mediawiki.
 +
 
 +
There is a project to provide the same capability using openZim, this could be an alternate in XC.
 +
 
 +
 
 +
'''Dictionary'''
 +
 
 +
XC in Nepal includes Wiktionary and a Nepali dictionary (Sabdakos). This will clearly be very deployment-specific.
 +
 
 +
'''Sugar Activities'''
 +
 
 +
XC includes a repository of Sugar Activities. This allows students to download and install activities of their choosing from the school server.
 +
 
 +
'''Dan's Guardian'''
 +
 
 +
Web filtering requires lots of disclaimers. Whoever is the authority for deploying a schoolserver needs to sign off that the filtering offered is accepted as adequate. This is part of XS in Nepal but moving it to XS might make the XS build easier.
 +
 
 +
'''Moodle'''
 +
 
 +
This is installed in XS in Nepal but could be installed in XS. It is dependent on the configuration of the LAMP stack in XS (Apache, MySQL or PostGreSQL). This might be a good time to move to Moodle 2. AFIK no deployment is currently using Moodle so there would be a minimum of issues with backward compatibility.
 +
 
 +
'''SchoolTool'''
 +
 
 +
While not directly related to the OLPC mission, one of the first uses of computers in schools is to automate the administration (attendance lists, academic calendar, and so on). There is a possibility to integrate SchoolTool with Moodle.
 +
 
 +
'''Mothership or Content Update'''
 +
 
 +
The model in Nepal and Rwanda is that the central development group provides the same software and content to each school. The school is not expected to make any changes and, if it did, they would be erased on the next update.
 +
 
 +
It is unlikely that schools will have sufficient broadband access to support concurrent browsing for every XO.
 +
However, there should be a mechanism where each school server can connect with the mothership (e.g. cron job) and receive updates and upload changes (e.g. email). The mothership could then include this information in the next connection opportunity for the other schools. There would have to be a parallel mechanism using usb keys (e.g someone from the school goes to town with the usb drive and connects from an internet cafe).
  
−
*SchoolTool: a free administrative software for schools around the
+
The schoolserver, in turn, provides updates to the XOs.
−
world. It provides a good administrative interface and facilities.
 
−
I?ve already packaged SchoolTool for Fedora and tested it on XS. OLE
 
−
Nepal is also in transition to pilot SchoolTool to a few schools. Also
 
−
that a integration of Moodle and SchoolTool is being worked out.
 
−
Moodle 2.x: a Course Management System (CMS), also known as a Learning
 
−
Management System (LMS) or a Virtual Learning Environment (VLE). The
 
−
moodle on current XS is outdated. Moodle 2.x hosts improved interface
 
−
and additional features than its previous versions. With Moodle, a few
 
−
other features would be interesting:
 
−
Using MySQL instead of PostgreSQL
 
−
Integration with SchoolTool: See
 
−
http://docs.moodle.org/en/Development:SchoolTool_Integration for
 
−
details.
 
−
A mechanism to consolidate Moodle data. The scenario would be like XS
 
−
would be shipped with some sample data, teachers and students at the
 
−
school would create some data, and additional data would be pushed
 
−
periodically through content updates. So there should be a mechanism
 
−
to consolidate all the data and retain it, without losing the previous
 
−
data while doing content update.
 
  
−
*Content Updates
+
'''Socializing/Communication'''
−
XO laptops with a limited storage can not hold much content, so heavy
 
−
content (e.g. E-Pustakalaya) is offloaded to the school server. Also
 
−
that the XS hosts sugar activity updates. In Nepalese deployment, we
 
−
generate content bundles including E-Pustakalaya and E-Paath along
 
−
with new releases of sugar activities every three month, and the
 
−
deployment team would generally visit each schools and update the
 
−
content. Nepalese XS is equipped with scripts to handle headless
 
−
content updates. Additionally we are also doing content update through
 
−
network/internet wherever feasible. Content update through network can
 
−
be really troublesome with deployment scenario of schools having
 
−
limited connectivity to internet and/or having only LAN level access
 
−
among schools. Devising content update would involve creating a
 
−
unified format for content bundles and devising a way to deploy
 
−
content updates easily through network with a minimal payload on the
 
−
content server. I would suggest a torrent based mechanism to handle
 
−
content deployment ? it will offload content through local peers and
 
−
handle data checksums and all. Meanwhile a mechanism to support
 
−
loading content on a USB harddisk would be great as it will help to
 
−
deliver the content to the XS with no internet connectivity.
 
  
−
*Web content filtering
+
Open Atrium is based on Drupal. Providing a way for teachers to communicate with the central support group and with each other is very important.
−
XS with internet access are configured as a internet gateway for XO
 
−
laptops and other devices connecting to the network. This poses one
 
−
problem ? children can be subjected to websites related with vandalism
 
−
and pornography. A content filtering mechanism for web browsing would
 
−
solve this problem. Additionally some file extensions and websites can
 
−
be blocked, so as to help traffic shaping. I would suggest
 
−
Dansguardian as a tool for this purpose. We have been using
 
−
Dansguardian on NE-XS (the Nepalese clone of OLPC XS), and has been
 
−
successfully using it. Dansguardian supports message/information
 
−
templates in case a extension or a website is blocked. Also that it
 
−
supports unicode message. Hence using a Dansguardian with customized
 
−
message templates in local languages would help a great for content
 
−
filtering, meanwhile displaying appropriate message in case of site
 
−
blockades.
 
  
−
*Journal Backup on a shared model distribution
+
Moodle may offer an alternate way to do this.  
−
I am aware that OLPC projec emphasizes the laptop distribution model
 
−
having 1:1 child-laptop ratio, that is to say each kid owns a laptop,
 
−
but sharing a laptops among few kids (say one laptop to be shared
 
−
among 3 kids) can be beneficial sometimes. For developing countries
 
−
like Nepal, it might take some time to arrange funds for mass OLPC
 
−
deployments. In such a scenario, where mass deployments might take
 
−
time, grounding on in available resources (XOs) would seem appropriate
 
−
than to wait to gather enough resources for mass deployments. This
 
−
focuses on having the XOs shared and utilized rather than keeping them
 
−
unused. Having said that, physically sharing a laptop among few kids
 
−
might seem no-brainer, but the complexity lies in how the XS interacts
 
−
with the school server and how services are provided/consumed. One
 
−
important aspect of this is Journal backup. XS has a service call
 
−
id-manager (idmgr) which registers a laptop with school server. The
 
−
registration uses the XO serial number as a unique key to maintain the
 
−
list and various service like ds-backup is provided based upon the
 
−
key. In the laptop-sharing scenario, the journal created on a laptop
 
−
might actually belong to more than one user, and managing journal
 
−
backups and restore can be troublesome. Meanwhile, multiple users
 
−
using one laptop means that more journal entries would be created and
 
−
hence the frequency for journal backup would increase inherently. To
 
−
solve this problem, the idmgr and the ds-backup service somehow needs
 
−
to recognize the user creating the journal entry rather than just
 
−
based upon the XO serial. Unfortunately, I do not know how to force
 
−
user logins on sugar; and forcing user logins consequently is going to
 
−
confuse the kids. Another way might be to use one folder per user per
 
−
XO serial. But then we need to tell idmgr and ds-backup on which
 
−
journal entry should go into which folder. I don?t yet have a clear
 
−
idea on how to implement this, but I would definitely like to have
 
−
this feature included with the XS
 
  
−
*Socializing/Communication Platform
+
WordPress and Planet may also be an option.
−
I have always been looking forward to implementing a socializing and
 
−
communication platform on the XS that will help users to socialize and
 
−
communicate. By this I mean inter-school and intra-school
 
−
communication. Also that this framework can be used to send messages
 
−
and notifications to users (teachers, administrators, and students).
 
−
Implementing an offline mail queue which keeps mail lined up and sends
 
−
them when it has internet connectivity would be a great features.
 
−
Schools in Nepal have sparse Internet connectivity, and such a mail
 
−
queue might help inter-school communication. I?m looking forward to
 
−
use Open Atrium as a tool for this purpose. Also a multi-node system
 
−
of Open Atrium, if it can be implemented, with a inter-node
 
−
communication, would ease the task a lot.
 
  
−
These were some of the customizations I envision would help a great
+
In any case, these tools need support from the mother ship.
−
deal with the XS. I?m not even sure if items off my wishlist are
 
−
feasible at this time. What is your XS wishlist?
 
 
_______________________________________________
 
_______________________________________________
 +
== References ==
 +
* http://www.mail-archive.com/server-devel@lists.laptop.org/msg04185.html
 +
* http://www.mail-archive.com/server-devel@lists.laptop.org/msg04196.html
 +
* http://www.mail-archive.com/server-devel@lists.laptop.org/msg04215.html
 +
* [[olpc:Nepal Wish List]]

Latest revision as of 17:51, 9 June 2011


This is a first attempt to organize my thoughts based on the XS Wish List. It attempts to organize the wish list roughly along the lines of the current division between XS and XC as deployed by OLE Nepal. I have attempted to include current features as a rough checklist of what is in the two builds. Please feel free to edit/fix/correct it.

In concept XS contains the software components and XC loads the content (into the /library partition). For historical reasons, the library (e-Pustakalaya) is loaded from XC including the Fedora Commons and Fez packages. There is no technical reason why other software packages such as Dan's Guardian and Moodle could not be included in XC.

In principle, an XS build should run on a school server without an XC install and satisfy the essential needs such as registration, lease-activation, mesh network support, Journal backup/restore and system administration by SSH.

XC should install the software needed to support the associated content. The decision whether a particular software package goes in XS or XC will have more to do with art than science.

XS in 25 words or less

XS is a LAMP stack.

Build Options

The current intent is to use SUSE Open Build System to allow a deployment to select the architecture (i386, X_64) and packaging (Fedora, Debian) at build time. Whichever of these options is chosen obviously affects the XC build.

The overall functionality is similar to XS-0.6 with some changes and additions discussed below.

Base system

  • Fedora: 15
  • Apache:
  • MySQL:
  • PHP:


Additional Components:


  • Python 2.x
  • Python 3.x

including python-devel to support 'python setup.py install'

Python 2 is probably required and Python 3 a build option.

Sugar Support

This is not a complete list but some examples include:

  • idmgr - registration of XOs
  • Journal backup and restore
  • XO lease-activation

XS configuration

Currently each component of XS is configured as it is added. It might be nice to configuration clearly separated so that it is easy to see what to do for local customization. This is particularly important for the network setup.

Network

The default is that an XS install configures the baseboard (RJ45) port for the LAN (172.18.0.1). A separate script such as netsetup.sh should be available to configure the WAN network. This script should not be required unless the schoolserver has a WAN connection. It would be easier if the script were a file on the XS install key rather than a file in the XS build. This would make it possible for a deployment to edit the script without modifying the XS build.

The network install and/or the netsetup.sh script should support access by the schoolserver using a gsm network.

XMPP

Currently this is ejabberd. XS needs to support XO sharing in the classroom by this or other means. This is another case where it would be helpful if the package install was separated from the configuration. Currently this configuration is fixed; however, some deployments may want to set up separate groups for each class. This would simplify the network view and probably improve performance.

Usbmount

Daniel Drake's usbmount should be installed in XS. The specific script configuration may be limited to a generic: if XC-install is present run it. This would allow the builder of XC to match the install scripts with the content without needing to rebuild XS. It would allow usbmount to be 'turned off' by renaming the script when the same hard drive is used for another purpose (e.g. backup).

Root et al

It should not be possible to log in as root directly (also su is possible with a password). It should be possible to log in as admin via SSH with a known password (i.e. known to authorized support staff). It is necessary for support staff to know how to administer the server by ssh even though they did not go to the school to attend to a server problem. This is not good security practice, but is better than having someone go to the school, be told there is a problem with the server, and have to send someone else later to deal with it.

Basic Self Tests

XS is composed of stable production upstream packages. The sugar-specific packages may need some sort of self-test; however, at the end of the day these are developer tests.

The questions in deployment are 'is the XS build ok' and 'has it been correctly installed on a specific server'.

In Nepal, this is satisfied by #mkusbinstall works, #the install works, and #it is possible to access the server from an XO via SSH.

It would be desirable to have the second ethernet port configured in XS for a direct SSH connection (patch cable) to test problems with the LAN network and router configuration (easily the most common problems are httpd not started or the router not configured correctly).

There should be a netsetup.sh script to configure the WAN network (second port). This should only have to be run when the school server has a connection to the internet. Currently this script is in the XS build. It would be easier for a support person to find and use if it were on the XS usb drive as a separate file. This way it could be edited on an XO.

"It would be great to have basic self 

tests embedded into the XS, which

will help the school side to diagnose and fix the problem easily. Individuals at the school looking after the school server might not be proficient with GNU/Linux and would have a hard time to diagnose and fix a problem with XS; this is a case with the Nepalese deployments. Adding to this, for a fix, either the support team needs to be dispatched to the school (which might be located in a remote place), or the ask the school to bring back the school server to the support centre. Given the scenario in Nepal, with just a single support centre, this fix can cost a lot of time, effort, and money. Basic self tests, with mechanism to provide instructions on now to fix simple problems is greatly going to ease the hassle. The self tests can contain testing services, network status and such."

IMO this is a 'holy grail'. Anyone who has used Microsoft diagnostic wizards knows the frustration and uselessness of trying to anticipate and provide automated corrections of problems.

XS has proven very stable. In a normal school evvironment new releases are probably only needed (or desired) one time per year, prior to the start of the new school year. This suggests that the critical requirement is extensive testing of the build prior to deployment.

New packages:

  • systemd: a replacement for SysVinit and Upstart that acts as a system

and session manager.

  • usb-modeswitch: a library/utility for handling Mode-Switching USB

Devices on Linux. This package is required to access internet through 3G cards (e.g. Mobile broadband).

  • ipcheck: a Dyndns.org client to register your dynamic IP address. It

helps to configure the server with dynamic dns and with port forwarding enabled on the Internet gateway, eases accessing the schoolserver from anywhere on the Internet.

  • Expect: a Unix automation and testing tool and used to automate

interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, etc. E-Pustakalaya uses Fedora Commons which has a interactive setup; we use expect to automate the installation by providing all answers to the setup program. Expect is useful to create headless installers, and it also has a python wrapper. libicu and unicode support: Adding unicode support in XS will help to have localized web applications hosted on the XS (using gettext framework).

< OLPC

There are two scenarios. One, a student with a defective laptop gets a replacement. The records on the schoolserver need to be updated to reflect the change. Two, students are in two shifts. The afternoon shift on Monday is the morning shift on Tuesday. In this case two students, one in each shift, could share a laptop (0.5 LPC). In Rwanda this would have allowed 100,000 laptops to service 200,000 students. This requires (1) a login to identify the student using the laptop, (2) two datastores - with a symbolic link at login, and (3) A and B backup folders on the school server.

XC in 25 words or less XC provides all of the software and content required in the school server but not included in XS.

Library

In Nepal this is Pustakalaya (www.pustakalaya.org). It is supported by Java, Fedora Commons and Fez. This installation is in XC.

There is a project to develop a library based on Django. This would be an alternate in XC.

Wiki4Schools

XC in Nepal includes the Wiki4Schools (2008 version - which apparently is the most recent). This is based on mediawiki.

There is a project to provide the same capability using openZim, this could be an alternate in XC.


Dictionary

XC in Nepal includes Wiktionary and a Nepali dictionary (Sabdakos). This will clearly be very deployment-specific.

Sugar Activities

XC includes a repository of Sugar Activities. This allows students to download and install activities of their choosing from the school server.

Dan's Guardian

Web filtering requires lots of disclaimers. Whoever is the authority for deploying a schoolserver needs to sign off that the filtering offered is accepted as adequate. This is part of XS in Nepal but moving it to XS might make the XS build easier.

Moodle

This is installed in XS in Nepal but could be installed in XS. It is dependent on the configuration of the LAMP stack in XS (Apache, MySQL or PostGreSQL). This might be a good time to move to Moodle 2. AFIK no deployment is currently using Moodle so there would be a minimum of issues with backward compatibility.

SchoolTool

While not directly related to the OLPC mission, one of the first uses of computers in schools is to automate the administration (attendance lists, academic calendar, and so on). There is a possibility to integrate SchoolTool with Moodle.

Mothership or Content Update

The model in Nepal and Rwanda is that the central development group provides the same software and content to each school. The school is not expected to make any changes and, if it did, they would be erased on the next update.

It is unlikely that schools will have sufficient broadband access to support concurrent browsing for every XO. However, there should be a mechanism where each school server can connect with the mothership (e.g. cron job) and receive updates and upload changes (e.g. email). The mothership could then include this information in the next connection opportunity for the other schools. There would have to be a parallel mechanism using usb keys (e.g someone from the school goes to town with the usb drive and connects from an internet cafe).

The schoolserver, in turn, provides updates to the XOs.

Socializing/Communication

Open Atrium is based on Drupal. Providing a way for teachers to communicate with the central support group and with each other is very important.

Moodle may offer an alternate way to do this.

WordPress and Planet may also be an option.

In any case, these tools need support from the mother ship. _______________________________________________

References

Retrieved from "https://wiki.sugarlabs.org/index.php?title=School_Server_Wish_List&oldid=66317"