Ask Klaus

VNC-Based Shared Desktop

Hi Klaus: I was asked to provide a generic method of remote desktop sharing on a fairly complex environment. The servers in this environment are running Fedora 19/20 with LightDM as the desktop manager and a variety of desktop environments available on each server (Gnome/KDE/LXDE/Xfce/Openbox) with TigerVNC as the VNC server/client.

I need each VNC session to go through system authentication via LightDM (I skip VNC passwords by setting the Xvnc option -SecurityTypes None), but I want to be able to connect to existing sessions. I've tried to tackle this problem two different ways.

1. I managed to set up a shared Xvnc inetd service, but once the user goes through the initial LightDM authentication, any additional connections log in to the existing session WITHOUT any authentication (i.e., I can't get them to authenticate via LightDM). This, of course, is completely unacceptable from a security standpoint. I can work around the problem by forcing the VNC server to accept connections from localhost only and then from the client side use SSH local port forwarding to the VNC session, thus forcing people to authenticate via SSH, but I'm looking for a solution rather than a workaround.

2. Conversely, I managed to set up LightDM to handle all VNC connection requests by un-remarking the [VNCServer] section in /etc/lightdm/lightdm.conf, but each request starts a new session. I cannot get any session to be shared.

Your assistance will be greatly appreciated. Thanks, Shiron

Hopefully, I understood your request correctly, so let me explain first what happened in your two scenarios.

In your first experiment, you started the VNC server via inetd, which means that inetd will:

1. Open a port and listen to it.

2. Once a client connects, the Xvnc server is started, then LightDM running on the Xvnc server will ask for login/password as usual, and the user can log in.

3. If a second client connects, it will just be attached to the same port, same Xvnc server, and same running session, which explains what you experienced: You just get a copy of the same session with no password asked (because a user is already logged in to the running Xvnc).

What you really want is a choice of starting a new Xvnc server session or attaching to a running one using the user credentials. Unfortunately, this cannot be done by running a single Xvnc instance. Using just one network port and just running one Xvnc server will not work if you want multiple users logging in.

You will need a session manager as a gateway. It will either start a new Xvnc on a new, free local port every time a connection is made to the session manager, or it will attach the user to an already running session, which needs to be listed in the session manager's choice, asking for authentication. Here, you could add a password for Xvnc itself so that the user will be asked for her login+password when logging in the first time, and then for a "shared connection" password that will allow others to connect to the same session. This way, the login is protected, as well as access to the running Xvnc server.

So, your second experiment using LightDM as session manager for Xvnc sessions is already going in the right direction. However, a configuration with LightDM as a session manager for VNC sessions, which keeps track of all users running sessions in a list, may be more complex than necessary.

Maybe xrdp using the RDP protocol (which can be used by Linux and Windows – Windows has a built-in RDP client) is a better choice, because it comes with a session manager (sessman) and can be configured as a "terminal server" that starts up RDP user sessions on demand. The package name is xrdp in Debian. The xrdp service can be configured in /etc/xrdp/xrdp.ini and started as:

/etc/init.d/xrdp start

As a nice side feature, xrdp also has a plugin to bridge protocols between running VNC sessions and remote RDP connection requests. For this reason, I use it in Knoppix, too, for remote desktop viewing and control for teachers when started from the menu, exporting the running local session.

Frozen Screen

I have a relatively new HP notebook with an NVidia card that, when starting Ubuntu, Debian, or even Knoppix, will end up in a frozen, pixelated screen. Starting Knoppix with

knoppix64 xmodule=vesa

will give me a working display but with the wrong resolution. How can I get the full resolution and decent performance?

The graphics chipset in question (lspci shows the card as ID 10de:0cbc) is not completely supported in the Nouveau driver, which is the open source accelerated Xorg module for NVidia cards. With some rather minor drawbacks, you can still use this card without installing a proprietary driver.

The trick is that the Nouveau kernel module needs to be loaded with option noaccel=1, which can be set in /etc/modprobe.d/nouveau.conf as:

options nouveau noaccel=1

Note that modeset=1, which is needed for kernel mode settings to switch resolutions, is normally enabled by default. Or, in the boot loader's APPEND line, use:

nouveau.noaccel=1

Additionally, make sure to set:

Option "Composite" "Disable"

in the "Extensions" section of /etc/X11/xorg.conf; otherwise, Compiz or other desktop managers using Composite extensions for effects will cause pixel freeze. In Knoppix, disabling Composite can be done with the nocomposite boot option. The full boot command line for Knoppix would be:

knoppix64 nouveau.noaccel=1 nocomposite

With these options, you can expect a frame rate of about 550fps in glxgears, which is even sufficient for playing Tux Racer or Neverball.