InDepth: Configuring xdm
Have you ever wanted to access your workstation's desktop remotely? How about accessing your desktop on a server machine? That's just the sort of problem I needed to solve recently. I was responsible for setting up and managing a group of Linux servers. By the fifth trip to the lab to access a GUI console for various reasons (badge access, key codes, flights of stairs, etc.), it was time to find a solution that would allow me to use my workstation to access X desktops on various server machines.
Some may think that the standard X tools used to handle remote sessions would be sufficient to solve my problem—something like:
telnet host1 export DISPLAY=mywkstn:0 gnome-session
(or some other session manager).
However, the solution I was looking for needed to provide more than just basic functionality. It needed to be more administrable, appear more automatic and be easier to use for developers new to Linux. There are pitfalls associated with authentication, session management, etc., that require some knowledge of the way X works. For example, I often forget to type xhost +host1 when using remote X clients. I also have been on the receiving end of a puzzled look when trying to explain the xhost authentication scheme to a Linux newbie. Since this development project was not the time to teach developers the basics of X, I was looking for a solution that fulfilled all of these requirements.
A couple of solutions would allow me to manage the X sessions more easily. The solution I chose for this project was the X display manager, or xdm, although another popular solution is vnc. I chose xdm over vnc for two reasons. First, vnc has a server-side requirement to have a dæmon running for each shared desktop. Second, I already had X server software installed on all of the workstations and didn't see the need to install additional client software. Other choices are kdm and gdm, part of the KDE and GNOME packages, respectively.
X is the graphical support system used in most UNIX environments. If you are using GNOME or KDE on your Linux desktop, then you are making use of the X Window System. It is defined and maintained by the X Consortium (www.X.org). Most Linux users use an implementation of the X Window System offered by the XFree86 Project (www.xfree86.org). xdm is a display manager that enables flexible session management functionality. While xdm is usually thought of as “that GUI logon screen that auto-starts my X stuff”, it is actually much more powerful, as we will see.
In the X world, the terms client and server can get a little confusing. Specifically, an X server is the application that controls the keyboard, mouse and display resources. A client is an application that makes requests for the server to perform actions on its behalf (i.e., display a window with some set of specified characteristics). This is a little different for those of us used to thinking of applications running on our workstations as clients.
xdm uses the X Consortium's X display manager control protocol, XDMCP, to communicate with the X servers. This allows X servers to obtain session services from servers running xdm. Three types of queries can be sent by X servers:
Direct—asks the named host directly to display a login screen.
Broadcast—broadcasts a message to all hosts on the network, and the first to answer offers the login-processing services.
Indirect—contacts a named host running xdm and asks it about known hosts with which it may communicate. The xdm server will present a list of available servers willing to manage an X session. The X server will eventually end up communicating directly with the selected host to obtain login-processing services.
One of the initial reasons xdm was created was to allow for management of X terminals. These devices are basically a display, keyboard and mouse with embedded X server software; all intelligence is located on a server in the network. xdm was used to push login screens and manage sessions for these devices. Several years ago these devices were popular because access to UNIX workstations was limited. Users who wanted to access graphical desktops at their desks were either lucky enough to have a UNIX workstation at their desk or required one of these devices. Lately these devices have become less popular and are being replaced by PCs running X server software, such as Linux and other Unices (Solaris x86, xBSD, etc.) or Windows (running Hummingbird Exceed or the like).
When using xdm to manage these X sessions there are some configuration gotchas. At first glance, it may appear that if you configure xdm (in order to take advantage of XDMCP), you get either a local X server started (i.e., the console goes into graphical mode when xdm starts) or, if you disable the local display in xdm and use startx, it doesn't give you access to the chooser. The configuration described here allows any XDMCP client to access the Linux server desktops (subject to X security provisions, of course). It also demonstrates one way to configure xdm in order to get both a local X desktop and access to other server desktops from the workstation.
Security and access control are managed by xdm but are beyond the scope of this article. xdm should only be used in controlled environments. In addition, incoming port 177 should be blocked on all firewalls. If you're interested in X security issues, the following man pages are a good place to start: xdm(1), xauth(1), Xsecurity(7), lbxproxy(1)--Low Bandwidth X proxy, xfwp(1)--X Firewall Proxy, and ssh(1) and sshd(8) man pages, specifically regarding X11 port forwarding.
xdm is highly configurable; the following is only one way to configure it in order to accomplish a specific goal.
On my Red Hat 7 system, xdm lives in /etc/X11/xdm. Its main configuration file is xdm-config (see Listing 1).
xdm's configuration files are in X resource format. There are resources for the configuration of the locations of various files. We are interested in the files pointed to by the resources servers, accessFile and resources. The adventurous will be interested in the session and DisplayManager._X.setup, where X is the display number.
Notice that DisplayManager.requestPort:0 is commented out. This resource specifies which UDP port to use to listen for XDMCP requests. If it is set to 0 (as is the default), then XDMCP requests are ignored, and xdm only manages local displays (see Xservers file). We comment it out so that xdm will listen on the default port (USP port 177).
My Xservers file looks like this:
#:0 local /usr/X11R6/bin/X
If this line were not commented out, then I would get a graphical login screen every time I started xdm. That is, it would start and manage a local X server on display 0 by running the command /usr/X11R6/bin/X. What we want to be able to do is select the host that we will connect to. We accomplish this using the Xaccess file:
#any indirect host can get a chooser * CHOOSER BROADCAST # # If you'd prefer to configure the set of # hosts each terminal sees, # then just uncomment these lines # (and comment out the CHOOSER line above) # and edit the %hostlist line as appropriate # #%hostlist host-a host-b #* CHOOSER %hostlist #Although the Xaccess file is a very flexible tool, we will only be using it to launch the chooser (indirect mode). The chooser is a little X application that displays a list of available hosts on the network, allowing us to select the one to which we would like to connect. I like to use the BROADCAST option because new hosts show up in the list automatically. Some may prefer to name the hosts specifically, as shown using the %hostlist macro. This method is sometimes required, especially in larger networks where the broadcast doesn't reach all desired hosts.
If you are interested in a finer level of control, you can use a list of servers instead of BROADCAST. This will allow you to specify the list of available hosts directly.
If you want to configure xdm to handle requests from different X servers in different ways, you can specify a hostname or host list instead of *. Examples of this follow.
The following lines tell xdm to handle all queries from either host-a, host-b or host-c itself (Direct mode):
host-a host-b host-c
To tell xdm to send indirect queries from host-a to server-a or server-b, type
host-a server-a server-bIt could also be written
%hostlist server-a server-b host-a %hostlistYou can set up xdm to handle indirect queries using the chooser (our preferred method). In our next example, host-a gets a chooser window containing a list of all hosts that answer the BROADCAST, while everyone else gets only the list specified by %hostlist:
%hostlist server-a server-b host-a CHOOSER BROADCAST * CHOOSER %hostlist.Finally, to finish up the basic functionality, we can look at the Xresources file. I left mine with the defaults, but some might want to customize the look and feel a bit. In this file you can change colors, fonts and other style options. I've found the Chooser*geometry resource to be the most useful because it allows you to set the size of the chooser application window.
You can configure some administrative functions in xdm-config as well. Things like DisplayManager.errorLogFilelogfile will set the location of the log file. This log file contains the stderr output of xdm, Xsetup, Xstartup, Xsession and Xreset scripts.
Upon successful logon-process completion, xdm launches the script file specified in the session resource. This allows users to customize the behavior of the X sessions. Administrators will most likely want to check out the Xsession script. Users will want to create a $HOME/.xsession or $HOME/.Xclients file to customize the behavior of the session manager (i.e., start a window manager, a clock, etc.).
In order to test our configuration, we need to find X (which X). On my system, it's in /usr/X11R6/bin/X. In any case, you should end up seeing a logon screen. To test direct mode you would type
/usr/X11R6/bin/X -query remotexdmhost
For indirect broadcast mode type
/usr/X11R6/bin/X -broadcastAnd for indirect mode using the chooser, type
/usr/X11R6/bin/X -indirect remotexdmhostOnce these were working, I created the /etc/rc.d/init.d script to auto-start and auto-stop the xdm service. See the article on using the chkconfig utility in the April 2001 Linux Journal for more information.
Then, I created the following scripts to make life simple for my users. On their workstations, I create a file named /usr/bin/X11/startx.xdmcp. If the host is called “wkstn1”, then the file contains
#!/bin/sh /usr/X11R6/bin/X -indirect wkstn1
where hostname is the name of the xdm server (in my case the workstations are both an xdm server and an X server).
Next, I entered
mv /usr/bin/X11/startx /usr/bin/X11/startx.original chmod 755 /usr/bin/X11/startx.xdmcp ln -s /usr/bin/X11/startx.xdmcp /usr/bin/X11/startx
This allows any user who may be used to logging in to their workstation and typing startx to get a console, to instead receive a list of available hosts to log in to (including their own workstation).
To recap, we configured the workstations and servers in the network to use xdm, XDMCP in indirect mode and the chooser in order to allow users to select the server they wish to use to manage their X session. This is an administrable solution allowing fine control over X sessions. It is also easy to use, in that it provides users a menu of hosts willing to manage their X session.
If this type of access is required from platforms such as Windows, and you don't want to buy or install an X server on your workstation, then vnc may be an alternative for you.
