Friday, September 12, 2008

Sharing computers on a Linux (or heterogeneous) network, Part 2

Original Source click here

Level: Introductory

David Mertz (, Programmer and author, Gnosis Software, Inc.

01 Mar 2002

This article is the second of two comparing SSH, remote X, VNC, and other technologies as ways of remotely running applications. In this part, David takes a look at some VNC configuration issues, glances at IBM's Desktop On-Call, introduces remote X, and talks a bit about security.
Show developerWorks content related to my search: DelphiShow developerWorks content related to my search: Delphi

In Part 1 of this pair of articles on sharing computers, I described my heterogeneous local network and how I use it to compare and test applications on different operating systems and architectures. Several technologies let a user at one workstation run an application that lives on another workstation. SSH provides text terminals to remote computers; the X Window System can be used to display an interactive application on a workstation other than where it actually runs; VNC can act as a "remote-control" to an entire remote desktop.

Each technology has advantages and disadvantages. They all run on Linux, but different variations (host or remote) allow interaction with various other OS environments for heterogeneous networks. Using combinations of these tools, I can sit at one workstation (say, the one with the best monitor, keyboard, and chair) and run, test, and time applications on a bunch of platforms -- usually without rebooting anything.

Part 1 introduced SSH and VNC. This second part talks a bit more about VNC, then moves on to remote X and security.

My network setup

My local network has seven nodes on it, named Apollo, Bacchus, Chaos, Delphi, Echo, Fury, and Gaia. These nodes are assigned local IP addresses through, in the obvious order. For the most part, the same physical machine gets the same IP address when multi-booted to different OSes (but sometimes I use DHCP, which assigns addresses above The whole thing sits behind a hardware firewall/router, and I trust the firewall enough that I am perhaps not as paranoid as I should be about the services that run on the local machines. Those readers who need to share computers over the public Internet should worry a bit more about security matters than I do. The above details will let readers follow some shell examples that I give below. The machine I actually sit at is Bacchus, and has IP address

Back to top

Configuring VNC

In Part 1 I showed how to launch VNC on a Linux platform, and I considered some issues about screen geometry and color depth, but I left aside consideration of some important matters around configuring and using VNC. This article focuses only on the use of UNIX-like Xvnc servers. Other systems have similar concepts but implement configuration differently, often through menus and dialogs instead of command lines and configuration files.

The first time vncserver runs within a given user account, it asks you to specify the password that VNC clients will need to connect. In addition, some default configuration files are created. Take a look at this first run:

Creating default VNC configuration
[vnc-user@fury vnc-user]$ vncserver

You will require a password to access your desktops.


New 'X' desktop is fury.gnosis.lan:3

Creating default startup script /home/vnc-user/.vnc/xstartup
Starting applications specified in /home/vnc-user/.vnc/xstartup
Log file is /home/vnc-user/.vnc/fury.gnosis.lan:3.log

Here I've created a VNC session. The default resolution is used when nothing to the contrary is specified on the command line. The default geometry is 1024 x 768, and the default color depth is 8-bit. Part 1 showed how to create a script file that used other resolutions.

The noteworthy thing in the initiation is the ~/.vnc/xstartup file that is created during the first run. This file controls what happens when the VNC session is created -- most notably, which window manager is used. The first time ~/.vnc/xstartup is created, the window manager specified is twm, an extremely minimal window manager that is present on nearly every X Window System machine. On the plus side, the minimal nature of twm makes it about the most bandwidth-friendly way possible to run VNC. On the minus side, twm lacks most of the bells-and-whistles of a full "desktop manager" like KDE, GNOME, or WindowMaker. Many users will want to edit their xstartup. Below is an example I have modified:

Customized VNC "startup"
xrdb $HOME/.Xresources
xsetroot -solid grey
#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &
#exec wmaker
exec startkde

In the example above, I have commented out the default twm and the default launch of an xterm. I have also commented out the launch of WindowMaker that I used for awhile. I did not actually delete those lines in case I want to restore them later. What I actually do with this account is launch KDE. However, I have configured this particular KDE desktop to avoid color gradients on the background and title bars, and use a minimum of animation effects. Minimizing the busyness of the desktop makes KDE easier on the channel bandwidth. Similar principles apply to whatever window manager you prefer.

One final note is on killing VNC sessions you have launched. You need to do this on the server end (including from a vncviewer window, which will sever the connection once you kill the server; but this causes no harm). A quick way to see what VNC sessions have been launched is with ps -ax | grep vnc. If you want, you can use the Linux kill command to end a session, but this can leave some dangling semaphore files that you will later need to manually delete. The cleaner approach is usually vncserver -kill :1 -- but if you want to force-kill a user VNC process from the root account, use the kill command.

Back to top

Desktop On-Call and eComStation

Readers of my "Charming Python" columns on developerWorks and of this pair of articles might have been slightly surprised by my occasional references to using OS/2, which has diminished in popularity (and even more in IBM attention) for a number of years. My "official" story is probably the observation that the Workplace Shell of OS/2 Warp is still far ahead of any GUI that has appeared on Linux, Windows, MacOS, or even BeOS. The WPS really is that good, but the actual reason for my continuing usage is mostly inertia on my part. Over the years, I have built up a large set of tools I am familiar and comfortable with on OS/2, and they work well with each other. I've never quite managed to fill all the gaps for my daily use when I boot to other systems (90% happiness still requires an occasional reboot).

Given my stubbornness, I was excited recently to receive a reviewer's copy of Serenity Systems' eComStation, which is an enhancement and rebundling of IBM's Warp 4.5/Workspace on Demand by a third-party licensee. eComStation (eCS) was released just this year, and includes all the newest patches to the "Warp core" and a bunch of extra tools.

One of the tools included with eCS is an IBM product called "Desktop On-Call (DToC)." Versions of DToC server are also available for Windows and Linux, but are hard to buy in the U.S. What DToC does is a lot like what VNC does. The DToC server piggybacks on the HTTP protocol (and by default uses port 80) to serve a "remote desktop" across a network -- either a LAN or the Internet. The client application for DToC is any Web browser with JavaScript and Java enabled. Basically, as with the VNC Java client, a Web browser is the connection interface to DToC. And DToC has exactly the same issue with locally captured keystrokes, multi-key sequences, and bandwidth/resolution tradeoffs as VNC.

DToC has a couple of advantages over VNC. The security issues are integrated into DToC, rather than travelling through other layers and translations that you need to configure separately. The piggybacking on HTTP means that DToC gets through a firewall more easily than VNC does (but that is both good and bad). Furthermore, within DToC you get a file transfer interface, so no separate FTP, Samba, NFS, or similar file transfer server necessarily needs to run on the server machine, as long as DToC is running (as you would need with VNC). On the down side, DToC feels a bit less responsive than VNC overall -- not terrible, but a little less good.

Another tool bundled with eCS is an X Server called Hoblink X11. I have not experimented with that yet, but when I do, this might bring even better integration into the OS/2 nodes of my local network (but Linux still does the best job of "playing nice").

Back to top

Remote X Window System

The X Window System is a remarkably nice software idea. All the more so given that it was first invented in 1984 (before Microsoft Windows 1.0, and just slightly after the first Macintosh). For most Linux users, the X Window System (or "X11", but properly speaking not "X Windows") is probably just the API that their window manager calls to display GUI applications locally. But X11 is actually something more interesting.

X11 always has a client and a server, even when both of them run on the same physical machine. The X client and X server are probably the opposite of what one would initially think they are. An X server is a device that is willing to "serve" a display capability to an underlying application. An X client is a particular application that would like some X server to provide it with a place to put its visual output.

Running on a local workstation, the server and client communicate over a purely internal channel. But when there are local and remote machines involved, the local one is usually the X server and the remote one is usually the X client. However, once in a while, you might want something to get displayed at a workstation you are not at, and the roles could be reversed.

The X Window System itself is really just an API that has calls such as "draw a window at these coordinates." To actually do much with the X Window System, you usually run a window manager on top of it, which lets you do things such as move windows, minimize them, and launch new X clients.

Let's look at how you might launch a remote application (X client) to display on a local workstation. All the machines in the demonstration are Linux, but other systems with X servers and clients will work in a similar manner. First we want to figure out what IP address our local machine uses; ifconfig is a good tool for this:

Finding the IP address of local machine (X Server)
[root@bacchus /root]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:48:54:83:82:AD
inet addr: Bcast: Mask:
RX packets:15933 errors:0 dropped:0 overruns:0 frame:0
TX packets:10426 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:10 Base address:0xe800

Next, you want to make sure that an application on the remote machine will have local permission to use your local X server:

Setting X server authorization (1st remove all)
[root@bacchus /root]# xhost -
access control enabled, only authorized clients can connect
[root@bacchus /root]# xhost + being added to access control list

Next, you will need to be able to launch an application to run on the remote machine. We could go to the physical machine (or get someone else to), but most of the time opening a remote shell session is the easiest thing (here, the insecure telnet method is used):

Connecting to remote machine Fury (X Client)
[root@bacchus /root]# telnet -l quilty
Connected to
Escape character is '^]'.
Last login: Tue Nov 27 18:07:51 from

If all goes well, the remote machine will automatically detect the machine that is connecting. But see below for what to do otherwise:

Check DISPLAY environment var on X Client Fury
[quilty@fury quilty]$ echo $DISPLAY

Now we can launch an X client. For the example, the trivial (but cute) application xeyes is used (it displays of pair of eyes on screen that follow the mouse cursor):

Launch an app on X Client to display on X Server
[quilty@fury quilty]$ xeyes &
[1] 9939

Some failures in launching the remote application

Occasionally, something goes wrong in the above sequence. Take a look at some typical problems:

Connect to remote machine Delphi
[root@bacchus /root]# /usr/local/bin/ssh quilty@
quilty@'s password:
Last login: Wed Nov 28 01:06:08 2001 from
Linux 2.2.19.

Try to do the sequence above:

Check DISPLAY environment var on X Client Delphi
quilty@delphi:~$ echo $DISPLAY

quilty@delphi:~$ xeyes &
[1] 17668
quilty@delphi:~$ Error: Can't open display:

[1]+ Exit 1 xeyes

Since there was no value automatically detected for the DISPLAY environment variable, the X client has no idea which server will do the displaying for it:

No (or wrong) DISPLAY was set, export value
quilty@delphi:~$ export DISPLAY=
quilty@delphi:~$ xeyes &
[1] 17669
quilty@delphi:~$ Xlib: connection to "" refused by server
Xlib: Client is not authorized to connect to Server
Error: Can't open display:

[1]+ Exit 1 xeyes

Making progress, but Bacchus hasn't authorized Delphi to use its X server yet (we need to switch to a local xterm to fix this):

X Server refused connection; enable it
[root@bacchus /root]# xhost + being added to access control list

All is well:

Launch an app on X Client to display on X Server
quilty@delphi:~$ xeyes &
[1] 17670

Back to top

Security issues

In Part 1, I mentioned that both VNC and remote X11 are insecure over Internet channels. The whole remote display gets shipped unencrypted over public routers. I do not worry on my private LAN, behind my firewall. But if I wanted to use these techniques to share remote computers across the world (or even across town), the VNC or X11 protocols should be "layered" over SSH. There is really no loss in doing this, and SSH even (optionally) adds its own compression layer to enhance performance. But you need to configure it.

To configure VNC over SSH, the best thing to do is to read the article "Making VNC more secure using SSH" (see Resources later in this article). It is well written, and says everything I might.

Layering X over SSH is pretty easy to do. Assuming you are using OpenSSH, you will need to modify a file called sshd_config to allow this. Different Linux distributions put this file in somewhat different places. Mandrake 7.1 keeps it at /usr/local/etc/; Slackware 7.0 uses /etc/ssh/. In any case, you want to make sure the file contains the following:

X11Forwarding yes

You will need to restart the sshd daemon to activate the setting.

Actually launching an X client to display on the local X server is even easier once sshd is configured correctly:

Using sshd X11 forwarding with X client
[quilty@bacchus quilty]$ ssh -X quilty@
quilty@'s password:
Last login: Fri Nov 30 16:53:03 2001 from
Linux 2.2.19.
quilty@delphi:~$ echo $DISPLAY
quilty@delphi:~$ xeyes &
[1] 201

Notice that even though you connected to Delphi, the DISPLAY variable seems to indicate the X server is on Delphi. It is, in a way, but the X server in question is the SSH daemon that ships the display to the appropriate remote computer.


  • The first installment of this series, Sharing computers on a Linux (or heterogeneous) network, Part 1 (developerWorks, December 2001), makes a close comparison of SSH and Virtual Network Computing.

  • eComStation is a rebundling and enhanced version of IBM's OS/2 Warp/Workspace on Demand that puts a particular emphasis on playing well in heterogeneous network environments.

  • X Window System resources
    The Web site for XFree86 is the best place to look everything related to this popular free software X Window implementation.

  • Technically, XFree86 is a clone of the official X Window System (much as Linux is a "clone" of UNIX). In practical terms, you do not need to worry about what is official -- all the versions play nice with each other. For information on the official system (including available source code), go to the home page.

  • A number of commercial implementations of the X Window System are available also:
  • Browse more Linux resources on developerWorks.