184
edits
Changes
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..."
'''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 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 all a deployment to select
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 similar to XS-0.6 with some changes and addtions discussed below.
'''Base system'''
Fedora: 15
Apache:
MySQL:
PHP:
'''Additional Components:'''
Python 2.?
Python 3.?
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.
'''Sugar Support'''
This is not a complete list but some examples include:
idmgr - registration of XOs
Journal backup and restore
XO lease-activation
'''Network'''
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.
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.
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 componsed 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.
The question in the deployment is the XS build ok and has it been correctly installed on a specific
server. In Nepal, this is satisfied by
(1) mkusbinstall works,
(2) the install works, and
(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
(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).
"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 evnvironment 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.
*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?
_______________________________________________
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 all a deployment to select
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 similar to XS-0.6 with some changes and addtions discussed below.
'''Base system'''
Fedora: 15
Apache:
MySQL:
PHP:
'''Additional Components:'''
Python 2.?
Python 3.?
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.
'''Sugar Support'''
This is not a complete list but some examples include:
idmgr - registration of XOs
Journal backup and restore
XO lease-activation
'''Network'''
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.
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.
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 componsed 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.
The question in the deployment is the XS build ok and has it been correctly installed on a specific
server. In Nepal, this is satisfied by
(1) mkusbinstall works,
(2) the install works, and
(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
(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).
"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 evnvironment 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.
*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?
_______________________________________________