Xhost/Xlib error

[sammysammy]

Hi,

I logged in Tru64 5.1B-4 as root and issued the following commands, but it failed:

# DISPLAY=tserver1:0
# export DISPLAY
# xhost +
Xlib: connection to "tserver:0.0" refused by server
Xlib: Client is not authorized to connect to Server
xhost: unable to open display "tserver:0"

Note, tserver is pingable.

Can anyone tell me how to fix this issue?

Thanks

[sammysammy]

I also verified that X11 is running:
# ps -ef | grep X11
root 1011 930 0.0 Mar 13 ?? 0:00.47 /usr/bin/X11/X :0 -auth /var/dt/authdir/authfiles/A:0-hIgjnl

Regards

[Steven Schweda]

Can we assume that "tserver1" was actually
"tserver"?

What is "tserver", and why should anyone in
the world be allowed to do "xhost +" on it,
which is essentially what you're asking for
here?

Fix it? Log into "tserver", whatever it is,
as the user who owns the X server there, and
_then_ try "xhost +".

Or, explain what you're talking about. You
may know what "tserver" is, but it's not
obvious to some of the rest of us.

[sammysammy]

tserver is tserver1, sorry for the typo.

tserver/ or tserver1 is running x11 service.
it is an Oracle server (this is not related to the problem I have with xhost + returns error).

Yes, I did a xhost +, but it returned the error as I posted in the first message.

Thanks

[Vladimir Fabecic]

Login as root on graphical console.
Then do # xhost +
You also have "dxhosts" utility for managing X server permitions.
Notice that dxhosts must be run on console.

[sammysammy]

Hi, I only can ssh login to its sh console, not the x console. xhost + shown error message ".... unablel to display "tserver"

Thanks
S

[Steven Schweda]

I'll try one more time.

What is "tserver1"? Is it the Tru64 system?

> I only can ssh login to its sh console, not
> the x console.

What is an "sh console"? Normally, "console"
means the keyboard-mouse-display stuff on a
workstation, or a serial terminal, if there
is no graphics hardware.

Assuming that there are a keyboard, mouse,
and display connected to the Tru64 system,
who is logged it there? And if it's not you,
how do you expect to control that display?
Normally, the user who is logged in at the
workstation keyboard-mouse-display gets to
run "xhost". Other users are "not
authorized" to do that.

A clear explanation of who is sitting where,
and at what bits of computer hardware, might
help considerably here.

[sammysammy]

Hi,

It is a remote Tru64 5.1B-4 server running at data centre. WE are million miles away from the tserver. The connection is via Internet with ssh from Windows.

We use ssh root login, then issued with the DISPLAY, export, and xhost + command, then get those Xlib and xhost errors. But the same set of commands work quite well in antoehr tru 64 5.1.B-4 server.

Thanks
S

[sammysammy]

Hi,

I also tried to execute the following netstat command to find out what services( perhaps x11) are listening to, but I got memory error:
# netstat -l
netstat: failed to allocate memory for buffer

Could this related to the problem that xlib and xhost + failed?

Thanks

[Steven Schweda]

So, if I read this right, you are sitting at
a Windows system, and you wish to log into a
distant Tru64 system (and that part works),
and then you would like to run a graphical
program on the Tru64 system, and have its
graphical stuff appear on the display of the
distant Tru64 system.

> But the same set of commands work quite
> well in antoehr tru 64 5.1.B-4 server.

And who is logged in at the console there?
The user who logs in at the graphics console
normally gets to say who can use that
display. Other users do not normally get to
control what happens on _my_ display.

Around here, I can rsh/ssh as user "root" to
my Tru64 system from my VMS system, set the
DISPLAY, and get the same failure, _if_ no
one is logged in at the Tru64 console. Then,
after user "root" logs in at the console, I
can do what I want. (Note: "xhost +" is not
needed in this case.)

If I log into the Tru64 console as a
different user, the failure returns.

So, the difference between the two systems
could be caused by things like:

- Different users are logged into the two
consoles.
- One of the user's shell start-up scripts
(~/.login, ~/.profile, or whatever) could be
doing an "xhost" command.
- ...

"man X" suggests:

For more information on access control, see the XSecurity(1X) manual page.