Team LiB
Previous Section Next Section

Hack 32. Access Your Programs Remotely

The full power of your desktop and its applications never need to be more than a network connection away.

For many years now, the X Window System, which plays host to KDE, GNOME, and other desktops or window managers, has had the ability to support networking in a way that other graphical environments can only dream of. These networking features not only allow you to run an application installed on a remote machine and display it on another machine, but also allow you to access and run an entire desktop from another computer. Using this feature, you can use any computer capable of running a basic X session to access a desktop environment on a faster computer. Provided your network bandwidth is plentiful, there isn't a noticeable lack of speed running a desktop in this way. In fact, because all the programs run at the speed of the faster remote machine, your performance might be better than it's ever been.

Despite these impressive abilities, the remote networking personality of X is largely ignored by most users. Few regular desktop users seem to experiment with the possibilities of running remote applications over a network, even though these features could save a lot of time in homes or offices with multiple X-based systems. This hack explores some of these features so that you can apply them in your own context and hopefully save some time rushing between different computers.

The final production work on nearly all O'Reilly books is done by running X applications over the network. Specifically, FrameMaker 5.5.6 is run on a Solaris server and displayed on various Linux, Windows, and Macintosh clients running an X server. All the Linux computers are actually thin clients that run their entire desktop over the network using X.


4.12.1. Access X Programs Securely

Running X applications from another computer is a fairly simple process. You just change the $DISPLAY environment variable (this indicates where the output of X applications should be directed) to point to another computer on the network, such as:

foo@bar:~$ export DISPLAY= "192.169.0.1:0.0"

Now, when you run an application, it is displayed at the new IP address rather than at your local display. Exporting a display like this is the function of the X client. Viewing the display is the function of the X server. For a user sitting at the machine whose address is 192.168.0.1 to see the exported program, he must have a running X server that accepts connections from an outside source. To set up a remote machine to accept X displays from other hosts, use the xhost command:

foo@bar:~$ xhost +
access control disabled, clients can connect from any host

The plus sign indicates you are willing to accept connections from any computer. Optionally, you can specify a specific host (by DNS name or IP address) in place of the plus sign.

Although you can run remote X applications from anywhere using this technique, the traffic between the two machines is entirely unencrypted and insecure. All this traffic operates on port 6000, and if you want to provide access from outside your network, it means opening another port in your firewall and potentially making yourself vulnerable to attacks. To solve this security problem, I advise you to encrypt your X sessions so that they are as secure as possible. The Secure SHell (SSH) has built-in support for running X applications remotely, and it is simple to turn on and use. Most Linux distributions install SSH by default, but if that isn't the case, use your distributions package manager to install the openssh packages.

The first step is to open /etc/ssh/sshd_config on the machine that will serve X applications and ensure the X11Forwarding option is turned on:

X11Forwarding yes

In many default installations of the SSH server, this option is added but commented out with the # symbol. If you remove the #, you can enable the option. After you have changed the configuration file, you need to restart the SSH server for the setting to take effect. You can do this with the following:

foo@bar:~$ /etc/init.d/ssh restart

Now you can run an application on the remote machine by using the -X option to forward the X connection. As an example, you can start the Gimp on 192.168.0.2 by entering this command into your local machine:

foo@bar:~$ ssh -X jono@192.168.0.2 gimp

To permanently enable X forwarding on your local machine, you need to modify your local copy of /etc/ssh/ssh_config. Simply add the following line (or uncomment this line if it already exists):

ForwardX11 yes

What you are doing is telling your local machine to always initiate SSH sessions with X forwarding enabled. This is different from the earlier step where you enabled the remote machine to allow X forwarding. There is no need to restart the sshd daemon when you make this change; it will automatically work for all new SSH connections.

If you receive errors when you attempt to run a remote X application, try enabling trusted X forwarding by adding the -Y option when you make your SSH connection. If this works, you can enable this permanently by modifying your /etc/ssh/ssh_config file to include this line:

ForwardX11Trusted yes

4.12.2. Access the Entire Desktop

There is no doubt that running X applications remotely is useful, but a truly killer feature is the ability to run the entire desktop from a remote computer on your local machine. To do this, you need to use a feature called the X Display Manager Control Protocol (XDMCP), which is part of X. This protocol allows remote computers to access the GDM/KDM/XDM login program, which then gives access to the remote desktop. If you have a reasonably fast network connectionEthernet speeds of 10-Mbit or greater are recommendedit is possible for a slow computer to be as responsive as a cutting-edge machine. This is possible because the local box is just a display device, like a television, and all the real work is done on the faster remote machine.

To use XDMCP, you must be running XDM, GDM, or KDM as your login manager on the remote machine. Each display manager has support for XDMCP, and you must turn on that support.

To enable XDMCP in GDM, you need to load the gdmconfig tool. Inside this tool is an XDMCP tab. Turn on XDMCP support by setting the Enable XDMCP option. You can use some additional settings on this tab to fine-tune XDMCP support. After you've made your changes, you must restart GDM.

There is no GUI way to turn on XDMCP in KDM, so you need to edit the kdmrc file on your system. Both a system-wide file (possibly in /etc/kde3/) and a per-user file (in ~/.kde/share/config) exist. Inside kdmrc is an [Xdmcp] section where you need to set the Enable option to TRue. After you save this change, you must restart KDM.

When you have turned on this support, you can return to your local machine and search the network for computers that are allowing XDMCP connections. To do this, ensure that you are logged out of X and run the following command:

foo@bar:~$ X -broadcast

X will start and the login screen from the remote machine will appear. Now you can log in and use the machine in the same way as if you were sitting in front of it. If you want to connect to a specific machine on the network, you can also run the following command on your local machine (remember to change the IP address to a host that is relevant to your network):

foo@bar:~$ X -query  192.68.0.2

    Team LiB
    Previous Section Next Section