Enter VNC

The other major graphical platform on the market, Microsoft Windows , had a very different evolution. It grew out of an environment that was almost totally ignorant of networking in general and of TCP/IP internetworking in particular. It grew up in an environment that assumed one user and only one user would be making full use of the computer resources and that that user would be sitting next to the box.

In a Windows-based PC, applications must run on the same box as they are being displayed. There is no distinction between the program's "server" (the operating system) and the user interface's server (the display API). In X, the display API is a set of services offered by a server that is actually network available. The program API is provided by the OS of the host on which the program runs. On a Windows PC, both sets of services are assumed to be local.

An entire class of applications arose to work around this deficiency in Windows. From Close-up to PC Anywhere, these programs essentially "poll" the display of a host PC and, using an entirely proprietary protocol, send the changes over a link (originally a modem, later an IP network). On the client side, they capture keystrokes and mouse movements and send them back over the link and then "regenerate" them as if they were performed on the host PC.

Such programs were used (and often still are used) to remote-control Windows-based PCs. This is nothing like X. It replicates an entire desktop. You cannot have windows open showing applications running on multiple hosts at the same time on the same desktop. Still, it gave Windows users something approaching the capabilities of X for remote computing.

AT&T developed an open standard for such transfer of a graphical desktop and user input. They called this VNC, or virtual network console. They developed servers and clients for a number of platforms and, luckily for the world of Linux, they put the code out under the GNU Public License.

Before we go into the details of the Linux implementation, let's examine the generic model of a VNC session ( Figure 2-2 ). In our diagram of a simple VNC session, we have a box running a VNC client (host salt.kitchen.org ) and a box running a VNC server ( pepper.kitchen.org ). Both of these boxes are Windows 98 machines. Pepper has a VNC server running. VNC servers have "names," similar to (but not identical to) X-windows server names .

Figure 2-2. Block diagram of a VNC environment.

A VNC server name is of the form:

 address:desktop

where "address" is the name of the server host, and "desktop" is a number specifying which VNC server session on that box to talk to. VNC servers start listening sockets on port 5900 plus desktop number. In other words, to contact desktop 2, a VNC client must connect to tcp port 5902.

Data bound for the server flows down the left-side layers, is sent over the Internet to the right side, where it moves up the layers . Data bound for the client moves down the right side, over the net, then up the left. All of this is invisible to the user. The user on the client just sees a window on "salt" that appears to have "pepper"'s desktop displayed in it.

So, as we can see, VNC is quite different from X. But that's okay. It serves a different need. When you have a good X-server and X-applications, X is all that you need. Remember, though, if you use Windows 98 and aren't made out of money, you probably do not have a decent X-server. And what about that poor schlep stuck on OS/2? What is he going to do? Don't worry ”we'll get there. Have patience.

VNC is, of course, available for all versions of Microsoft Windows. It is, happily for this book, also available for Linux. The generic model of a VNC session covers most of what's going on when you use VNC on Windows platforms. On Linux platforms, it is a little bit more interesting.

XVNC ”The Best of Both Worlds

The program that implements a VNC server for Linux is actually called Xvnc. It is a complicated little beastie with literally hundreds of possible configurations. More often than not, it is started with a shell script called "vncserver" that reads a configuration file and sets up an Xvnc instance with settings most users will want ( Figure 2-3 ).

Figure 2-3. Block diagram of an Xvnc environment.

VNC on Linux has a bit of a twist: Xvnc is not only a VNC server; it is also an X-server. That's right. When you run a VNC server on Linux you are actually running a full-blown X-server. This X-server provides a complete, self-contained X-desktop. It has a unique X-display specification.

How is this done? Most Linux boxes already have a running X-server, the default graphical console. It does this by setting up each VNC server as a separate display number. Remember, your standard console X-server is probably:

 flour.kitchen.org:0.0

Your first VNC server instance will set up its "X self" as:

 flour.kitchen.org:1.0

If you point an application at the former, it will display on the console. If you point it at the latter, it will display on the VNC console. Neat, eh?

Wait! It gets better. Your standard X-desktop looks like Figure 2-4 . That same X-desktop with a VNC client running looks like Figure 2-5 . That client shows the VNC desktop, running a totally different desktop environment.

Figure 2-4. Image of an X-desktop, probably a KDE desktop, but I'm not picky.

Figure 2-5. Image of the same X-desktop as in Figure 2-4 , but this time with a VNC client showing a GNOME desktop.

It gets better yet! You can connect to a VNC server from a totally different OS ( Figure 2-6 ). Figure 2-7 shows a Windows 98 desktop running a Windows VNC client, with that client connected to a Linux box. So even if you don't have a decent X-server for Windows, you're able, as you can see, to make full use of X within the VNC client.

Figure 2-6. Same desktop again as in Figure 2-4 , except this time the VNC client is talking to a Windows box.

Figure 2-7. Windows 98 desktop running VNC to a Linux box.

So what about OS/2 or even some other orphaned platform? What about that? Well, it so happens that there is an experimental OS/2 VNC client for Presentation Manager, but there is an even better solution. Not only does Xvnc provide an X-server listening on X port 1 (which, just for those who are dying to know, is actually TCP port 6001) and a VNC port listening on port 5901, it also opens an HTTP server listening on TCP port 5801. An HTTP server? A Web server? Yup. A Web server. It doesn't serve up much in the way of HTML, however. What it serves up is a Web page containing a Java applet. That Java applet is a full-blown VNC client!

That's right. If the platform you are on has a Java-enabled Web browser, then you can connect to a Linux VNC server. It is just that easy. Take a look at Figure 2-8 . I'm still an X bigot, but I must admit that VNC provides a certain level of cross-platform, not just cross- continent , functionality that I am already unable to live without.

Figure 2-8. OS/2 VNC session.

VNC is not without limitations. It can't forward sounds (but then, X can't forward digital sound either). It is not terribly secure (but we'll cover using SSH to lock down this and many other protocols later in the book), being protected by a simple password and having no encryption. It is often set to lower color depth to make the protocol faster, limiting the usefulness of the protocol for remote multimedia work. The screen " paints " top to bottom and left to right as fast as the communications medium allows. This painting effect makes VNC rather useless for full-motion-animation applications. Still, it allowed me to make full use of a Linux platform, even through my severely limited desktop environment.

One exciting thread: Apparently, there is a VNC client for the Palm organizer! That's right: Use Windows, X, anything, right from your Palm-connected organizer. Maybe in the next book.

Using VNC with Linux

Meanwhile, let's walk you through using vncserver, the two Linux vnc clients, and finally through using your browser to connect to a VNC server.

To run an X VNC server, you would generally just type:

 $ vncserver

If you have never run a vncserver session before, the response should look like this:

 $ vncserver

 You will require a password to access your desktops.

 Password:

 Verify:

 New 'X' desktop is roux.kitchen.org:1

 Starting applications specified in /etc/X11/Xsession

 Log file is /home/mschwarz/.vnc/roux.kitchen.org:1.log

You must type and then retype a password. If they don't match, you will have to rerun vncserver. This password is then permanently set for this user. The home directory of your user account will now contain a .vnc directory. That directory contains control files and logs for VNC. Feel free to explore these files at your leisure.

If you want to change your VNC password, use the vncpasswd command.

The vncserver session keeps running until the machine is rebooted or until you kill it. Here's how you kill a VNC session on Linux:

 $ vncserver -kill :1

 Killing Xvnc process ID 13824

When you run vncserver you will get the first available desktop number. This is generally :1 (since :0 is probably taken by the system's "real" X-server console). If you wish to run one on a specific desktop number, try:

 $ vncserver :8

 New 'X' desktop is roux.kitchen.org:8

 Starting applications specified in /etc/X11/Xsession

 Log file is /home/mschwarz/.vnc/roux.kitchen.org:8.log

There are quite a few options and choices to set on VNC. Where these are set depends on how you install VNC. Debian sets you up with an entry in /etc for VNC server configuration. This is very nice, because it gives you one place to set defaults for the entire system.

On RedHat (and other RPM-based distributions), the defaults are all set in /usr/bin/vncserver, which is a Perl script that runs the real VNC X-server (which is called Xvnc ). Here you must edit the actual script.

One convention that is often used but that is by no means required is to set the VNC X-server display size to be "one smaller" than the client display. That convention is followed in all of the screenshots in this chapter. If you have an 800 x 600-pixel display, set your VNC server to 640 x 480. If you have a 1024 x 768-pixel client display, set your VNC server to 800 x 600, and so on. This ensures that the entire server desk top will fit on your client screen with room to spare, and you won't have to use scroll bars to move around the server desktop. That works, but it does get both distracting and annoying.

While only Mandrake and Debian ship with VNC on their installation media, the source code is available, and RPM packages are available from the usual suspects .

To make use of a VNC server, you must run a VNC client.

There are actually three clients for Linux VNC. Some packages include only two of these three. The three clients are:

· vncviewer/xvncviewer: This is an X-windows client for VNC. This one is included in every VNC package I have seen.

· svncviewer: This is an SVGA (or console) version of the VNC client. This can be run from a text-mode console on your Linux box. Debian optionally includes this one. Otherwise, compile it from the source.

· The Java client: The Xvnc server can offer an HTTP server that pushes a Java VNC client to a browser. Thus, any Java-enabled browser can be used to access the VNC server! We discuss this in depth later.

When you use the X vncviewer, you may launch it as in Figure 2-9 . Once vncviewer (or xvncviewer) is running, your desktop might look as it does in Figure 2-5 .

Figure 2-9. xviewer xterm .

The svncviewer works much the same, except it will run only on the text-mode console of a Linux box. It uses the SVGA library support (which is shipped with every Linux distribution I know of, including very old ones) to present a VNC graphical desktop on the console. The only reason to obtain or compile the SVGA client is if you need a VNC client on a Linux box that doesn't have an X-server.

You run svncviewer in exactly the same way as vncviewer/xvncviewer, but when it runs it will not open a window with a desktop in it; it will instead take over the entire screen with the VNC desktop. You may find this useful on older machines (386/486-class machines) with limited memory (16M or less), where running an X-server would be a major burden .

Finally, let's cover the Java client. Let's assume you've started an Xvnc server on your Linux box at soda.kitchen.org . Let's assume it is desktop :2. To use the Java client, just point your browser at:

http://soda.kitchen.org:5802/

and you will get the login screen of Figure 2-10 .

Figure 2-10. Browser with VNC login screen.

Once logged in, you will get a browser window with a VNC client inside that looks just like Figure 2-7 . That's how I used Linux with a fully functional X-desktop from my OS/2 box!