![[no author]](../../common/images/white.gif){kind=small}
original in en Joel McCarty
The focus of this article is the setup and use of the X Display Manager. The X Display Manager runs as a daemon on a host machine and manages multiple X displays (remote or local) providing basic user session management analogous to init(8), getty(1) and login(1) on character based terminals. Also, xdm provides cleanup facilities for displays on which the X server is no longer running. One of the most valuable of xdm's features is it's ability to generate authorization information that can be used by the display server to control access based on host and account level schemes. Because of it's ability to spawn X session logins using standard authentication techniques, xdm is ideal for sites where a single machine is shared by multiple users running individually customized X sessions.
Scope
Although this column briefly addresses authorization under xdm, X Window security being a topic onto itself will be examined in more detail in next month's column. If you are interested in running xdm on a standalone system you can skip the XDMCP section and probably have a pretty decent canned setup that came with your distribution. If this is the case, you can most likely get by just checking out the customization and Running xdm sections as the rest of the article deals manly with networked environments and X terminal interaction. Also, if your are looking for a start to finish cookbook approach to setting up an X terminal environment I suggest referring to O' Reilly & Associates " The X Window System Administrators Guide" as it covers details of X terminal administration beyond the scope of this article.
Session management under X
In a traditional tty login a session is a user's login shell, under xdm a session is controlled by an arbitrary session manager; because in a windowing environment a user's login shell process does not necessarily have any terminal-like interface with which to connect. For session management in the X Windows environment we use the window manager as a "session manager" and when the window manager process terminates, so does the user's session.
xdm basic concepts
xdm is an Xclient that manages the first and last points of connection, control and coordination of a user's session. Xdm keeps track of which X servers are available for connection by reading the Xservers file and listening on the XDMCP port for other servers requesting management. When xdm is given management of an X server it sends a login box to the server display and waits for user input. Once a user enters a name and password they are authenticated using the same mechanisms as a standard tty login. Now, xdm executes a series of shell scripts that start the user's desired Xclients. Now a normal X session is in progress, when the user logs out of this session xdm closes all connections and resets the terminal back to the login state, ready for a new session.
Besides the security features, remote capabilities and convenience, xinit is considered obsolete via the X Consortium ( now The Open Group ) with all new functionality being built in to xdm. Xdm provides a way for administrators to configure environments system wide. Also, xdm is the only way (that I'm aware of) to share a machine between multiple users without have to kill the X server and restart for each new user else, share a common desktop settings.
xdm is configured through standard ASCII text files. Global files are traditionally located in /usr/lib/X11/xdm or /etc/xdm while local files are located (where else?) in each user's home directory. Of significant interest is the fact that the xmd-config file can state an alternate location for all other files and it's own location can be explicitly stated when executing xdm using the -config parameter, thus systems with a canned xdm setup can easily be modified leaving the stock installation in place. Below is a brief description of each file and a commented example (when appropriate).
Global Files
xdm-config
This file specifies the location of all other configuration files ( if settings other than the default location are to be used) and sets commands for xdm setup, startup, reset and initial script. In the example below all additional files are specified as being located under /etc/X11/xdm so I can leave the default files in /usr/lib/X11/xdm unmodified.
Xservers
A list of servers to be managed by xdm. At minimum this file should include the local display server. NOTE - this file is only reread after a session terminates or xdm receives a SIGHUP signal. To send SIGHUP signal to xdm find it's pid and kill that process. I.E.
# ps -a | grep xdm
2639 ? R 0:09 /usr/bin/X11/xdm
# kill -9 2639
Below is an example of an Xservers file for use with a standalone machine...
Xsession
Initial startup script used by each X session.
Xresources
Defines resources to be loaded via xrdb(1) for all servers managed by xdm.
xdm-pid
File containing process id of xdm ( for informational purposes only, do not edit)
xdm-errors
Error log file for xdm.
Xaccess
Configures access control for XDMCP (X11R5 and later). This file only defines access permissions for XDMCP queries.This file will also allow you to define macros to logically group sets of related hosts. Server access control is set using the DisplayManager*authorize resource set in the xdm-config file. For more information on XDMCP setup and examples see the CHOOSER section below.
GiveConsole
A shell script utilized to change ownership of the console to the user. Unless you have a very good reason leave this and the take console scripts with the default settings as shown below
Take Console
A shell script that changes ownership of the console back to root (X11R5 and later). Once again leave this one at the original settings
Xsetup_0
A shell script used for display setup for local console server. (X11R5 and latter) Sets up the xconsole which is a terminal window that displays system generated messages between logins.
Local Files
~/.xsession
User-specific startup script called from the global Xsession script. Unlike ~/.xinit this can be written in any shell (~/.xinit must be a Bourne or Bash shell script)
~/.Xresources
User-specific resources read by the global Xsession script.
~/.xsession-errors
Error log file for users individual X session.
~/.Xauthority
Contains authorization information for users server.
XDMCP
The X Display Manager Control Protocol was first introduced in X11 release 4 to solve various problems between xdm and X terminals. Prior to XDMCP the only way xdm was aware of servers available for management was through reading the Xservers file. Since the Xservers file is only read at xdm's startup problems developed when X terminals where powered off then back on. Basically anytime n X terminal was powered up after being off it required a SysAdmin forcing xdm to re-read the Xservers file by sending the SIGHUP signal to xdm via it's process id.
XDMCP allows servers to talk to xdm without it have explicit prior knowledge of the server. Under XDMCP the host listens for requests (in any of the three supported communication modes) on the XDMCP port and when it receives a management requests it spawns a copy of itself and transmits the login screen to the terminal.
Communication Modes
XDMCP allows three modes of communication to servers requesting management that are not explicitly listed in the Xservers file; these methods are DIRECT, INDIRECT, or BROADCAST.
DIRECT mode a server is making a non-specific request for management on the network. The first xdm process to respond to a DIRECT query becomes the server's manager. An INDIRECT query results in the X terminal receiving a chooser box which list all host available for connection and lets the user decide which host should provide management. INDIRECT mode is especially useful in a multiple host environment. To implement INDIRECT mode you need to use the CHOOSER keyword when setting resources in the Xaccess file. Another way to implement the chooser is to use BROADCAST mode in conjunction with the CHOOSER resource which sends a broadcast message to all hosts on the network and allows the user to choose among them.
Chooser
When using X terminals that do not offer a host menu at startup the chooser programs can be used in conjunction with BROADCAST or INDIRECT modes. To enable the chooser program use CHOOSER as the first entry in the indirect host list of the Xaccess file.
eng*.odhs.dsd.com CHOOSER BROADCAST
allows all engineering terminals at odhs.dsd.com to use a chooser box listing all other hosts available. A more likely scenario would be that all the terminals in the engineering department have a set list of hosts they should be allowed to connect to, this could be better accompolished by utilizing the INDIRECT mode.
eng*.odhs.dsd.com CHOOSER dsdapps.odhs.dsd.com dbsrv.odhs.dsd.com test.odhs.dsd.com
The above setting would allow all terminals in the engineering department to access the application, database and test servers via a chooser menu.
The Xaccess file will also allow you to define macros lo logically group related hosts. Following is an example using macros with the previously used settings for the engineering depatment.
%ENGHOSTS dsdapps.odhs.dsd.com dbsrv.odhs.dsd.com test.odhs.dsd.com
eng*.odhs.dsd.com CHOOSER %ENGHOSTS
The chosers visual settings can be set by modifying it's defaults in Xresources file(s).
To test your xdm setup without rebooting, from the console issue try
$ init 5
this should launch the system to run level 5. xdm is usually set up to start automatically when the system enters run level 5. If switching to run level 5 does not start xdm take a look at /etc/inittab it should tell you which run level on your system starts xdm ( Slackware distributions sometimes use run level 4 for xdm but most other distributions I've used tend to stick with 5). You should now see the xlogin widget requesting account name and password and be able to login and test your various settings. If you are certain you are at the correct run level and xdm still does not respond as expected skim through the troubleshooting section below. Otherwise, from this point you can tweak the individual settings (check out the customization section below). Once you have xdm configured, you can modify the /etc/initab file to change the default run level at bootup to 5 (or equivalent run level for xdm on your system). The modification on my machine is as simple as changing
#/etc/inittab
id:3:initdefault:
to
id:5:initdefault:
this starts Linux in run level 5 by default which in turn automatically starts xdm each time the system boots up.
Troubleshooting xdm
If xdm is not functioning as expected the first place to look is ~/.xsession-errors. This local error log contains errors generated only under your account and is therefore more specific than the system logs. Below I've outlined some potential "gotcha's" and they're potential fixes.
Login box doesn't appear on screen
This is most likely an error in the configuration files, you are testing this before making it the default system run level, right?
You login successfully and the login box reappears
Your .xsession file may not be executable. Try logging in end but, press CTRL-RETURN after your password instead of enter. This will bypass the .xsession script and give you a single terminal window from which you should
# chmod +x .xsession
and try again.
After logging on, the screen flickers and the login box reappears
Use the method stated in the above scenario to bypass your .xsession file during login and make sure the last command in your .xsession file starts in the foreground.
Conclusion
I hope this article has convinced you of the power and extensibilty of the X Display Manager. If you're looking for more in depth information regarding xdm please check out the links below for additional information. Next issue we'll delve into the oft overlooked topic of X Window security. Please feel free to mail any questions and comments to jmccarty(@)theshop.net
For more information: