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
_______________________________________________
Server-devel mailing list
[email protected]
http://lists.laptop.org/listinfo/server-devel
