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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>**> 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 >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>** >> >__> >> >> 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 >> >> >> >> >> >
_______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
