Hi,
Anthony J Biacco wrote on 12.09.2007 um 09:13:12 [Re: [BackupPC-users] Got
fatal error during xfer (fileListReceivefailed)]:
>
> I'm betting it is in some profile script somewhere..
I believe that is what I said.
> in addition to
> looking in those files, you might try in your ssh command the option: -o
> ForwardX11=no
And you might as well not. '-x' is shorthand for that, and you've tried
that. In fact, presuming the message comes from the client side, '-x' is
guaranteed not to help, as something is trying to connect to :0.0 on the
client computer (robert-laptop). If ssh could and would set up X11
forwarding and thus pass $DISPLAY, <whatever> would not try :0.0 but rather
the forwarded channel (unless it ignores DISPLAY, in which case it is simply
wrong anyway). Disabling it when it obviously already is disabled or ignored
won't help.
I've just done a further test: point DISPLAY to a non-existing X11 display
(:1.0 for this test), run ssh (works without complaint), echo $DISPLAY on the
remote side (gives localhost:12.0 in my case, depends on which ports are free
on the remote side), then try to access $DISPLAY (that's what 'xeyes' is for,
right?). At this point I get an error, or in fact two errors:
1.) "connect to /tmp/.X11-unix/X1: No such file or directory"
This error occurs on the local side when ssh tries to access :1.0.
2.) "X connection to localhost:12.0 broken ..."
This error occurs on the remote side to the client application when ssh
closes the socket.
If I set DISPLAY locally to hostname:1.0 and rerun the test, error message
#1 changes to "connect hostname port 6001: Connection refused".
My point: unless your 'ssh' acts differently, the error message 'Xlib:
connection to ":0.0" refused by server' is *on the client machine side*
(in your case robert-laptop) as I suspected before, *not* on the BackupPC
server side.
In fact, *even if* your 'ssh' acts differently (different implementation),
nobody in their right mind implementing X11 tunnelling will use Xlib to
connect to the X server ;-).
To sum it up: 'Xlib: connection to ":0.0" refused by server' *always* means
the culprit is on the remote side.
Or have I overlooked something?
Regards,
Holger
P.S.: As a side note, my test shows that at least the ssh implementation I
use does not contact the X server unless an application on the remote
end requests a connection. This makes perfect sense. I see no reason
why other implementations should differ. Consequentially, setting up
X11 forwarding without a meaningful local X display is harmless,
*unless the remote end tries to use it*. Granted, the existance of
a DISPLAY environment variable *might* lead a shell startup sequence
to do just that, but the user account you use for running backups
should probably not attempt any such exotic things anyway ;-).
In fact, the '-x' flag to ssh will prevent $DISPLAY from being set and
thus *can* actually help in some cases, but, in my opinion, that is
just a workaround for an incorrect configuration.
Maybe the BackupPC daemon should undef $ENV {DISPLAY} ?
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
