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 KVM.

This brief lesson makes the following assumptions:

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.

Xdm

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 host.

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.

X server

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).
id:5:initdefault:
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 storch.

Caveats

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 program (www.rdesktop.org). 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 and instructive.
However, it is provided with ABSOLUTELY NO WARRANTY OF ANY KIND.