From a user’s perspective, using VNC can seem simpler than at least some methods of using X for remote access; however, VNC actually complicates the internal workings of the system. Figure 11-8 illustrates the relationship between VNC and X. The VNC server is actually two servers in one: it’s a server for the RFB protocol and a server for X. The X client program connects to the VNC server as if it were a local X server. The VNC server then creates a bitmap for display, much as a local X server would, but instead of sending that bitmap to a local screen, it’s sent to the VNC client. This VNC client does double client duty because it’s also a client for the local X server. The VNC client delivers the bitmap to the X server, which displays it on the screen. Similar interactions occur, but in the opposite direction, for delivering keypresses and mouse movements from the user to the target X program on the remote system.

Figure 11-8. On a Linux-to-Linux connection, VNC serves as a double translator between the X client and server

VNC was designed to provide whole-screen displays to its clients. For this reason, it delivers an entire remote desktop, much like to an X server that runs in rooted mode (as in Figure 11-2). VNC has no equivalent to X’s rootless display.

VNC delivers entire bitmaps from the server to the client. By contrast, an X client can and often does deliver shorthand descriptions of operations, which the X server interprets locally. This difference means that VNC must frequently deliver more data across the network than does X, but X’s transactions involve more back-and-forth exchanges. These characteristics give rise to the differing performance limitations of the two protocols, with VNC degrading on low-bandwidth networks and X degrading on high-latency networks.

To use a regular VNC server, such as RealVNC or TightVNC, you must first install it. You may want to check your distribution’s package list to see if it includes a VNC server (probably under a name like tightvnc or vnc-server). If you can’t find a VNC package for your distribution, check the RealVNC and TightVNC web sites. These have source code and binaries in various formats, such as tarballs and RPMs. Note that some VNC packages split off the VNC client from the VNC server, whereas others include everything in a single package.

Once you’ve installed the VNC server, it’s time to configure it. You must do this as an ordinary user—specifically, the one who will be using the server:

At this point, the VNC server is running on VNC port 0 (indicated by the :0 trailing the machine name—pluto in the preceding example). Be sure to remember this port number because it’s necessary for connecting to the VNC server! The VNC port number, like an X port number, is relative to a larger number—5900, in the case of VNC—so VNC port 0 is TCP port 5900. You should be able to connect to the server using the VNC port number in a client, as described in Section 11.4.4.

When you first start the VNC server, it creates a default startup script in ~/.vnc/xstartup. This script is equivalent to a normal X startup script; it launches applications when the VNC X server starts. The basic configuration, though, is to launch an extremely primitive window manager called twm. If you’re used to another desktop environment or window manager, you should edit this file to change the reference to twm to something else, such as startkde to start KDE or icewm to launch IceWM.

The vncserver command is actually a script that calls the real VNC server program, Xvnc. If you want to make systemwide changes to VNC’s defaults, you must edit the vncserver script. Ordinarily, you’ll do this as root, although you can copy the script to your home directory as an ordinary user and edit it yourself, if you prefer. Options you may want to adjust include:

Once you as an ordinary user are finished with VNC, you can shut it down by passing the -kill :session-number option to vncserver. For instance, vncserver -kill :0 kills VNC session number 0.

The usual mode of VNC’s operation is peculiar by Linux server standards. Instead of connecting to the server using a fixed port and entering a username and password to gain entry, you must log in using a text-mode tool or run the server while you’re at the console, then connect using a port number that you must remember and enter a password (but no username). This approach certainly works, but it can be a bit awkward if arbitrary users should have access to the VNC server. To work around this problem and create a more typical Linux-style login experience, you can tie VNC to an XDMCP server. The result is that, when users connect to the VNC server, they’ll be greeted by a GUI login screen that’s similar to the one they see when logging in at the console or via an XDMCP-enabled remote X server.

Before proceeding, check the earlier Section 11.2.5. You should configure your XDMCP server to accept remote connections, with one possible exception: you can use Xaccess rules or firewall rules to restrict XDMCP access to the local computer itself. Both the XDMCP server and the VNC server will be running on the same computer, and the XDMCP server only needs to accept connections from the VNC server. You can configure the XDMCP server to be more promiscuous in the connections it accepts, but if this isn’t necessary, it can be a bit of a security risk, particularly if the computer is accessible to the world at large, and you use firewall rules or super server security settings to restrict access to the VNC server.

Once you’ve configured the XDMCP server, you should edit your /etc/services file. This file gives names to various TCP and UDP ports. You should add entries for any ports you want to assign to VNC. The names you use are arbitrary, but vnc or something related to it is a logical choice. Note that you can use just one port or many ports. Using many ports lets you run multiple VNC servers with different options—for instance, to run servers with different virtual screen resolutions for the benefit of clients with different screen resolutions. For example, suppose you intend to run VNC with 760 530 and 950 700 resolutions. First, create two entries in /etc/services:

vnc-760x530   5900/tcp
vnc-950x700   5901/tcp

This configuration assigns TCP ports 5900 and 5901 to VNC, using names that describe the intended uses for these ports as supporting different resolutions.

Once this is done, edit your super server configuration to call the Xvnc server. This call must include several parameters that are normally handled by the vncserver script, such as -geometry, -depth, and -fp. Other options that may be necessary include:

To produce a xinetd configuration incorporating these elements, create the file /etc/xinetd.d/vnc. This file should have one or more entries like this:

service vnc-760x530
{
   disable      = no
   socket_type  = stream
   protocol     = tcp
   wait         = no
   user         = nobody
   server       = /usr/bin/Xvnc
   server_args  = :1 -inetd -query localhost -geometry 760x530 \
                  -depth 24 -ac -once \
                  -fp /usr/share/fonts/misc/,/usr/share/fonts/100dpi/
}

You may need to experiment with the -ac and -SecurityType parameters to get this to work. Your font path is also likely to be longer than the one shown here. Some distributions, such as Fedora, provide a font server for local use, which can greatly shorten the font path entry, but the entry is likely to read unix/:7100.

After restarting your super server, the VNC server should become available to VNC clients, as described in Section 11.4.4. You’ll notice several differences in how VNC behaves, though:

Overall, linking VNC to an XDMCP server can be an excellent way to provide remote GUI logins to a Linux system. This approach follows typical expectations for GUI logins and works much like accessing Linux via a rooted X server using XDMCP. VNC client software is inexpensive and easier to configure than X servers, though, which can simplify your overall configuration and education efforts, even if linking VNC with XDMCP is a bit more work.

KDE is unusual in that it supports the VNC protocol, RFB. You can access KDE’s options from the KDE Control Center (type kcontrol in an xterm window or locate the Control Center option in the KDE menu system). The options in question are visible in the Desktop Sharing area within the Internet & Network option set, as shown in Figure 11-9. (Specific KDE implementations vary somewhat in their names for these options; for instance, some use Network rather than Internet & Network.) KDE’s Desktop Sharing system works more like VNC under Windows than under Linux: it shares an existing login session, rather than create a new session. The intent is that it be used as a collaborative tool, to enable users to create demonstrations and presentations for other users at remote locations. For this reason, it emphasizes use by invitation: click Create & Manage Invitations to create a time-limited password, which you can give to another user in some appropriate way, such as over the phone. (You can also email invitations directly, but this makes them susceptible to network sniffing.)

Figure 11-9. KDE’s VNC support enables you to share an existing KDE login session

KDE also supports “uninvited” connections, which are essentially time-unlimited invitations. This tool isn’t likely to be useful for providing yourself with remote access, though, because KDE displays a dialog box on its local display whenever a connection attempt is made. If you don’t accept the connection, the remote system is refused access. Thus, remotely accessing the system via KDE’s VNC features requires that somebody be present at the console when a connection attempt is made.