Hi

Debian Squeeze: Linux jilldando 2.6.32-trunk-486 #1 Sun Jan 10 05:53:18 UTC 2010 i686 GNU/Linux

gdm for desktop manager

I have 4 differences situations, 2 work, 2 do not: So I think my server box (Jill) is messed up.

1) On the server desktop, I can open a console as the gui logged in user and type:
xeyes
and those eyes appear.
echo $DISPLAY
:0.0


2) If from that console I log in as another user (ros) and then type:
xeyes
I get:
Error: Can't open display:
echo $DISPLAY
(NOTHING)
so that will be a problem.


3) If I ssh into my offices remote server from my XP machine with putty and x-forwarding and then type:
xeyes
and those eyes appear.
echo $DISPLAY
localhost:11.0


4) If I ssh into Jill from my XP machine with putty and x-forwarding and then type:
xeyes
I get:
Error: Can't open display:
echo $DISPLAY
(NOTHING)
so that will be a problem.


This leads me to think I have something messed up on my Linux box Jill.

I have tried setting DISPLAY= to various values but same error, so this led me to believe something else needs setting. Especially as env yields alot more in situation 1 than in situation 2.

What can I set where, that will allow me run xeyes (anything X) in situations 2 and 4, just like in situation 1 and 3?

2) You have to transfer the magic cookie and also set DISPLAY to be the same. See http://www.debian-administration.org/articles/494
4) Is X11Forwarding enabled in /etc/ssh/sshd_config? If no, change it to yes, restart SSHD, and retry.

1 members found this post helpful.

in case 2:

To run something as root:

$ su -
# xauth merge ~<gui-logged-in-user>/.Xauthority
# export DISPLAY=localhost:0.0
# xeyes


To run something as another user, there are a number of options, some more complex than others, but the simplest is to just allow all connections from localhost:

$ xhost +localhost
$ su - ros
$ xeyes



in case 4:

You probably don't have X11Forwarding enabled in the sshd_config on Jill.. enable it and restart sshd.

Hm. Perhaps I should reload before replying Ah well..

0 members found this post helpful.

For the PuTTY X tunnel the issue is that when you login as a user you are establishing a fake display that tunnels back through your ssh connection. Also when you do that kind of tunnel it creates a file in your original user's home directory called .Xauthority (and may set a $XAUTHORITY variable).
You can do an su and use the same tunnel but it requires that you:
1) Set permissions on original user's .Xauthority so that new user can read it.
2) echo $DISPLAY (original user)
3) Switch user (su - <newuser>)
4) export DISPLAY=<DISPLAY of Original user>
5) export XAUTHORITY=<path to .Xauthority of original user>
That is to say AFTER switching user you must set both the DISPLAY and XAUTHORITY variables so they are using what the original user did.

Note that setting permissions on .Xauthority for others to read means anyone that can read it can use the tunnel to your XP system so you should do this sparingly and undo it when done.

For the console issue I don't see the same problem on my CentOS 5 console. However I do notice that unlike the PuTTY session my console session has XAUTHORITY variable set and it is a file in /tmp. It may be security on your distro is such that you have to set DISPLAY and XAUTHORITY after su similar to the way you do it for PuTTY. Just echo your $XAUTHORITY in step 1 to see what it is using then use that path in step 5.

Perhaps instead of giving a user the equivalent of RTFM you might actually try to answer the question.

Explain. I don't see why you think my reply was an RTFM.

Because all you did was provide a series of links. The first one goes to a page talking about NFS. If the answer is somewhere within one of the links then maybe you could point out WHICH one it is in and give some indication as to WHERE in the page yo think the answer is. Otherwise all you've done is provided a list of reading material which may or may NOT (and I'm guessing NOT) be germane to the question asked.

1. Dismount high-horse.
2. Re-read.

Once those steps are complete you will notice that the links are within my signature and that the post regarding "maybe i should reload.." is a *second* reply; the first being the one with the answer to the OP's queries.

1 members found this post helpful.

My apologies.

I'd swear your first reply wasn't there when I responded to you the first time - I note both your replies and mine show being exactly 1 minute apart so maybe it somehow delayed post of your first reply when I saw it after clicking on my reply to OP. There was no reply at all before I started replying to OP.

This was the solution with the addition of also set DISPLAY for situation 2

Cant believe I did not think to check 4!! ;-(