[Server-devel] Schoolserver development in Uruguay

Bernie Innocenti bernie at codewiz.org
Thu Aug 19 20:25:14 EDT 2010


I'm currently at Plan Ceibal. As you may know, Uruguay developed its own
schoolserver based on Debian, running software developed in-house and
managed with CFengine. Yesterday we briefly discussed their future plans
for the school server.


== Debian vs Fedora ==

First of all, there's no way they're going to reinstall 2500
schoolservers with Fedora or even a newer release of Debian. Online
upgrades would be possible, though.

There's some interest in repackaging in Debian the datastore backup
server and other components of the OLPC XS. This work could be
contributed back to you or whoever will become the next schoolserver
architect.

Perhaps we could get one of the Debian maintainers in our community to
get these packages accepted. I could do the same for Fedora.

As you said, recommending or supporting multiple schoolserver
configurations in parallel doesn't make sense, but it wouldn't hurt if
some of the underlying components were shared horizontally, especially
for the configurations that are already widely deployed.


== Jabber ==

There are two people working on Jabber. They have been using ejabberd
and, quite surprisingly, they've not seen any issues of high CPU load
and database corruption. Tomorrow I'll get to work more with them.

I still had no time to review Prosody, the Jabber implementation
recommended by Collabora. My hacker senses are telling me that switching
from Erlang to Lua is a small step in the direction of sanity and
simplicity.

The Sugar Labs Infrastructure Team has setup new dedicated VM for
collaboration, but at this time nobody has been working on it. It's an
Ubuntu Lucid machine, but we could reinstall it if needed.

Tomeu and Collabora overwhelmed the collaboration stack in Sugar 0.90
and seem to have plans to further evolve it. They should be consulted
prior to making any long-term decision on the server side.


== Backups ==

This is a black hole in all deployments I visited.

Redundant storage is too expensive. One cheap 500GB hard-drive is
typical. In one year, 3 of the 10 schoolservers in Caacupé developed a
hard drive failure.

Loosing all data is sadly the status quo in both Uruguay and Paraguay. I
worked on implementing remote backups for a subset of /library using
rsync, but 2Mbit per school and 70Mbit on the backup server are
insufficient for the initial sync and probably also for nightly updates.

What numbers are we talking about, in terms of size? Here are some
numbers from an actual school which has been operating for over one year
with 530 registered laptops:

 262M   backup
 19G    cache
 3.4M   games
 1.7M   orug
 62M    pgsql-xs
 67M    uploads
 238G	users
 20K	webcontenido
 17M	xs-activation
 516M	xs-activity-server
 827M	xs-rsync
 2.7G	zope-var

The feasibility of remote backups varies depending on how much we care
to backup. In Paraguay, it was decided that the journal backups are to
be considered a valuable if we are to instill the idea in teachers that
the laptop is the same of a notebook with homework on it.

Journal backups, however, amount to a whopping 238GB of rapidly
changing, mostly uncompressible and undeltable data. Quite not the ideal
case for an incremental backup. With today's available resources, we
could afford to backup everything *but* the journals.

Yesterday Daniel Castelo and I discussed the idea of performing
cross-backups between nearby schools. This solution would probably work
well in terms of bandwidth distribution, but it would bring some
logistic complexity. Probably an acceptable trade-off.


== Content management ==

Paraguay seems quite happy with Plone, but frankly I can't understand
why. Teachers heavily use a really simple php tool called PAFM, which
provides basic hierarchical file management with no access control or
versioning.

Oddly, I've not yet may anyone using Moodle. When I ask why, I always
hear some vague comment about it being designed for higher education.
Same goes for Schooltool. These more structured tools probably present
an steeper learning curve and a bad fit for unsophisticated requirements
of users who are being exposed to information systems for the first
time.

After they have functioning backups, Uruguay would like to provide a
wiki. They have already looked at Dokuwiki, with which I'm not familiar.
It seems to have a readable and easy to learn Creole-like syntax. I
would personally recommend going either for the simplest possible wiki
in this category, or straight to Mediawiki--the most feature-complete
out there.

Any mid-size solution such as MoninMoin is likely to bring the worst of
both worlds. Having written my own minimalist wiki, perhaps I'm slightly
biased on this topic. Just slightly, yeah :-) 

Seriously, the choice of wiki would depend on what other tools would
complement it. If you already have Moodle or Schooltool, you probably
need just a basic wiki for taking notes on the side. With Mediawiki, one
would probably install a bunch of powerful extensions to build
calendars, lesson plans and even student records right inside the wiki.

I have a dream that one day each school will evaluate and choose their
favorite tools autonomously... but this is still a few years into the
future. For the time being, we have to make a choice that would fit
everyone and requires minimal remote management. If we make an impopular
choice, teachers will simply start using Google Docs and other online
tools.


== Server management tools ==

Paraguay uses Puppet. We're very happy with it.
Uruguay uses CFengine. They seem to be very happy with it as well.

Both employ a flat hierarchy with one puppet master controlling all the
schools, which is simple and straightforward, but requires excellent
connectivity.


Needless to say, comments are very welcome. Especially criticism.
But no distro advocacy, please... they're all good, ok? :-)

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/



More information about the Server-devel mailing list