Do you ever run across something that’s just so neat that you run around telling all your friends how they have to try it and how it’s the greatest thing since Mountain Dew? And eventually your friends get tired of it and want to hit you in the head with a crowbar?
Well, neither do I. Mainly because I don’t have any friends. But if I did, I’d be running around bugging them about VNC (Virtual Network Computing, www.uk.research.att.com/vnc). So, since I don’t have any friends, I’m going to bug you about how you can have a free graphical remote-control for your Freenix machine (through XFree86) from any other Unix, Windows, MacOS – or almost any other platform, including PalmOS – computer. Even better, you can control your Unix, Windows or Mac computer from your Freenix machine. It’s like X windows, Symantec PCanywhere and Apple Remote Access all rolled into one.
VNC is a client/server program from the good folks at AT&T Labs in Cambridge, UK. VNC has two components: a server program and a viewer. Install the server on any supported OS, and you can use the viewer to control that computer in a graphical window. VNC is released under the GPL (GNU Public License), so the source code is freely available along with the binaries.
So, what does this mean to you? If you’re accustomed to administering your Freenix through an X windows environment (like AfterStep, Enlightenment or KDE), VNC allows you a completely portable, free and easy-to-use way to do this from virtually any other computer, no matter what OS it’s running. In addition, this one app allows you to manage your consumer-OS workstations from your servers as well. On multi-user systems, VNC can be run for specific users and reflect their particular environments.
Some of you may be saying, “On Unix, this utilizes X windows. So, why is this better than running X windows sessions remotely?” Well, you should get professional help, since you’re talking to a magazine. But the answer is that VNC has three notable advantages over traditional remote X administration.
First, the session state is stored on the server rather than on the client machine. This means that I can leave my VNC session at work in the middle of typing a line, go home and fire up a VNC viewer on my home PC, and pick things back up in the middle of the line. While this may not sound ground-breaking, it’s very useful if you need to administer a single server from multiple clients.
Second is the amazing variety of ports of the VNC viewer (see “VNC Platforms,” below). Plus, there’s a Java version, so VNC should be able to be run through a web browser on any platform for which a standards-compliant Java Virtual Machine (JVM) exists. The side benefit from this is standardization: you can install VNC across your network, train your staff on VNC and then let them administer Unix, Windows NT and MacOS servers using the same program, from almost any computer.
Third, it’s a lot easier to configure and run than free X clients generally are. Anyone with the brains to breathe on a regular basis and use their turn signals correctly should be able to get the VNC server up and running within five to 15 minutes, and the VNC viewer in less than that. Of course, if you want your Freenix sessions to run nicely, you’ll have to do a bit of tweaking to your preferences file (like changing the default window manager from the antiquated twm to something more useful). The more you know about X windows, the better; but it’s still usable even if you don’t.
VNC also performs remarkably well, considering that it’s a free, non-commercial product. On Unix machines, I found its performance to be as good as traditional remote X windows sessions. Performance on Windows machines were, in my extremely unscientific tests (I didn’t get around to testing the Windows version until after my third or fourth Heineken), about the same as I had experienced with PCanywhere. I didn’t see any “dancing Bill Gates” while I used PCanywhere, but I’m attributing this to the Heinekens.
Installing VNC on your Freenix is as simple as following John Dvorak’s delicious Pickled Walnuts recipe (remember: soak in brine for at least six days!). The VNC server for Unix is a Perl script that utilizes XFree86. An XFree86 installation is usually pretty painless on most Freenix flavors; if you don’t have Perl installed, double-check yourself to see if you have a working brain installed in your skull (see “Windows NT”).
On FreeBSD, VNC is part of the ports collection, so installation is fast and easy. Simply cd /usr/ports/net/vnc, type make install, and you’re on your way. One of the beauties of the ports install is that it will also install necessary X components if you need them.
For Linux, .tar or .tgz archives of the binaries are available (note: newer versions require glibc, which you’re probably already using anyway). Simply use gunzip and/or tar –xvf to upack them, and you’re ready to go; if you aren’t planning on keeping VNC to yourself, you’ll want to move the new directory of VNC files under /usr/X11R6/bin. If you’re fond of using (ugh) RedHat Package Manager or Debian packages for one-click installation, those are available as well from rufus.w3.org/linux/RPM and www.debian.org, respectively.
The program’s important binaries (vncserver, vncviewer and vncpasswd) are normally installed in /usr/X11R6/bin. To start a server, simply issue the vncserver command (assuming that the directory that it’s installed in is in your $PATH), or type the full path to the command. The first time that you run it, you’ll be prompted to choose a password, which will be stored in your user’s $HOME/.vnc/ directory that will be created for your session logs, password and preference files. Later, you can use the vncpasswd program to change your password if necessary. Your X/VNC session preferences are stored in the xstartup script located in this directory, as well; this file can usually be changed to be a link to your normal X startup script.
With Windows, although external programs like X and Perl aren’t required, things are a bit more complicated. Downloading, unzipping and installing the client and server files for Windows 9x are pretty simple. Unfortunately, under WinNT (NT 4.0 Service Pack 3 or higher required), there are certain important functions (like the ever-important remote CTRL-ALT-DELETE and remote unlocking) that can only be accomplished if you’re running VNC as a service. See the VNC FAQ (www.uk.research.att.com/vnc/faq.html) or a deck of Tarot cards for more information.
On MacOS computers, to run the server, drag the associated Extension and Control Panel into your active System Folder, then restart and double-click the server application (place an alias of the server app in your System Folder/Startup Items folder to run automatically).
To start a VNC client session, run the vncviewer program (or whatever it’s called on your OS), choose a hostname and session number. The first session you start on hostname foo.bar.com is designated 0, and the next one is designated 1, et cetera. So, to connect to the second VNC server started by a user on that host, you’d connect to foo.bar.com:1.
While VNC’s performance is very good, any remote-GUI solution is not going to provide performance equal to a console connection. Of course, the faster and cleaner your network connection is, the better your results will be.
However, an equal consideration is the video card you have on the client machine – 2 MB or 4 MB video cards with older chipsets probably aren’t going to get you far. Souped-up video cards will significantly improve performance (hint: use this as an excuse to buy a 16 MB Riva TNT2 card for your Linux machine and then play Quake on it). Changing your X, Win or Mac desktop pattern to a single uniform color or shifting down your default color depth (e.g., 24-bit color to 16 or 8 bits) will also help significantly.
Over a 10 Base-T LAN connection, performance for both the client and server on the Freenix versions was good for common tasks (virtually indistinguishable from console access with terminal sessions and X-based admin tools, plus a few simple games and amusements). Over a 56 kbps modem connection, it worked fine for terminal sessions and very light graphical stuff – but even xsnow had some frameskips, so you’re probably still better off with traditional terminal access under most circumstances if you have to use a modem-speed connection.
While the performance of the VNC viewer is excellent for nearly any platform, the server performance is inherently slower with Windows or Mac (since source code for these platforms isn’t open like XFree86 is).
With Windows 9x/NT, performance is fine but not as fast as the Unix versions, so you may be better off running VNC on Windows machines to control your Unix machines than vice versa. There are some things you can do to increase the performance of the WinVNC server; see the www.uk.research.att.com/vnc/faq.html page for more details. The MacOS version of the server was abysmally slow, although the viewer worked just fine. The MacOS server also proved to be incompatible with MacOS 9, so this may be responsible for the slowness. A superior version of the Mac viewer (which makes use of enhancements for MacOS 8.5 and above) is available at www.webthing.net/gpl/.
If you’re concerned about security (and you should be), adding any services to a machine is an issue. If you’d like, you can use VNC Unix server with TCP Wrappers to restrict VNC port access to specified hosts.
VNC requires simple password challenge-response authentication (only the first eight characters are significant on all platforms, syncing with the Unix version). However, you can use VNC over SSH (providing some compression as well as encrypting all traffic so it can’t be “sniffed”) – more info is available at www.uk.research.att.com/vnc/sshvnc.html. It should be noted that “sniffing” even an unencrypted VNC session would be significantly more difficult than sniffing something like a telnet session, since 1.) the data is compressed (albeit using an open-source method), and 2.) there’s a whole lot of graphical garbage in the data stream.
By default, the VNC server executable can be run by non-privileged users. VNC opens the first session on port 5900 (port 5800 for HTTP connections) and increments additional sessions on the next available port up. If you’re worried about unsanctioned users running it, you may wish to make vncserver root-owned with 700 permissions, or prohibit non-privileged users from opening up new sockets above 1024.
Platforms aside from those discussed above which have servers include AIX, BSD/OS, HP/UX, LinuxPPC (Linux for Power Macintoshes), Linux/SPARC, NetBSD, NetWinder (Linux for ARM), OSF (DEC Alpha), SGI Irix, SCO OpenServer, and SunOS (by the way: why are you still running SunOS?).
VNC Viewers are available (with varying degrees of updatedness) for the abovementioned OSes, as well as Acorn RISC OS, Amiga, BeOS, CygWin32, MS-DOS (by the way: why are you still using MS-DOS?), Geos/Nokia 9000, OpenStep, OS/2, PalmPilot, VMS, Windows CE and Windows NT/Alpha. There’s also a version that integrates nicely with KDE on Linux for x86. For more information on both server and viewer platforms, see www.uk.research.att.com/vnc/platforms.html.