[Server-devel] Schoolserver development in Uruguay

SgtPepper ncorrare at gmail.com
Thu Aug 19 21:24:35 EDT 2010


Bernie, Guys:
A few of my ideas are below:

2010/8/19 Bernie Innocenti <bernie at codewiz.org>

> 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.
>
> Whichever the distro... It should be easily maintainable and deployable.
I've no problem in building the dpkg's of the XS components. I think its
justified, since there is a 2500 servers base. Let me tell you that I've
only worked with rpm before, but I've no problem in learning the Debian
guidelines, and maybe, try to push the packages into debian testing.


> 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.
>
>
> How about 2 500GB in RAID-1? I mean, specially in Paraguay, bandwidth is
scarce.


> == 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.
>
> There is also another project, called Proyecto ALBA (at least I'm sure its
in spanish) for course, grades, and students management. Its worth taking a
look. If you want I can try to set up a demo in a virtual server at home.
Still, a wiki its very usefull at school. I don't thinkg it replaces moodle,
but complements it.

>
> == 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? :-)
>
> I'm one of the Spacewalk fans, but until they get Oracle out of the way...
The guys at La Rioja here wanted to go with puppet. I'll also go ahead and
try CFengine.

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> _______________________________________________
> Server-devel mailing list
> Server-devel at lists.laptop.org
> http://lists.laptop.org/listinfo/server-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/server-devel/attachments/20100819/0c1b1550/attachment-0001.htm 


More information about the Server-devel mailing list