The Unix Poor Man's KVM
by James R. Williams Zavada, May 2002
The X Display Manager (xdm) is a versatile program that allows you to
do all sorts of wonderful things with an X server. I use it to set up a
virtual KVM (Keyboard Video Monitor) switch to save
a bit of money. Most of the machines on my LAN run headless
(without keyboard, mice or monitor), and I've set up a couple of machines
with monitors, keyboards and mice to run as master consoles. These
master consoles have access to the native X windows desktop running
on any Unix host on the LAN, including the headless ones. This
is a description of how I configured each Unix machine on my home network
to use xdm and the X server to create my Unix Poor Man's
This brief lesson makes the following assumptions:
- DNS or an adequate substitute is already set up and running on your
LAN (ie. named or /etc/hosts).
- Each Unix host machine (or at least the master consoles) on
your LAN already has a configured and working X server supplying your
- Your LAN is secured against intrusions from the WAN or Internet and
you have a significant amount of trust in the users on the LAN.
- You are familiar with the basic system administration of all the Unix
hosts on your LAN, that is, you know how to use man pages and your
favourite text editor, are familiar with the underpinnings of your
X-windows configuration and administration, are familiar with each Unix
host's implementation of the init service (either SYSV-style, BSD-style,
or some hybrid thereof) and how to automate service startup upon booting.
The basic idea is that we are going to configure xdm
on each machine so that it allows you to choose which machine you
wish to login to, and to configure the X server on the master consoles
so that it uses the local xdm to establish an X session.
Then, we need to set up each Unix host so that it automatically starts
xdm. Whether or not the X server is started automatically is
a matter of individual preference. Because I often like to run experiments,
I find it easier to troubleshoot my machines if I don't automatically start
the X server, but your needs may lead you to prefer otherwise.
The first step is to configure xdm. Where these
files are located, as well as their names, is implementation-dependant.
As an example, on current versions of RedHat Linux they are located
in /etc/X11/xdm/, but SGI's Irix 5.3 places them in /var/X11/xdm/.
There are four files we need to modify (Make sure you've made
backups before you make changes!): xdm-config, Xresources,
Xaccess, and Xservers.
In xdm-config, we need to make sure that the
DisplayManager.requestPort is either commented
out or set to the default X Display Manager Control Protocol (XDMCP)
port, which is 177. This ensures that xdm will be ready and listening
for X display management requests. As well, for safety's sake, I
set the DisplayManager*terminateServer option to false.
Rather than having xdm kill my X server when I log out of
an X session, I want it to allow me to start a new session on a chosen
Next, we are going to modify the Xresources
file. Keep in mind that this step is entirely optional, and a matter
of personal preferences, so modify this step to suit your tastes.
First, I commented out all the Font settings. I didn't like the
settings on any of my Unix hosts, and commenting them out makes xdm
use system defaults. This saved me the time it would take to hunt down
fonts I liked and experiment to find the right size, which I can do on
a rainy day. I also modified the key resources for the xlogin to
add some extra utility: One of the very few preferences that I take from
the Microsoft world is that I like to use the TAB key when entering login/password
information at the X windows login window.
The next step is extremely important. The Xaccess
file is how xdm determines access to the various hosts.
The idea is that we want xdm to do two things. First, we
want every host on the LAN to be allowed to choose from amongst all available
X servers running on all other hosts. Second, we want to allow any host
to be allowed to login to the current host as well as all the others.
For the first, we make sure the following line is added to the Xaccess
file: * CHOOSER BROADCAST # xdm allows all hosts to ask for a list of available hosts
For the second, we add the following line to the Xaccess file:
* # xdm allows all hosts to login to this host
Make sure that any other lines in the Xaccess file are commented
out, unless you know that you want them there for some particular reason,
otherwise you are likely to munge things.
The final configuration change is to the Xservers
file. Here, we do not want xdm to automatically start/use the
local host's X server. If it does, it only allows us to login to the
local host, whereas we want to choose which host we will use to login.
Therefore, we comment out any local X servers configured in the Xservers
file. If you have any X terminals or machines acting as
dedicated X terminals, do not comment out those lines or the X terminals
will not work. Having done this, the xdm configuration is complete,
and we now have to make sure the Unix host starts up xdm every
time it reboots. This section of our project depends upon how your Unix
implementation's init service works. The BSD-style implementations
vary widely in terms of what services are initialised by which initscripts,
while the SYSV-style is very uniform across most of its implementations,
so we'll approach this from a SYSV perspective. If youe a BSD-style machine,
the onus is on you to determine how to do this on your system. SYSV's init
uses a configuration file called /etc/inittab to determine which
services/scripts to initiate, and does so based on runlevels. For our
purposes, we want xdm to be run during all the runlevels that allow active
network connections (usually 2-5). To do so, we'll add a line similar
to the following to /etc/inittab:xd:2345:respawn:/usr/X11R6/bin/xdm -nodaemon
If your /etc/inittab already has a line that activates
any other display manager (such as RedHat's prefdm, Gnome's gdm, or
KDE's kdm), you'll want to comment it out unless you prefer to make that
one do what is needed. If so, itl be your turn to write one of these.
To get init to actually run the new entry, use your implementations method
of getting init to re-read /etc/inittab.
Once we have each Unix host running our newly configured
xdm , we can then move on to configuring the X servers
on our master consoles. Now we decide if we want to start the
X server manually from the command line, or have it started automatically
for us at system boot. If we want to start it manually, we can either
start the X server itself, or via the startx or xinit programs.
As we are only going to cover the former, you'll have to explore the latter
on your own. The following example assumes that the host name of the
master console we are currently working on is storch :
X -indirect storch
This starts the X server and has it send a query for any hosts
that the xdm running on storch finds available on the
LAN. Xdm then responds with a list of hosts to choose for
logging in. Starting the X server upon system startup only takes a little
more work than doing so from the command line. On storch , a SYSV
machine, the easiest way is to add a line to /etc/inittab as follows:
xs:5:respawn:/usr/X11R6/bin/X -indirect storch
We also need to change the line that sets the default runlevel
as follows (remembering that on this particular Unix implementation
runlevel 5 is for a X windows environment upon startup).
We then tell init to re-read /etc/inittab and
we can restart storch. After the machine reboots, we get an
automatic X server, which asks the xdm running on storch
to give a listing of available hosts to choose for logging in. At this
point, we're now ready to use storch as our new master console
and as long as all the headless machines are properly configured
and running, we will get a listing of hosts to choose from, including
For some reason I've yet to debug, the version of X windows
that comes with RedHat 7.2 Linux (XFree86 4.1.0) has a bit of wierdness about
it: Although the host running RedHat 7.2 will be listed amongst the available
hosts, it will be listed as "this account is currently not available",
and yet if you choose that particular host you can still log in and get
an X session.
Food for Thought
Because xdm and X windows are so versatile, there are
any number of customizations that can be made to fit your particular
environment. In keeping with our Unix Poor Man's KVM topic, here's
something you might want to try, providing you use a really beefy machine
as your master console: On Unix implementations that have virtual
consoles (such as Linux and FreeBSD), the X server allows you to pick
which virtual console you use to display X windows. You can therefore
have multiple X servers running on multiple virtual consoles, and thus
have access to several machines at a time from the same master console.
However, each X server is going to eat up a large chunk of memory,
hence the need for the powerful machine.
Something else to consider is that there are both commercial
and free X servers that run on the Microsoft Windows platform. For those
of you who like to have a high-end PC running Windows for games and the
latest and greatest virtual toys and commodity software, you can eat your
cake and still have it by using your Windows box as the master console.
And if you're into doing some extreme Windows hacks, I'm sure there's
a market out there for a "Windows-ized" xdm. You could take its source
( www.xfree86.org), port it to Windows,
and merge it with something like the rdesktop
I know a number of professionals, including myself, who would
love to be able to use their Unix workstations to access all those Windows
desktops/servers we have to deal with in the course of our jobs.
Lots o' Links
This information is provided in the hopes that you will find it useful
However, it is provided with ABSOLUTELY NO WARRANTY OF ANY KIND.
Copyright © 2002 by James R. Williams Zavada