x0vncserver (TigerVNC) - physical display :0 owned by GDM, connection refused even to display :1

[fermu...@gmail.com]

Hey all,

I'm hoping to bounce some ideas; struggling to get x0vncserver binary to connect to my physical display (run by GDM)

i am remote, and /really/ need to connect to this physical display grrrr
{{{
just get connection refused...
vncviewer: ConnectToTcpAddr: connect: Connection refused
}}}

Debug Info:

$ ll /tmp/.X11-unix/
total 0
srwxrwxrwx 1 gdm gdm 0 Feb 14 09:02 X0 <<--- the main GDM
srwxrwxrwx 1 FOO Domain Users 0 Feb 14 09:03 X1 <<--- i want in to this one
srwxrwxrwx 1 gdm gdm 0 Feb 24 06:50 X1001 <-- someting else started this
srwxrwxrwx 1 FOO Domain Users 0 Feb 24 10:00 X1002 <- don't care (it's a virtual session)

# -----
First off, of note, is that I /can/ start vncserver (virtual display), and it all works,
{{{
# server
$ vncserver :5 -geometry 800x600 -depth 24
# client
$ vncviewer <hostname>
}}}
, done; works fine

# -----
# BUT, I need access to the /physical/ session...
# to start (for my sanity) i can even use x0vncserver binary to attach to the one i don't want to, it works
$ x0vncserver -display=:1002 -Log=*:stdout:0 -rfbport=5900 -PasswordFile=/home/FOO/.vnc/passwd
--> WORKS (but ugh i don't want that virtual display, )

# If I try the one I /want/, it "starts", but doesn't do anything nor does it work, no logs , ugh
$ x0vncserver -display=:1 -Log=*:stdout:100 -rfbport=5900 -PasswordFile=/home/FOO/.vnc/passwd
{{{
Fri Feb 24 13:43:27 2017
Config: set rfbport(Int) to 5900
Config: set PasswordFile(String) to /home/mcallaghan/.vnc/passwd
}}}

NO_MORE_OUTPUT

# on client
$ vncviewer <HOSTNAME>
vncviewer: ConnectToTcpAddr: connect: Connection refused
Unable to connect to VNC server

The server-side, NOTHING logs :(
{{{
<EMPTY>
}}}

It's almost as though the firewall is blocking ..?? but ; it worked fine for the virtual display!

And, to confirm:
{{{
$ sudo firewall-cmd --list-all | egrep "vnc|590"
services: dhcpv6-client samba mdns samba-client ssh vnc-server
ports: 1025-65535/udp 1025-65535/tcp 5900/tcp 5901/tcp
]}}

---

if I try to have x0vncserver hook into the gdm display 1001, it can't do it...
(tried sudo, as my own user, and even {sudo su - gdm -c "x0vncserver ..."}

if I try to hook into gdm display 0, it behaves the same as display:1

[fermu...@gmail.com]

for my sanity, these are the refs I've been using to try to figure it out...

http://tigervnc.org/doc/x0vncserver.html

http://leranda.com/2014/03/connect-to-physical-display-using-tigervnc/

https://www.server-world.info/en/note?os=Fedora_24&p=desktop&f=6

https://wiki.archlinux.org/index.php?title=TigerVNC#Running_vncserver_to_directly_control_the_local_display
https://help.ubuntu.com/community/VNC/Servers#TigerVNC
https://www.linuxquestions.org/questions/linux-newbie-8/vncserver-works-but-x0vncserver-doesn%27t-794997/
http://unix.stackexchange.com/questions/17255/is-there-a-command-to-list-all-open-displays-on-a-machine#17278

[DRC]

VirtualGL includes a script (vglserver_config) that modifies the startup
environment of most display managers in order to grant access to the
root X server (optionally for a specific user group, or for all users on
the system) while the display manager is sitting at the login prompt,
and that sounds like what you need. VGL does that so it can access the
GPU through the root X server, but you could just as easy take advantage
of that same access in order to start x0vncserver on Display :0. Note
that the act of logging in and logging out will probably disconnect
x0vncserver, but you can still reconnect it.

vglserver_config should work on all reasonably stable Linux distros.
There is a known issue with the bleeding edge version of GDM used in the
latest Fedora releases whereby it doesn't run the normal GDM startup
scripts (and thus the hooks VirtualGL inserts into those scripts to
grant access to itself are never executed.) However, switching to
LightDM on those bleeding edge platforms in an easy workaround.

DRC

[fermulator]

On Friday, February 24, 2017 at 2:21:43 PM UTC-5, DRC wrote:
> VirtualGL includes a script (vglserver_config) that modifies the startup
> environment of most display managers in order to grant access to the
> root X server (optionally for a specific user group, or for all users on
> the system) while the display manager is sitting at the login prompt,
> and that sounds like what you need. VGL does that so it can access the
> GPU through the root X server, but you could just as easy take advantage
> of that same access in order to start x0vncserver on Display :0. Note
> that the act of logging in and logging out will probably disconnect
> x0vncserver, but you can still reconnect it.
>
> vglserver_config should work on all reasonably stable Linux distros.
> There is a known issue with the bleeding edge version of GDM used in the
> latest Fedora releases whereby it doesn't run the normal GDM startup
> scripts (and thus the hooks VirtualGL inserts into those scripts to
> grant access to itself are never executed.) However, switching to
> LightDM on those bleeding edge platforms in an easy workaround.
>
> DRC
>

> > Config: set PasswordFile(String) to /home/FOO/.vnc/passwd

> > }}}
> >
> > NO_MORE_OUTPUT
> >
> > # on client
> > $ vncviewer <HOSTNAME>
> > vncviewer: ConnectToTcpAddr: connect: Connection refused
> > Unable to connect to VNC server
> >
> > The server-side, NOTHING logs :(
> > {{{
> > <EMPTY>
> > }}}
> >
> > It's almost as though the firewall is blocking ..?? but ; it worked fine for the virtual display!
> >
> > And, to confirm:
> > {{{
> > $ sudo firewall-cmd --list-all | egrep "vnc|590"
> > services: dhcpv6-client samba mdns samba-client ssh vnc-server
> > ports: 1025-65535/udp 1025-65535/tcp 5900/tcp 5901/tcp
> > ]}}
> >
> > ---
> >
> > if I try to have x0vncserver hook into the gdm display 1001, it can't do it...
> > (tried sudo, as my own user, and even {sudo su - gdm -c "x0vncserver ..."}
> >
> > if I try to hook into gdm display 0, it behaves the same as display:1
> >

Interesting. So I also was trying NoMachine (NX server), and it ships with this script.
{{{
$ sudo /usr/NX/scripts/vgl/vglserver_config --help

USAGE: /usr/NX/scripts/vgl/vglserver_config [flags]

Flags (for unattended mode):
-config Configure server for use with VirtualGL
-unconfig Unconfigure server for use with VirtualGL
-s Restrict 3D X server access to vglusers group [default]
+s Open 3D X server access to all users of this machine
-f Restrict framebuffer device access to vglusers group [default]
+f Open framebuffer device access to all users of this machine
-t Disable XTEST extension [default]
+t Enable XTEST extension

Flags (for both interactive and unattended modes):
-gid {g} If vglusers group must be created, then set its group ID to {g}
}}}

and indeed, one could install VirtualGL toolkit...
{{{
$ dnf search virtualgl
Last metadata expiration check: 3:32:12 ago on Fri Feb 24 11:46:16 2017.
=============================================================================== N/S Matched: virtualgl ================================================================================
VirtualGL-devel.i686 : Development headers and libraries for VirtualGL
VirtualGL-devel.x86_64 : Development headers and libraries for VirtualGL
VirtualGL.i686 : A toolkit for displaying OpenGL applications to thin clients
VirtualGL.x86_64 : A toolkit for displaying OpenGL applications to thin clients
}}}

[Fermulator]

Crud. After configuration
{{{
Done. You must restart the display manager for the changes to take effect.
}}}
, this doesn't help me get into the physical display remotely NOW :/
I don't want to restart GDM, else I'll lose my session

[DRC]

I don't understand. If it's sitting at the login prompt, then what is
there to lose? Just restart x0vncserver after you restart GDM.

[DRC]

Perhaps I misunderstood something. vglserver_config is designed to
grant access to the X server while the display manager is sitting at the
login prompt. If the X server is logged in, then you shouldn't need
vglserver_config in order to access it. All you need in that case is to
log in via SSH using the same user account. The appropriate cookie for
Display :0 will be in ~/.Xauthority if the user is logged in locally.

On 2/24/17 2:24 PM, Fermulator wrote:

[Fermulator]

There is a real session logged in @ DISPLAY 1, that's what I need to connect to.

[Fermulator]

I do not see any flags/parameters to pass into x0vncserver that could leverage the Xauthority file?

[DRC]

Is Display :1 a "local" display connected to a real graphics device?
And are you logged into that display using your own account? If so,
then you shouldn't need to do anything other than run 'DISPLAY=:1
x0vncserver' in order to connect to it. But you might try

xauth merge ~/.Xauthority

prior to connecting, in case for whatever reason your ~/.Xauthority file
isn't automatically being loaded in the SSH session. Otherwise, I have
no clue. Your original message said you were trying to connect to
Display :0, and now you are contradicting that, so I no longer have any
clear idea of what you are trying to do.

[Fermulator]

Right, I see the confusion. Will clarify:
 - Primarily, want to connect to DISPLAY=:1. <-- This is the /actual/ physical user's session, running yes on a physical graphics card.
 - In the past, I've had issues (physically at the desktop) and sometimes switching to DISPLAY=:0, allowed me to access GDM login, and I could login to that same user, and it flipped me into DISPLAY=:1.

So, I was primarily trying to get to :1 (actual user), but was also trying for :0 (gdm session) - either one, I had hoped, would provide accessibility.

Unfortunately, /both/ attempts for x0vncserver resulted in the "blank output" and "connection refused" issue, and then of course I was getting muddled up with different user accounts since I was trying to attached via the actual user account, or posing as GDM...

This was the command I /thought/ should have worked
{{{
# as the user account user:

$ x0vncserver -display=:1 -Log=*:stdout:100 -rfbport=5900 -PasswordFile=/home/FOO/.vnc/passwd

}}}

But you have suggested 2x additional ideas;
 1) xauth merge ~/.Xauthority
 2) DISPLAY=:1; x0vncserver ...

Will try this as soon as I can.
(sadly, the remote system is no longer responding to SSH (connection timeout on read) ... so I've got to deal with that first now sigh)

[DRC]

Yes, if you are trying to connect x0vncserver to another user's X
session, then you will need to merge that user's .Xauthority file into
yours (using 'xauth merge'.) That requires having access to their home
directory, i.e. root privileges. This would be the case if you wanted
to run any X program against that user's X session, so your issue is not
specific to x0vncserver.

> --
> You received this message because you are subscribed to the Google
> Groups "TigerVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to tigervnc-user...@googlegroups.com
> <mailto:tigervnc-user...@googlegroups.com>.
> To post to this group, send email to tigervn...@googlegroups.com
> <mailto:tigervn...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tigervnc-users/f95b6bf4-a17b-4f3a-b072-029620788849%40googlegroups.com
> <https://groups.google.com/d/msgid/tigervnc-users/f95b6bf4-a17b-4f3a-b072-029620788849%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Fermulator]

Wasn't able to recover SSH connectivity awkward... Going to physical workstation today to see what happened.

NOTE: this entire time I /have/ been trying to connect to my own user's session. DISPLAY =:1 is owned by me, and I was starting x0vncserver as that user.
(except for when I was trying to get DISPLAY=:0, owned by gdm of course)