Hack10.Access Systems Remotely with VNC

Hack 10. Access Systems Remotely with VNC

Virtual Network Computing is the next best thing to being thereand it's cross-platform, too.

Command-line-oriented utilities (such as ssh and telnet) for accessing remote systems are fine for many things, but they don't help much when you need to run graphical utilities on a remote system. You can play around with the standard X Window System DISPLAY environment variable to output programs to different displays, or you can take advantage of cooler, newer technologies such as VNC to display the entire desktop of a remote system in a window on the system on which you're currently working. This hack explains how to use VNC to do just that. VNC is a cross-platform thin client technology originally developed by Olivetti Research Labs in Cambridge, England, who were later acquired by AT&T. A VNC server runs on a desktop or server system and exports an X Window System desktop that can be accessed by a VNC client running on another system. VNC servers are typically password-protected and maintain their state across accesses from different clients. This makes VNC an optimal environment for accessing a graphical console and running graphical administrative and monitoring applications remotely.

Any host system can run multiple VNC servers, each of which exports a separate desktop environment and therefore maintains separate state. Similarly, multiple clients can connect to and interact with the same VNC server, providing an excellent environment for training, since many users can view the same desktop.

VNC follows the traditional client/server model rather than the X Window System client/server model. A VNC server is actually an X Window System process that exports an X desktop from the system on which it is running, using a virtual framebuffer to maintain state information about the graphical applications running within that server. VNC uses its own Remote Frame Buffer (RFB) protocol to export graphical changes and handle mouse and keyboard events. Though VNC exports a graphical environment, the RFB protocol is highly optimized, minimizing the amount of screen update information that must be passed between client and server.

VNC is released under the General Public License (GPL), and many of the original VNC developers now work for a company called RealVNC (http://www.realvnc.com), which distributes and supports a commercial VNC implementation. Another extremely popular VNC distribution is TightVNC (http://www.tightvnc.com), a small, even more highly optimized VNC client and server. TightVNC makes better use of network bandwidth, utilizing JPEG compression for the display and differentiating between local cursor movement and cursor movement that needs to be communicated back to the VNC server. TightVNC also features automatic SSH tunneling for security purposes, though any VNC session can be run through an SSH tunnel [Hack #12]. This hack focuses on using TightVNC, although RealVNC is also an excellent choice. Most Linux distributions install one of these VNC implementations as part of their default client/server installations, but you can always obtain the latest version from the appropriate web site.

2.2.1. Understanding the VNC Server Startup Process

The actual VNC server binary, Xvnc, is usually started by a Perl script called vncserver. The vncserver script provides a more flexible mechanism for passing arguments to the server, displays status information once the server has started and detached, and also builds in the ability to use a startup script to identify the window manager and any X applications the VNC server should start. The VNC server's startup script is the file ~/.vnc/xstartup. If this directory and the startup file do not exist the first time you start a VNC server, the directory is created and the startup script is cloned from the default X Window System startup file (/etc/X11/xinit/xinitrc). On Red Hat and Fedora Core systems, the default ~/.vnc/xstartup script simply executes the command script /etc/X11/xinit/xintrc:

 #!/bin/sh # Red Hat Linux VNC session startup script exec /etc/X11/xinit/xinitrc 

This enables VNC on Red Hat and Fedora Core systems to follow the same somewhat convoluted chain of X Window startup files that are normally used: ~/.Xclients, ~/.Xclients-$HOSTNAME$DISPLAY, ~/.Xclients-default, and /etc/X11/xinit/Xclients. Xclient files can start various desktop environments and window managers by using environment variable settings, and they finally fall through to execing the twm window manager (http://www.plig.org/xwinman/vtwm.html).

On SUSE systems, the ~/.vnc/xstartup script is a little more straightforward:

 #!/bin/sh xrdb $HOME/.Xresources xsetroot -solid grey xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & twm & 

This startup script loads the X Window System resource settings specified in the file $HOME/.Xresources, sets the background to solid grey, starts an xterm with the specified parameters, and then starts the twm window manager. Later in this hack, in the section "Customizing Your VNC Server's X Window System Environment," I'll discuss how to customize this script to start the X Window System environment and applications of your choice. For now, it's simply useful to understand how the VNC server determines what X Window System applications to run.

2.2.2. Starting Your VNC Server

To start a VNC server you execute the vncserver script, which starts the Xvnc server and the X Window System window manager or desktop and applications defined in your ~/.vnc/xstartup script. The first time you start a VNC server on your system, you will be prompted to set and confirm a password for read/write access to the VNC server. You will also be prompted as to whether you want to set a view-only password for the VNC server. As the name suggests, a view-only password will enable you to see but not interact with the remote desktop displayed in the vncviewer window. The first time you run the vncserver script, you'll see something like the following:

 $ vncserver You will require a password to access your desktops. Password: Verify: Would you like to enter a view-only password (y/n)? n New 'X' desktop is 64bit:1 Starting applications specified in /home/wvh/.vnc/xstartup Logfile is /home/wvh/.vnc/64bit:1.log 

You'll notice that I didn't bother to set a view-only password: I've never found this to be all that useful. You can change your VNC password at any time using the vncpasswd command. Like most password-changing utilities, it first prompts you for your old VNC password, then for the new one, and finally asks for confirmation of the new VNC password.

When you start a VNC server on a system console or as a privileged user, make sure you have set a VNC password that follows the most stringent rules for password security. Anyone who breaks your password will have instant virtual access to one of your desktops and all applications it contains. This would be paradise for a script-kiddy who might not otherwise know his way around a Linux box.

Once you've set a password and, optionally, a view-only password, the vncserver script will display a message like the following whenever a server is successfully started:

 New 'X' desktop is home.vonhagen.org:1 Starting applications specified in /home/wvh/.vnc/xstartup Logfile is /home/wvh/.vnc/home.vonhagen.org:1.log 

VNC servers export their virtual displays via ports starting at 5900 plus the number of the display being exported. For example, a VNC server running on the X Window System display:1 will use port 5901, a VNC server running on the X Window System display:2 will use port 5902, and so on. If your system does kernel packet filtering or your network uses a firewall, you must make sure that you do not block ports 590x (used to export VNC server displays), port 6000 (used to communicate with the X Window System server), or ports 580x (if you want to communicate with a VNC server over the Web [Hack #11]).

2.2.3. Connecting to a VNC Server

Once you've started a VNC server, you can connect to it from any remote system by executing the command vncviewer host:display, where host is the host on which the VNC server is running and display is the number of the X Window System display on which the VNC server is running. Figure 2-1 shows a connection to a remote SUSE system using the default xstartup script shown in the previous section. As you can see, the default VNC server setup is a bit austere, even if you are a window manager bigot or connoisseur of simplicity.

2.2.4. Customizing Your VNC Server's X Window System Environment

Most VNC server configurations automatically start the twm window manager in the VNC server environment by default. However, the VNC server's use of a startup script makes it easy to start any window manager, desktop environment, and X Window System applications that you'd prefer to use in the VNC environment.

Figure 2-1. The default VNC desktop

For low-bandwidth conditions, the twm window manager may still be the best choice: due to its comparatively minimal feature set, it is relatively lightweight. In higher-bandwidth network environments, however, you may want to use a window manager or desktop environment that you are more comfortable with. You can easily do this by commenting out the twm entry in your xstartup file and adding the commands that you want to use to start another window manager or a desktop environment such as GNOME or KDE. For example, Figure 2-2 shows a connection to a remote SUSE system when the default xstartup script has been modified to start KDE on that desktop, as in the following:

 #!/bin/sh xrdb $HOME/.Xresources # xsetroot -solid grey xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & # twm & /opt/kde3/bin/startkde & 

If directed to do so when you exit, KDE remembers its state across restarts. Figure 2-2 therefore shows two xterms being startedthe one from KDE's saved information about the last time I started it, and the one specified in the VNC startup script.

Figure 2-2. A VNC desktop using KDE

2.2.5. Stopping Your VNC Server

Like any process, a VNC server will always terminate when you shut down or reboot the machine on which it's running. (No kidding!) However, this isn't the cleanest shutdown mechanism, because it will leave useless PID files in your ~/.vnc directory and will leave some temporary and socket files in various locations in your system's /tmp directory. A much cleaner way to shut down a running VNC server process is to use the vncserver script's -kill option:

 $ vncserver -kill  :number  

Besides cleanly terminating VNC servers when you're planning to shut down or reboot your systems, you may also want to manually terminate a VNC server if you have modified its startup file and want to restart the VNC server with the new window manager, desktop, or X Window System applications.

If your system crashes while running a VNC server or the VNC server itself crashes, you should clean out the files associated with the VNC server in the /tmp and /tmp/.X11-unix directories. For example, if your VNC server was running on display number 1, you would delete the files /tmp/.X1-lock and /tmp/. X11-unix/X1. Doing so ensures that any newly started VNC server will start on the first available X display.

2.2.6. Optimizing VNC Performance

You can optimize VNC performance at two different levels, either by minimizing X Window System updates that have to be communicated between the VNC client and server, or by optimizing how VNC sends that information between the client and the server.

Minimizing the amount of graphical X Window System traffic sent between the VNC client and server is largely a matter of reducing updates to a minimum while still retaining a usable X Window System session. Regardless of the window manager or desktop environment that you're using in VNC, here are some general tips for improving performance by minimizing graphical updates:

• Minimize the color depth of the desktop.

• Eliminate window highlighting when windows get focus.

• Don't automatically raise windows when they get focus.

• Don't use opaque moves when moving windows. Configure your window manager or desktop environment to move window outlines instead.

If you stick with twm in your VNC sessions, you can further optimize VNC performance by tweaking its core capabilities to minimize graphical feedback when it's unneeded. The old AT&T web site for VNC (http://www.uk.research.att.com/archive/vnc/twmideas.html) provides some specific tips for optimizing twm for VNC.

Optimizing the way in which the VNC client and server exchange update information is the other possible way to improve VNC's performance. VNC clients and servers attempt to communicate using encoded update instructions to minimize network traffic. All graphical updates between the VNC viewer and server are communicated as rectangles of pixels to be updated. The supported encoding mechanisms differ based on whether you're using the VNC server/viewer from RealVNC or TightVNC. The TightVNC viewer enables you to specify a custom sequence of encoding mechanisms to try in order by using the -encoding option. This option must be followed by a series of supported encodings enclosed within double quotation marks. The RealVNC viewer enables you to specify a single preferred encoding mechanism using the -PreferredEncoding option, which must be followed by the name of the encoding mechanism you want to try first. In either case, the encoding mechanism will default to sending all information in an unencoded fashion (known as raw encoding) if no supported encoding mechanism can be negotiated with the server.

The following list shows the encoding mechanisms supported by the RealVNC and TightVNC packages. Different encoding mechanisms will improve performance in different situations, depending upon conditions such as whether the VNC client and server are running on the same system, the load on your network, and so on. You may want to refer to this section later to experiment with customizing VNC server/viewer communications, depending on your network environment and whether you are actually seeing performance problems. The supported encoding mechanisms are:

CopyRect (TightVNC only)

Copy Rectangle encoding sends only the location and size of a rectangle on the screen from which data should be copied and the coordinates of its new location.

CoRRE (TightVNC only)

Copy Rise-and-Run-Length Encoding (RRE) is a variation of RRE that uses a maximum of 255 x 255pixel rectangles. Limiting the number of rectangles to values that can be expressed in a single byte reduces packet size and improves efficiency.

Hextile (both)

Hextile encoding splits the rectangular portion of the screen to be updated into 16 x 16 tiles that are sent in a predetermined order. The data in each tile is encoded in the raw or CoRRE format. Hextile is the preferred choice for remote connections over a high-speed network.

Raw (both)

Sends width x height pixel values with no compression or repeat counts. This encoding mechanism is fastest for local server/viewer connections because there are no bandwidth limitations on local connections, and it requires no special processing. All VNC clients must support this encoding type.

RRE (TightVNC only)

Rise-and-Run-Length Encoding is a two-dimensional version of Run-Length Encoding (RLE) that applies RLE-encoded sequences across different subrectangles. This is extremely efficient when encoding updates consisting of large blocks of the same color.

Tight (TightVNC only)

Tight encoding uses the zlib library to compress the pixel data, but preprocesses data to maximize compression while minimizing processing time. It uses JPEG compression internally to encode color-rich portions of areas to update. This is usually the best choice for modem connections and low-bandwidth network environments.

Zlib (TightVNC only)

Zlib encoding uses the zlib library to compress raw pixel data. This provides good compression at the expense of the local CPU time required to compress the data.

ZRLE (RealVNC only)

Zlib Run-Length Encoding combines RLE with Zlib compression. Sequences of identical pixels within the rectangle to be updated are compressed to a single value and repeat count, and the resulting information is then compressed using Zlib.

Table 2-1 shows the sequence in which a TightVNC viewer tries these different encoding mechanisms when communicating with a remote or local VNC server.

Table 2-1. Order of encoding mechanisms used by TightVNC

	Remote	Local
CopyRect	1	2
CoRRE	5	6
Hextile	3	4
Raw	7	1
RRE	6	7
Tight	2	3
Zlib	4	5

2.2.7. See Also

• man vncviewer

• man vncserver

• http://www.tightvnc.com

• http://www.realvnc.com

• TightVNC binaries for various Unix systems: ftp://ftp.kinetworks.com/tightvnc

• OS X VNC server: http://www.redstonesoftware.com/vnc.html