On 4/5/18 2:52 PM, qwofford wrote:
> I realized shortly after posting that I mis-spoke. Although I have
> tigervnc installed, I am using xinetd to launch Xvnc, /not/ tigervnc.
>
> |
> service xvnc_darwin
> {
> disable =no
> protocol =tcp
> socket_type =stream
> wait =no
> user =nobody
> server =/usr/bin/Xvnc
> server_args =-Log*:syslog:100-inetd -query localhost -once -geometry
> 1024x768-depth 24securitytypes=none
> }
> |
>
> Do you prefer using Xvnc for *nix systems in your own work, or something
> else? It is not important to me how remote X servers are managed, I just
> need multiple users to be able to create an SSH tunnel, and point their
> TurboVNC viewer at this port to receive a private remote desktop, with
> VirtualGL capabilities. This xinetd/XDMCP configuration popped up on the
> RHEL 7 server documentation, so this is where I got the idea. Very open
> to your thoughts.
TurboVNC is recommended and supported by this project. If you have
TigerVNC installed, then /usr/bin/Xvnc is probably the TigerVNC Server,
so I think your initial assertion was correct. XDMCP (which provides a
login dialog within the VNC session) is old and very insecure, and it
isn't necessary, because Xvnc sessions are inherently per-user. When
you start an Xvnc session (regardless of whether you're using TurboVNC
or TigerVNC or RealVNC or whatnot), it runs under the credentials of the
user account that started it, and it chooses a unique port so as not to
conflict with other Xvnc sessions on the same machine. TurboVNC and
TigerVNC both have the ability to authenticate remotely, using either
their own built-in encryption and authentication layer or using an SSH
tunnel for both encryption and authentication. The general procedure
for TurboVNC would be (assuming the TurboVNC Server is installed on the
server machine-- note that you can install TurboVNC concurrently with
TigerVNC, since our installation resides in /opt/TurboVNC):
- Log into the server using SSH
- Start a TurboVNC Server session by running /opt/TurboVNC/bin/vncserver
in the SSH session. The vncserver script will report back the display
number that Xvnc is listening on. NOTE: It will ask you to choose a VNC
password. Choose something that is not the same as your Unix password.
- Start the TurboVNC Viewer on your client machine.
- Enter the hostname:display that Xvnc is listening on, and click "Connect".
- Enter the VNC password when prompted.
This is the simplest way to get up and running. More advanced
configurations include:
- Using Unix login credentials. Generally you would do this by:
* (as root) Copying /etc/pam.d/passwd to /etc/pam.d/turbovnc on the server
* Passing '-securitytypes TLSPlain,X509Plain' to
/opt/TurboVNC/bin/vncserver.
This ensures that the Unix password won't be passed over the network
without encryption, and it disables other forms of authentication. You
can optionally add the OTP security types (TLSOtp,X509Otp,OTP) to this
list if you want to use either Unix login credentials or a one-time
password. That would be useful, for instance, if you wanted others to
be able to temporarily connect to your session for collaboration
purposes. You can also modify /etc/turbovncserver-security.conf to
enforce this type of authentication for all TurboVNC sessions started on
the machine.
- Using one-time passwords. Generally you would do this by passing
'-otp' to /opt/TurboVNC/bin/vncserver. You can then enter the token it
prints to the console instead of a VNC password, when prompted by the
TurboVNC viewer. Since the token is discarded after one use, it is safe
to use it without encryption. Run '/opt/TurboVNC/bin/vncpasswd -o' on
the server to generate a new OTP.
- Using time-based one-time passwords/Google Authenticator. Refer to
https://turbovnc.org/Documentation/TOTP for instructions.
- Using SSH. Generally you would do this by:
* modifying /etc/turbovncserver-security.conf and setting
no-reverse-connections
no-remote-connections
permitted-security-types = VNC, OTP
NOTE: this disables TurboVNC's built-in encryption, since you're
using SSH, but it continues to enable simple authentication. This is to
prevent others from launching a VNC viewer within their own VNC sessions
on the same machine and thus connecting to your session. If that isn't
a concern, then you can set 'permitted-security-types = None'.
* In the TurboVNC Viewer, prior to connecting, set the "SSH user" and
"Host" fields under the "Security" tab in the Options dialog (must use
the Java version of the viewer if you're running a Windows client), then
check "Use VNC server as gateway" and click "OK". When you connect, the
viewer will now prompt you for the SSH password as well as the VNC password.
Documentation is here:
https://turbovnc.org/Documentation/Documentation
Also, please address any support questions that are specific to TurboVNC
to one of those Google groups:
https://turbovnc.org/About/MailingLists
> Once I'm able to access the server node, I will plug in a monitor to
> assess whether I am able to run GL applications, such as glxinfo.
>
> I was not able to run the sanity checks from your documentation, because
> I do not have a vgl_xauth_key file in /etc/opt/VirtualGL/. In fact,
> there are no files in this directory at all. Perhaps this is where I
> should have started our discussion!
>
> I ran the vglserver_config to view its output once more, and noticed
> that part of the setup failed with 'can not rmmod nvidia, module is
> currently in use by nvidia_modeset. I stopped the gdm service again, and
> used rmmod to remove all the nvidia dependencies, and finally the nvidia
> module itself before running the vglserver_config. I am still unable to
> use vglrun from the remote desktop, but perhaps the file I am missing in
> /etc/opt/VirtualGL has something to do with that?
Yep. GDM bug. <sigh> I don't know why that silly bug hasn't been
fixed. It has existed for years now.
I am seeking funding for a project that will allow VirtualGL to access
the GPU without going through an X server-- using nVidia's EGL
implementation (https://github.com/VirtualGL/virtualgl/issues/10).
However, that's likely to be a very disruptive project, requiring a lot
of time and money to implement. So far, no one has stepped forward to
sponsor it financially.
--
You received this message because you are subscribed to the Google Groups
"VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/virtualgl-users/476f95ad-f6f0-a1d8-4192-6d2840038a18%40virtualgl.org.
For more options, visit https://groups.google.com/d/optout.
