Running X Window Applications

Setting up and configuring the X Window System to your liking is the hard part. By comparison, using X to run applications is relatively easy. If you have used Microsoft Windows operating systems, you already know the most basic ways of running an application from a graphical desktop. X, however, provides a much more flexible environment for running native Linux applications.

Cross-reference: 

See Chapter 3 for information on setting up an X desktop.

Starting applications from a menu

To run applications on your own desktop, most X window managers provide a menu, similar to the Microsoft Start menu, to display and select X applications. Applications are usually organized in categories. From the GNOME or KDE desktops in Fedora Core, open the red hat menu, select the category, and then select the application to run. Figure 5-1 shows an example of the Fedora Core Applications menu and the Sound & Video submenu.

Figure 5-1: Starting X applications from the Red Hat Menu.

Starting applications from a Run Application window

Not all installed applications appear on the menus provided with your window manager. For running other applications, some window managers provide a window, similar to the Run Application window, that lets you type in the name of the program you want to run.

To access the Run Application window:

1. Open the Actions menu.

2. Click Run Application. The Run Application window appears.

3. Click Show List of Known Applications, click the program you want, and then click Run.

   If the application you want isn't on the list, you can either type the command you want to run (along with any options) and click Run, or you can click Append File to browse through directories to select a program to run. If you are running a program that needs to run in a Terminal window, such as the vi command, click the Run in Terminal button before running the command. Figure 5-2 is an example of the Run Application window.

   
   Figure 5-2: Select a program to run from the list in the Run Application window.

Starting applications from a Terminal window

I often prefer to run an X application, at least for the first time, from a Terminal window. There are several reasons why I prefer a Terminal window to selecting an application from a menu or Run Application window:

• If there is a problem with the application, you see the error messages. Applications started from a menu or Run Application usually just fail silently.

• Applications from menus run with set options. If you want to change those options, you have to change the configuration file that set up the menu and make the changes there.

• If you want to try out a few different options with an application, a Terminal window is an easy way to start it, stop it, and change its options.

When you have found an application and figured out the options that you like, you can add it to a menu or a panel (if your window manager supports those features). In that way, you can run a program exactly as you want, instead of the way it is given to you on a menu.

Here is a procedure to run X applications from a Terminal window:

1. Open a Terminal window from your desktop (look for a Terminal icon on your Panel or a Terminal selection on a menu.)

2. Type

   $ echo $DISPLAY  

   The result should be something similar to the following:

   :0.0 

   This indicates that the Terminal window will, by default, direct any X application you run from this window to display 0.0 on your local system. (If you don’t see a value when you type that command, type export DISPLAY=:0.0 to set the display value.)

3. Type the following command:

   $ xmms &

   The xmms program should appear on your desktop, ready to work with. You should note the following:

   • The xmms command runs in the background of the Terminal window (&). This means that you can continue to use the Terminal window while xmms is running.

   • I encountered no errors running xmms on this occasion. With other applications, however, text sometimes appeared in the Terminal window after the command was run. The text may say that the command can't find certain information or that certain fonts or colors cannot be displayed. That information would have been lost if the command were run from a menu.

4. If you want to know what options are available, type:

   $ xmms --help

5. Try it with a few options. For example, if you want to begin by playing a file and you have a WAV audio file named file.wav, you could type:

   $ xmms file.wav

6. When you are ready to close the xmms window, you can either do so from the xmms window (right-click on the xmms window and select Exit) or you can kill the process in the Terminal window. Type jobs to see the job number of the process. If it was job number 2, for example, you would type kill %2 to kill the xmms program.

You should try running a few other X commands. A couple of old X commands you might try are xeyes or xcalc.

Running remote X applications

X lets you start an application from anywhere on the network and have it show up on your X display. Instead of being limited by the size of your hard disk and the power of your CPU and RAM, you can draw on resources from any computer that gives you access to those resources.

Think about the possibilities. You can work with applications launched from any other computer that can run an X application — from a small PC to a supercomputer. Given the proper permission, you can work with files, printers, backup devices, removable drives, other users, and any other resources on the remote computer as though you were on that computer.

With this power, however, comes responsibility. You need to protect the access to your display, especially in networks where the other machines and users are not known or trusted. For example, you wouldn’t want to allow anyone to display a login screen on your display, encouraging you to inadvertently give some cracker your login and password.

Traditionally, to run remote X applications, you basically only need to know how to identify remote X displays and how to use whatever security measures are put in place to protect your network resources. Using ssh to launch X applications is even simpler and more secure than the traditional method. Those issues are described in the following sections.

Traditional method to run remote X applications

If there is an X application installed on another computer on your network and you want to use it from your desktop, follow these steps:

• Open permissions to your X server so that the remote application can use your display.

• Identify your X server display to the application when it starts up.

When you run an X client on your local system, your local display is often identified as :0, which represents the first display on the local system. To identify that display to a remote system, however, you must add your computer’s host name. For example, if your computer were named whatever, your display name would be:

whatever:0 

Tip 

In most cases, the host name is the TCP/IP name. For the computers on your local network, thename may be in your /etc/hosts file, or it may be determined using the Domain Name System (DNS) service. You could also use a full domain name, such as hatbox.handsonhistory.com. X does support other types of transport, although transports other than TCP/IP aren’t used much anymore.

You will probably use the display name in this form most of the time you run a remote X application. In certain cases, however, the information may be different. If your computer had multiple X displays (keyboard, mouse, and monitor), you may have numbers other than :0 (:1, :2, and so on). It is also possible for one keyboard and mouse to be controlling more than one monitor, in which case you could add a screen number to the address, like this:

whatever:0.1 

This address identifies the second screen (.1) on the first display (:0). The first screen is identified as .0 (which is the default because most displays only have one screen). Unless you have multiple physical screens, however, you can skip the screen identifier.

There are two ways to identify your display name to a remote X application:

• DISPLAY shell variable — The DISPLAY shell variable can be set to the system name and number identifying your display. After this is done, the output from any X application run from that shell will appear on the display indicated. For example, to set the DISPLAY variable to the first display on whatever, type one of the following:

   export DISPLAY=whatever:0  

  or

   setenv DISPLAY whatever:0 

  The first example shows how you would set the DISPLAY variable on a bash or ksh shell. The second example works for a csh shell.

• -display option — Another way to identify a remote display is to add the -display option to the command line when you run the X application. This overrides the DISPLAY variable. For example, to open an xterm window on a remote system so that it appears on the first display on whatever, type the following:

   xterm -display whatever:0  

With this information, you should be able to run an X application from any computer that you can access from your local computer. The following sections describe how you may use this information to start a remote X application.

Launching a remote X application

Suppose you want to run an application from a computer named remote1 on your local area network (in your same domain). Your local computer is local1, and the remote computer is remote1. The following steps show how to run an X application from remote1 from your X display on local1.

Caution 

This procedure assumes that no special security procedures are implemented. It is the default situation and is designed for sharing applications among trusted computers (usually single-user workstations) on a local network. This method is inherently insecure and requires that you trust all users on computers to which you allow access. If you require a more secure method, refer to the section “Using SSH to run remote X applications” later in this chapter.

1. Open a Terminal window on the local computer.

2. Allow access for the remote computer (for example, remote1) to the local X display by typing the following from the Terminal window:

    $ xhost +remote1  remote1 being added to access control list 

3. Log in to the remote computer using any remote login command. For example:

    $ telnet –l user remote1 Password:  

   Replace user with the name of the user login that you have on the remote computer. You will be prompted for a password.

   Note 

   By default, the telnet service is not enabled in Fedora Core. The server (in this example, remote1) must consider the security consequences of enabling remote login services.

4. Type the password for the remote user login. (You are now logged in as the remote user in the Terminal window.)

5. Set the DISPLAY variable on the remote computer to your local computer. For example, if your computer were named pine in the local domain, the command could appear as:

   $ export DISPLAY=pine:0

   (If you are using a csh shell on the remote system, you may need to type setenv DISPLAY pine:0.)

6. At this point, any X application you run from the remote system from this shell will appear on the local display. For example, to run a remote Terminal window so that it appears locally, type:

   $ xterm -title "Terminal from Remote1"

   The Terminal window appears on the local display with Remote1 in the title bar.

   Tip 

   As a rule, I use the -title option when I run remote X applications. In the title, I try to indicate the remote computer name. That way, I am reminded that the application is not running locally.

You need to remember some things about the remote application that appears on your display:

• If you only use the login to run remote applications, you can add the line exporting the DISPLAY variable to a user configuration file on the remote system (such as .bashrc, if you use the bash shell). After that, any application that you run will be directed to your local display.

• Even though the application looks as though it is running locally, all the work is being done on the remote system. For example, if you ran a word processing program remotely, it would use the remote CPU and when you save a file, it is saved to the remote file system.

  Caution 

  Don’t forget when a remote shell or file editor is open on your desktop. Sometimes people forget that a window is remote and will edit some important configuration file on the remote system by mistake (such as the /etc/fstab file). You could damage the remote system with this type of mistake.

Securing remote X applications

There are several different traditional methods available to prevent just any X application from appearing on your display. Each method offers a different level of security, as well as different amounts of setup. The major security methods that are supported include:

• Host Access — This method, described earlier as a default method, lets you decide which host computers can have access to your computer’s X display. Use the xhost command to indicate those computers that are allowed access (xhost +hostname) and those that are not (xhost -hostname). If you allow a host access, any user from that computer is allowed access. This security method works best with small networks and single-user computers owned by people you trust.

• Magic Cookie — This method, referred to as the MIT-MAGIC-COOKIE-1 method, lets you grant an individual user remote access to your display. The remote client must present a valid cookie before it can access your display.

  The steps go something like this: You generate a magic cookie (using the mcookie command); you refer to the cookie when you start your X server (usually from a copy of the cookie in your $HOME/.Xauthority file); you distribute this cookie to remote computers that want to show X clients on your display; and the remote client refers to this cookie when it starts.

There are other X security methods that are also based on storing one or more randomly generated keys in the .Xauthority file. XDM-AUTHORIZATION-1 uses a two-part key — a DES encryption key (56-bit) and some random data (64-bit) — to enable access. When a system supports secure RPC, the SUN-DES-1 method can be used to enable access by setting up public and private key pairs that can be validated on a per user basis. Finally, the MIT-KERBEROS-5 method enables both the X client and X server to validate each other (using a Kerberos trusted third party).

Cross-Reference: 

For more information about Kerberos, visit the Kerberos home page at http://web.mit.edu/kerberos/.

Using SSH to run remote X applications

Not only does the ssh command provide a secure mechanism for logging in to a remote system, it also provides a way of securely running remote X applications. With X11 forwarding turned on (it is off by default in Fedora Core 3), any X application you run from the remote location during your ssh session will appear on your local desktop.

After you log in to the remote computer using ssh, you can use that secure channel to forward X applications back to your local display. Here is an example:

1. Type the following ssh command to log in to a remote computer (the -X option enables X11 forwarding):

    $ ssh -X jake@remote1 jake@remote1’s password: ******* 

2. Check that the display variable is set to forward any X applications you run through this ssh session to your local display:

    $ echo $DISPLAY localhost:10.0 

3. After you are logged in, type any X command and the window associated with that command appears on your local display. For example, to start the gedit command, type:

   $ gedit &

For this to work, you don’t need to open your local display (using xhost). The reason this works is because the SSH daemon (sshd) on the remote system sets up a secure channel to your computer for X applications. So as not to interfere with any real display numbers, the SSH daemon (by default) uses the display name of localhost:10.0.

This X forwarding feature is off by default with Fedora Core 3, although it was on by default in earlier Red Hat Linux systems. By adding the line ForwardX11 yes (instead of ForwardX11 no) to the local /etc/ssh/ssh_config file, this service is turned on automatically when you use the ssh command (so you don't need the -X option).