[Server-devel] Journal backup on school server

George Hunt georgejhunt at gmail.com
Sun Apr 7 08:42:39 EDT 2013


Thanks Tony,

I really am enjoying reading your code.  Some tricks there that I'm
learning from.

It seems to me that your retinking of ds-backup makes a wonderful addition
to the ways we can think about ds-backup. I'd like to set up a github repo
which starts from the current laptop.org one, and then branches to all the
different ways ds-backup can be expanded.  Eventually, each branch could
become it's own thing.  It might be nice to incorporate an upgrade feature
in ds-backup, so that when a specific school server is installed, and the
XO's connect to it, the proper ds-backup behavior is substituted.

George


On Sun, Apr 7, 2013 at 7:46 AM, Tony Anderson <tony_anderson at usa.net> wrote:

> Hi,
>
> I have attached the ds_backup.py code. Tack on all disclaimers - it has
> not been tested in the XS-0.7 and 12.1.0 environment. It will need some
> revision to deal with the 'shared' XO environment in Lesotho so I will work
> on it while I am there.
>
> However, it really is not changed from XS-0.7 in areas that matter to you.
> The changes are in the way the Journal objects are handled. Martin Langhoff
> used rsync so that the backup is a snapshot of the local datastore. I am
> trying to establish the server-side as the real Journal with the local
> datastore containing only the currently relevant content. It seems sad that
> kids must delete their Journal because of the limited size of the local
> store. The message: Journal is full is not helpful, because the fact is
> that the store is full, often because of the excessive number of installed
> activities. With a school server, this is totally unnecessary since the
> Sugar Activities are available on the school server so that unused ones can
> be deleted on the XO.
>
> I had to move to mod_wsgi for Django (library). As far as I know, there is
> no change needed client-side. Apache needs to have wsgi installed (in
> XS-0.7 it is). Then all that is needed is a file in httpd/conf.d.
> I have also attached the one I am using.
>
>
>
> On 04/07/2013 06:04 AM, George Hunt wrote:
>
>>
>> Hi Tony,
>>
>> I'm playing with ds-backup now, because one of the dependencies for
>> ds-backup is mod_python which was dropped from fedora 18, in favor of
>> mod_wsgi. It seems like a great time to rethink the issue.
>>
>> I cannot find the working code you mention in this email in my google
>> stack.  Can you send it to me again?
>>
>> I'm also talking with Tim Moody, about using puppet client as a way of
>> pushing and modifying the configuration of XO's in the classroom.  Do
>> you have any experience, or ideas, about such a proposal? I'm not sure
>> whether ds-backup might be used to introduce puppet client back into XOs.
>>
>> George
>>
>> On Sun, Dec 9, 2012 at 12:25 PM, Tony Anderson <tony_anderson at usa.net
>> <mailto:tony_anderson at usa.net>**> wrote:
>>
>>     Hi,
>>
>>     I will send you the scripts as soon as I have a chance to try them
>>     on 12.0.1 and XS-0.7. Last year they were running on xs-0.6 and
>>     build 852 at Saint Jacob. There shouldn't be too much difference,
>>     although so far on most of the code I have been wrong by about 3 days!
>>
>>     The identity problem really isn't that hard. A lot of the mailing
>>     list discussion seems related to running Sugar on something besides
>>     an XO.
>>
>>     The user is identified on the server by the serial-number. For the
>>     backup, this is not a problem. The problem comes from <OLPC where an
>>     XO is shared. Then there needs to be something like a login to
>>     identify the actual user. There also needs to be separate Journals
>>     on the XO and separate backups on the school server.
>>
>>     I should be able to give you working code within a week (I leave
>>     Kigali on 12/23 so it must be before then).
>>
>>     Yours,
>>
>>     Tony
>>
>>
>>     On 12/09/2012 04:11 PM, George Hunt wrote:
>>
>>         Wow Tony,
>>
>>         Your solution definitely needs to be part of the mix as we go
>>         forward.
>>         Can you send me copies of the scripts, or the changes you made to
>>         accomplish these objectives?  If we are going to look at the
>>         serialnumber-user-identity issue, we might be making changes to
>>         the same
>>         packages.
>>
>>         Have you worked through the changes needed to add user identity to
>>         journal backups? As Paul Fox was suggesting, I think there will
>>         be lots
>>         of ripple effects, if and when we start adding additional users,
>> in
>>         addition to the user "olpc".  Or maybe, someone will come up with
>> a
>>         simplifying assumption, or approach.
>>
>>         George
>>
>>
>>
>>         On Sun, Dec 9, 2012 at 4:49 AM, Tony Anderson
>>         <tony_anderson at usa.net <mailto:tony_anderson at usa.net>
>>         <mailto:tony_anderson at usa.net <mailto:tony_anderson at usa.net>**
>> >__>
>>
>>         wrote:
>>
>>              Hi, Sameer
>>
>>              I got an email from Nick Doiron re his visit to the Marshall
>>              Islands. He mentioned that you gave him a script to create
>>         a csv
>>              from the Journal backup.
>>
>>              As I have mentioned several times on the list, I believe
>>         Martin's
>>              backup scheme while elegantly implemented is not adequate.
>>         His model
>>              is the traditional backup/restore.
>>
>>              The problem, as always, is storage space. When an XO-1 is
>>         out of
>>              space, the user gets a message 'Journal is full'. The only
>>         practical
>>              solution often is to reflash the XO losing all of the Journal
>>              objects. If a user deletes an object from the Journal on
>>         the XO, the
>>              rsynch also removes it from the backup.
>>
>>              I modified the scripts ds-backup.sh and ds-backup.py on the
>>         XO to
>>              use a different paradigm. The registration process creates
>> two
>>              scripts in the /library/users/serial-number folder on the
>>         school
>>              server: journal and log. The backup script uploads the
>>         object to
>>              journal if there is an associated data file; otherwise, it is
>>              uploaded to the log folder and deleted from the local
>>         store. The
>>              remaining objects are marked as favorites in the Journal
>>         Activity to
>>              show that the data file is available on the XO. If the user
>>         clears
>>              the star, the data file is deleted from the datastore but
>>         remains on
>>              the school server. If the user fills a clear star, the
>>         backup script
>>              downloads the data file from the school server.
>>
>>              At Saint Jacob, all of the laptops are 4gb XO-1.5 so I have
>>         not had
>>              to implement storage management. The plan would be to set
>>         limits on
>>              the size of the datastore and the /home/olpc/Activities
>>         folders. If
>>              a datastore outgrows the limit, data files can be deleted
>> LRU.
>>              Similarly, activities can be deleted LRU. This way the user
>>         will not
>>              have to be involved. The user can always request a needed
>>         file to be
>>              restored to the local datastore and can request an activity
>> be
>>              downloaded and installed from the school server repository.
>>         I expect
>>              this will be needed in Lesotho for XO-1.
>>
>>              This method also supports restoring the users Journal after
>>         a reflash.
>>              It also enables a replacement laptop by renaming the
>>         serial-number
>>              folder on the school server (and updating the registration
>>         information).
>>
>>              I am not sure if you are trying to implement this
>>         functionality, but
>>              it is important at a deployment.
>>
>>              Yours,
>>
>>              Tony
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20130407/bcd64b33/attachment.html>


More information about the Server-devel mailing list