Can't open display

[Mike_811]

Hi,
I've just installed RedHat WS 4.0.
I'm trying to setup my X server and there's a pb while trying to open a window (for instance xclock) : can't open display.
The initial value of the DISPLAY parameter is set to :0.0 and for application purpose, I need this variable setup to computer_name:0.0
I've already tried xhost +
Any clue where the pb comes from ?

[Steven E. Protter]

Shalom Mike,

Make sure the computer name resolves either with dns or /etc/hosts

DISPLAY=computer_name:0.0
export DISPLAY

Put this in the profile or enter it into the command line.

This will enable you to use X from the console. Make sure the system is set to run level 5 in /etc/inittab

If you wish to run X apps external to the machine:

ssh -X computer_name application_name
example
ssh -X computer_name system-config-display

This will permit you to run X apps off the system with an encrypted tunnel and not having to bother with actually being on the console.

SEP

[Jarle Bjorgeengen]

If you want to start xclients (programs ) as a user other than the user logged into the desktop environment, you need to copy the desktop-environments users ~/.Xauthority file to the other user homedirectory. The file conatains a key (MIT-MAGIC-COOKIE) that is need to access the display of the desktop user.

[Mike_811]

Thanks Steve, but still not working.
I've entered :
DISPLAY=poconfig:0.0
export DISPLAY
poconfig is an entry in /etc/hosts
xclock : can't open display

I've also tried :
ssh -X poconfig system-config-display
result : connect poconfig port 6000 : connection refused

I've think there's something wrong with authorisation.

The daemon X (daemon) has the option -nolisten. is it normal ?

[Steven E. Protter]

Shalom,

who -r

Lets see what run level the machine is at. Linux needs to be at run level 5 to properly run X.

I think you should check permissions as my itrc colleague says. Non-response is common if permissions are wrong.

Here is my X daemon on a working system.

root 4452 4409 0 Feb28 ? 00:00:29 /usr/bin/X11/X :0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7


-nolisten is both non-informative and misleading since this system runs applictions just fine on its console.

SEP

[Matti_Kurkela · Accepted solution]

Most Linux distributions today are configured to *ignore* unencrypted X sessions over the network. By default, the only way to use X window system remotely is to use SSH and enable its X11 forwarding.

I'm reasonably sure your application would work with no code changes through SSH's X11 forwarding: just the documentation needs to be updated to use the newer, secure connection methods. You'll find that SSH's X11 connection forwarding is actually *easier* to use than the traditional method.

When asked to forward a X11 connection, SSH will automatically handle setting the DISPLAY variable for you. It will also automatically handle the xauth keys, so that you won't need to damage your security with "xhost +".

If you enable unencrypted X sessions, be sure your network is secure. If you use an unencrypted session with "xhost +", anyone who can connect to your workstation's TCP port 6000 can e.g. open onto your screen a full-screen, borderless transparent window which captures and passes through all keyboard and mouse events, thus seeing everything you do.

Please see my answer to this thread:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=990009

This is the relevant part:

3.) The X display system must allow TCP connections. Reflection and "old" Unix servers allow this by default, but most new Linux distributions have this disabled.

This is set when starting the X display system. If you're using XDM as your login dialog, check the file /etc/X11/xdm/Xserver.
Usually there is only one line without the comment sign ("#"). If there is a "-nolisten tcp" option on that line, the display system will accept only local connections (in technical terms, only "Unix domain socket" connections).