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:

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.

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.