[techtalk] bad display name in "add" command - Solved

[Jennifer Hamilton]

Almut Behrens wrote:
> I guess that there's some problem with resolving the short hostname
> "cvstest" on the remote server (does "nslookup cvstest" work?).
> Could also be something else, though...

In fact, nslookup does not work for 'cvstest' because it is set up under
a sub domain and our DNS server will not resolve the name without the
sub domain (firewall stuff). DNS will resolve 'cvstest.ops', but not
'cvstest'. Since the output from creating the ~/.ssh/rc file (thanks!)
had cvstest, I figured the box must be getting it's own hostname
information from files instead of DNS (b/c of how nsswitch.conf is
configured). That made me look at the /etc/hosts file. There, I found
the incorrect entry for cvstest (it's a new box, so I forgot to change
the info there. oops). 

Thanks!  
Jen



-----Original Message-----
From: Almut Behrens [mailto:almut_behrens at yahoo.com]
Sent: Tuesday, July 31, 2001 10:48 AM
To: techtalk at linuxchix.org
Subject: Re: [techtalk] bad display name in "add" command


On Tue, Jul 31, 2001 at 09:47:00AM -0700, Jennifer L. Hamilton wrote:
> 
> The DISPLAY is set to :0.0. See below:
> 
> [cvsuser at attila test_module]$ cvs -q update -P -A
> jhamilto at cvstest.ops.n2h2.com's password: 
> /usr/bin/X11/xauth: (stdin):1:  bad display name "cvstest:10.0" in
> "add" command
> [cvsuser at attila test_module]$ echo $DISPLAY
> :0.0
> 
> I wonder what is the "add" command it is talking about. Perhaps I can
> run that from the command line and see what happens.

Hi,

when X forwarding is enabled for ssh (which it seems to be in your case)
the ssh daemon on the remote server sets up a kind of X proxy server
and tries to register it using xauth. The command looks something like:

/usr/bin/X11/xauth add cvstest:10.0 <protocol> <cookie>

(cookie and protocol are supplied by sshd)

If you feel like experimenting, and would like see the exact values, you
could create a little script ~/.ssh/rc, which logs the stuff to stdout
while leaving functionality intact:

# example /bin/sh script ~/.ssh/rc (will be run by sshd when logging in)

if read proto cookie; then
  # log to stdout
  echo $DISPLAY  $proto  $cookie
  # replicate regular functionality
  /usr/bin/X11/xauth -q add $DISPLAY $proto $cookie
fi

I guess that there's some problem with resolving the short hostname
"cvstest" on the remote server (does "nslookup cvstest" work?).
Could also be something else, though...

Anyway, the simplest thing to get rid of your problem would probably be
to *unset* DISPLAY before issuing the cvs update command. This will
indirectly disable X forwarding for the ssh connection, which in turn
will avoid that xauth gets called at all on the server side.

(Alternatively, you could try to find out how to have cvs pass the
option "-x" to the ssh that it uses to connect to the server. This would
also disable X forwarding. From the top of my head I don't know where
that is configured...)

In case you should need/want X forwarding enabled, just report back --
then we could try a few other things...

Cheers,

- Almut


_______________________________________________
techtalk mailing list
techtalk at linuxchix.org
http://www.linux.org.uk/mailman/listinfo/techtalk