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

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

David Mertz (mertz@gnosis.cx), 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.

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 192.168.1.101 through 192.168.1.107, 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 192.168.1.200). 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 192.168.1.102.

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:

[vnc-user@fury vnc-user]$ vncserver

You will require a password to access your desktops.

Password:
Verify:

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:

#!/bin/sh
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:

[root@bacchus /root]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:48:54:83:82:AD
          inet addr:192.168.1.102  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          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:

[root@bacchus /root]# xhost -
access control enabled, only authorized clients can connect
[root@bacchus /root]# xhost +192.168.1.106
192.168.1.106 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):

[root@bacchus /root]# telnet -l quilty 192.168.1.106
Trying 192.168.1.106...
Connected to 192.168.1.106.
Escape character is '^]'.
Password:
Last login: Tue Nov 27 18:07:51 from 192.168.1.201

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

[quilty@fury quilty]$ echo $DISPLAY
bacchus.gnosis.lan:0

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):

[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:

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

Try to do the sequence above:

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:

quilty@delphi:~$ export DISPLAY=192.168.1.102:0
quilty@delphi:~$ xeyes &
[1] 17669
quilty@delphi:~$ Xlib: connection to "192.168.1.102:0.0" refused by server
Xlib: Client is not authorized to connect to Server
Error: Can't open display: 192.168.1.102:0

[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):

[root@bacchus /root]# xhost +192.168.1.104
192.168.1.104 being added to access control list

All is well:

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:

[quilty@bacchus quilty]$ ssh -X quilty@192.168.1.104
quilty@192.168.1.104's password:
Last login: Fri Nov 30 16:53:03 2001 from 192.168.1.102
Linux 2.2.19.
quilty@delphi:~$ echo $DISPLAY
delphi:10.0
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.

Resources

• 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 X.org home page.
  
  
• A number of commercial implementations of the X Window System are available also:
  • Accelerated-X
  • Metro-X
  
  
• Browse more Linux resources on developerWorks.
  

About the author

		David Mertz is all things to all people. Computers crash at the very sight of him. David may be reached at mertz@gnosis.cx; his life pored over at http://gnosis.cx/dW/. Suggestions and recommendations on this, past, or future columns are welcome.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Back to top