[Server-devel] Schoolserver development in Uruguay

Martin Langhoff martin.langhoff at gmail.com
Tue Aug 24 18:05:30 EDT 2010


Hi Bernie, list.

apologies for the latency! Thanks for the work you're doing in Uy, and
for the thoughtful email. Some notes below...


On Thu, Aug 19, 2010 at 8:25 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> == Debian vs Fedora ==

I have spoken with the Ceibal team several times. My recommendation
was that they looked into repackaging, but that some aspects would be
hard to repackage. I am of course happy to include a "debian" dir in
the git repo.

I've also repeated this several times on this list.  I'm kind of
surprised this isn't mentioned at all. Anyone who's been in
server-devel would know anyway ;-)

[ So yes, your work and patches in this direction are very welcome! ]

I have also recommended that Ceibal looks closely at a running XS to
see how it works, how it all fits together.

> == 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.

If you have gathered more info, please share some if possible (in a
separate thread?).

Overall, there are number of reasons that hint at Uy _not_ actually
using Jabber services much. The ejabberd release they are using...
just doesn't work or scale very well.

> 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.

My reaction to this line is unprintable.

At this moment, I will need very strong proof that an xmpp daemon is
more solid and significantly less resource hungry, and easily
hackable. Erlang is hard to hack but when it runs, OMG it runs. And
we've hacked the bit needed.

> == Backups ==
>
> This is a black hole in all deployments I visited.

Server backups, I assume? Let's break this into a separate thread if
you want. Much of it should not be backed up, or benefits from
aggressive hardlinking.

> 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.

I like that.

> Journal backups, however, amount to a whopping 238GB of rapidly
> changing, mostly uncompressible and undeltable data.

Does aggressive hardlinking across users help? (Do users have big
jounral entries that are related to resources many of them download?)

> 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.

That probably gives you worst network performance and usage case.

Assuming the usual asymmetric bw caps, you transfer _double_ the
traffic over bw-limited links just to run the crossed backups.

And the "restore" case gets bogged down (perhaps to an unusable point)
by the "upload" limit on the "other server".

Backup (using rsync) to an "upstream" server makes a lot more sense.

> == Content management ==
(...)
> 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.

And they are right. I _really_ need help to simplify its usage. Lots.

Everything other than Moodle (and I've used a very wide range of
related tools) is... just not fit for this role.

> After they have functioning backups, Uruguay would like to provide a
> wiki.

 - Moodle has a wiki (and a much improved wiki in the next release).
This wiki is 'course' or 'group' oriented.

 - MediaWiki can be easily installed sharing magic login credentials
with Moodle.

> I have a dream that one day each school will evaluate and choose their
> favorite tools autonomously...

More unprintable words follow.

Teachers are overwhelmed. The technical team is overwhelmed by a large
deployment. I am not sending anyone to evaluate (and then integrate!)
random software bits, specially when they usually have no experience
doing that.

The goal of XS is to provide a well-chosen, well integrated set of
tools. (If a deploymetn has the expertise, drive and _time_ to pick
and integrate something else, bravo! Most deployments don't have
them).

> == 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.

Puppet is on its way to be the recommended tool to manage a herd of XSs.

Puppet is -- AFAIK -- a lot more tolerant of bad connectivity, and my
intention is to add a sneakernet mechanism for config updates.

> But no distro advocacy, please... they're all good, ok? :-)

I love/hate them all :-)

Official XS will follow the F/RH lineage, but more are welcome.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff


More information about the Server-devel mailing list