<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>sudo seems to work without setting the bit on ping, so that would be an
alternate approach.</DIV>
<DIV> </DIV>
<DIV>either way, I did a test that confirms that your approach fixes the
problem.</DIV>
<DIV> </DIV>
<DIV>as far as testing is concerned, ds-backup is already on the checklist, but
we haven't always followed the list. I was more diligent this time in
following <A
href="https://github.com/XSCE/xsce/blob/master/docs/TESTING.rst">https://github.com/XSCE/xsce/blob/master/docs/TESTING.rst</A>
because I was afraid that restructuring the install might break things.</DIV>
<DIV> </DIV>
<DIV>Miguel started automating the smoke test and we should add ds-backup to
it.</DIV>
<DIV> </DIV>
<DIV>Tim</DIV>
<DIV>-----Original Message----- </DIV>
<DIV>From: James Cameron </DIV>
<DIV>Sent: Monday, June 16, 2014 6:46 PM </DIV>
<DIV>To: George Hunt </DIV>
<DIV>Cc: Tim Moody ; Adam Holt ; unleashkids@googlegroups.com ; XS Devel </DIV>
<DIV>Subject: Re: [UKids] Server Backup on HaitiOS </DIV>
<DIV> </DIV>
<DIV>On Mon, Jun 16, 2014 at 03:35:40PM -0400, George Hunt wrote:</DIV>
<DIV>> Tim discovered that backups to the XSCE in release 5.0 were</DIV>
<DIV>> failing. I had changed ds-backup-server to use the WSGI
interface</DIV>
<DIV>> (mod_python was obsoleted in FC18).</DIV>
<DIV> </DIV>
<DIV>I suggest adding a test for backups to the release checklist for
XSCE.</DIV>
<DIV> </DIV>
<DIV>> So I assumed that the ball was in my court. But I believe the
test</DIV>
<DIV>> just completed indicates that the problem was really that the</DIV>
<DIV>> superuser bit in /bin/ ping was removed in FC17 (the base for</DIV>
<DIV>> HaitiOS).</DIV>
<DIV> </DIV>
<DIV>It was replaced by another mechanism in Fedora 17 (no core), but that</DIV>
<DIV>other mechanism was incorrectly removed by OLPC OS, and the setuid
bit</DIV>
<DIV>is a workaround.</DIV>
<DIV> </DIV>
<DIV>(In my opinion a more correct solution is to change ds-backup to not</DIV>
<DIV>need ping, but instead attempt the backup anyway. This would
avoid</DIV>
<DIV>failing a backup if ping could not be run.)</DIV>
<DIV> </DIV>
<DIV>> The test:</DIV>
<DIV>> </DIV>
<DIV>> 1. Load OS13.2.0 on an XO4. </DIV>
<DIV>> 2. Install XSCE release 5.0 on top of that -- installs
ds-backup-server hash</DIV>
<DIV>> c5d86 (unchanged from XSCE-0.4)</DIV>
<DIV>> 3. Load HaitiOS hash 6d78 on an XO1</DIV>
<DIV>> 4. Register XO1 to server</DIV>
<DIV>> 5. Wait for 2 hours -- observe no data in directory at
/library/user/SHC....</DIV>
<DIV>> 6. execute "chmod 4755 /bin/ping" on the XO1</DIV>
<DIV>> 7. Wait for 1 hour -- observe that the backup had occurred</DIV>
<DIV> </DIV>
<DIV>You can make this test faster by starting the backup manually on the</DIV>
<DIV>XO-1, by typing this in Terminal:</DIV>
<DIV> </DIV>
<DIV>/usr/bin/ds-backup.sh</DIV>
<DIV> </DIV>
<DIV>You can find in /etc/cron.d/ds-backup the method by which the backup</DIV>
<DIV>is started.</DIV>
<DIV> </DIV>
<DIV>> I think the wifi fixup that Tim has prepared for Sora to take to</DIV>
<DIV>> Haiti should include the change in permissions on /bin/pin.
</DIV>
<DIV>> </DIV>
<DIV>> I do remember that, in the Tiny Core environment, it is hard to
find</DIV>
<DIV>> the file that I wanted to change (because I don't have a clear
idea</DIV>
<DIV>> of the disk tree, before the chroot that the firmware does as it
is</DIV>
<DIV>> bringing up the XO. </DIV>
<DIV> </DIV>
<DIV>You can find files more easily in the Tiny Core Linux environment by</DIV>
<DIV>doing the chroot manually at a prompt. You can pull fragments out
of</DIV>
<DIV>Jerry's xo-custom, especially the functions, and use them as command</DIV>
<DIV>line tools.</DIV>
<DIV> </DIV>
<DIV>-- </DIV>
<DIV>James Cameron</DIV>
<DIV>http://quozl.linux.org.au/</DIV>
<DIV> </DIV>
<DIV>-- </DIV>
<DIV>Unsung Heroes of OLPC, interviewed live @ http://unleashkids.org !</DIV>
<DIV>--- </DIV>
<DIV>You received this message because you are subscribed to the Google Groups
"Unleash Kids" group.</DIV>
<DIV>To unsubscribe from this group and stop receiving emails from it, send an
email to unleashkids+unsubscribe@googlegroups.com.</DIV>
<DIV>For more options, visit
https://groups.google.com/d/optout.</DIV></DIV></DIV></BODY></HTML>