News    Archives    Map

by Joel McCarty <jmccarty(at)theshop.net> Content: Introduction Why use xdm ? Configuration Running xdm

The X Display Manager Abstract: 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. _________________ _________________ _________________

Introduction

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.

Why use xdm ?

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.

Configuration

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.

DisplayManager.errorLogFile: /var/log/xdm-error.log

DisplayManager.pidFile: /var/run/xdm.pid

DisplayManager.keyFile: /etc/X11/xdm/xdm-keys

DisplayManager.servers: /etc/X11/xdm/Xservers

DisplayManager.accessFile: /etc/X11/xdm/Xaccess

DisplayManager._0.authorize: true

DisplayManager._1.authorize: true

DisplayManager._0.setup: /etc/X11/xdm/Xsetup_0

DisplayManager._0.startup: /etc/X11/xdm/GiveConsole

DisplayManager._0.reset: /etc/X11/xdm/TakeConsole

DisplayManager*resources: /etc/X11/xdm/Xresources

DisplayManager*session: /etc/X11/xdm/Xsession

DisplayManager*authComplain: false

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

# first line should be the local display

:0 local /usr/X11R6/bin/X

# :0 specifies console

# local denotes the X server is running on the locally

# /usr/X11R6/bin/X executable run at startup

# the syntax for X terminals is slightly different

# since they run their X server from another machine

# ONLY enter X terminals if they DO NOT support XDMCP

eng1:0 foreign NCD xterminal

# eng1 is the name of the terminal

# :0 is the display to use on the terminal

# foreign signifies the X server is running on a different machine

# NCD xterminal are display class resources specific to this terminal

# and aren't absolutely neccesary

eng2:0 foreign NCD xterminal

eng3:0 foreign Visual xterminal

Xsession

Initial startup script used by each X session.

#!/bin/sh

# following section enables failsafe logon when neccesary

# using <CTRL><RETURN> after password activates failsafe mode

case $# in

1)

case $1 in

failsafe)

exec xterm -geometry 80x24-0-0

;;

esac

esac

# redirect errors to a file in user's home directory

for errfile in "$HOME/.xsession-errors" "${TMPDIR-/tmp}/xses-$USER" "/tmp/xses-$USER"

do

if ( cp /dev/null "$errfile" 2> /dev/null )

then

chmod 600 "$errfile"

exec > "$errfile" 2>&1

break

fi

done

# use users local .xsession and .Xresources files if they exist

startup=$HOME/.xsession

resources=$HOME/.Xresources

if [ -x "$startup" ]; then

exec "$startup"

elif [ -x "$HOME/.Xclients" ]; then

exec "$HOME/.Xclients"

elif [ -x /etc/X11/xinit/Xclients ]; then

exec /etc/X11/xinit/Xclients

else

if [ -f "$resources" ]; then

xrdb -load "$resources"

fi

exec xsm

fi

Xresources

Defines resources to be loaded via xrdb(1) for all servers managed by xdm.

# key settings to be used by Xlogin widget

xlogin*login.translations: #override\

# Ctrl R stops xdm from managing display

Ctrl<Key>R: abort-display()\n\

# F1 or Ctrl Return run a failsafe session

# consisting of a single xterm window

<Key>F1: set-session-argument(failsafe) finish-field()\n\

Ctrl<Key>Return: set-session-argument(failsafe) finish-field()\n\

<Key>Return: set-session-argument() finish-field()

# display setings for Xlogin widget to be displayed by xdm

xlogin*borderWidth: 3

xlogin*greeting: CLIENTHOST

xlogin*namePrompt: login:\040

xlogin*fail: Sorry Try Again

#ifdef COLOR

xlogin*greetColor: CadetBlue

xlogin*failColor: red

*Foreground: black

*Background: #fffff0

#else

xlogin*Foreground: black

xlogin*Background: white

#endif

# settings for xconsole client which is used when xdm connection on

# local server is initialized. This keeps console messages sent between

# logins from going everywhere across the screen

XConsole.text.geometry: 480x130

XConsole.verbose: true

XConsole*iconic: true

XConsole*font: fixed

Chooser*geometry: 700x500+300+200

Chooser*allowShellResize: false

Chooser*viewport.forceBars: true

Chooser*label.font: *-new century schoolbook-bold-i-normal-*-240-*

Chooser*label.label: XDMCP Host Menu from CLIENTHOST

Chooser*list.font: -*-*-medium-r-normal-*-*-230-*-*-c-*-iso8859-1

Chooser*Command.font: *-new century schoolbook-bold-r-normal-*-180-*

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

#!/bin/sh

# Assign ownership of the console to the invoking user

# $XConsortium: GiveConsole,v 1.2 93/09/28 14:29:20 gildea Exp $

#

# By convention, both xconsole and xterm -C check that the

# console is owned by the invoking user and is readable before attaching

# the console output. This way a random user can invoke xterm -C without

# causing serious grief.

#

chown $USER /dev/console

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

#!/bin/sh

# Reassign ownership of the console to root, this should disallow

# assignment of console output to any random users's xterm

# $XConsortium: TakeConsole,v 1.2 93/09/28 14:30:29

#

chmod 622 /dev/console

chown root /dev/console

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.

#!/bin/sh

# $XConsortium: Xsetup_0,v 1.3 93/09/28 14:30:31

/usr/X11R6/bin/xconsole -geometry 480x130-0-0 -daemon -notify -verbose -fn fixed -exitOnFail

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

Running xdm

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:

• Read other articles in this series: Connfiguring X

2002-11-02, generated by lfparser version 2.34