Running a VNC Server

Because X is the GUI environment that's most common on Linux, and because X was designed with network operations in mind, X is a common method of remote GUI access in Linux. X is not, however, the only method. Another tool, VNC, is available for providing remote GUI access to Linux. As described shortly, VNC uses a different network model than does X, and so has certain inherent advantages and drawbacks. Installing and configuring a VNC server is also a very different task than is installing and configuring an X server. Likewise, using a VNC client for remote access is different than using an X server.

Understanding the VNC Client/Server Relationship

I've taken pains in the preceding discussion to make the client and server roles of different programs explicit. This can become confusing at times, because in any connection, one computer functions as a client and the other as a server for one protocol, but this client/server relationship is reversed for another. VNC is somewhat easier to discuss because the connections between the two computers are simpler and more intuitively understandable to most people: The user sits at a VNC client and runs programs on the VNC server. This relationship is like that of a Telnet or SSH server.

If you recall the earlier discussion of the relationship between X clients and servers, though, you may wonder how this happens. After all, the X server controls the keyboard, mouse, and display, so how can the user not sit at the X server but still use X programs? The answer is an added layer of network complexity that's hidden from the user. The VNC server computer runs the X clients, which talk to an X server that runs on the local computer. This X server interfaces to the VNC server as if the VNC server were the human input and output devices. Instead of using the local keyboard, mouse, and display, though, the VNC server uses a network connection to communicate with a remote VNC client, which provides the input/output devices. This arrangement, and a comparison of it to a normal local X server and a networked X server, is shown in Figure 14.5. As you can see, it adds considerable complexity compared to a traditional remote X server configuration, but this complexity is largely hidden from the user.

Figure 14.5. A VNC server runs its own custom X server locally, and interfaces to a simple remote network client that provides a keyboard, mouse, and monitor for the X server.

The X server that's run on the VNC server system can maintain its state even if the VNC link is broken. For instance, if the VNC client system crashes, or if the user simply exits from the VNC server without logging out, the VNC server continues to run, and the next time a user makes a connection to the VNC server, all the applications that were run on the VNC server will remain open . This feature can be extremely convenient in some environments, but you shouldn't rely on it too heavily. Just as when you step away from a computer console for an extended period, the VNC server might crash, or the connection might be hijacked. (This maintenance of the local state doesn't apply when you use VNC in conjunction with XDMCP, as described in the upcoming section, "Running an XDMCP Login Server in VNC.")

In terms of security, VNC sits in-between a plain X connection via Telnet or XDMCP and an SSH-encrypted X connection. VNC encrypts its passwords, so they should be reasonably secure; but VNC doesn't encrypt other data, so anything you type or display after logging in could conceivably be viewed by others, particularly if your connection passes over the Internet at large.

X was designed with network operations in mind; it passes data in terms of lines, characters , and so on, not the bitmaps that are displayed on the screen. This results in a large number of back-and-forth transactions that transfer relatively little data. VNC, by contrast, is more bitmap-oriented; it performs relatively few transactions, each of which transfers more data. This fact means that on some networks and for some applications, VNC is more sluggish than a normal X connection, because more data must pass between the computers. For instance, if you use a text editor, the text editor can pass words to the X server, which generates the bitmaps for those words locally. VNC, however, must pass the entire bitmap, which is usually larger than a higher-level description of the display. This advantage may be small or nonexistent on a fast network or when running programs like bitmapped graphics editors, though. On the other hand, VNC's use of fewer data exchanges means that it can be faster if your connection has a very high latency, such as a satellite link; the many back-and-forth exchanges of conventional X slow it down in such situations. If you're dissatisfied with VNC's speed, you might look into an expanded version of VNC that supports more efficient encodings, such as TightVNC (http://www.tightvnc.com) or TridiaVNC (http://www.developvnc.org). These more bandwidth-efficient encodings consume more CPU time, though, so they're best used when both systems have fast CPUs. Likewise, tunneling VNC through SSH and using its compression features can improve or degrade performance, depending on available bandwidth and CPU time.

One of the big advantages of VNC over X is that you can use VNC to control a Windows or MacOS system. Although they don't use an X server internally, as shown in Figure 14.5, VNC servers for Windows and MacOS are available. These servers intercept the Windows or MacOS screen display and user input calls and echo the results to the VNC client, or take input from that client. I don't describe the operation of these Windows and MacOS VNC servers, though. They're conceptually similar to the Linux VNC server, but the Windows and MacOS servers offer fewer options and are configured through dialog boxes rather than text files. You can connect to the Windows and MacOS VNC servers exactly as you connect to a Linux VNC server. Because the Windows and MacOS VNC servers intercept screen calls, it's only practical for one person to use the computer at once.

Installing a VNC Server

You can obtain a VNC server from the main VNC Web site, http://www.uk.research.att.com/vnc/. Both the VNC server and the VNC client also ship with many Linux distributions (VNC is an open source package). Some distributions ship both server and client in a single package (usually called vnc ), but others break out the server and client packages (usually called vnc-server and vnc , respectively). The TightVNC and TridiaVNC sites have their own packages, but their installation and use is similar to what's described here.

If your distribution ships with VNC, or if you want to install it from an RPM or Debian file obtained from another source, you should be able to accomplish the task by installing the package in the usual way. As of version 3.3.3r2, the original VNC's official distribution form is precompiled x 86 binary code in a tarball or zip file, or source code. Assuming you obtain the code as a binary tarball, you can install it as follows :

1. Uncompress the tarball with a command such as tar xvfz vnc-3.3. 3r2_x86_linux_2.0.tgz . This creates a directory called vnc_x86_linux_ 2.0 .

2. Copy the files vncviewer , vncserver , vncpasswd , vncconnect , and Xvnc from the vnc_x86_linux_2.0 directory to a directory on your path , such as /usr/local/bin . Alternatively, you can move the entire vnc_ x86_linux_2.0 directory to a location such as /opt and either add it to your path or create links from these program files to a location on your path.

3. Create a directory called .vnc in the home directory of the user who is to use VNC. This directory should be owned by the user in question. It will hold individualized VNC configuration files, including a VNC password file. To prevent snooping, you might want to set this directory's permissions to 700 ( rwx------ ).

4. . As the user who will use VNC, type vncpasswd . The vncpasswd program, as you might expect, sets a password. Unlike most other Linux login servers, VNC doesn't rely on the Linux username and password database to control access. Instead, it's run as a normal user, and so the server itself must provide password authentication. (If you pair VNC with an XDMCP server, as described shortly, Linux handles authentication, so you can skip this step and Step 3.)

NOTE

These instructions describe installing and using the conventional VNC server and client. VNC also supports a Java server mode, which allows you to access the VNC server from any Java-enabled Web browser. The necessary Java classes appear in the classes subdirectory of the installation directory. Read the README file for more information on installing and using these classes.

At this point, the VNC server is installed and configured. To run it, you must first log into the server as an ordinary user. Typically, you'll do this from the computer from which you want to use VNC, much as you'd log into a remote computer using Telnet or SSH in order to use X programs via an X server. There are other ways to do this, though; for instance, you could run VNC from the console in preparation for accessing the system from some other location. You can run the server by typing its name as an ordinary user:

 $  vncserver  New 'X' desktop is vncserv.threeroomco.com:1 Starting applications specified in /home/rodsmith/.vnc/xstartup Log file is /home/rodsmith/.vnc/vncserv.threeroomco.com:1.log 

It's important to pay attention to the output of this command, and particularly the line that identifies the desktop number1 in the preceding example, as indicated by the number at the end of the hostname ( vncserv.threeroomco.com:1 ). VNC operates by starting an X server (the Xvnc program), which doubles as a VNC server. You can think of this X server as being like an X session started from a text-mode console login by typing startx it has no login prompt, and starts an individual's desktop environment or window manager, as described shortly. If two or more individuals run VNC servers on a single computer, they must be differentiated from each other in some way. The method used is the X server number. The number 0 is often taken by the local console's X server, so chances are the first VNC session will use a number of 1. Subsequent VNC sessions may use higher numbers .

WARNING

If you used SSH to log into the VNC server system in order to run the VNC server, you may find that the VNC server runs, but all X programs (including window managers) fail to run in it. The result is that when you try to access the VNC server, you see a gray background with no windows, and you can't do anything with it. The cause is that SSH adjusts the xauth configuration for its own X forwarding features. A quick and dirty workaround is to type export XAUTHORITY=~/.Xauthority before running vncserver . This resets the X authority file to its default, so VNC won't become confused . Another workaround is to copy the authority entries from the default file into SSH's temporary authority file, which it maintains in the /tmp directory tree (typing xauth from an SSH login will use this file).

If you've finished with a VNC session, you can shut it down by using the -kill option, thus:

 $  vncserver -kill :1  

The number you use is the VNC session number, as reported when you started that session. Shutting down the VNC server when it's not in use isn't necessary, but reduces the memory load on the server computer and improves securitya server that isn't running can't be broken into. Be sure you've exited from any important programs before you do this, thoughwhen you shut down a VNC server in this way, you won't be prompted if you want to save open files.

Using a VNC Client to Access the Server

The Linux VNC client is called vncviewer . To use it, you type its name, optionally followed by the name of the VNC server and its display number, thus:

 $  vncviewer vncserv.threeroomco.com:1  VNC server supports protocol version 3.3 (viewer 3.3) Password: 

The password doesn't echo when you type it. The VNC client then displays additional information on the nature of the connection, such as the color depth and some other technical information. If all goes well, you'll see a window appear showing a Linux desktop on the VNC server. As noted in the next section, however, the defaults for the VNC server may not be to your liking, so you may want to adjust them.

If you don't include the display number, the VNC client tries to connect to display number 0, which won't work with most Linux systems, since that number is generally used by the local X server. Omitting the display number will usually work when connecting to a Windows or MacOS VNC server, though. If you omit the hostname, in addition to the display number, the VNC client prompts you for the hostname and password using an X-based dialog box.

Windows and MacOS VNC clients work in a way that's similar to that of the Linux VNC viewer, but the program is somewhat more GUI-centric. Specifically, you double-click the VNC viewer icon to launch the program. It then presents a dialog box in which you enter the VNC server's name and display number (such as vncserv.threeroomco.com:1 ). If this corresponds to a valid VNC server, the program then asks for a password and, if the password is correct, displays a window in which the VNC server's desktop appears.

Adjusting VNC Server Configuration

VNC can be a useful remote-access tool, but it's not without its problems. Some of these are inherent to VNC. For instance, many people report problems with the NEdit editor (http://www.nedit.org) and VNC. On my systems, NEdit doesn't accept keystrokes, making it essentially useless. Fortunately, such serious problems are rare. Other VNC problems aren't so severe; they can be overcome by adjusting VNC's configuration. You can change several basic features by editing the main VNC server startup script. You can set other features by customizing users' configuration files.

Adjusting Basic Server Features

The main VNC server program is Xvnc . This program includes both an X server (which communicates with local X programs) and the VNC server (which communicates with the remote VNC client). You'll note, though, that the preceding instructions don't refer to Xvnc . This is because this program is called by a script, which is used to start the server: vncserver . This script is written in Perl, and you can edit it yourself to adjust many of the VNC server's default settings. Some that you might want to change include the following:

• Auto-configured X defaults Recent versions of vncserver use the &GetXDisplayDefaults() call to retrieve various defaults for the X display, such as the display size and bit depth. Unfortunately, the system may recover a size that's inappropriate for your desired clients. You can comment out this line by preceding it with a pound sign ( # ) if you want to use a different display size. You'll then need to set the display size separately. The default script includes lines to do this before the &GetXDisplayDefaults() call, as described shortly.

• Display size When Xvnc starts, it creates a virtual screen of a specific size. If you don't use the automatic X defaults option, you can set this display size with the $geometry variable. For instance, you might include a line like the following to set up a 900x675 display:

   $geometry = "900x675"; 

TIP

Because VNC clients display a VNC server's desktop within a local window, it makes sense to create a display size that's slightly smaller than the client's screen size to provide for window borders. If the VNC display size is too large, users will have to scroll their local VNC windows to see the entire server desktop.

• Color depth As with the display size, you can set the color depth by setting a variable, which is called $depth in the standard script. Sixteen bits is generally a good minimum for X, because color-hungry programs can rob colors from other programs. This rule doesn't apply to VNC, though; 16-bit displays tend to create corrupted color maps. This problem may be fixed in the future, though.

• Font path The default vncserver script uses the default font path for the server. You can adjust it in the section that's commented Add font path and color database stuff here . The relevant line adds a font path using the -fp parameter to the $cmd string, which is ultimately used to call Xvnc . You can even configure VNC to use a font server, as described in Chapter 15.

• Default window manager The default vncserver script includes a variable called $defaultXStartup , which stores the contents of the default user startup script. The vncserver script writes this file to the user's directory the first time the user runs the script. The default window manager is twm , which few people use today. You can adjust this default by changing the twm call to a call to whatever window manager or desktop environment you like, such as startkde , sawmill , or icewm . Adjusting the vncserver script will only affect the default for users who have not yet run the script, though. Consult the upcoming section, "Customizing Individual Users' Settings," for information on adjusting existing users' configurations.

Even if you're not familiar with Perl, you can peruse the script to find more advanced features you might want to adjust. Mostly the script sets options to be passed to Xvnc by adding them to the $cmd string, so if you can decipher the options added to that string, you can modify them. Typing Xvnc -help &> Xvnc-help.txt creates a text file called Xvnc-help.txt that contains information on available Xvnc options.

WARNING

Be sure to back up the vncserver script before making any changes. If a change you make should render the script unusable, you'll be glad to have the backup.

One important caveat is that the vncserver scripts shipped with some distributions differ substantially from the original. Debian's script, in particular, is quite different from the original. That said, the advice presented here applies to them all, but you might need to go about making changes in slightly different ways. For instance, Debian's vncserver script creates a variable called $fontpath in which it holds the font path.

Customizing Individual Users' Settings

Global VNC server settings are controlled through the vncserver script. If your users want to change these settings themselves , they have three choices:

• Create a customized startup script Individual users may copy the normal VNC server startup script to their home directories and modify these copies, as described earlier, then use their customized scripts to start the server.

• Pass options to the script The vncserver script accepts several options that can be used to override the defaults. For instance, -geometry width x height sets the desktop size. These options are largely the same as the underlying Xvnc options.

• Use individualized option files The standard VNC server script runs the ~/.vnc/xstartup script at the end of its running process. This is where the default script places commands to start a window manager and xterm window. Users may modify these files as they would ordinary X startup scripts. Some distributions alter the name or location of this script. For instance, Debian's configuration calls the /etc/X11/Xsession script, which in turn calls the user's ~/.xsession script.

On the whole, the last two options are usually the simplest. Each option has its role to play. For instance, users can set their desktop sizes with the -geometry option to the vncserver script, but not via an option file; and they can adjust the window manager they use by setting it in their personal startup scripts, but not by passing an option to vncserver . As a general rule, the vncserver options let users adjust how VNC's X server as a whole operates (similar to standard X server options), but their startup script options let them adjust how their desktop environments and window managers behave (as do their X session options in more conventional X servers).

Running an XDMCP Login Server in VNC

One potentially serious problem with VNC is the fact that, as just described, it requires you to log in using a standard remote-login protocol, launch the server, and remember the display number to connect to the correct display. This process can be tedious , and it requires you to run a conventional login server, assuming you want to allow convenient and truly remote access. One solution to these problems is to combine the VNC X server with an XDMCP server run on the local system.

The VNC X server supports management of its display by an XDMCP server, just as do most X servers. To enable this feature, you must launch the VNC X server with the -query hostname option, as described earlier, in "Configuring a Remote X Login Client." You can do this in any way you might normally launch any server, as described in Chapter 4. As an example, consider the following xinetd configuration entry:

 service vnc {         disable         = no         socket_type     = stream         protocol        = tcp         wait            = no         user            = nobody         server          = /usr/local/bin/Xvnc         server_args     = -inetd -query vncserv -once } 

The server arguments are extremely important. Specifically, -inetd tells Xvnc that it's being run from a super server, -query vncserv tells it to call the computer vncserv for the XDMCP login prompt, and -once tells the server to quit after it's been called one time, which has the effect of terminating the VNC link after a user logs out. You can add more Xvnc options, such as -geometry or -fp , to customize the setup. This entry should be combined with an entry in /etc/services that defines the vnc port number:

 vnc             5900/tcp 

VNC uses port numbers 59005999 for normal connections, or 58005899 for Web browser (Java) access. Port 5900 corresponds to display 0, 5901 to display 1, and so on. Thus, this definition sets up VNC to respond to its first display (0), and to immediately present an XDMCP login prompt. Of course, an XDMCP server must be running on the system specified by -query for this to work. You can even set up multiple ports to respond to VNC clients, but configure them differently. For instance, you might set up display 0 to present an 800x600 desktop, display 1 to use 1024x768, and so on. You'll need multiple /etc/services entries to identify these servers, each with a unique name and port number. When run in this way, VNC doesn't prompt for a password; it leaves that detail to the XDMCP server. (Note that the username and password are transmitted unencrypted, unlike a more conventional VNC login.) One other feature of VNC when run like this is that it can accept multiple logins to the same port by different users, so users don't need to remember a potentially changing port number. As a rough approximation , then, when you run VNC with an XDMCP server, the effect is very similar to running an XDMCP server directly and using a remote X server. There are a few major differences, though:

• The VNC solution requires a single connection between the two computers. This may be helpful if the system at which the user sits is protected by a firewall, and it can help you reduce the number of servers that are available to the outside world.

• The VNC solution uses a VNC client where the user sits, rather than an X server. As open source software, a VNC client is inexpensive, but most X servers for Windows and MacOS are commercial software.

• The VNC protocols, as noted earlier, have their own unique quirks . When compared to a native X server on the user's computer, VNC may be superior or inferior in this respect, depending upon the quality of the X server and the users' specific needs.

• The VNC protocols, as noted earlier, tend to be slower than X protocols on most connections, although they may be faster on some, so using this solution has speed implications.