Linux Today: Linux News On Internet Time.

Using Xnest

Linux has long provided tools for running multiple programs
simultaneously. In the X Window System
environment, in particular, you can run multiple programs, each in
its own window, on one screen. Most window managers take this a
step further by implementing a pager, where
each “page” hosts its own unique collection of windows,
enabling you to run dozens of programs without cluttering your
screen with a confusing mish-mash of windows.

Sometimes, though, even a pager doesn’t go far enough
— you might want to run multiple window manager or desktop
environments, perhaps even as different users. Similarly, you might
want to run one desktop environment on your local computer while
accessing another computer, including its own desktop environment,
using the first computer’s screen and keyboard. Fortunately,
Linux provides tools to do all of the latter.

One solution is to run multiple instances of your X server, but
link each one to a separate Linux virtual terminal. This approach
works well, but has the disadvantage of requiring awkward
keypresses to switch between environments. Another approach is

Xnest is a standard part of the
XFree86 and X.org-X11
X servers, and provides an X server that runs inside a standard X
window. Using Xnest, you can run two
different GUI environments, one inside another’s window. The
Xnest- hosted session can function under a
different username than the main environment, or can link to a
remote computer, if necessary. Xnest can be
handy for local or remote system administration (you can log into
remote computers or test a user’s malfunctioning GUI
configuration) and for day-to-day (non- "i">root) functions (for remote system access or to run
multiple desktop environments).

The Relationship Between X and Xnest

To fathom X and Xnest is to understand
the role of servers. Put succinctly, server
 responds to data transfer requests from other
(client) software. In the X model of the world, client programs
(such as Mozilla Firefox, OpenOffice.org,
and xterm) request data transfers to and
from a computer’s screen, keyboard, and mouse. The X server
manages those resources on behalf of its client programs and
leverages network protocols to connect clients from remote systems.
The fact that a human interacts directly with the screen, keyboard,
and mouse is irrelevant. So is the fact that the X clients and
servers often both reside on the same computer. It’s the
nature of the interaction between the X server and the programs it
manages that’s important in defining X as a server.

Where does this leave Xnest, though? This
program is both a client "i">and a server: Xnest runs within a
normal X session, making it a client of that X session.
Simultaneously, Xnest functions as an X
server to additional programs, providing them with a (virtual)
display, keyboard, and mouse.

In principle, a program that runs within an "i">Xnest session needn’t know that "i">Xnestis using another X server’s calls to manage
its own input and output. In practice, though, this fact does have
consequences. In passing its clients X calls on to its own X
server, Xnest introduces inefficiencies and
opportunities for things to go wrong. Thus, in practice, programs
sometimes run more slowly or exhibit display quirks when run within
an Xnest session. These problems
aren’t usually very onerous for typical office programs or
the like, but they can cause games and video-display programs to
behave poorly.

Figure One:
Xnest lets you run one
desktop environment within another one.

class="story_image"> "http://www.linux-mag.com/images/2007-03/guru/xnest.png" class=

Figure One shows "i">Xnest in operation: The main display is the normal X
session, running XFce. Within it is a
smaller Xnest display running "i">GNOME. And within that is a still smaller "i">Xnestdisplay showing a KDE login
prompt on a different computer.

Basic Xnest Use

Before proceeding further, you should verify that "i">Xnest is installed on your system. Look for a binary
file called Xnest;
it’s usually installed in /usr/bin or
/usr/X11R6/bin. If you can’t find the
program file, look for and install an Xnest
package for your distribution, such as xorg-x11-

If you consult the Xnest man page,
you’ll learn that you can launch Xnest
from an X session by typing the program’s name and passing it
a display number. Unfortunately, this doesn’t always work
correctly. The default X security settings, which apply to
Xnest, prevent it from accepting connections
from clients (that is, user programs) that are launched from
anything other than the Xnest session
itself. Thus, you’ll be left with an "i">Xnest window with no running programs and no way to
launch programs. One way around this problem is to add the
-ac option to the command line, which
disables most X security features:

$ Xnest -ac :1

You can change the session number (:1 in
the preceding example) to a higher number. In fact, each
Xnest (or other X server) requires its own
session number. You can launch programs and select an "i">Xnest session by specifying a display parameter when you
launch the program from xterm or similar
tool outside of the Xnest session. For
instance, you might type:

$ xterm -display :1

You can usually omit the -display:1 part
by setting the DISPLAY environment

$ export DISPLAY=:1

This action affects all the programs you launch thereafter from
that shell until you reset the DISPLAY
environment variable. This approach has the advantage that it works
with all X programs, as not all programs accept a "c">-display command-line option.

Remember that window managers and desktop environments are
programs, too. Thus, you can start them in your "i">Xnest session, either by specifying a "c">-display command-line option (if it’s supported)
or by setting the DISPLAY environment
variable. For instance, you might type "c">icewm--display=:1 to launch IceWM
in your Xnest display. Unfortunately, window
managers and desktop environments sometimes don’t start
cleanly when launched in this way because they get confused about
which X session to manage.

Enabling Xnest Logins

Launching and using Xnest as just described can be awkward, and
disabling security via the -ac option is
undesirable. One way to reduce the awkwardness and increase your
options is to use Xnest as a way to log into a fresh X session. To
do this, connect Xnest with an X Display Manager
Control Protocol
 (XDMCP) server to manage logins. (Most
Linux computers run an XDMCP server to manage local X logins.) This
approach enables you to log in as any user and even to log into
remote computers.

The simplest way to link Xnest to an XDMCP server is to use the
gdmflexiserver program:

$ gdmflexiserver --xnest

The gdmflexiserver program launches a new
GNOME Display Manager (GDM) XDMCP server.
Ordinarily, this server launches X on a free Linux virtual console.
However, when you pass it the --xnest (or
-n) option, this program launches
Xnest rather than the main X server. The end
result is that you’ll see a new GDM greeter in your
Xnest session. You can log in as any user or
specify an alternate desktop environment as a login option,
enabling you to debug user-specific problems or test new desktop
environments without shutting down the one you’re

Although using gdmflexiserver in this way
is convenient and simple, it does have its limitations. You
can’t pass Xnest options (described
later) via gdmflexiserver, and you’re
limited to using GDM on your own local computer. A more flexible
way of linking Xnest to an XDMCP server does
exist, but it’s got some important caveats. Before dealing
with the caveats, understand that Xnest
accepts many of the same command-line options as other Linux X
servers. Thus, you can use the -query option
to have Xnest link to the XDMCP server
that’s running on your local computer (that is, "c">localhost):

$ Xnest -query localhost :1

The result of this command is similar to the result of using
gdmflexiserver, but you’ll see
whatever your normal XDMCP server is, whether it’s GDM,
KDM, XDM, or something more exotic. The
caveat of this approach is that your XDMCP server must be
configured to accept remote logins, or at least accesses from your
own computer. For security reasons, most Linux distributions
configure their XDMCP servers to refuse such access attempts. To
loosen the security grip, you must reconfigure your XDMCP server,
but how you do this varies from one server to another, as described
shortly, in “XDMCP Configuration.”

In addition to accessing your local computer, you can access a
remote computer — just substitute its hostname for
localhost in the preceding command line. To
use the remote computer, though, its XDMCP
server must be configured to accept remote logins from the computer
you’re using.

If your network sports a number of Linux or Unix systems that
support remote XDMCP logins, you can use the "c">-indirect hostname option to
obtain a list of potential clients from an XDMCP server
that’s configured to deliver them. For instance, if
you’ve configured your local XDMCP server to honor indirect
requests, you could type:

$ Xnest -indirect localhost :1

The result is a list of available XDMCP servers; you can then
pick one and log into it.

XDMCP Configuration

To get the more advanced Xnest
configurations working, you’ll need to delve into XDMCP
configuration on one or more computers. The simplest XDMCP server
to reconfigure is GDM, which is the default for Red Hat and some
other distributions.

Edit the /etc/X11/gdm/gdm.conf file and
locate the [xdmcp] section. Change the line
that reads enable=false to read "c">enable=true, and if there’s a line that reads
Port=0, change it to read "c">Port=177. These changes reconfigure GDM to function as a
network-enabled XDMCP server; it will accept remote login requests.
If you prefer, you can use the gdmsetup
program to edit gdm.conf. Click the
Security tab and check the Enable XDMCP

The XDM configuration files usually reside in "i">/etc/X11/xdm, and old versions of KDM use those files,
as well. More recent versions of KDM use similar files in another
directory, typically "i">/usr/kde/3.5/share/config/kdm/"i">/opt/kde/share/config/kdm, or something similar. For
both KDM and XDM, one critical file is "i">Xaccess. This file controls who may access the XDMCP
server. For the configuration described here, a line that reads
localhost should do the job. To open the
XDMCP server to any remote system’s
access, a line that reads * will work.

XDM’s main server options are set in a file called
xdm-config. To have the server listen for
connection requests from a VNC X server or
other computers, you must tell it to listen to port 177 with a line
like this:

DisplayManager.requestPort: 177

The default configuration on most systems substitutes
0 for 177, which
keeps the server from listening for connection requests. In recent
versions of KDM, the same task is accomplished through a line that
reads Enable=true in the "i">kdmrc file.

In all of these cases, you should be aware of the security
implications of enabling XDMCP access. I don’t advise you to
do this if your computer is accessible from the Internet, unless
you also implement firewall rules or other restrictions to prevent
unwanted access. In the case of KDM and XDM, you can limit the risk
by specifying only localhost (or a list of
computers) in the Xaccess file.
Unfortunately, no similar tool for limiting access exists for

Additional Xnest Options

You may want to peruse the Xnest man page
or type Xnest--help
to see a list of options. You can adjust a number of "i">Xnest features via command-line options. A couple of the
more useful options sets the window size and longevity.

*The "c">-geometry parameter lets you set the window size. For
instance, -geometry 800x600 creates an
Xnest window with an internal area of
800x600 pixels. You can add a starting screen position if you like,
too, as in -geometry 800x600+100+200, which
positions the window 100 pixels to the right and 200 pixels down
from the top-left corner of the host screen.

*If you pass the "c">-once option to Xnest, it will
terminate when the session finishes. This is most useful when you
link to an XDMCP server and don’t intend to log in again
after you log out of the remote session.

Xnest vs. VNC

Xnest isn’t the only way to achieve
a session within a window or remote GUI access under Linux.
Virtual Network Computing (VNC; "i"> "story_link">http://www.realvnc.com and "i">"story_link">http://www.tightvnc.com, among other sites)
software is one alternative that comes to mind (see the March 2003
“Guru Guidance” column online at "http://www.linux-mag.com/2003-03/guru_01.html" class=
"story_link">http://www.linux-mag.com/2003-03/guru_01.html). If
you’re already using VNC for this purpose, you might be
wondering why you should switch; or if you’re using neither
tool but want the capabilities I’ve just described, you might
wonder which one to use.

The main advantages of Xnest are that
it’s a native X protocol, so it entails relatively little in
the way of overhead and it integrates more smoothly with
applications. You’re less likely to see video redrawing
errors or other glitches with Xnest, for
instance. (This isn’t to say that "i">Xnest is perfect in this respect; it is imperfect,
particularly when you try to run graphics-intensive programs, such
as games.)

VNC, by contrast, is a platform-neutral protocol, so its main
advantage is that it can be used on multiple operating systems,
including Linux, Windows, Mac OS X, and
others. This fact can be a big plus when you need cross-platform
access, but it’s not very important for Linux-to-Linux (or
Linux-to-Unix or Unix-to-Linux) access.

Xnest and VNC also use different
client-server relationships. You sit at the computer that runs the
VNC client and use it to access a (possibly remote) VNC server. As
noted earlier, though, you sit at the Xnest
server and use it to access a (possibly remote) X client. This
reversal of relationships can have consequences in some situations,
such as when you’re using a computer that resides behind a
firewall. Typically, VNC will require less in the way of special
firewall configuration to work correctly. (In the case of remote
access, the XDMCP server is on the X client computer, which further
complicates matters when using X from a firewalled computer.)

Overall, Xnest is usually a superior
solution for Linux-to-Linux connectivity on a local network,
whereas VNC is superior when used in a cross-platform manner and
sometimes when working through a firewall is necessary. If in
doubt, you may want to try both tools and see which one works best
for you.

Comment and Contribute

    (Maximum characters: 4000). You have 4000 characters left.