Running Remote Applications

Displaying remote applications on a local system or even controlling a remote desktop requires little configuration and almost no changes to your everyday application use.

One of the advantages to using a GNU/Linux system is the separation of the display system from the underlying operating system. The Linux desktop has at its core the X Window System, a software architecture that provides layering of display components. Each component provides its own set of display features. These features include the ability to change out window managers, directly drive hardware, provide alternative desktop environments and even remotely display some or all of a desktop.

Most Linux users will be familiar with window manager and video display hardware tools, because the desktop paradigm has long assumed the user is sitting in front of the system running the desktop applications. Remote display, although not new to the X Window System, is discussed less often, because end users were thought to have only one system in use. But, end-user needs have grown more sophisticated, and applications like media and Web servers, for example, provide ample reasons to manage multiple PCs remotely, even within a single household.

In this article, I discuss the variety of methods available to Linux users for running Linux applications on a remote system for display locally. I cover basic configuration issues, discuss limitations and advantages, consider security implications and contrast the reasons for using each method. All of the tools discussed in this article should be available from any popular Linux distribution, although package names may vary. Examples and discussion focus on GNOME-based solutions running on Fedora, although similar functionality and applications exist for KDE users. This article does not specifically address display of Mac or Windows applications on Linux systems; however, the section on VNC is closely applicable.

The GNU/Linux Display Architecture

From a very high level, the GNU/Linux display system can be viewed as three distinct components (Figure 1). At the lowest level comes the Linux kernel and the X.org display server and its associated libraries (referred to commonly and collectively as X11). The display server and kernel work together to provide management of the display hardware, and the libraries provide higher-level software a convenient means of using them.

Figure 1. The Linux Display System Stack

The desktop environment sits in the middle of this stack. This includes GNOME, KDE and Xfce, the three most popular desktop environments. In support of these environments are application libraries, such as GTK+ and Qt, as well as a variety of other general-purpose libraries used by desktop applications.

Applications sit above the desktop environment. These are the actual tools users run to view movies, listen to music, communicate with friends and coworkers and purchase products from the Internet.

Remote display of applications is handled by features found within the Infrastructure and Desktop layers. Applications that run in the desktop and X11 environments can be told to display remotely but leave the details of how that is done to the underlying layers of the stack.

There are three methods by which users can run an application on a remote system and have it display locally—that is, on the screen in front of which they are seated. The first method involves the use of the X Display Manager Control Protocol (XDMCP). This protocol is part of the X11 specification and is implemented on Linux systems using the GNOME Desktop Manager (GDM) or when using KDE, by the KDE Display Manager (KDM), both of which are replacements for the X Display Manager (XDM). This method is focused on running individual applications, although there are applications that can provide a complete remote desktop.

The second method relies on OpenSSH support of X11 protocols. It also is focused on running individual applications and is typically easier to configure and use.

The last method is based on Virtual Network Computing (VNC) mechanisms that are operating-system-independent and more suited to complete desktop sharing.

Using XDMCP via GDM

In X11 parlance, the server is the thing that manages your display hardware, and the client is the application that needs the server to display windows. This often confuses people, because it's backward from one's normal understanding of the terms client and server, as now the server is the computer in front of you and the client is the remote computer.

Most applications on the Linux desktop provide the -display command-line option. This option is equivalent to setting the DISPLAY environment variable, and it tells X11 clients (applications) which X server to display on. The default setting is to display on the local server, referenced as :0.0. A remote server can be specified by prefixing this value with the hostname (or IP address), such as galileo:0.0. The reference to galileo:0.0 works only if the host galileo is running at least one instance of an X server.

The use of the -display option is tied to the configuration of XDMCP on the X server. XDMCP is the old-school method of displaying remote applications on a local display. Most old-time UNIX and X11 users are familiar with its use, although configuration issues have evolved with the Linux desktop.

On GNOME systems, XDMCP is controlled by GDM. GNOME users are familiar with GDM from the graphical login screen. That screen is actually only one part of GDM and not related to our discussion. GDM also controls XDMCP usage for an X session, otherwise known as a graphical login. The graphical login starts a new X server with various options. By default, GDM does not permit XDMCP connections to the X server from remote client applications. To enable it, edit the file /etc/gdm/custom.conf to look like this:

# GDM configuration storage
[xdmcp]
Enable=true
[chooser]
[security]
DisallowTCP=false
[debug]

The [xdmcp] section has a single option, Enable, which when set to true, allows XDMCP connections. However, GDM also needs to be told to allow TCP connections in order for the remote applications actually to use XDMCP when communicating with the X server. The [security] section option DisallowTCP must be set to false in order to disable the feature that denies TCP connections.

Note that XDMCP is the higher-level protocol (the way a client application and an X server will communicate), while TCP is a lower-level protocol, which for our purposes can be defined as the networking port that the communication flows through.

Once configured, restart GDM. You can do so by changing the run state to 3 and then back to 5 with the following commands, with a short pause between them recommended. Be aware that if you execute the first command in a terminal/shell window, the window will disappear, because this command kills the X server. You'll be dropped into a virtual console/terminal, at which point, you probably will have to log in to execute the second command:

sudo init 3
sudo init 5

Now the local X server is configured to allow remote applications to connect to it. One additional step is required to specify which hosts have access to the local X server. There are two ways to do this. One is to edit the /etc/hosts.allow and/or /etc/hosts.deny files. A simpler method is to run the xhosts command after logging in to the local system:


xhost +<hostname-or-ip>
xhost -<hostname-or-ip>
xhost +

The first command allows a specific host to display locally, and the second denies a host. The third method allows any host to display locally. This option should be used only on a trusted network, such as your network at home that is behind your firewall. The xhost settings are applicable only to the current login session.

Now, open a terminal window, log in to the remote system (preferably with SSH, but Telnet if you must), and start another terminal with the display option set to the local X server:

xterm -display galileo:0.0

The xterm started here is running on the remote system but displaying on the local X server (on the computer in front of you). You can start other applications the same way with each appearing as an ordinary window on the local desktop. In this way, the remote applications mix seamlessly with the local desktop. If for some reason your shell prompt doesn't include the name of the host in the prompt, you probably should set it so that you know on which system each xterm is running.

GDM comes with GNOME, so as long as you have GNOME installed, you can use this method of remote application display. With KDE, you normally would use KDM, but its configuration is not covered here.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

NX server

Anonymous's picture

On the site of the Dutch MandrivaClub (www.mandrivaclub.nl) I also read very positive reviews about FreeNX. Much faster than vnc.

Dana, you are right. NX shouldn't be ignored.

Arvi Pingus

NX server

dwellen's picture

Having tried most of these methods I stumbled on NX by NoMachines. It does have some advantages over most remote desktop in that it has very good performance, if fact some applications that normally, due to poor performance are usable over a WAN or VPN. I know it's closed source but the company has released much of their code to the open source project called freeNX. I have done about 6 months of testing along with user testing/feedback and have had great success using NX. It also handles multimedia content (Haven't tried but it claims to) and using ssh along with compression so you get the advantages of secure ssh along with almost native performance.

Thanks,
Dana Wellen

BTW, I don't work for or have any connection to NoMachines but NX seams to get ignored often.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix