Nepal Wish List

Abhishek Singh of OLE Nepal published a wish list for the School server project, reproduced here. Please comment.

OLPC XS: My wishlist

By Abhishek Singh ⋅ May 27, 2011

The XO school Server, or XS, is one of the products of the OLPC project, designed to complement the XO laptop. It is a Linux-based OS (a Fedora-based distribution) engineered to be installed on generic low-end servers. (Source: http://wiki.laptop.org/go/School_server) School Server has always been an integral part of OLPC deployments. School Server acts as a central hub and provides various services to XO laptops. It also hosts additional contents that could not be fit onto the XOs (it would be worth noting that the XO-1.0 has 1GB of storage space).

Despite given such a prominent position, the development of XS software has stuck somewhat and have lost focus, with the last release on 7 October 2009. The most recent release of OLPC XS (version 0.6) is based upon Fedora 9. The upstream Linux distribution (i.e. Fedora) has made a lot of changes since its version 9 release, and has just released Fedora 15 hosting a lot of new and interesting features.

My work at Open Learning Exchange (OLE) Nepal revolves around building customized images for OLPC XS, XO and bundling the content. I had always wanted to have XS maintained to keep up with the innovations going on at the upstream distribution, as well as to get benefited by new services and infrastructures supported by the newer releases of upstream distribution. We, at OLE Nepal had been doing some changes to the OLPC XS image to suit our needs, and adding services required, but I strongly believe the the worldwide OLPC community can benefit through collaboration, and hence building a general XS image to fit all (it would always be open for local customizations).

Below is a list of changes that I wish to have in the OLPC XS (some of which comes from our own list of customization):

Porting XS to new version of Fedora

Fedora Project has come to the release of version 15 of their Linux distribution host a lot of interesting features, but OLPC XS is still stuck with Fedora 9 (which itself has moved to “End of Life”). This state hinders us from using more stable software components, access to bug-fixes, and improved infrastructure. This also forces packagers to package software for Fedora 9. Porting XS to Fedora 15 will bring into all the awesomeness, but again it will be a lot of work porting the patches and packages (developed by OLPC community) to Fedora 15.

Support for multiple architecture

Though XS is targeted to be run on generic low-end servers (mostly i386 architecture), but the recent trend of hardware price fall, deployers will tend to use more advanced hardware (which might support x86_64 architecture). Current XS effort is targeted at i386 (32 bit) builds, but adding x86_64 (64 bit) builds would not be that cumbersome, and would definitely attract deployers eyeing 64bit hardware.

Basic Self Tests

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.

Inclusion of 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.
• 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 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).
• Java: Adding a Java Runtime Environment (JRE) would add support for running java based applications (e.g. Tomcat, Fedora Commons, etc.)
• tzdata and extensions: Adding timezone data and its wrapper libraries in various languages will help the support for timezone data in applications hosted on XS (e.g. SchoolTool needs pytz).
• SchoolTool: a free administrative software for schools around the 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

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

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

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

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 deal with the XS. I’m not even sure if items off my wishlist are feasible at this time. What is your XS wishlist?

Comments

Abhishek Singh

NEXS (the Nepalese version built upon OLPC XS) has separated the content part from the base server. We call the content part NEXC ("C" for content). This separation has helped us a lot in managing content bundles and content updates. The NEXC generally contains:

   Content of the digital library (see http://www.pustakalaya.org), which is spanned across:
       Database dumps for Fedora Commons and Fez
       Fedora Commons datastream files
       Fez's customized interface (that is being used at pustakalaya.org)
   Wiki for schools
   English Wiktionary
   Nepali Dictionary
   External Content: All the other static content (e.g. video files, maps etc) are packaged as external content
   Learn English Kids from British Council (recently added)

We have a 3-month NEXC release schedule. At every release, we'll bundle the most recent content and put it on a USB HDD, test it internally on our test school server, and then finally release it. After every release, the deployment team will go to the schools with the USB HDDs and plug it to the school server at the site schools. Daniel Drake's usbmount script takes care of installing/updating the content from the USB HDDs - you just nee to listen to the starting and the ending beep during which all the content update is done. We have tried updating it over Internet, but the connection here in Nepal is so flaky and slow (most schools do not even have Internet connection yet), and the content being huge (approx 12GB now), makes it almost impossible.

Corrections to Tony's discussion: Moodle and Dansguardian is not installed as a part of NEXC, rather they are built with NEXS and get installed as a part of NEXS. The NEXS is also not released as an img file (Tony might be confused with NEXO being released as an IMG file), rather as an iso file. The mkusbinstall (using the OLPC forth script) is then used to copy the install image to a usb flash drive (using syslinux).

We would really try to test the Au-script for Anaconda USB race conditions.

All our customizations and scripts are available at a few mercurial repositories hosted at hg.olenepal.org. For NEXS and NEXC, please check:

   NEXS Scripts, http://hg.olenepal.org/NEXS_scripts/
   NEXS Image Builder, http://hg.olenepal.org/NEXS-image-builder/
   NEXC Maint, http://hg.olenepal.org/NEXC-maint/
   NEXC Scripts, http://hg.olenepal.org/NEXC_scripts/

Mokurai

• Fedora 9-->15 +1

• x86_64 +1

• Self tests +1 We should write a tutorial and FAQ on testing, maintenance, and simple admin tasks. I have done such work as a Senior Technical Writer, and would be happy to take part, and to coordinate the project. We will need subject-matter experts, a photographer, an artist, at least one copy editor. Anyone else can contribute, also. If you know nothing about the subject, you can test whether our explanations explain. We can use the collaborative booki software on the Sugarlabs Replacing Textbooks server, booki.treehouse.su, to write and publish this. All of this is an issue in Uruguay, where school servers are kept in locked cages, and Plan Ceibal rigorously limits what can be done with them. For example, they cannot be used for printing.

• Moodle upgrade +1 I will talk to FLOSS Manuals about creating a Moodle manual. Can you get some Nepali translators for us?

• "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." Have you considered FidoNet? I can get Tim Pozar, one of the original FidoNet implementors, into this discussion. He is currently working on free wide-area wireless networks. Would you like to talk to him about that, too? Or Clif Cox, who designed the wireless network for all of Bhutan?

• Dansguardian for Internet filtering, with customizable Unicode messages for blocked sites. +1 Unless someone knows of a better alternative.

• Socializing and communication platform, with provision for forwarding messages when Internet connectivity is available. +1 I, too, have been looking forward to such a function. I consider linking all of the children of a country to be as important as any educational content we can provide. Actual contact with the widest possible variety of people is essential for overcoming prejudice. Regular contact promotes friendship, language learning, cultural and geographic learning, and forming alliances for later development of civil society and founding of businesses.--Mokurai 18:40, 27 May 2011 (UTC)

Aleksey Lim

From my side, I see the whole picture in case of school server like having:

• sugar-server, the base of any school server. it doesn't provide stuff like moodle (too complicated to be basic) or puppet (useless on this level, since configuring sugar-server should be just install packages/iso and do some automatic work, the higher levels might user puppet or so)
• any additional services that might be useful in some deployments but are not basic, eg, moodle or wiki. sugar-server should provide needed info via reliable API for these services. in my mind, such services might be formed as separate projects (like sugar-server-moodle) to make it possible to attach it on purpose (there might be useful configuration tool that is being used in sugar-server, mace).
• final products that include components on purpose (but sugar-server is a required one). It is entirely depends on local needs.

My own running though your wishlist keeping in mind sugar-server plans:

1. Porting XS to new version of Fedora
   • sugar-server will be build on OBS for distros that are being used in the field (deb or/and rpm based). So, downstream can just use these packages, add new one and create the final product (there is an idea to teach OBS to create isos for not only SUSE, obs is designed originally)
2. Support for multiple architecture
   • see the 1), as well for arches
3. Basic Self Tests
   • I'm gathering all OLPC XS packages/services/scripts to one project, one package, one CLI tool. unittest for this stuff is a from-scratch decision. Also, having additional projects like sugar-server-moodle, let people concentrate, thus test better (including auto tests) this exact module.
4. Inclusion of new packages
   • Entirely not sugar-server level
5. Content Updates
   • no ideas, but would be useful (thanks to new modular desing) to have some experiment sugar-server-* modules to test
6. Web content filtering
   • Agree, it should be a basic component (and it will be a part of sugar-server)
7. Journal Backup on a shared model distribution
   • See the 5)
8. Socializing/Communication Platform
   • See the 5)