Linux-Based X Terminals with XDMCP

Want to get some use out of your early 90s vintage PC, the one
barely powerful enough to run Windows 3.1? Need to
outfit a group of users with workstations on a budget?
Tired of administering a homogeneous workgroup from afar? Want to introduce Linux to a group of
Windows or Mac users with the least amount of
resistance? Can't stop tinkering with the
oodles of options Linux offers? XDMCP may be for
you, even if you answered yes to even one of these questions.

The X display manager control protocol (XDMCP for
short) provides a means for a user sitting at one
(client) computer running X to communicate with another
(server) computer running an X display manager. Once a
connection is established, the user can log in and run
programs as if the user were sitting at the remote
computer. The station where the user sits often is
referred to as an X terminal, which essentially is a
window into the server. All of the software resides on the server,
all of the processing is done on the server's CPU, and all of the files to be accessed
reside on the server.

So, for those of you trying to reduce administration hassles, this means you have
to administer only the servers. The clients' software
remains the same. For those trying to get some use
out of old equipment, the speed of the client computers
and the size of their hard drives is nearly irrelevant.
Even my old Pentium 120 with a CPU upgrade to 180 MHz, 32MB of
RAM and a 1GB hard disk provides more than enough
muscle to be an X terminal. And, for those trying to
outfit a workgroup on a budget, as many as five or six cheap
computers can be configured as X terminals for every
expensive workstation configured as a server. This
would require a fast local network, however. Finally,
for those trying to introduce Linux to Windows and Mac
users, the only necessary intrusion into their machines
is the installation of an X server, and free ones exist.
Basic Configuration
XDMCP is a communication protocol with the power to
deliver all the items listed above. A word of
caution is in order, however. XDMCP is an inherently insecure
protocol. Although technologically nothing is
standing in the way of running XDMCP between two
computers on the Internet or on an untrusted network, it
should never be done. It is too easy for hackers to
snoop and grab such critical information as usernames and
passwords transmitted over the connection
without encryption. XDMCP should be run across only a
trusted network. If you need to provide an X terminal
across an untrusted network, a slower, slightly less
convenient way to do this is mentioned in the security section.

Assuming you have not been scared off, to begin
configuring XDMCP, be sure the computer to
become the X terminal and the one to become
the server are connected over your network. The
simplest way to check this is to ping one from the
other. If you can ping in both directions, you are
ready to begin the configuration.

If you are trying to get some use out of old hardware
or trying to outfit a workgroup or lab on a budget, the
most powerful machine(s) is your server(s). In the
case of bringing the power of Linux to Windows or Mac
users, the Linux machine(s) is your server(s). For
now, I assume you are configuring only one server.
Multiple server set up is discussed later.

The server must be running some display manager, the
standard being xdm. Both gdm and kdm, respectively the
GNOME and KDE replacements for xdm, are shipped with
many distributions and offer preconfigured interfaces that are
likely to be sexier than what is offered by xdm. Operationally, they all
are capable of providing X terminal services. In
fact, if your server boots into a graphical login
screen, you already are running a display manager. To
find out which one, login and issue the command ps -A |
grep dm. The results should be something like

634 ? 00:00:00 cardmgr
857 ? 00:00:00 gdm-binary
889 ? 00:00:00 gdm-binary

which means you are running gdm. If your computer
boots into a text login screen, you either can
reconfigure it to boot into a graphical login or
run a display manager from the command line
after logging in as root. This second option
is useful only as a temporary solution while you
are experimenting, however.

If you intend to use the machine as
an XDMCP server, it's best to configure it to run a
display manager upon booting. This is done by modifying
/etc/inittab. The default run level is set in the line
containing initdefault. It should read

id:5:initdefault:

Once you have made this change, you may reboot or
issue the command telinit 5 to get a graphical login.
Be sure X is set up with a resolution less than or
equal to the resolution to be used on the X terminals.

At this point, the impatient may skip the rest of this
section and configure an X terminal. If your
distribution shipped with XDMCP enabled and configured
to serve fonts and no firewall gets in your way, you
should have a fully functional XDMCP server. For the
patient, simply continue reading and reconfiguring or
verifying that XDMCP is configured correctly.

At this point, I assume you are patient or you're
back here because your attempt to connect an X terminal
failed. One likely reason for a failed connection is
the firewall on the server or, worse, somewhere else in
your network. To temporarily disable the firewall on
the server while you attempt to configure XDMCP, issue
the command ipchains -F (or iptables
-F) on the server. This eliminates the firewall altogether. To be more
selective about your firewall policies, you may try the
ipchains (or similar iptables) command

ipchains -A input -p udp -i $extint --dport 177 -j ACCEPT

In addition, make the following changes (if necessary) to
the following xdm configuration files. In
/etc/X11/xdm/xdm-config, change the line
DisplayManager.requestPort: 0 to
!DisplayManager.requestPort: 0 (that is, comment it out)
so that the server can listen for XDMCP connections.
In /etc/X11/xdm/Xaccess, change the line #* # any host
can get a login window to * # any host can get a login
window so others can access xdm. If you are not using kdm or gdm as your display
manager, you are done with this part. However, if
you are using kdm, you must edit kdmrc as well. Under
Red Hat, this file is located in /etc/X11/xdm. In the
[Xdmcp] section, set Enable=true and uncomment the line
Port=177. If you are using gdm, you must make the same
modifications to gdm.conf, which is located in
/etc/X11/gdm under Red Hat.

Configuring an X terminal simply amounts to installing
an X server and running an X query. No window manager
or desktop environment are necessary. This is why the X terminal's
hardware is relatively unimportant, except perhaps the
network interface card. There are at least three ways
to configure an X terminal to utilize XDMCP. One way is
to setup a dummy terminal to run X with no window
manager and no applications and then have the XDMCP
server push a login screen onto the terminal. This is
covered in
this useful
mini how-to.

I, however, will stick to configuring a not-quite-so-dumb X
terminal. This means the X terminal must have some
operating system with a configured X server installed.
In case of Linux, Windows or Macintosh, an
implementation of XFree86 is available free of charge. For
Linux, installing XWindows is an option that should be chosen when the OS is installed. For
Windows, consider installing
Cygwin with the (optional) XFree86base
package and dependencies installed. For Mac, consider
installing
XDarwin,
an implementation of the XFree86 server. X servers are
available for many other platforms as well, and any one
is sufficient to run an X terminal.

Once you have an X server installed, all you need to do
is run it with a query option. Three types of queries are
available. If you are running only one
XDMCP server, it is best to use a direct query. This is
done from a non-X shell, not an xterm. If you are
running Linux or UNIX, you should configure the machine
to boot to a text login. If this already is the case,
you are all set. If not, this is done, under Linux, by
modifying the default run level in /etc/inittab. The
default run level is set on the line containing
initdefault. It should read

id:3:initdefault:

Once you have made this change, you may reboot or
issue the command telinit 3 to get a text login. Log in
as any user and issue the command X -query
my.XDMCP.server, where my.XDMCP.server is either the
name or IP address of the XDMCP server. If you are
running windows and have installed Cygwin, from the
Cygwin bash shell, issue the command XWin.exe -query
my.XDMCP.server. If you are running Mac OS and have
installed XDarwin, from a terminal issue the same
command as used under Linux/UNIX. You should see the
graphical login window of your XDMCP server. If you are having font issues,
consult
this excellent
how-to to find the
necessary server configurations to resolve the issue.
Customizing the Login Screen
The display manager login screen and chooser interface
are fully customizable. If you are running gdm, you may
use the graphical setup utility gdmsetup or modify the
text file /etc/X11/gdm/gdm.conf. If you are running
kdm, modify /etc/X11/xdm/kdmrc. If you are running xdm,
start with modifying /etc/X11/xdm/Xresources. If you
don't find everything you want to customize in these
files, look at the other files in /etc/X11/xdm/,
for example, XSetup_0 or xdm-config. I expect most
people choose to use gdm or kdm, so I won't go
into details on xdm customization. Also, because gdm
offers a graphical customization tool, I scratch only
the surface of customizations, focusing on kdm
customization under Red Hat only.

Regardless of which display manager you run, you may want to consider customizing a few things.
For example, you may want your own background image
and your own welcome message to appear on the login
screen, and you definitely want to prevent users from
shutting down the server through the login window. For
kdm users, the background image is presented on the
login screen by an auxiliary program called xsri. Under
Red Hat, the script /etc/X11/xdm/XSetup_0 checks for the
existence of the program and the associated file
/etc/X11/xsrirc. If both exist, xsri is run and the
graphic indicated in /etc/X11/xsrirc is displayed on
the login screen. So, if you want to change the
background image, simply change the graphic file listed
in /etc/X11/xsrirc. To change the welcome message, find
the GreetString option under the [X-*-Greeter] section
of the file kdmrc. You may set this string equal to
anything you like, but long messages may not display
fully or may distort the appearance of the login
window. Macros may be used in the GreetString too. For
example, the default greeting is "Welcome to %s at %n"
where %s is expanded into the operating system and %n
is expanded into the node name (usually the hostname
without domain name). Other macros are available and
are listed above the GreetString line in kdmrc.

Finally, and most importantly, you need to keep
regular users from shutting down the server. Allowing
them to shut down is dangerous because they may shut it
down while other users are working on the same
machine. Again, inside the file kdmrc, find the
AllowShutdown option under both the [X-*-Core] section
and the [X-:*-Core] section and set them both to Root.
This change requires the root password in order to shut
down the machine from the login window. Additionally,
when a user logs out of a session, the shutdown option
does not appear in the ensuing dialog box. However, you
may prefer to set these options to None, in which case
the shutdown button will not appear at all in the login window.
Multiple Server Setup
Multiple servers may be set up in exactly the manner
described in the section on configuring a server, and
they can be accessed by X terminals in exactly the
manner described in the section on configuring an X
terminal. However, this requires the user to pick a
server to login to and to know its name or IP address.
A more effective method of managing multiple servers is
to run a chooser and have users of X terminals submit
indirect queries.

To begin, configure each server as described
previously. Then, pick one machine to run a chooser. On
this machine, modify the file /etc/X11/xdm/Xaccess in
one of two ways. The easiest way is to uncomment the
line * CHOOSER BROADCAST. When an indirect query is
received, the chooser sends out a broadcast query
and displays a list of machines that responded to the
query. The X terminal user then may select to log in to one of these
machines. This setup does not work in all
environments, however, and you may not want to give users access
to all servers on your network.

To be selective as to which servers are reported by the
chooser, comment out the line * CHOOSER BROADCAST by
putting a # at the beginning and uncomment the lines
#%hostlist host-a host-b and #*
CHOOSER %hostlist. Then, replace host-a
host-b with a space-separated list
of all hosts that you wish to appear in the chooser. This
way, the chooser can send direct queries to each
machine in the list and report the results to the chooser.

Finally, to see the chooser from an X terminal, run X
with the option -indirect my.XDMCP.chooser, where
my.XDMCP.chooser is the name of the machine configured
to supply a chooser. Under UNIX, remember the command
to run X is X and under Cygwin it is
XWin.exe.
Further Information
Advantages: the main advantages of running XDMCP are clear from the
goal you wish to meet by running it. However, there are
some disadvantages, one big one being the lack of
security. Additionally, access to the
X terminal's sound card, floppy drive, CD-ROM drive,
scanner and any other local hardware besides the
keyboard, mouse and monitor is difficult at best. I do
not have a reasonable solution to offer on this issue.
Perhaps someone can offer one in a future article.

Security: as stated earlier, XDMCP is an insecure protocol.
However, if you require X terminal services over an
insecure network, there is at least one option. Instead
of setting up your server to run XDMCP, configure it as
an SSH (secure shell) server. Then, from the X
terminal, start an X session running nothing but an
xterm, not even a window manager. From this xterm,
issue the command ssh -X loginname@ssh.server, where
ssh.server is the name or IP address of the ssh server
and loginname is your login on the server. The -X
enables X11 forwarding over the secure connection.
After logging in, issue startkde to begin a
KDE session or gnome-session to begin a GNOME session.
Alternatively, you may run a full blown desktop
environment on the X terminal, run an xterm there and
issue the command ssh -X loginname@ssh.server
command
where command is the command/program you wish to run.
This allows you to run a single program at a time on
the remote machine rather than on a desktop environment.

Installing and running an SSH server and client should
be straightforward. For example, Red Hat ships with an
optional sshd (server) package and the client is
installed by default. For Cygwin, an OpenSSH client is
an optional package. For more information than you
probably care to know about SSH, see
www.openssh.org
or read the man pages on SSH and sshd.
References
XDMCP How-To
by Thomas Chao

XDM-Xterm Mini
How-To by Kevin Taylor.

Much of the information for this article was
taken from these two documents. Additionally, each
how-to contains a list of more reference materials.

Leon Brin has been a member of the mathematics department
at Southern CT State University for three years and a Linux
enthusiast for five. He welcomes your comments at
brin@southernct.edu.