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