Re: [BackupPC-users] backuppc rsync problem on freebsd

Hi,

Taskin/Osman wrote on 2008-12-19 11:35:57 +0100 [[BackupPC-users] backuppc 
rsync problem on freebsd]:
> dear backuppc community,
> 
> i have successfully installed backuppc on freebsd but since 24h i could
> not fix following problem;
> [...]
> full backup started for directory /
> Running: /usr/bin/ssh -q -x -l root 192.168.100.31 /usr/local/bin/rsync 
> --server --sender --numeric-ids --perms --owner --group -D --links 
> --hard-links --times --block-size=2048 --recursive --ignore-times . /
> Xfer PIDs are now 11145
> Got remote protocol 1868767320
> Fatal error (bad version): X connection to backup2.ns3.org:11.0 broken 
> (explicit kill or server shutdown).

this indicates that the ssh command results in the string

    X connection to backup2.ns3.org:11.0 broken (explicit kill or server 
shutdown).

being output, interrupting the rsync version negotiation. What happens when
you log in manually? There should be *no* extraneous output. In particular,
something like

    ssh -q -x -l root 192.168.100.31 true

should not output *anything*. If there is output, usually something in your
shell startup process is broken (in this case, $DISPLAY seems to be set,
prompting some X program to be run). You should check your relevant .profile
or .bashrc files (or whatever [email protected]'s shell uses).

> I am executing the command manually; then i see command is beeing
> executed on .31 machine but it never finishes;

You are probably providing the '--server --sender' args. The rsync process is
waiting for you to start an rsync protocol session. Most of us use the rsync
program for that rather than typing ourselves ;-). The correct way to test
what you are trying to test would be something like

    rsync -e ssh --numeric-ids --perms --owner --group -D --links --hard-links \
      --times --block-size=2048 --recursive --ignore-times \
      [email protected]:/ /tmp/test

(which starts the command with the '--server --sender' args via ssh and then
talks to it) but there is little point in trying it, really. The problem is
not caused by rsync; once the ssh connection works cleanly, rsync will also
work.

> What i also notice is; i am connected to backup machine via securecrt
> ssh. I get on securecrt a popup that server tries to Xforward but i dont
> have X server on host etcetc. I dont understand why it try to x forward
> at all.

Neither do I. Check the man page for securecrt ssh (whatever that is) - maybe
its option syntax differs from OpenSSH's (which I believe is commonly used).
In particular, '-x' is supposed to *disable* X11 forwarding and *should* result
in an unset DISPLAY variable on the server side (err, ssh server == backup
client, 192.168.100.31, to be explicit). '-q' is quiet mode. Is $DISPLAY set
in the shell you are manually running 'ssh' in? Does unsetting it make any
difference? Try

    etcetc% echo ${DISPLAY-unset}
    ???
    etcetc% unset DISPLAY
    etcetc% ssh -q -x -l root 192.168.100.31 true
    etcetc%

Regards,
Holger

------------------------------------------------------------------------------
_______________________________________________
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/