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.

[Steven Schweda]

> # netstat -l
> netstat: failed to allocate memory for buffer

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

Many things are possible. You seem to have
some major problems there.

"swapon -s"?

[sammysammy]

Hi,

this is the output from swap -s:
# swapon -s
Swap partition /dev/disk/dsk0b (default swap):
Allocated space: 2097152 pages (16.00GB)
In-use space: 5 pages ( 0%)
Free space: 2097147 pages ( 99%)

Swap partition /dev/disk/dsk2c:
Allocated space: 26674020 pages (203.51GB)
In-use space: 5 pages ( 0%)
Free space: 26674015 pages ( 99%)


Total swap allocation:
Allocated space: 28771172 pages (219.51GB)
Reserved space: 2265276 pages ( 7%)
In-use space: 10 pages ( 0%)
Available space: 26505896 pages ( 92%)

It seems there are still plenty of memory space.

Thanks

[sammysammy]

Hi,

I found that in the /usr/dt/config/Xaccess file, I should add in a missing configuraiton line:
*.mysite.com.au
since this missing line is appeared in another working Tru64 5.1B-4 server.
Now how I restart X server remotely so that it re-read the Xaccess file?

Thanks

[sammysammy]

Hi,

I just managed to restart the X windows remotely, but I still having problem with xhost + command:

# kill -HUP 1011
# ps -e | grep /usr/bin/X11/X
310146 ?? S 0:00.46 /usr/bin/X11/X :0 -auth /var/dt/authdir/authfiles/A:0-hIgjnl
310049 pts/14 S + 0:00.00 grep /usr/bin/X11/X
# DISPLAY=tserver: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"
#

I have no idea how to fix it now.

Thanks

[Steven Schweda]

> I have no idea how to fix it now.

Look back at the part which begins "And who
is logged in at the console there?"

alp $ rsh /user = root urtx
[...]

urtx# export DISPLAY=:0.0
urtx# xhost
Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
xhost: unable to open display ":0.0"
urtx# # Log in at console as "root".
urtx# xhost
access control enabled, only authorized clients can connect
urtx#

Problem solved.

[sammysammy]

But I logged in as root.

[sammysammy]

Still having the error:
# export DISPLAY=:0.0
# xhost
Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
xhost: unable to open display ":0.0"
#

[Steven Schweda]

> But I logged in as root.

At the graphics console?

[sammysammy]

no. I logged in the server from windows with putty.

[Steven Schweda]

> no.

So, as I keep asking, "And who is logged in
at the console there?" If no one is logged
in there, who will be looking at the stuff
you want to put onto the display?

What part of this wasn't clear?:

urtx# # Log in at console as "root".

[sammysammy]

so if there is someone already logged in the X (graphical) console there, I will have this xhost + error message? is that what you meant?
If this is the case, I will need to kill all login session before executing xhost +

Thanks

[Steven Schweda]

If someone _else_ is logged in there, then
you will get that error. If you log in as
the _same_ user as is logged in there, and
set your DISPLAY the same as that user, or if
you "su other_user" (and set your DISPLAY the
same), then it should work.

And you may not need to do the "xhost +"
unless you stop being "other_user".

[sammysammy]

If I killed all xterm in the system, then logged in the server as root from my windows, and set DISPLAY=tserver:0 , export DISPLAY, will xhost + works in this way?
Here is a list of xterm alraedy running in the system:
# ps -ef | grep -i term
root 131890 1 0.0 Apr 02 ?? 0:08.42 xterm
root 132135 1 0.0 Apr 02 ?? 3:12.84 xterm
root 208916 1 0.0 Mar 26 ?? 0:03.54 xterm
root 495300 1 0.0 Mar 22 ?? 1:41.78 xterm -geometry 80x24+10+10 -ls -title X Desktop
root 495407 495362 0.0 Mar 22 pts/5 0:15.71 xterm
root 131674 497279 0.0 Apr 02 pts/8 0:01.05 xterm
root 315419 313855 0.0 13:16:31 pts/15 0:00.00 grep -i term

Thanks

[Steven Schweda]

The problem is not the xterms, it's whom the
X server trusts. If user "fred" is logged in
at the console, then user "fred" controls
these things, and normally only user "fred"
can do an "xhost" command.

However, user "root" can do "su fred", and
then he can do the same things that user
"fred" can do.

Here, with user "sms" logged in at the Tru64
console:

alp $ rsh /user = sms urtx
[...]
urtx> who am i
sms pts/4 Apr 4 22:44 (alp.antinode.org)

urtx> export DISPLAY=:0.0
urtx> xhost
access control enabled, only authorized clients can connect


alp $ rsh /user = root urtx
[...]
urtx# who am i
root pts/4 Apr 4 22:45 (alp.antinode.org)

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

But:

urtx# su sms
urtx# export DISPLAY=:0.0
urtx# xhost
access control enabled, only authorized clients can connect

Problem solved (again).

[sammysammy]

I am not sure which user have executed export DISPLAY in my enviornment. Is there any way I can tell which user account had actually executed export DISPLAY and xhost +?

Thanks