Compiling and running VNC in Linux

NC is a remote control application that sends the display, mouse, and keystrokes to a remote computer. (Not all keystrokes are transmitted—if you type Ctrl-Alt-Delete, for instance, it reboots your local PC instead of the remote one.) It's particularly useful in communicating between Linux and Windows machines.

This document describes how to set up Tight VNC 1.3.9 on a Linux server.

There are several different kinds of vnc out there with different ways of configuring them. I prefer to compile it myself, so I can use the same one on both newer and older computers.

Building vnc server

1. Download and untar vnc server source code.
2. cd vnc_unixsrc
3. xmkmf
4. make World
5. cd Xvnc
6. ./configure
7. make
8. cd ..
9. su
10. ./vncinstall /usr/local/bin /usr/local/man

Some versions of vnc use a file in /etc/sysconfig/vncservers. This has the advantage of only needing to start a single copy of Xvnc, which is running as root. The vncservers file looks like this:
VNCSERVERS="1:bruce 2:lance 3:steve"
VNCSERVERARGS[1]="-geometry 1920x1080"
VNCSERVERARGS[2]="-geometry 800x600"


Other versions ignore this file. For these versions, each user starts a separate copy of Xvnc and leaves it running continuously. This may be a little safer, but is less scalable. Typically this second scheme would be used if all your Windows users log in on the same shared account. The second version is described here.

Xvnc is started using the vncserver, which is a script that needs to be edited.

Running vnc server

1. For each user: Type vncpasswd to create the ~/.vnc directory and default startup files for that user.
2. Edit their xstartup file, e.g. /home/bruce/.vnc/xstartup. This file is comparable to the ~/.xinitrc file for X11. The last line is their window manager. My xstartup file looks like this:
   #!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
/usr/bin/urxvt -geometry 100x35+100+100&
/usr/bin/urxvt -geometry 100x35+100+200&
/usr/bin/wmcalclock&
/usr/local/bin/e16
3. Edit the vncserver script and set the correct path, like this:
   #$fontPath = "unix/:7100";
$fontPath = "/usr/share/fonts/,/usr/share/fonts/misc,/usr/share/fonts/100dpi/,/usr/share/fonts/75dpi/";
   The vncserver script can also be edited to change the window size and other parameters.
4. Start a copy of Xvnc for each user, giving each user a different screen:
   su bruce; vncserver :1
su lance; vncserver :2
su steve; vncserver :3
They will be logged in as the person who started the vncserver, so if you're using this type of vnc, you need to be careful not to start vncserver as root.
5. On your firewall, open ports 5901 to 5901 + number of users, and ports 6001 to 6001 + number of users. Each user needs a different port.

This procedure might seem strange since you can't connect to X11 using vncviewer (e.g., by typing vncviewer localhost:0). VNC is not really an X server; they use entirely different protocols. It is only sending a copy of the display.

X11 doesn't even have to be running in order to use Xvnc, so if the server is on a text-mode command line Xvnc still gives you a graphical desktop. But X11 has to be installed, and of course the files you include in your xstartup must exist. So you could use it as a cheap KVM switch if you want. With a fast enough network, there's no reason not to.

Connecting

1. From Linux:
   vncviewer server.domain.com:1
   VNC will try to connect you to the specified screen (:0, :1, etc.) using your current login name. If the screen happens to be :0, as is the case on Windows vncserver, you can omit the :0. Notice there must be no space between the hostname and the colon in this command, but other vnc commands require it.
2. In Windows: Click on the vncviewer.exe icon and enter server.domain.com:1.
   
3. Personally I don't bother with hostnames, because I have all the IP addresses memorized. In that case, you would type:
   vncviewer 192.168.100.1:1
4. To stop it, type vncserver -kill :1 . This kills the remote for one single user.

Caveats

1. VNC also opens a second port whereby it communicates via HTTP protocol. This allows users to connect to it using a Java-enabled browser. The default ports for regular VNC are 5901 for :1, 5902 for :2, etc. The default ports for HTTP VNC start at 5801. I've never gotten it to work; all the browsers that I've tried just get hopelessly confused.
2. Vncserver can be restricted to a specific network interface using the option -interface your-ip-address. This is an essential feature: if you have a public and a private interface, you want to block the public one to avoid getting scanned by IT or by outsiders. IT will accuse you of running a web server, which is not a good thing to happen in a corporate environment, so it's best to turn off or block this function.
3. If you set it to :0 it can screw up your X11 session if one is running. So don't do that, either.
4. This version of VNC use doesn't use TCP wrappers, so intruders can't be locked out with hosts.deny.
5. VNC uses its own password, not the system password. If you don't set a password on a Windows server, anyone can log in without a password. When Xvnc is running on a Unix server, not setting a password causes the Windows user to get an error message.
6. VNC tries to log in as the username of whoever is starting vncviewer. In Linux, you can specify the user with the -user username option. In Windows, there is no way to specify the username as far as I can tell. This means your users must have the same username on the server as on their Windows PCs.

I'm a big fan of this program. It eliminates the expense and hassle of trying to get an X11 running on a Windows machine. We use vnc on all our HPLC instruments, so we can watch the data from our desk as it appears. We can start a new sample or stop the machine remotely if a problem occurs without having to run down the hall trying to get through all those damn security doors.

When you run it in Windows, it even puts anything you select into the clipboard of the local PC, so you don't even have to transfer files from one PC to another.