X11VNC

Introduction
VNC is a popular remote-desktop protocol. Most implementations of VNC servers on UNIX create their own X display that is not associated with a physical screen. This is very useful for allowing multiple remote users to have desktop sessions through VNC independently of anyone actually sitting at the computer. On the other hand, one might want to access a computer remotely in the following way:


 * Start a session on a physical display
 * Keep this session open, and access it remotely, then disconnect the remote session
 * Return to the physical display and continue using it.

This may be the case, for example, when one wants to use a computer at work remotely from home. One could of course start a further non-physical session on the work computer, if its main attraction is that it is faster or has some tedious proprietary programs not available at home. But if many necessary applications are open, arranged and perhaps currently running some calculation on the physical session then connecting to that physical session is desirable.

Problem
Working with opengl and existing X sessions is not supported by normal VNC packages.

To work remotely on a running session on a physical display, one can:


 * 1) run x11vnc as a user or
 * 2) configure the (physical display's) X server to support the vnc extension

Limitations

 * VNC uses a separate authentication system. It's not yet integrated with PAM, for example.
 * Users need to know the X display number to which they can connect. However, xrdp can solve this problem.
 * Unlocking a screen remotely also unlocks it locally.
 * A real monitor or at least a dummy xorg monitor should be attached to X.

Other Notes

 * Either of the methods presented here will have the same result: a remotely-accessible X session.
 * The ebuilds "vnc" or "tightvnc" may also be emerged for running further (non-physical) displays for other VNC logins, for providing a VNC client (vncviewer), and for the neat vncpasswd command.
 * tightvnc claims better compression in some cases, but (as of version 1.2.9) doesn't provide the X module, however, if you wish to use tightvnc, simply follow the directions for method 2, then unmerge realvnc and merge tightvnc, it will simply continue using the realvnc module for control of the X:0 display, using tightvnc compression.

USE Flags

 * - Enable threads.
 * - Enable Avahi support.
 * - Enable Unix password support.
 * - Enable JPEG compression.
 * - Enable built-in SSL tunneling and SSL cryptography.
 * - Disable internal libvncserver. This pulls in and enables the  USE-flag.
 * - Enable remote V4L access.
 * - Enable Xinerama support.
 * - Enable zlib(deflate) compression.

Installation
Take note that the USE flags and  are required for x11vnc to do compression.

User Server
In this method, the user that starts the X session also starts the VNC server. x11vnc is what we are going to use to connect to our current X session. Edit the x11vnc config file:. See

for more details (the config file options are just those from the command line but without the leading "-").

If it doesn't already exist, create :

For security we have to create a password for the incoming connections to the X session.

OR, if tightvnc or vnc is installed, just use their utility to do the same:

This passwd file will be used by x11vnc or tightvnc/realvnc servers to authorize incoming connection to displays that you start.

To start the vnc server you need the x11vnc command. This could be put somewhere for starting on login. E.g. make a script in ~/.kde4/Autostart/, perhaps by:

Start "gnome-session-properties" from your terminal, if you are GNOME user to setup autostart.

Else, start it manually each time, possibly necessitating logging in from a remote host by ssh and giving the x11vnc command, perhaps as

to allow you to log out leaving it running, and to have its output logged.

If no one is logged into an X session yet, but there is a greeter login program like "gdm", "kdm", "xdm", or "dtlogin" running, you will need to find and use the raw display manager MIT-MAGIC-COOKIE file. Some examples for various display managers:


 * gdm:    -auth /var/gdm/:0.Xauth
 * kdm:    -auth /var/lib/kdm/A:0-crWk72
 * xdm:    -auth /var/lib/xdm/authdir/authfiles/A:0-XQvaJk
 * xdm:    -auth /etc/X11/xdm/authdir/authfiles/A:0-gy9mxf (Gentoo xdm)
 * dtlogin: -auth /var/dt/A:0-UgaaXa
 * xorg7.0: -auth /var/run/xauth/A:0-TD4u0I

Only root will have read permission for the file, and so x11vnc must be run as root. The random characters in the filenames will of course change, and the directory the cookie file resides in may also be system dependent. Sometimes the command "ps wwaux | grep auth" can reveal the file location.

An example:

You can also setup x11vnc to autostart when KDE starts, by creating a symlink.

Once you login like this, x11vnc may crash, but your session will load. Start up x11vnc again as normal-user and you'll be able to login to your newly created session.

System Server
Install a vncserver package that provides the vnc.so extension module for the X server. (the vnc ebuild is "vnc": it works on amd64, and provides a vnc.so module for X11 server)

The Xserver needs to know where to look for authentication information when someone tries to connect. You could make some other file for this, if not wanting to reference a user's home directory (e.g. NFS root_squash or AFS): we'll use the familiar here.

Edit (for X.org server) or  for the old XFree server.

Save your changes and close your editor. You will have to restart X (no need to reboot, just log out (end session in KDE), and hit CTRL-ALT-BACKSPACE when the login window comes back up, then login).

You also need to create your passwd file that you specified above. Password: Verify:

If you're using the X.org server, you may need to create a symlink to vnc.so

Restarting X is presumably necessary to see the changes! To debug (if not able to connect by VNC) try the log files and stopping the display manager  then starting X from a terminal to see the messages.

The vnc.so module for VNC 4.1.2 was changed from vnc.so to libvnc.so. If you have VNC 4.1.2, you should make a simlink to from within.

System Server via x11vnc
Install x11vnc:

In our example we will run x11vnc physical screen session with name "default".

Make password file:

Refer to man x11vnc for options.

Create init script:

Add x11vnc service to autostart:

Note: You can run multiple services by copying init script and changing x11vnc name and options.

Headless Configuration
If you need a headless (no monitor) setup these additional steps are necessary:
 * disable kms using grub command line:

To disable kms as driver option. Create a file in the /etc/modprobe.d/ folder with an arbitrary name (e.x. kms.conf) and add a line in it.

driver name can be "nouveau", "i915", "radeon" or ... you can check availability of modeset option for your driver with modinfo command


 * setup a dummy graphic card and a dummy monitor


 * Note: What are told above are general settings that should be compatible with most of the hardwares. Your opengl driver in this setting would be llvmpipe that is a virtual software emulated driver. Using a driver specific options, however, you would be able to have hardware acceleration. You can also keep the kms and power management options of your GPU enabled. You don't need above configurations if you choose to use these driver specific options.

The Nvidia closed-sourced driver:

The open-source nouveau driver:

The open-source radeon driver:

The ATI driver:

Clients
Whichever method (user-started x11vnc or X-started Xorg vnc extension) you have chosen, you should now be able to log in by connecting as:

from some host with vncviewer (part of vnc or tightvnc ebuilds---see first section for comparison).

BUT: the catches are the following:

1) You may find that although x11vnc or Xorg's extension is running listening to the physical display :0 (or :1 or whatever), the respective conventional port of 5900 + displaynumber may have been occupied, forcing the tcp listening to be on a higher port: you should be able to find this in the log output of whichever server you used. So you might, for example, need to connect to HOST:2 by vnc to view display :0 ...

2) If you've specified the localhost option for the server, then it will only allow connections _to_ localhost (127.0.0.1) through the loopback interface, accessibly only on the local host---not much use for remote connection, you may think: but a solution is to use SSH tunnelling, which also makes the connection far more secure:

where host is the host on which the vnc server is running, and which must have the SSH service accepting connections! You will then be asked for your system login followed by the vnc password for the display you've chosen.

3) Even if you didn't specify localhost, there may be packet-filtering preventing incoming connections, so either open the relevant ports or use SSH tunnelling as above.

Bear in mind that the type and level of compression of the picture is very important to good performance. It seems that when SSH tunnelling is used, and the VNC display is "localhost", the automatic compression selection can go for very low compression (assuming a true local connection).

Some good command-line options are:

to use full colour, tight encoding, and allow multiple simultaneous users of the session! See the manual page for more details.

As an example of some vncviewer options from the previous version of this page (the compression-related ones don't work with my client, in RHEL4):

Add these or read the manual, if wanting compression more suited to slower connections. Correctly set, vnc allows very efficient use of bandwidth and impressive speed of working even on quite low-rate connections: don't tolerate low colour or sluggish response without playing with the variables, unless you

Note that as vnc essentially sends a load of pictures, fast movement makes it much more sluggish. So, those streams of text churning down an open console can use 100% CPU on the server for compressing the images, then fill up the network connection too. Just minimising all unneeded such windows is a very good start to avoiding this problem!

Localhost bound X Server
Even though X is handling the VNC connections directly through the X VNC module, it is still possible to force it to listen on the localhost interface only, or bind to a specific interface at your choosing.

For the localhost option, add the following to the "Screen" section of your file:

Restart your X server and verify that your VNC connections are now only listening on your localhost interface:

X        27426          root   19u  IPv4 6548414       TCP 127.0.0.1:5900 (LISTEN)

You should now be able to tunnel your VNC connections over SSH to localhost:5900. This setup will provide two things, two sets of verification credentials to access your system, SSH and VNC itself and an encrypted session.

Dual-Head Displays
Depending on your particular setup, the X VNC module for will allow connections to either one or both monitors. If you desktop spans over monitors (effectively one X session stretched across monitors), then no further configuration needed.

Another common setup is to have a separate session for each monitor that allows for mouse movement between them (normally a single video card with dual outputs). In this scenario, VNC will only allow for a connection to one head/monitor per session (you can of course run two remote sessions concurrently). Your primary monitor will listen on port tcp/5900. The second head will listen on port tcp/6900. How you connect to the second head is dependent on your particular viewer application. Most will simply require that you append ':6900' to the connection string. You may also need to duplicate the "Option" statements for each Screen section in your.

Once configured, you can check to see if your X server is listening on the proper ports.

X       27426    root   19u  IPv4 6548414       TCP 127.0.0.1:5900 (LISTEN) X       27426    root   20u  IPv4 6548415       TCP 127.0.0.1:6900 (LISTEN)

Tunnelling Script
This simple script takes two arguments, first is open or view, the second is user@target. Written with GDM in mind.

Links

 * More VNC SSH Tunnel Information
 * Gentoo Wiki VNC - old wiki cached version