<div dir="ltr"><br><div class="gmail_extra">Hi Tony,</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I cannot find the working code you mention in this email in my google stack. Can you send it to me again?</div><div class="gmail_extra"><br></div><div class="gmail_extra">
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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">George<br><br><div class="gmail_quote">On Sun, Dec 9, 2012 at 12:25 PM, Tony Anderson <span dir="ltr"><<a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
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!<br>
<br>
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.<br>
<br>
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.<br>
<br>
I should be able to give you working code within a week (I leave Kigali on 12/23 so it must be before then).<br>
<br>
Yours,<br>
<br>
Tony<div class="im"><br>
<br>
On 12/09/2012 04:11 PM, George Hunt wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Wow Tony,<br>
<br>
Your solution definitely needs to be part of the mix as we go forward.<br>
Can you send me copies of the scripts, or the changes you made to<br>
accomplish these objectives? If we are going to look at the<br>
serialnumber-user-identity issue, we might be making changes to the same<br>
packages.<br>
<br>
Have you worked through the changes needed to add user identity to<br>
journal backups? As Paul Fox was suggesting, I think there will be lots<br>
of ripple effects, if and when we start adding additional users, in<br>
addition to the user "olpc". Or maybe, someone will come up with a<br>
simplifying assumption, or approach.<br>
<br>
George<br>
<br>
<br>
<br>
On Sun, Dec 9, 2012 at 4:49 AM, Tony Anderson <<a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a><br></div><div><div class="h5">
<mailto:<a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>><u></u>> wrote:<br>
<br>
Hi, Sameer<br>
<br>
I got an email from Nick Doiron re his visit to the Marshall<br>
Islands. He mentioned that you gave him a script to create a csv<br>
from the Journal backup.<br>
<br>
As I have mentioned several times on the list, I believe Martin's<br>
backup scheme while elegantly implemented is not adequate. His model<br>
is the traditional backup/restore.<br>
<br>
The problem, as always, is storage space. When an XO-1 is out of<br>
space, the user gets a message 'Journal is full'. The only practical<br>
solution often is to reflash the XO losing all of the Journal<br>
objects. If a user deletes an object from the Journal on the XO, the<br>
rsynch also removes it from the backup.<br>
<br>
I modified the scripts ds-backup.sh and ds-backup.py on the XO to<br>
use a different paradigm. The registration process creates two<br>
scripts in the /library/users/serial-number folder on the school<br>
server: journal and log. The backup script uploads the object to<br>
journal if there is an associated data file; otherwise, it is<br>
uploaded to the log folder and deleted from the local store. The<br>
remaining objects are marked as favorites in the Journal Activity to<br>
show that the data file is available on the XO. If the user clears<br>
the star, the data file is deleted from the datastore but remains on<br>
the school server. If the user fills a clear star, the backup script<br>
downloads the data file from the school server.<br>
<br>
At Saint Jacob, all of the laptops are 4gb XO-1.5 so I have not had<br>
to implement storage management. The plan would be to set limits on<br>
the size of the datastore and the /home/olpc/Activities folders. If<br>
a datastore outgrows the limit, data files can be deleted LRU.<br>
Similarly, activities can be deleted LRU. This way the user will not<br>
have to be involved. The user can always request a needed file to be<br>
restored to the local datastore and can request an activity be<br>
downloaded and installed from the school server repository. I expect<br>
this will be needed in Lesotho for XO-1.<br>
<br>
This method also supports restoring the users Journal after a reflash.<br>
It also enables a replacement laptop by renaming the serial-number<br>
folder on the school server (and updating the registration information).<br>
<br>
I am not sure if you are trying to implement this functionality, but<br>
it is important at a deployment.<br>
<br>
Yours,<br>
<br>
Tony<br>
<br>
<br>
</div></div></blockquote>
<br>
</blockquote></div><br></div></div>