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
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 (
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.
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 (
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
client running looks like
running a totally different desktop environment.
probably a KDE desktop, but I'm not picky.
X-desktop as in
showing a GNOME desktop.
It gets better yet! You can connect to a VNC server from a
totally different OS (
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.
talking to a Windows box.
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
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
admit that VNC provides a certain level of cross-platform, not just
cross-continent, functionality that I am already unable to live without.
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
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
and logs for VNC. Feel free to explore these files at your leisure.
If you want to change your VNC password, use the
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
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
running, your desktop might look as it does in
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
VNC login screen.
Once logged in, you will get a browser window
with a VNC client inside that looks just like
how I used Linux with a fully functional X-desktop from my OS/2 box!
No comments:
Post a Comment