Link to home
Start Free TrialLog in
Avatar of jwolter
jwolter

asked on

Problem when moving .Xauthority

I'm running a Linux cluster, and I'm having some X problems.  

Background: Dell X86 machines running Fedora Core 1; networked together on a private LAN. The worker nodes are all automounting their /home directory off of the master/storage node. Display, mouse, keyboard connected to the master/storage node.  When a user logs on, DISPLAY = :0.0

When I tried to ssh between the master and the workers, I'd get "Warning: No xauth data; using fake authentication data for X11 forwarding.", I assume because everybody was trying the use the same .Xauthority file.

So I created a directory for each user under /usr/local on each node (including the master/storage node).  I added a line to the end of my .bashrc:

export XAUTHORITY=/usr/local/myusername/.Xauthority

I copied .Xauthority from /home/mysername to /usr/local/myusername and checked that permissions on the file and directory were the same as the originals.

Now I'm no longer getting the "No xauth data" when ssh'ing between the nodes, but when I try to log in to the master/storage node at the console, the login fails, and the session log says:

Xlib: connection to :0.0 refused by server
Xlib: No protocol specified

I can get back in by commenting out the line in the .bashrc to revert to my original .Xauthority file.

Anyone got any idea what's going on?

John
Avatar of jlevie
jlevie

From the way you describe the cluster environment each user has an account & home dir on the head node and you are exporting /home to the member nodes. Since you don't say otherwise I assume that you aren't using NIS and created user accounts on each of the memember nodes. When you did that did you make sure that each memember node accout had the same UID/GID as that user has on the head node and that their home dir points to the NFS mount?
Avatar of jwolter

ASKER

jlevie,

Your assumptions are correct. /home is exported; each worker has user accounts, and yes, on each node the UID/GID are the same and their home directories point to the mount.

Since I posted this, I have found a workaround.  I'll keep the question open because I'm curious as to what is going on, but if no one comes up with something, I'll close the question.  The workaround is remove the reassignment of XAUTHORITY, so that xauth looks for $HOME/.Xauthority, and then create $HOME/.Xauthority as a symbolic link to /usr/local/myusername/.Xauthority . Not sure why this works, but it does.

John
I'm not sure the "No XAUTH" thing is due to what you describe... Are you running an X server (that you have an auth entry for) when you do the ssh -X from master to slave? You have probably started X as a regular user and ssh -X as someone else... root perhaps... And root have never gotten an .Xauthority file ... Or your regular users X don't have xauth defined at all (as is the case with Cygwins default X startup for example). The "error" is just information that since there is no valid information about this for ssh to use, some fake info will be inserted for slave:10 (or whatever) _on slave_. Not really something to work up a sweat over. Nor to try fix.
I presume you are still able to make the "faked local tunneled connections" through ssh -X?

-- Glenn
Oh, and the fix works since then you do have valid xauth info...:-).
Still not really something needing a fix:-)

-- Glenn
Just a quick "demo" from a cygwin X session:

$ ssh -X glenn@vampire
glenn@vampire's password:
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last login: Thu Sep  2 14:08:38 2004 from dt2116.xxx.xxx
[glenn@vampire glenn]$ echo $DISPLAY
vampire.xxx.xxx:10.0
[glenn@vampire glenn]$ xauth list | grep vampire.xxx.xxx:10
vampire.xxx.xxx:10  MIT-MAGIC-COOKIE-1  533f8b8e4835905844f047d831394854
[glenn@vampire glenn]$ xterm&
[1] 29653
[glenn@vampire glenn]$

... And of course the xterm start as it should.

-- Glenn
Avatar of jwolter

ASKER

Glenn,

Thanks for the comments.  

The "No xauth" message appears for "straight" ssh connections (i.e. no -X option).  The ssh session proceeds normally afterward, and I was inclined to ignore it, but I started noticing a delay during the process *sometimes*.  In a cluster, delays are the enemy of performance, so I wanted to see if I could elimnate the delay be eliminating the error.  

John
ASKER CERTIFIED SOLUTION
Avatar of Gns
Gns

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
... And if you have latency problems, these aren't that likely to have anything to do with an unused tunneling feature... More to do with the usual stuff  (perhformance/"load" on the machines involved, the rather ... less than stellar... latency of tcp/ip over ethernet:-)...

-- Glenn