[Server-devel] XSCE 0.3

[Tony Anderson]

Hi,

This is going to take some time to provide a useful reply.

Perhaps, the easiest way is to comment on the XSCE specification:

Summary

 >The school server is very similar in concept to a standard home 
wireless router.

The school server is a server. The router provides network access to the 
server.





 >In everyday usage it provides various services which extend 
capabilities of the connected laptops while being totally transparent to 
the user.

The school server provides the storage capacity not available on the XO. 
In the deployments I serve, there is no internet access. The school 
server is 'an internet in a box'.


 >These services can include:

     >Network connection – various services similar to what you would 
find in a home router.

This service is provided by a router.

     >Presence server – Augments sugar's native collaboration functionality.

Yes - this has always been a part of XS.

     >NEW IN 0.4 - Web filtering – Enables schools to comply with 
local/legal restrictions on internet access for children.

This has been deployed by OLE Nepal since XS-0.4 in the form of Dan's 
Guardian - no need to re-invent this wheel. This is, of course, 
irrelevant in deployments not connected to the internet.

     >NEW IN 0.4 - XS-Stats - Enables deployments to collect anonymous 
student usage.

School staff need the ability to keep a 'gradebook' with information on 
student accomplishments that is not anonymous. The above feature is a 
need for the deployers, not the school.

     >NEW IN 0.4 - Backup and Restore.

This has been provided since XS-0.4. The primary problem here is that 
the backup is considered as a backup (for use in emergency restore 
situations). The real need is to maintain the Journal on the school 
server for active recall as needed. Over time, the Journal grows to fill 
the available capacity on the XO. Currently, the fix is to delete 
Journal items. The current backup also deletes these items from the backup.

Currently, I am using a modified ds_backup.py script which treats the 
Journal as a store for documents. These are uploaded to the school 
server. Metadata only entries are uploaded to a log and deleted from the 
datastore. The user has the option to delete documents from the data 
store and then to reload them from the school server.

 >[edit] Reference User

 >The XS-CE has two different types of reference user:

     Skilled sysadmins running micro-deployments
     Mid-sized deployment with limited onsite sysadmins

The user of a server are the client computers. In general, a school 
server should need no admin attention beyond morning start up and 
evening shut down during a school year. The development arm of the 
deployment should prepare updates for installation between school years.

 >[edit] Hardware

School servers can be either an XO or standard x86 based hardware.
[edit] XO

XSCE v0.4 will run on all 4 XO laptops:

     XO 1 - Likely experimental
     XO 1.5
     XO 1.75
     XO 4

In common usage, the XO may be augmented by SD cards and two off the 
shelf USB devices:

     Network connector – Allow the server to offer internet access to 
connected XO's.
     2 USB ethernet dongles.
     NEW IN 0.4 -- External USB hard drive – Allows the server to 
provide additional storage capabilities.

The school server platform should meet the following requirements:
	
	1. Large memory capacity (2GB+)
         2. Large persistent store (500GB+)
         3. Operates directly from 12vdc battery (e.g. car or marine 
deep cycle)
         4. Low power consumption (e.g. <2x XO 4.0). Power consumption 
dictates the size of the solar panel required to charge the batteries.
         5. Headless operation. Schools with a monitor, keyboard, and 
mouse attached the school server will be tempted to use them as a client 
system - with negative impact on stability.
         6. Low cost (e.g. < 2x an XO or < $400)

Most other requirements are satisfied automatically be the system chip 
set (e.g usb ports, ethernet port, etc.)

 >[edit] Standard Hardware

 >For greater flexibility some schools will want to use standard hardware.

     Trim-Slice.
     Raspberry Pi

The Trim-Slice indeed appears to meet the requirements for a school 
server. I plan to try one in the next few weeks. One interesting 
possibility is to boot from an SD card for installation and 
trouble-shooting (via SSH).

The Raspberry Pi is attractive (esp. for low cost); however, I am 
concerned about it's physical packaging in a school environment.

 >Diligent volunteers can help make x86, x86-64bit, and ARM support 
increasingly widespread.
[edit] Deliverable
[edit] RPM

XS-0.7 is deliverable now, albeit without ARM support.

A RPM combined with tested installation instructions necessary to 
convert a standard XO or Fedora-compatible computer into a School Server.
[edit] IMAGE

XS-0.7 has tested installation instructions - although the mkusbinstall 
could be made a little more robust. As mentioned above, it could be 
possible on the Trim-Slice to install the school server as an image on a 
hard drive from an SD card.

 >NEW IN 0.4 -- A downloadable USB flash drive image, combined with 
tested installation instructions, which permit deployment staff to 
install XSCE software without an internet connection.
[edit] Base OS

     OLPC-OS 13.2.0
     Fedora 18

I consider running a school server on an XO as similar to using a Smart 
car as a school bus. I realize that bureaucratic procurement problems at 
some large deployments may make this the only option. Luckily that is 
not a problem so far at deployments I am servicing.

 >[edit] Modular design

 >One of the key design criteria of successful community-based projects 
is modularity.

 >Plug in services
[edit] Configuration Tools
[edit] GUI

 >Command line configuration/administration should eventually be 
discouraged as the system matures. Future target users are often not 
familiar with Linux system administration. Initial setup or fixing a 
problem with their server is not a good time to introduce system 
administration skill.

System administrators and a deployments development team will use the 
command line because it is the most efficient tool available. In 
general, server administration is not and should not be done on a 
production machine.

[edit] Remote Configuration

 >NEW IN 0.4 -- Remote administration – There are several systems such 
as CFEngine and puppet which enables remote management.
[edit] Command Line

The problem here is that the school server is not connected to the 
internet. There are many available and proven technologies to manage 
networked computers.

It would be handy if the XOs at a school could be managed from the 
school server. Perhaps Puppet is the right technology for this task.

Where a 'mother ship' is possible managing school servers (and XOs) at 
multiple schools, the problem is often that the school server connection 
to the internet (WAN) is via DHCP. One solution is for the school server 
to call home periodically.

???
 >>[edit] Core Server

 >>>The core server will contain five services which can be extended via 
extended services.

 >Service: Network setup
Purpose:
Provider: xs-setup-network


 >Service: Dynamic Host Configuration Protocol
Purpose: Schoolserver and clients need to be on same subnet.
Provider: dhcpd

 >Service: Iptables -- Network Address Translation (NAT)
Purpose: Permits all XO’s to access the internet.
Provider: gateway (?)


 >Service: Internet domain name server
Prupose:
Provider: named

 >Service: Backup student work
Purpose: To back up student work
Provider: idmgr

Idmgr registers XO laptops by serial number. Registration is a 
requirement for backup which is provided by ds_backup.sh and 
ds_backup.py. (run by chron).

Service: Restore student work
Purpose: ???
Provider: ???

 >Service:Jabber server Purpose: collaboration > 15 clients needs to work.
Provider: ejabberd
[edit] Extended Services

Actually, Ejabberd serves all connected XOs (>100 at most schools). I 
doubt that 'collaboration' in this technical sense is widely used in 
deployments. Sadly, it is not in the deployments I service.

Currently, all XOs are connected in the same emulated 'mesh' network. I 
think this would be better configured so that XOs in a single classroom 
form a 'mesh'. This can be done by the administration tools included 
with Ejabberd.

 >Service: Web server
Purpose: Building block for many other extended services
Provider: apache

Apache, of course, services web requests.

 >Service: proxy server and web cache
Purpose: bandwidth, web-filtering, web-monitoring
Provider: squid

I suspect that squid is of little use for school servers not connected 
to the internet. It will certainly be needed if all connected XOs are 
surfing.

I really think that we may never see a deployment which provides direct 
XO access to the internet for all XOs due to cost and bandwidth issues.
In the developing world, the internet provider is a telecom company 
which charges for time and megabytes downloaded. Most require special 
contracts for shared usage. A more likely scenario is that the school 
server will download information from the internet (e.g. email) in batch 
by a cron job.



 >>Service: Moodle
Purpose:
Provider:

Purpose is well described by a blank entry. I have not heard of a 
deployment making a constructive use of Moodle. It is, of course, a 
standard part of XS.

 >>Service: OLPC-update
Purpose: OLPC-update is necessary to update the kernel of XO
Provider: rsync

While this is available, I have never been able to make use of it. 
Generally, the XO software should be updated only between school years. 
In this context, there is a need to update much more than the kernel. I 
am not sure rsync is the right vehicle (what do you do about the 
datastore, for example?) The school server gives access to all of the 
activities on ASLO; how does rsync deal with a different installed base 
of activities on different XOs?

 >Service: Activity update
Purpose: Enables teachers to easily distribute new or updated activities 
to their students
Provider: activity updater

I assume this refers to Sugar activities. With a school server, the 
situation is more complex. Teachers can assign specific activities using 
a Sugar Activity (e.g. Memorize with a specific quiz or to read a 
specific text or to write a report or to take a test). I have not found 
the 'Activity update' to be useful.

 >Service: Virtual Private Network (VPN)
Purpose: Creating secure point-to-point or site-to-site connections in 
routed or bridged configurations and remote access facilities
Provider: openvpn

I assume this could be a good alternative where a 'mother ship' is feasible.

 >NEW IN 0.4 -- Service: Content filtering (TimM??)
Purpose: age-appropriate surfing, legal compliance, religious risks
Provider: dansguardian and opendns

One concern - the development team for the deployment must make it very 
clear (in writing - CYA) that the school server provides a filtering 
mechanism but the responsibility for using this capability belongs 
totally to the school administration. I don't think any of us want to be 
the target of legal action if some child finds something inappropriate 
on the internet.

NEW IN 0.4 -- Service: 1-N WebDEV(JerryV, GeorgeH)
Purpose: Journal submissions to teacher, academic record (homework etc)
Provider: WebDAV

This is an important requirement. Is this implementation documented?

 >NEW IN 0.4 -- Service: Statistics Collection
Purpose: Collects users statics for academic research
Provider: pilot monitoring system

 >NEW IN 0.4 -- Service: Book server (SameerV, AlexK, GeorgeH struggling!)
Purpose: compete with Khan Academy?
Provider: pathagar

OLE Nepal has provided Pustakalaya capability on the school server since 
XS-0.4. This capability is provided at the schools I am servicing using 
Django (as does Pathagar). The webkit based Browse Activity supports the 
library directly (eliminating the need for the Library activity). The 
important point is that there are two parts to this requirement: (1) a 
means to add items to the library and (2) a means to download items 
selected by the user to the XO for offline use.

 >>NEW IN 0.4 -- Service: Internet in Box
Purpose: Provide offline content
Provider: ???
[edit] Future Features and Objectives

I hope to have the opportunity to work with 'Internet in a Box' this 
summer. Possibly, XS could be installed on the Seagate device. Possibly, 
the content on the Seagate could be added to the school server.

 >>    Browser-based GUI Config - as primary configuration tool? To 
configure install setup and core services?
     Puppet remote management (future service below, design goals 
reviewed May 2013)
 >>    ejabberd roster admin
Currently availbale with ejabberd.

     >>Consideration of other devices (Android, Kindle, iPods, iPads)
As clients>.

     >>Content curation (beyond dumping stuff into Apache directories)
I am not sure I understand what is meant here. Certainly the deployment 
is responsible for curating the content on the school server.

     Khan Academy

Currently installed at the schools I am servicing, including the 
exercises. There are 40 topics for primary school (through pre-algebra).
There is some difficulties. The videos can be converted to ogv at 
considerable expense in computer time (ffmpeg2theora). Alternatively, 
mp4 and mp3 capability can be added to the XOs. The videos and exercises 
are licensed under Creative Commons. However, the student profile is 
not. This means an alternative must be developed.

[edit] Future services

Please consider adding features and objectives to this list if you feel 
they should be included in a future release. If you consider the feature 
important and are willing and able to do the necessary work please sign 
your name to take responsibility for that service.

Service: (GeorgeH, Gerald, AnnaS)
Purpose: local distribution/replication of Sugar Activities etc
Provider: pdsh

Done.

Service: MediaWiki
Purpose:
Provider:

Done

Note: Daniel Drake has provided an effective mechanism to add 
capabilities to the server via 'usbmount'. MediaWiki can be added by a 
simple script (the only tricky part is adapting to pgsql). Wiki4Schools 
is also available. Django was added in the same way.

There are some capabilities that would be very desirable:

1. Email. This requires an email client on the XO (there have been some 
attempts to build such a activity, e.g. Gmail.activity). The email 
system should operate locally among the registered XOs as well as 
batch-forward and receive email via usb key from a local internet cafe 
or from a periodic connection via gsm. The system should also provide 
mailing lists (e.g. school computer club).

2. Printer. The ability to attach a printer to the school server. XOs 
should be able to put printable items in a print queue. The school 
administration should be able to select which items are to be printed 
(ink and paper cost $). Having print drivers on the XO should not be 
required.

3. Portable Journal. In the Lesotho schools, there are not enough XOs 
for one to be permanently assigned to a student or teacher. Even in a 
true OLPC environment, laptops at home will be used by family members.
There should be a login facility to identify users. Separate datastores 
should be kept for each user. The datastore backup should backup up by 
user, not serial-number. The Journal should enable a logged-in user to 
load his/her Journal from the school server (metadata) and documents as 
needed. This facility should certainly support changing laptop 
assignment (e.g. when the user's laptop needs repair).

4. Wiki collaboration. The school server in general assumes that it is 
provided by an external deployment and that it will not be modified by 
the clients (except for the Journal). There should be a means for 
students and teachers to create collaborative documents, Wiki-style.
Perhaps this can be done by setting up a local wiki in mediawiki. 
Perhaps, something like Tiddly-wiki or etherpad would be useful.

The school server provides services. There can never be a definitive 
specification of those services. At least, the above are my thoughts at 
the moment.

Tony

On 05/28/2013 10:39 PM, David Farning wrote:
> Tony,
>
> I was wondering if you have gotten to take a look at the XSCE project
> lately. We have done a lot of modularization so that people can test out
> different ideas on a common platform.
>
> Any thought on if your work can be adopted to run on XSCE as an
> 'extended service'?
>
> --
> David Farning
> Activity Central: http://www.activitycentral.com