X Terminal via XDM



XDM Setup , XDM Chooser

XDM: The basic concept:

xdm is a "display manager", providing X login windows to users. The traditional use of xdm is to provide a graphical login on the local display on an X11 workstation, so that the user does not need to start up X "by hand".

However, xdm can also provide graphical X11 logins to remote machines, such as NCD Xterminals. The only requirement is that the remote machine speak X. To accomplish this, they use the X11 Display Manager Control Protocol, or XDMCP.

What we are describing here is configuring a cheap PC to act just like one of these Xterminals.

There are two distinct methods of using XDMCP, the "direct query", in which the X terminal directly requests a login window on a workstation, and the "indirect query", in which the X terminal contacts a "chooser server", which presents the X terminal with a menu of machines to log into. I'll discuss both of these in turn.

(If you don't care about the details, feel free to skip to the Setup section now.

Direct XDMCP Queries

The figure below shows a simple direct XDMCP setup, in which the machine xterminal is requesting a login window on xdmserver (for simplicity, we'll be using these same hostnames in all the direct XDMCP examples).


Figure 1. A direct XDMCP connection.

The process works as follows:

  1. The X terminal contacts the XDM server via the XDMCP protocol
  2. If the X terminal is authorized to connect to the XDMCP server, the XDM server starts up a login window which displays on the X terminal.
  3. A user logs in to the XDM server through the X terminal. All X programs the user runs in this session will be displayed on the X terminal.

Indirect XDMCP Queries

In an indirect XDMCP query, the X terminal is configured to contact a specially configured machine, the "Chooser Server" (called chooserserver in this example), which is configured to present a list of machines (in this example, workstation1 and workstation2) to the X terminal from which the user can select which machine to log into.

The basic technique is shown in the figure below:


Figure 2. An indirect XDMCP connection.

The process for an indirect XDMCP query is similar to a direct query:

  1. The X terminal contacts the chooser server via an indirect XDMCP request
  2. If the X terminal is authorized to connect to the chooser server, the chooser server starts up a "chooser window", which presents a list of available machines on the X terminal.
  3. A user selects a machine from the chooser list. The chooser server directs the X terminal to directly connect to selected workstation via XDMCP
  4. From this point on, the connect looks exactly like a direct XDMCP connection.

This all becomes more clear when we do an example.






XDM Basics , XDM Chooser

Setting up the X Terminals

Setting up the 486 PCs as graphical X terminals was fairly straightforward, consisting of just a few steps:

  1. Installing a minimal Debian Linux system on each PC
  2. Configuring each PC to start up X and query an XDM server to get a list of hosts to connect to.
  3. Configuring one or more XDM servers to provide "chooser" services to the X terminals.
  4. Configuring XDM and the chooser to be more aesthetically pleasing and useful.

I'll discuss each of these steps in turn.

Installing a minimal Linux system:

Since our existing Linux systems run Debian Linux we chose to use it for these PCs as well.

On each system, we installed just the basic Debian system from floppy, which provides a very bare-bones Linux system with networking support. No user accounts were created, since none are needed (since no users actually log into the machine itself). A complete list of installed packages necessary to run the X server is listed here.

Next, Debian packages of XFree86 3.3 were loaded on each system. We loaded the base X11 libraries, the X extensions, the S3 X server (since the PS/Valuepoints have 2-meg S3-based video card), and all the X11R6 fonts.

Finally, we installed a few additional packages for convenience, including basic networking utilities (netbase), ssh (to allow use to remotely log in through a secure channel), and nvi since the systems staff here doesn't like the default Debian text editor.

Configuring each PC to start up X:

The first step was configuring X to run locally on each PC. An XF86Config file was created for the machines using the standard 'xf86config' utility, with a couple of considerations:

  • The "Emulate3Buttons" option was enabled, since the mice that came with the machines are only 2-button mice.
  • While the 2-meg S3 card in the Valuepoints is capable of up to 1152x900x16bit resolution, we chose to run 1024x768x8bit, since it runs at a more comfortable refresh rate, better viewability on the 15-inch IBM monitors, and provides better compatibility with local applications than 16-bit color.
  • For added security, "DontZap" is specified so that users cannot inadvertently kill the X server.
  • We added additional SGI-defined colors to /usr/lib/X11/rgb.txt so that the X-stations could talk to our SGIs without errors.
  • You may wish to set up a font server somewhere.

Once we were satisfied with the configuration of the X server, we then tested if it could connect to a workstation running xdm (xdmserver in this example):

X -quiet -query xdmserver
which gives us the standard xdm login window for xdmserver:

standard xdm login window

So, we now know everything is basically working. If we just want the PC to talk to a single workstation, then we are basically done. The only remaining step is to make sure that X is started upon bootup. We can do this with a script in /etc/init.d/xterm.

On a Debian system, we install it with 'update-rc.d xterm defaults 99'. (The procedure for Redhat, Slackware, etc., is similar). We then reboot the machine to make sure it starts X upon boot.








XDM Basics , XDM Setup

Configuring an XDM server to provide a "chooser":

We've already set up a basic X Terminal. However, it can only talk to a single machine. If we would like it to be able to connect to a number of other machines, we'll have to have at least one machine in our network configured to provide a host "chooser" to our X terminals. In this discussion, the machine providing "chooser" xdm services is called "weber" (note that in this example "weber" is a Linux box, but it could be any xdm-enabled workstation).

The first step is to configure weber to provide the chooser to hosts that connect through an "indirect" XDM connection. This is controlled by the Xaccess file (located in /etc/X11/xdm on Debian machines, it may be located under /usr/lib/X11 or another location on other machines). Typically, the default Xaccess file on most systems is fairly well commented and includes a number of simple examples, so it's pretty easy to figure out.

Basically, you have to add a line to the file of the form

hostname CHOOSER host-a host-b
where hostname is the name of the host to provide the chooser to (it can be a wildcard such as "*" or "*.domain.name", the CHOOSER tells xdm to provide a chooser to these hosts, and the remainder of the line is a list of machine names to list in the chooser. If you use the special hostname BROADCAST, it will list all xdm-enabled machines on the local network.

So, if we want all machines to be given a chooser that allows them to select any machine on the local network, we'd make sure Xaccess has the line

* CHOOSER BROADCAST

However, in our system we have a number of machines in different subnets, so we can't rely on a broadcast to find them all. So we use

* CHOOSER machine list ...
instead.

Additionally, we can specify different lists for different machines. As mentioned previously we wanted to use one of the PCs as a graphical terminal for our headless SGI workstation (which runs xdm). So we have this machine, "console", be given a list of only the server machines:

console.me.umn.edu CHOOSER server1 server2 ...

The next step is to modify the X terminal to connect to the XDM server using an 'indirect' query. We first test it by logging into the X terminal PC, and starting X with

X -indirect weber
and we should then see the chooser come up:

Functional, but a little ugly, wouldn't you say?

So now that we know it works, we change our /etc/init.d/xterm script, replacing the "-query rayleigh" with "-indirect weber".