X Window System Administration

When the X Window System was first
released, many complained that the system was big, slow and
complicated. My first experience with X was installing one of the
earliest releases available for Intel hardware on my 386 running
UNIX with 4MB of RAM and an 80MB hard drive. The installation took
up most of the drive, and X ran so slowly (with much thrashing of
virtual memory) that it was simply unusable. I quickly decided to
remove it from my system and went on to “real work”.

However, I got a taste of what X was like and appreciated how
the developers took the “high road” in their design. They
combined a high degree of versatility and a client-server
architecture, at the noticeable expense of performance on what is
now generally considered to be archaic hardware.

Today, most computers running Linux have more than sufficient
hardware resources to run X with good performance, so running X on
an inexpensive desktop system is commonplace. Now that we've all
got X running on our desktops, the next hurdle is configuring X and
customizing it to meet our needs.

X's Client-Server Architecture

I will start out by presenting a brief description of how X
is structured and how the parts interoperate. Once you know this,
it will be much easier to make sense of the implementation
details.

One of the most basic facts to be aware of is that X is not
part of the kernel. Unlike other operating systems, where
applications make requests to put up windows, menus, et al., to the
operating system API, X is entirely contained in user space,
running as ordinary processes. These processes are classed into two
groups: client processes and server processes.

The job of the X server is to handle the interface to the
hardware (graphics adapter, keyboard and mouse) and a few
additional low-level services such as drawing, color allocation,
event handling, inter-client communication and managing a resource
database of user preferences.

Clients communicate with the X server through the X protocol,
which can be run over interprocess communication (IPC) on one
system, or between systems using TCP/IP. This allows an X client to
run on one system and use the display, keyboard and mouse on
another. Yes, it is even possible to run an X protocol over the
Internet.

For example, if I use TELNET to access my ISP and run the
command xeyes, the program will
start up and display a window on my Linux system. The program seems
to be running locally, even though it is actually running on the
remote system and just using my system for the display. The way
this works is that the remote system is running xeyes, while the
client (requesting services) and my Linux system are running the X
server (which fulfills the client's requests). This, of course,
requires that my system be set up to allow it; I use the
xhost command to allow my ISP's
system to use the X server on my system. Also, the
$DISPLAY environment variable in my TELNET
session must be set correctly (see below). I am using this example
only as a demonstration; if you want your system to be secure, you
will probably not want to allow people to access your X server from
an outside network. One trick used by crackers is to put up an
invisible window covering your display that catches all keyboard
input, including passwords.

Each display is handled by one server process, but many
clients can use a display at the same time. One of the most
fundamental client types is the window manager, which allows the
user to manipulate windows. A window manager performs actions such
as drawing “decorations” around windows (borders, title bars and
buttons), and provides functionality such as pop-up menus and the
iconization of running clients. Desktop environments such as KDE
and Gnome are implemented as user-space X clients, as are all other
applications that run under X. These applications can be of any
level of complexity, from xlogo to
Netscape Navigator.

X Administration

In the remainder of this article, I will cover some basic X
Window System administration. A full treatment would take a whole
book, so I'm going to discuss only what I consider the most
important points for the novice X administrator. For the most part,
I will assume you have X already configured and running. I will
skip over advanced topics such as security and running X over a
network (on X terminals or remote systems) as much as possible.
This article covers XFree86, which comes with most Linux
distributions. If you are running a commercial X server, you may
want to skip the section below on configuring the X server, but the
rest of the material covered is independent of the server you are
using.

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.