[Server-devel] Schoolserver development in Uruguay

Bernie Innocenti bernie at codewiz.org
Thu Aug 19 23:51:52 EDT 2010


El Thu, 19-08-2010 a las 20:56 -0600, Daniel Drake escribió:

> XS-0.6 and some of the package updates that come later fix a few bugs
> related to ejabberd CPU/DB. I guess in Paraguay they are still on 0.5.

Indeed. Three schools moved to 0.6 due to an HD crash and the 27 new
schools which are receiving th next wave of laptops will have 0.6 too.

Is there a documented upgrade procedure for the remaining 7 schools? If
not, can we hope "yum upgrade" to be sufficiently smart?


> But it's not a huge issue because the XOs also have a copy of the
> journal. So, if technical resources are available for a quick XS
> repair, disruption should be minimal.

Also my thinking.

There's however the problem of loosing registrations to the
schoolserver.

With Sugar 0.84, all the laptops in the school would be stuck without
the "Register" menu item.

In Dextrose-1, we've worked around this and similar cases by providing a
"Register Again" function.

Admittedly, this solution sucks. Ideally we'd want laptops to probe for
a schoolserver in the background and attempt to register automatically
until they gain access. Something like the patch for Sugar 0.82 which
you wrote. I wanted to rework it for 0.88 so we could merge it in
Dextrose, but there wasn't enough time.


> You're giving numbers but missing an important consideration - the XS
> backup system makes multiple backups. And it'll continue to do make
> more and more copes until it meets a certain threshold based on disk
> size (likely to be 238GB in your case). At this point, it will purge
> the oldest backups before making new ones.

Oops.

Actually, no cleanup was being done on that particular schoolserver.
There was a /var/lib/ds-backup/ds-cleanup.run left there from 2009 :-(


>[...]
>
> It's possible that within that space you have 10 backups of every
> journal. So you could possibly get away with a disk half the size, and
> "only" retain 5 copies. I'm inventing numbers (and they aren't
> strictly copies either), but you can provide real ones - how many
> backups (on average) are there of a journal in this server? What's the
> disk space used if you only total the space used by the most recent
> backup of each journal? Also, is it possible that your space-measuring
> script is counting a 5mb file with 2 hardlinks as 10mb of used disk
> space?

Heh, these are good questions, but answering them all would take quite
some time, and it's 1AM over here :-)

You still have shell accounts on our schoolservers. Feel free to perform
any forensic analysis of this kind.


> "Excellent" is a bit subjective, but yes, the fact that it requires
> any form of connectivity is a roadblock in many cases. However, we
> came up with a way around this (ideas only, for now, but wouldn't be
> hard to implement) for puppet:
> - clone all the puppet repositories and the config files and put them
> on a USB disk (and do this periodically)
> - install puppet-server on all the XSs (but dont run it by default)
> - go to a school with said USB disk, plug it in and run puppet-server
> - run puppet-client, connecting to localhost
> - stop puppet-server, unplug USB disk, go home

Excellent idea, although the complexity of puppet is hard to justify if
the only thing it provides over a mere shell script is some
sophisticated dependency checks.

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



More information about the Server-devel mailing list