BackupPC-users

[BackupPC-users] BackupPC on Solaris10 rsync/ssh-Problems

2011-11-25 10:40:15
Subject: [BackupPC-users] BackupPC on Solaris10 rsync/ssh-Problems
From: chris101 <backuppc-forum AT backupcentral DOT com>
To: backuppc-users AT lists.sourceforge DOT net
Date: Fri, 25 Nov 2011 03:54:23 -0800
Hi,

I am having problems with BackupPC on Solaris10. I have been searching on 
Google, the forums and the Wikis for help, but could find no solution. Any help 
from someone in this forum is greatly appreciated.

I have been using BackupPC 2.1.2pl1 on Debian/Linux for some time now and it 
works like a charm. For several reasons that go beyond this post I am now 
forced to run BackupPC on Solaris10. However, there are some problems with 
rsync/ssh.

I am trying to run BackupPC 3.20  on Solaris10 on host 'backuppc2' to backup a 
client named 'forbin' which is a Ubuntu/Linux 904.
Root login on the client works fine for the backuppc user via ssh-keys, no 
password is required, no ssh-agent is running, no SSH-Variables are set:

backuppc@backuppc2 />/opt/csw/bin/ssh root@forbin whoami
root

But if I run BackupPC_dump via command line it is stuck at some point:

backuppc@backuppc2 />/usr/local/BackupPC/bin/BackupPC_dump -fv forbin
cmdSystemOrEval: about to system /usr/sbin/ping -s forbin 56 1
[... ping output]
CheckHostAlive: returning 0.251
full backup started for directory / (baseline backup #0)
started full dump, share=/
Running: /opt/csw/bin/ssh -c blowfish -q -x -l root -o 
PreferredAuthentications=publickey forbin /usr/bin/rsync --server --sender 
--checksum-seed=32761 --numeric-ids --perms --owner --group -D --links --times 
--block-size=2048 --recursive --ignore-times . /
Xfer PIDs are now 9634
xferPids 9634
Got remote protocol 30
Negotiated protocol version 28

Nothing will happen from this point onward.

*However*, if I press the return key 4 times, output continues:

Sent include: /etc
Sent include: /root
Sent include: /local
Sent include: /local/mysql
Sent include: /local/mysql/mysql
Sent include: /local/mysql/give_et
Sent exclude: /*
Sent exclude: /local/*
Sent exclude: /local/mysql/*
Read EOF: 
Tried again: got 0 bytes
fileListReceive() failed
Done: 0 files, 0 bytes
Got fatal error during xfer (fileListReceive failed)

I do _not_ believe this is ssh waiting for a password! Why would it take 
exactly 4 input characters?

It looks to me like the rsync/ssh pipe is broken in some way, like ssh is 
trying to read its input not from the rsync, but from STDIN from the command 
line. If I add a '-n' to the ssh options (redirects stdin  from  /dev/null) the 
BackupPC_dump fails quicker, without and keyboard input:

full backup started for directory / (baseline backup #0)
started full dump, share=/
Running: /opt/csw/bin/ssh -n -c blowfish -q -x -l root -o 
PreferredAuthentications=publickey forbin /usr/bin/rsync --server --sender 
--checksum-seed=32761 --numeric-ids --perms --owner --group -D --links --times 
--block-size=2048 --recursive --ignore-times . /
Xfer PIDs are now 9668
xferPids 9668
Got remote protocol 30
Negotiated protocol version 28
Sent include: /etc
Sent include: /root
Sent include: /local
Sent include: /local/mysql
Sent include: /local/mysql/mysql
Sent include: /local/mysql/give_et
Sent exclude: /*
Sent exclude: /local/*
Sent exclude: /local/mysql/*
Read EOF: 
Tried again: got 0 bytes
fileListReceive() failed
Done: 0 files, 0 bytes
Got fatal error during xfer (fileListReceive failed)


I tried looking into the problem via truss, the strace equivalent of Solaris. 
In the truss output I can see rsync on the backup client sends 4 bytes that 
look like the rsync protocol version: 0x1e 0x0 0x0 0x0. The same goes for the 
backuppc side where the rsync process sends 4 bytes as well that look like the 
rsync protocol version: 0x1c 0x0 0x0 0x0. However, communication from the the 
backuppc rsync just does not go on until I sent 4 characters via keyboard, jsut 
like I am supplying the 4 byte rsync version via keyboard to the ssh pipe to 
the backup client. I tried disabling  pseudo-tty  allocation via ssh -T, buit 
the result is the same.

What I do not quite understand is why keyboard input is having any effect at 
all? In my opinion rsync/ssh communicate directly via some pipe/fifo.

Does anybody have an explanation for this?


These are the versions in use:
Client (always worked fine with BackupPC 2.1.2pl1 on Debian/Linux)
Ubuntu/Linux 904
rsync 3.0.5  protocol version 30
ssh OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007

Server:
BackupPC 3.20
/opt/csw/bin/ssh OpenSSH_5.3p1, OpenSSL 0.9.8p 16 Nov 2010
/bin/ssh Sun_SSH_1.1.4, SSH protocols 1.5/2.0, OpenSSL 0x0090704f (same result 
as /opt/csw/bin/ssh)
Perl File::RsyncP 0.70
/opt/csw/bin/rsync 3.0.6  protocol version 30 (not sure if this is used at all)

Any help or pointers are greatly appreciated!

Chris

+----------------------------------------------------------------------
|This was sent by backuppcforum AT coli.uni-saarland DOT de via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

<Prev in Thread] Current Thread [Next in Thread>
  • [BackupPC-users] BackupPC on Solaris10 rsync/ssh-Problems, chris101 <=