There are times when you will want to run a certain application from a remote machine on a local client. How is this done? Very simply, as I’ll demonstrate in this Daily Feature.

Introducing the export and the xhost commands
By using both the export and the xhost commands, you can configure a client/server setup so that you can run X applications on the client (think thinserver). Be warned, however, that a lightspeed connection is pretty much a necessity here. With a slow connection, you’ll feel like you’ve regressed to the days of the 386 and Win 3.1!

The Linux display
Before we actually dive into this setup, let’s briefly review a few of the major points concerning the Linux display that would affect the setup. The first point is that X is network-aware. Because of this, you’ll want to think of the X environment as TCP/IP and its display name as consisting of the following parts:

  • Hostname (or the IP address)
  • Display number (usually 0)
  • Screen number (Optional unless you have one keyboard that controls more than one screen.)

The X display name has the following structure (where the host is Cartman, whose IP address is 172.22.1.1):

  • hostname:displaynumber.screennumber—the basic display name structure
  • Cartman:0.0—screen 0 on display 0 on Cartman
  • Cartman:0—display 0 on Cartman
  • :0—display 0 on the local system (default display)
  • 172.22.1.1:0—display 0 on Cartman

What does this all mean? Let’s say you’re working at the machine named Cartman and you’re on the default desktop. This setup could be considered in a few different ways:

  • Cartman:0.0
  • Cartman:0
  • 172.22.1.1:0
  • localhost:0
  • :0

Although each of the above is correct, the instance that is generally considered to be most correct, in the local default situation, is :0.

Moving away from local
The above information comes into play when you’re running X remotely. Here you’ll define the X display name using the remote information and not the local information.

Let’s say you’re working on Kenny (with an IP address of 172.22.1.2) and you want to be able to run Cartman’s gtop application. Obviously, you can’t run Cartman’s gtop with the :0 display name. Instead, you’re going to have to use 172.22.1.1:0 as the display name. How do you do this? You make use of DISPLAY=.

What DISPLAY= will do for you is allow you to set your display so that a remote machine can connect to that machine and then run the X application as if it were local to that machine. Sticking with our scenario above (displaying Cartman’s gtop application on Kenny), the following steps are involved (don’t type anything preceded by #):
#add the remote host (Cartman) to the local machine’s (Kenny’s) xhost list
xhost +172.22.1.1
#telnet to Cartman from Kenny
#change Cartman’s display to Kenny’s
DISPLAY=172.22.1.2:0
#run Cartman’s gtop
gtop

As important as it is to configure the remote setup properly, it is equally important to reconfigure the setup to the default. To do this, you will reset the DISPLAY variable on Cartman with
DISPLAY=:0

Once you’ve reset Cartman’s DISPLAY variable, close the Telnet connection and remove Cartman from Kenny’s xhost with
xhost -172.22.1.1

and all is back to the default.

A simpler method
There is, of course, another method that is not only easier but more secure: Secure Shell, or ssh. By using ssh, you can initialize through tunneling. Tunneling is a technique to encapsulate IP datagrams within IP datagrams, which allows datagrams destined for one IP address to be wrapped and redirected to another IP address.

By creating an ssh connection from one machine to another, the ssh application automatically exports your DISPLAY variable so you don’t have to. All that is needed is to connect via ssh, and any X app that you run on the remote machine will appear on the local machine. Simple.

Caution
Of the two methods described above, only one is secure: ssh. Opening up a Telnet connection unleashes a plague of insecurities. With the Telnet connection, you’re not only passing plain-text passwords, you’re transmitting unsecure X protocols across that same unsecure connection. By using the Secure Shell method, you’ll at least have one less security issue.

Conclusion
If bandwidth is not a problem, exporting X applications to a remote client can be an easy way to save on CPU cycles as well as impress your friends and colleagues. The methods are simple and the results are incredible. As long as you keep security in consideration, exporting your Linux X DISPLAY variable is a viable solution when most other solutions require either third-party applications or extensive configuration.

Jack Wallen, Jr., editor in chief of Linux content, was thrown out of the “Window” back in 1995, when he grew tired of the “blue screen of death” and realized that “computing does not equal rebooting.” Prior to Jack’s headfirst dive into the computer industry, he was a professional actor, with film, TV, and Broadway credits (anyone see “The Great Gilly Hopkins”?). Now, Jack is determined to use his skills as a communicator to spread the word—Linux. Ladies and gentlemen, the poster boy for the Linux Generation!

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.