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 RelationshipI'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 ServerYou 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 :
NOTE
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'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 ServerThe 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 ConfigurationVNC 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 FeaturesThe 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:
TIP
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
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' SettingsGlobal VNC server settings are controlled through the vncserver script. If your users want to change these settings themselves , they have three choices:
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 VNCOne 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:
|