We have been using a Xvnc server system in XDMCP mode to present a login greeter dialog to the TurboVNC viewer, so that the user can log in as from a local screen.
This has been working fine until recently, I suspect the recent tightening of security has changed the conditions.
We suddenly got a black screen instead of the greeter.
We tried to reinstall from scratch using the same methods as when we started, and now we cannot even get a black screen.
This combination used to work fine, but now TurboVNC viewer responds for connection "vnchost":50 with an immediate "Connection closed".
Testing with telnet from loaclhost:
telnet localhost 5950
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
RFB 003.008
Connection closed by foreign host.
The telnet response is the same from any remote host.
So it seems like some security issue.
What has changed?
I cannot find any log files that shows anything related to this problem.
Are there any alternative solutions to achieve the same function?
Any constructive input is appreciated.
BN
Last edit: BeNi 2016-06-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is not solved from TurboVNC's point of view. vnc4server is a much less performant and feature-rich implementation, so for most people, it would not be an adequate substitute. I will investigate the issue, but it will take a few weeks, as I am traveling right now.
I spent several hours looking at this. It's puzzling to me as well, because I can't figure out how you were able to make TurboVNC work with inetd in the first place. On all of the machines I tested (Ubuntu 14, RHEL 5, RHEL 6), this code:
caused the server to immediately fail with "setsockopt: Socket operation on non-socket", but because stderr had already been closed, that error was never displayed. That code is old-- it goes all the way back to at least TightVNC 1.2.9, which was the first version from which TurboVNC forked in 2004. Unless something magically changed recently to make that code not work on a variety of Linux distros, then apparently TurboVNC's inetd support has been broken for at least 9 years (that's how old RHEL 5 is) if not more.
When I remove the offending code, it produces the black screen, as you asserted. But so do TigerVNC 1.6.0 and RealVNC 4.1.1 (vnc4server). So I guess the first thing I need to know is how to make any of these solutions work, period. I tried adding xserver-allow-tcp=true under [SeatDefaults], which I'm given to understand is necessary to make XDMCP work properly. Still doesn't work.
This can easily be fixed in TurboVNC, but first I need to see it working with another VNC flavor. Your assistance is greatly appreciated, since I would like to get this fixed for the 2.1 release, which is long overdue.
Last edit: DRC 2016-08-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note, however, that I was able to successfully make TurboVNC work with xinetd and XDMCP on RHEL 6. The error message "setsockopt: Socket operation on non-socket" only occurred if I tried to manually launch Xvnc with the -inetd argument. If I launched it from xinetd, it worked properly and presented me with a login screen as expected.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just tried xdm on Ubuntu 14.04. It also works fine with TurboVNC, using the procedure in your original post. Also tried lightdm and gdm on another install of Ubuntu 14.04 and had no luck getting XDMCP to work with either, regardless of the VNC flavor used. If you are interested in actually helping us to improve our product, then I would appreciate help in reproducing your claims. Otherwise, this issue is closed. There is nothing I can do without the ability to reproduce the issues you are having.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry I missed your replies, apparently there was something wrong with my thread subscriotion settings. So I read your replies today, which maybe is too late.
I have installed vnc4server/inetd on a debian system, got it to "work", but my java application does not work with VGL: [VGL] 986: Could not obtain RGB visual on the server suitable for off-screen rendering
So I would like to bring up TurboVNC again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not working:
root@nnnnn:/etc# telnet localhost 5950
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
The system is running xdm, and I have edited /etc/X11/xdm/Xaccess to accept any host.
This worked for vnc4server but not for TurboVNC
The issue is the same as in my original post.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried the /opt/TurboVNC/bin/vncserver to create a personal vnc server, I connected to nnn:1 using the TurboVNC client, got in, but then I got a black desktop.
I looked at the ./vnc/xstartup.turbovnc, but I found no reference to the xdm display manager. Is xdm supported?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to get a desktop by modifying .vnc/xstart.turbovnc.
But my java 3D application did not run, while it does on the HW desktop.
So TurboVNC/VGL was no improvement in this case.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The VirtualGL error you're getting is likely because you aren't running a 3D graphics driver that supports Pbuffer rendering. If you have an nVidia or AMD/ATI GPU, it is recommended that you install their proprietary driver. Then the error ([VGL] 986: Could not obtain RGB visual on the server suitable for off-screen rendering) should go away. Follow the procedure outlined in the VirtualGL User's Guide to sanity check whether your 3D X server configuration properly supports Pbuffer rendering (https://cdn.rawgit.com/VirtualGL/virtualgl/2.5.1/doc/index.html#hd006). In a nutshell, you can run /opt/VirtualGL/bin/glxinfo -c on the root display to verify that you have Pbuffer-enabled FB configs available. If you don't, then VirtualGL will not work, and you won't be able to run 3D applications in TurboVNC. Some of the drivers that ship with Linux support Pbuffer rendering, but some don't, and even the ones that do aren't going to be as fast as the vendor-supplied drivers from AMD, nVidia, Intel, etc.
Your inetd command line is incorrect. There is no Xvnc4 in TurboVNC. The server is /opt/TurboVNC/bin/Xvnc.
TurboVNC doesn't use xdm. VirtualGL uses the display manager in order to get access to the GPU through the "root" X server (usually Display :0) while the server is sitting at the login prompt. TurboVNC, however, starts sessions on a per-user basis, so it works entirely under your user account credentials.
The black screen may be because you don't have the GNOME Fallback or GNOME Flashback session installed. TurboVNC's default xstartup.turbovnc file will launch Fallback or Flashback on Ubuntu 14.04 and later, if one of those WM's is installed. It does this to avoid Unity, which requires 3D support. You should be able to launch Unity in TurboVNC by passing -3dwm to it, but that assumes that VirtualGL is properly configured and working. It's usually better to run a 2D window manager in TurboVNC instead.
The default xstartup.turbovnc script will also look for MATE if it is installed on Ubuntu 14 and later. Make sure one of those WM's (either Fallback/Flashback or MATE) is installed, and you should be able to successfully start TurboVNC without a black screen and without modifying the default xstartup.turbovnc file.
The Java 3D application will require VirtualGL, which isn't working because of lack of Pbuffer support in your graphics drivers. Once you get that resolved, you should be able to vglrun your Java 3D application.
If any of the above still doesn't work, then let's take it one step at a time and try to resolve the problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The 3D java works on the HW desktop.
nvidia-vdpau-driver is installed, as well as libgl1-nvidia-glx.
There are more listed in synaptic (search: nvidia), I can give a complete list if necessary.
The inetd connection behaviour is the same with /etc/netd.conf:
vnc stream tcp nowait nobody /opt/TurboVNC/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 1280x1024 -depth 24 -securitytypes=none
root@ip-node:~# telnet localhost 5950
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
My provate "vncserver" works with the following xstartup.turbovnc
#!/bin/sh# Uncomment the following two lines for normal desktop:# unset SESSION_MANAGER# exec /etc/X11/xinit/xinitrc[-x/etc/vnc/xstartup]&&exec/etc/vnc/xstartup
[-r$HOME/.Xresources]&&xrdb$HOME/.Xresources
xsetroot-solidgrey
vncconfig-iconic&
xterm-geometry80x24+10+10-ls-title"$VNCDESKTOP Desktop"&#twm &
gnome-session&
which is fine with me, but I would really like to get the inetd solution working, since it is more flexible.
Finally: I am apparently unable to get any email notifications when you post a reply, is this normal?
Last edit: BeNi 2016-12-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I get that the Java3D application works on the local desktop, but when it's using VirtualGL, it has different visual requirements because VirtualGL redirects rendering into Pbuffers. Thus it is possible that, if your graphics driver isn't exporting Pbuffer-enabled visuals, a 3D application could work locally but not with VirtualGL. I again refer you to the aforementioned section of the User's Guide that lists a procedure that you can use to verify whether your drivers have Pbuffer support.
You should be able to click on the e-mail message icon at the top of the thread to enable notifications, but if they aren't working, then I have no idea why. Sourceforge. :|
I don't generally recommend XDMCP, for a variety of reasons. If you absolutely need it, then it is generally enabled in the display manager configuration file (for instance, in /etc/gdm/custom.conf if you're running GDM.) In a nutshell, TurboVNC isn't really designed to authenticate within the VNC session. It's designed to authenticate as you connect to the VNC session.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I fully understand the problem with the old XDMCP, but we have everything inside a HW firewall, so I am not too worried.
I will study the manual regarding Pbuffers.
Thanks for the info about the email icon, it will surely help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have given up on XDMCP.
I am now using a private vncserver, as suggested. The TurboVNC/bin/vncserver now works, after I removed all display managers (xdm, gdm3, lightdm and config files) and reinstalled lightdm.
Apparently, I don't have Pbuffer support in the vnc server environment:
/opt/VirtualGL/bin/glxinfo -c
name of display: :1.0
Xlib: extension "GLX" missing on display ":1.0".
Xlib: extension "GLX" missing on display ":1.0".
Xlib: extension "GLX" missing on display ":1.0".
Xlib: extension "GLX" missing on display ":1.0".
Xlib: extension "GLX" missing on display ":1.0".
Error: couldn't find RGB GLX visual or fbconfig
Xlib: extension "GLX" missing on display ":1.0".
Xlib: extension "GLX" missing on display ":1.0".
Xlib: extension "GLX" missing on display ":1.0".
Xlib: extension "GLX" missing on display ":1.0".
Error: couldn't find RGB GLX visual or fbconfig
Xlib: extension "GLX" missing on display ":1.0".
nvidia-detect recommends nvidia-glx, and apt-get claims I already have the latest version.
Next week I plan to change from Debian Wheezy to Ubuntu Server LTS.
I will get bakck to this thread once that is done.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You cannot run OpenGL applications in TurboVNC without using VirtualGL (vglrun). Please read these instructions for how to troubleshoot Pbuffer support:
Thanks, very useful instructions.
However my environment is currently not stable, for unknown reasons it crashes when I start|stop the display manager.
We decided not to put any more time into troubleshooting this, we will install something more modern and standard, such as the mentioned Ubuntu Server LTS.
I will be back to this next week.
👎
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have been using a Xvnc server system in XDMCP mode to present a login greeter dialog to the TurboVNC viewer, so that the user can log in as from a local screen.
This has been working fine until recently, I suspect the recent tightening of security has changed the conditions.
We suddenly got a black screen instead of the greeter.
We tried to reinstall from scratch using the same methods as when we started, and now we cannot even get a black screen.
OS: Ubuntu 14.04 LTS xfce4
openbsd_inetd
Xvnc server:TurboVNC Xvnc -inetd mode
/etc/services
....
"#"Local services
vnc 5950/tcp
/etc/inetd.conf
vnc stream tcp nowait nobody /opt/TurboVNC/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 2560x1024 -depth 24
/etc/lightdm/lightdm.conf
...
[XDMCPServer]
enabled=true
port=177
This combination used to work fine, but now TurboVNC viewer responds for connection "vnchost":50 with an immediate "Connection closed".
Testing with telnet from loaclhost:
telnet localhost 5950
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
RFB 003.008
Connection closed by foreign host.
The telnet response is the same from any remote host.
So it seems like some security issue.
What has changed?
I cannot find any log files that shows anything related to this problem.
Are there any alternative solutions to achieve the same function?
Any constructive input is appreciated.
BN
Last edit: BeNi 2016-06-15
The problem is now solved.
I removed TurboVNC and openbsd-inetd, replacing them with vnv4server and inetutils-inetd from the ubuntu repository.
The problem is not solved from TurboVNC's point of view. vnc4server is a much less performant and feature-rich implementation, so for most people, it would not be an adequate substitute. I will investigate the issue, but it will take a few weeks, as I am traveling right now.
I spent several hours looking at this. It's puzzling to me as well, because I can't figure out how you were able to make TurboVNC work with inetd in the first place. On all of the machines I tested (Ubuntu 14, RHEL 5, RHEL 6), this code:
https://github.com/TurboVNC/turbovnc/blob/master/unix/Xvnc/programs/Xserver/hw/vnc/sockets.c#L135-L139
caused the server to immediately fail with "setsockopt: Socket operation on non-socket", but because stderr had already been closed, that error was never displayed. That code is old-- it goes all the way back to at least TightVNC 1.2.9, which was the first version from which TurboVNC forked in 2004. Unless something magically changed recently to make that code not work on a variety of Linux distros, then apparently TurboVNC's inetd support has been broken for at least 9 years (that's how old RHEL 5 is) if not more.
When I remove the offending code, it produces the black screen, as you asserted. But so do TigerVNC 1.6.0 and RealVNC 4.1.1 (vnc4server). So I guess the first thing I need to know is how to make any of these solutions work, period. I tried adding
xserver-allow-tcp=trueunder[SeatDefaults], which I'm given to understand is necessary to make XDMCP work properly. Still doesn't work.This can easily be fixed in TurboVNC, but first I need to see it working with another VNC flavor. Your assistance is greatly appreciated, since I would like to get this fixed for the 2.1 release, which is long overdue.
Last edit: DRC 2016-08-30
Apparently I'm running into this bug, which still appears unsolved:
https://bugs.launchpad.net/lightdm/+bug/1212069
I switched to GDM, though, and it still doesn't enable XDMCP. I give up.
Note, however, that I was able to successfully make TurboVNC work with xinetd and XDMCP on RHEL 6. The error message "setsockopt: Socket operation on non-socket" only occurred if I tried to manually launch Xvnc with the
-inetdargument. If I launched it from xinetd, it worked properly and presented me with a login screen as expected.I just tried xdm on Ubuntu 14.04. It also works fine with TurboVNC, using the procedure in your original post. Also tried lightdm and gdm on another install of Ubuntu 14.04 and had no luck getting XDMCP to work with either, regardless of the VNC flavor used. If you are interested in actually helping us to improve our product, then I would appreciate help in reproducing your claims. Otherwise, this issue is closed. There is nothing I can do without the ability to reproduce the issues you are having.
Sorry I missed your replies, apparently there was something wrong with my thread subscriotion settings. So I read your replies today, which maybe is too late.
I have installed vnc4server/inetd on a debian system, got it to "work", but my java application does not work with VGL:
[VGL] 986: Could not obtain RGB visual on the server suitable for off-screen rendering
So I would like to bring up TurboVNC again.
I removed vnc4server from my debian, and re-activted TurboVNC in /etc/inetd.conf:
vnc stream tcp nowait nobody /opt/TurboVNC/bin/Xvnc4 Xvnc4 -inetd -query localhost -once -geometry 1280x1024 -depth 24 -securitytypes=none
Not working:
root@nnnnn:/etc# telnet localhost 5950
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
The system is running xdm, and I have edited /etc/X11/xdm/Xaccess to accept any host.
This worked for vnc4server but not for TurboVNC
The issue is the same as in my original post.
I tried the /opt/TurboVNC/bin/vncserver to create a personal vnc server, I connected to nnn:1 using the TurboVNC client, got in, but then I got a black desktop.
I looked at the ./vnc/xstartup.turbovnc, but I found no reference to the xdm display manager. Is xdm supported?
I was able to get a desktop by modifying .vnc/xstart.turbovnc.
But my java 3D application did not run, while it does on the HW desktop.
So TurboVNC/VGL was no improvement in this case.
Let me take these one at a time:
[VGL] 986: Could not obtain RGB visual on the server suitable for off-screen rendering) should go away. Follow the procedure outlined in the VirtualGL User's Guide to sanity check whether your 3D X server configuration properly supports Pbuffer rendering (https://cdn.rawgit.com/VirtualGL/virtualgl/2.5.1/doc/index.html#hd006). In a nutshell, you can run/opt/VirtualGL/bin/glxinfo -con the root display to verify that you have Pbuffer-enabled FB configs available. If you don't, then VirtualGL will not work, and you won't be able to run 3D applications in TurboVNC. Some of the drivers that ship with Linux support Pbuffer rendering, but some don't, and even the ones that do aren't going to be as fast as the vendor-supplied drivers from AMD, nVidia, Intel, etc.-3dwmto it, but that assumes that VirtualGL is properly configured and working. It's usually better to run a 2D window manager in TurboVNC instead.vglrunyour Java 3D application.If any of the above still doesn't work, then let's take it one step at a time and try to resolve the problems.
The 3D java works on the HW desktop.
nvidia-vdpau-driver is installed, as well as libgl1-nvidia-glx.
There are more listed in synaptic (search: nvidia), I can give a complete list if necessary.
The inetd connection behaviour is the same with /etc/netd.conf:
vnc stream tcp nowait nobody /opt/TurboVNC/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 1280x1024 -depth 24 -securitytypes=none
root@ip-node:~# telnet localhost 5950
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
My provate "vncserver" works with the following xstartup.turbovnc
which is fine with me, but I would really like to get the inetd solution working, since it is more flexible.
Finally: I am apparently unable to get any email notifications when you post a reply, is this normal?
Last edit: BeNi 2016-12-07
This might have something to do with XDMCP enable.
What file should I edit to enable XDMCP in this configuration?
I get that the Java3D application works on the local desktop, but when it's using VirtualGL, it has different visual requirements because VirtualGL redirects rendering into Pbuffers. Thus it is possible that, if your graphics driver isn't exporting Pbuffer-enabled visuals, a 3D application could work locally but not with VirtualGL. I again refer you to the aforementioned section of the User's Guide that lists a procedure that you can use to verify whether your drivers have Pbuffer support.
You should be able to click on the e-mail message icon at the top of the thread to enable notifications, but if they aren't working, then I have no idea why. Sourceforge. :|
Referring to this comment:
https://github.com/TurboVNC/turbovnc/issues/73#issuecomment-264493131
I don't generally recommend XDMCP, for a variety of reasons. If you absolutely need it, then it is generally enabled in the display manager configuration file (for instance, in /etc/gdm/custom.conf if you're running GDM.) In a nutshell, TurboVNC isn't really designed to authenticate within the VNC session. It's designed to authenticate as you connect to the VNC session.
I fully understand the problem with the old XDMCP, but we have everything inside a HW firewall, so I am not too worried.
I will study the manual regarding Pbuffers.
Thanks for the info about the email icon, it will surely help.
I have given up on XDMCP.
I am now using a private vncserver, as suggested. The TurboVNC/bin/vncserver now works, after I removed all display managers (xdm, gdm3, lightdm and config files) and reinstalled lightdm.
Apparently, I don't have Pbuffer support in the vnc server environment:
nvidia-detect recommends nvidia-glx, and apt-get claims I already have the latest version.
Next week I plan to change from Debian Wheezy to Ubuntu Server LTS.
I will get bakck to this thread once that is done.
You cannot run OpenGL applications in TurboVNC without using VirtualGL (vglrun). Please read these instructions for how to troubleshoot Pbuffer support:
https://cdn.rawgit.com/VirtualGL/virtualgl/2.5.1/doc/index.html#hd006001
Under "Sanity Check".
Thanks, very useful instructions.
However my environment is currently not stable, for unknown reasons it crashes when I start|stop the display manager.
We decided not to put any more time into troubleshooting this, we will install something more modern and standard, such as the mentioned Ubuntu Server LTS.
I will be back to this next week.