[Server-devel] Issue with ds-backup in XS 0.4

[Bill Bogstad]

On Tue, Nov 11, 2008 at 1:58 PM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> On Tue, Nov 11, 2008 at 12:18 AM, Bill Bogstad <bogstad at pobox.com> wrote:
>> I was just about to try to upgrade my XS 0.4 to 0.5 dev8 and noticed
>> something odd concerning ds-backup.  When I originally installed 0.4,
>
> Thanks for the report! As Douglas mentions, you can force a
> re-registration; however I can't think of any good reason for the
> upgraded XO to not perform its backups.
>
> Is there any evidence of the laptop attempting the backups? Some ideas
> for debugging:
>
> on the XO
>  - look for entries in the cron log

On the XO which isn't being backed up:

# grep ds-backup.sh /var/log/cron | tail -10
Nov 11 15:30:01 localhost CROND[658]: (olpc) CMD
((/usr/bin/ds-backup.sh 2>&1 ) > /dev/null)
Nov 11 16:00:01 localhost CROND[816]: (olpc) CMD
((/usr/bin/ds-backup.sh 2>&1 ) > /dev/null)
Nov 11 16:30:01 localhost CROND[1051]: (olpc) CMD
((/usr/bin/ds-backup.sh 2>&1 ) > /dev/null)
Nov 11 17:00:02 localhost CROND[1228]: (olpc) CMD
((/usr/bin/ds-backup.sh 2>&1 ) > /dev/null)
Nov 11 17:30:01 localhost CROND[1421]: (olpc) CMD
((/usr/bin/ds-backup.sh 2>&1 ) > /dev/null)
Nov 11 18:00:02 localhost CROND[1582]: (olpc) CMD
((/usr/bin/ds-backup.sh 2>&1 ) > /dev/null)
Nov 11 18:30:01 localhost CROND[1749]: (olpc) CMD
((/usr/bin/ds-backup.sh 2>&1 ) > /dev/null)
Nov 11 19:00:02 localhost CROND[1909]: (olpc) CMD
((/usr/bin/ds-backup.sh 2>&1 ) > /dev/null)
Nov 11 19:30:02 localhost CROND[2067]: (olpc) CMD
((/usr/bin/ds-backup.sh 2>&1 ) > /dev/null)
Nov 11 20:00:01 localhost CROND[2228]: (olpc) CMD
((/usr/bin/ds-backup.sh 2>&1 ) > /dev/null)

Ample evidence that attempts are being made to backup.

>  - check that /etc/cron.d/ds-backup is in place (you can edit it to
> get logs of the execution)
>
> on the XS
>  - look for entries in the logs that indicate logins via ssh

On the XS machine:

[root at schoolserver ~]# grep Accepted /var/log/secure
Nov  9 19:02:45 schoolserver sshd[17206]: Accepted publickey for
CSN74800E35 from 10.0.0.22 port 36015 ssh2
Nov  9 19:02:45 schoolserver sshd[17211]: Accepted publickey for
CSN74800E35 from 10.0.0.22 port 36016 ssh2
Nov 10 19:08:42 schoolserver sshd[18943]: Accepted publickey for
CSN74800E35 from 10.0.0.22 port 47021 ssh2
Nov 10 19:08:42 schoolserver sshd[18948]: Accepted publickey for
CSN74800E35 from 10.0.0.22 port 47022 ssh2
Nov 10 23:30:42 schoolserver sshd[19173]: Accepted publickey for root
from 10.0.0.8 port 54741 ssh2

That CSN is for the machine that IS being being backed up.

[root at schoolserver ~]# grep 'closed' /var/log/secure | tail -10
Nov 11 10:13:30 schoolserver sshd[20289]: Connection closed by 10.0.0.24
Nov 11 10:40:44 schoolserver sshd[20312]: Connection closed by 10.0.0.24
Nov 11 11:12:24 schoolserver sshd[20334]: Connection closed by 10.0.0.24
Nov 11 11:47:46 schoolserver sshd[20354]: Connection closed by 10.0.0.24
Nov 11 12:11:03 schoolserver sshd[20397]: Connection closed by 10.0.0.24
Nov 11 12:35:45 schoolserver sshd[20462]: Connection closed by 10.0.0.24
Nov 11 13:14:50 schoolserver sshd[20486]: Connection closed by 10.0.0.24
Nov 11 13:39:57 schoolserver sshd[20504]: Connection closed by 10.0.0.24
Nov 11 14:11:49 schoolserver sshd[20533]: Connection closed by 10.0.0.24
Nov 11 14:44:29 schoolserver sshd[20553]: Connection closed by 10.0.0.24

That IP address is the one assigned by my DHCP server to the XO that
isn't getting backed up. I'm not using the schoolserver to do DHCP.
My DHCP server has the MAC address of my XO's hardwired to always give
the same IP address to a particular machine.  So these entries are
always from the 'bad' XO.  This would indicate to me that attempts are
reaching the XS, but are failing.

>  - check for permissions/ownership issues in the homedir

The files they have in common appear to have the appropriate
ownership/Unix permissions. (I didn't check ACLs.)  The failing XO
home directory has NONE of the datastore entries.  Not the timestamped
ones, nor the -current or -latest entries.  Could this be it?

I'll do some more looking around and wait for your response before I
manually create those entries.

Bill Bogstad