XDMCP(3X) X11 5.4R3.00 XDMCP(3X)
NAME
XDMCP - The X Display Manager Control Protocol
DESCRIPTION
X11R4 provides the addition of the X Display Manager Control Protocol
(XDMCP), which provides users of Xterminals with a simple method to
establish a login on a host system and start X clients.
This document describes the implementation of XDMCP and xdm on AViiON
workstations running revision 4.32 or later of DG/UX and AVX-30
Xterminals running release 2.2.1 of the NCD X Server. For more
information, consult the documentation listed in the "See Also"
section.
INTRODUCTION
Through the use of xdm, the user may choose to boot directly to the X
Window System and have xdm verify the login/password pair entered via
a login window. There are several advantages to booting the system to
the X Window System. First of all, it spares the user from having to
login at the console and invoking xstart or xtdstart to start the
user's session. Secondly, terminating the session under xdm is as
simple as exiting one of the clients in your session rather than
killing the server directly. Lastly, once in the X Window System, the
screen saving feature is enabled and the user does not run the risk
of permanently damaging the CRT.
HISTORY
An xdm daemon program was provided as part of X11R3. The daemon was
typically started by the init process, which then read a
configuration file, started a list of X servers, waited for the
servers to become initialized, opened a connection to the displays
and ran a login widget on the displays. Everything worked fine until
the Xterminal was powered OFF, then back ON. The xdm daemon had no
means for knowing that the Xterminal had disappeared and reappeared,
and consequently did not start the login widget. In addition, any X
clients waiting for a read to complete, were simply left dangling.
XDMCP
In order to rectify these problems a new control protocol, XDMCP, has
been added to X11R4 to supplement xdm. xdm(1) now supports XDMCP.
X11R4 servers as well as Data General AVX-30's running version 2.1 or
later can make use of this feature.
XDMCP has two parts, additions to the sample X server, and additions
to the xdm daemon. The XDMCP X server is available in AVX-30 X Server
Release 2.1.
Note 1 AVX-30 Release 2.1 is included in DG/UX 4.30, but it was not
used as the default, due to incompatibilities with the AVX-30
Boot PROM. The default has /usr/opt/X11/xtd/avx30boot linked
to /usr/opt/X11/xtd/avx30.1.6.2b, which does not support
XDMCP. Revision 2.0 or greater of the AVX-30 Boot PROM is
required to upgrade to NCD Release 2.1. The PROM upgrade is
specified in FCO 900712 release during July, 1990. Xterminals
Licensed material--property of copyright holder(s) 1
XDMCP(3X) X11 5.4R3.00 XDMCP(3X)
shipped by DG after that date may use the AVX-30 Release
2.1.0 software. The AVX-30 Boot PROM revision is displayed in
the "Diagnostic Session" window on the AVX-30.
Note 2 AVX-30 Release 2.2.1 has shipped with revision 4.32 and later
of DG/UX. It adds the 'tftp-timeout' configuration
parameter, which has proven useful in configurations with
large numbers of Xterminals.
XDMCP is composed of:
* A manager - the xdm daemon running on a host,
* A display - the X server running on a device such as an
Xterminal, and
* A message exchange protocol - XDMCP itself.
Together these components perform the following functions:
1) Request for Management
A method for a display to request management from a selection
of managers.
2) Authentication
The ability for the display to authenticate the manager and
other clients started for the same session.
3) Session Initiation
The manager displays a login window, and starts a user
session.
4) Manager Shutdown
The ability for the display manager to detect a crashed
display, and shut down the open connections to the display.
5) Display Shutdown
The ability for the display to detect a crashed manager host,
and shut down connections to the host.
1) REQUEST FOR MANAGEMENT
When an Xterminal is powered on, it has no permanent memory. First
is must load its X Server from the AViiON host that has been
configured as its Boot Server. See the AVX-30 release notice for
information on configuring the AViiON host.
Second, if "Remote Configuration" is selected in the Xterminal's
"Network Parameters" menu, it loads the remote configuration file
from the specified "Configuration Server".
Next it will load font information from the AViiON host selected as
the Font Server.
Then it inquires for a host offering display management. Display
Licensed material--property of copyright holder(s) 2
XDMCP(3X) X11 5.4R3.00 XDMCP(3X)
management implies control by a system administrator. xdm may be
configured to satisfy one of the following three approaches:
* Broadcast. The display broadcasts a query packet, and one or
more manager host may respond.
* Direct. The display transmits a query packet directly to a
single manager host.
* Indirect. The display transmits a query packet to an
intermediary host, which relays the request to the manager.
Note 3 The current MIT xdm daemon does not support indirect mode.
In the case of the AVX-30 implementation, the user can select either
direct or broadcast query from the display's setup menu or a remote
configuration file.
The method for managing a display under X11R3 was to enter the
display into the file /usr/lib/X11/xdm/Xservers. Under X11R4, xdm
responds to the query request to begin display management. xdm will
continue with X11R3 behavior unless the display to be managed is
removed from the Xservers file.
Note 4 The NCD 2.1 Release Notice states the following "Known
Problem". "If you are using X11R4 xdm and the XDMCP feature
of the NCD X server... you must make sure that the NCD
network display station that is to use XDMCP is not listed in
the file specified by the DisplayManager.servers resource of
xdm(1). IF it is, it will be managed as in X11R3 and XDMCP
will not operate correctly.
Note 5 In DG/UX 4.32 (X11R4), the default location for the Xservers
file is in the /var/X11/xdm directory.
A broadcast query is sent to the IP broadcast address, and all X11R4
xdm daemons willing to service the Xterminal will respond. The
Xterminal will select the first responding xdm daemon as its choice
of hosts to start the xdm negotiations with.
The direct query is sent only to the IP address specified in the
"xdm-server" parameter of the Xterminal's remote configuration file.
If the host refuses service, an error message is written to the
Xterminal's "Diagnostic Session". The direct query is probably the
method that most users will choose.
Note 6 The file /usr/opt/X11/xtd/sample.config is a sample remote
configuration file. The directory /usr/lib/X11/ncd/configs is
the default location for remote configuration files. The
default file name is the Xterminals hexadecimal internet
address. You may need to create a symbolic link
ln -s /usr/opt/X11/xtd /usr/lib/X11/ncd
Licensed material--property of copyright holder(s) 3
XDMCP(3X) X11 5.4R3.00 XDMCP(3X)
if you have not already done so for the default font path, as
recommended in the AVX-30 Release Notice.
The basic configuration needs for the Xterminal to use XDMCP are
relatively simple. The (remote configuration) parameter "virtual-
terminal-at-reset" should be set to "xdm". The parameter "xdm-access"
which determines what kind of query is sent initially, defaults to
"broadcast". Other choices are "direct", "indirect", or "disabled".
Parameters "direct" and "indirect" require that the "xdm-server"
parameter be provided. Note that none of the xdm-specific parameters
are saved in NVRAM, so use of a remote configuration file, for any
choices other than the defaults, is required. In the Xterminal's
setup menus, these parameters are in the "X Server Parameters" menu.
2) AUTHENTICATION
NCD Release 2.2 supports only NULL authentication, i.e. no "magic
cookie" authentication used. However, host-based authentication (i.e.
xhost) is used.
3) SESSION INITIATION
During the installation of X11R4, the following line is added to the
end of the /etc/inittab file:
xdm:3:once:/usr/sbin/xdmstart -nodaemon -config /var/X11/xdm/xdm-
config
The xdmstart script delays the execution of xdm until the
/usr/bin/X11/xdm file exists. This is necessary due to the delay
involved in mounting the /usr/opt/X11 LDU on diskless client systems,
and the caching of symbolic links. After the xdmstart script executes
/usr/bin/X11/xdm, the xdm daemon process is created.
If an Xterminal, configured for XDMCP support, is connected to the
LAN and properly installed, it will request service from the xdm
daemon. Upon receiving the request, the xdm daemon will create a
"display control" process with a name of the form Xterminal. The
login window resources, by default, are contained in the file
/usr/lib/X11/xdm/Xresources.
Any protocol errors will be logged in the Xterminal's diagnostic
session. The Xterminal configuration parameter "xdm-fail-action"
controls what happens when such an error is detected. The default is
"persist", which causes the Xterminal to start over again with the
XDMCP negotiation. The other choice is "stop", which causes the
AVX-30 not to start the XDMCP over again.
Note 7 The "stop" option does not work in the AVX-30 2.2.1 X Server.
Assuming all goes well, the login window will appear. This is just an
X client that is run on the host and connects to the Xterminal.
On the 'local' display, the display manager login window has been
enhanced to include four command widgets or buttons. Each button
performs a function that was previously done by a key sequence. See
Licensed material--property of copyright holder(s) 4
XDMCP(3X) X11 5.4R3.00 XDMCP(3X)
the xdm man page for more information on the key sequences. The four
buttons, Reset, Restart, Terminate, and Failsafe each perform a
separate predefined function. The Reset button, when selected, will
cause the display manager to reset the X server and start a new
session. The Restart button will terminate and restart the X server.
The Terminate button will perform an abort-display function which
causes the "display control" process and the session to terminate.
The Failsafe function is a toggle button that will enable the
failsafe mode of the session. The failsafe mode of the session is to
simply execute an xterm terminal emulator with no other clients.
On 'foreign' displays (i.e. Xterminals) only the Reset and Failsafe
buttons are available. System administrators may choose to disable
these function buttons by including the following line in the
/usr/lib/X11/xdm/Xresources file:
xlogin*CreateChildren: no
On a 'local' display with the display manager running, any user may
terminate the session and server at the login window by entering a
Control-Z (^Z) or by selecting the Terminate button. This will stop
the server and revert back to the console device. This feature is
included for those users that do not wish to use the X Window System
or users that need to access the console device in order to run
shutdown(1).
After the local Xserver has been terminated, it can be restarted by
either logging-in as "xdm", or running 'telxdm -HUP'.
A user logged in as root may also terminate the display manager and
all managed sessions by invoking telxdm(1) with the -TERM option.
Once this command has been invoked, the display manager has
terminated completely and only the super user may restart the display
manger by executing xdm from the console window or rebooting the
system. To execute xdm, it is recommended to use the /etc/inittab
entry for xdm as follows:
/usr/sbin/xdmstart -nodaemon -config /var/X11/xdm/xdm-config
After the user supplies his login name and password, the "display
control" process executes the /usr/lib/X11/xdm/Xsession script. In a
normal case, this shell script will set up several default
environment variables and create the "session log xterm" process with
the user's login shell and $HOME/.Xsession as the command to execute
in that shell. This provides the user with the same environment as
logging-in through an ASCII terminal (a DGC enhancement). For
example, it will run $HOME/.login and $HOME/.cshrc for a csh(1) user.
This feature is accomplished by executing one of the shell scripts in
the /usr/lib/X11/xdm directory which starts with login- (e.g.
/usr/lib/X11/xdm/login-csh).
The xterm command line executed from the /usr/lib/X11/xdm/Xsession
script looks like this for the csh:
Licensed material--property of copyright holder(s) 5
XDMCP(3X) X11 5.4R3.00 XDMCP(3X)
exec /usr/bin/X11/xterm -name xsession -title "session log" -e
/usr/bin/csh -f /usr/lib/X11/xdm/login-csh $HOME/.Xsession
This xterm will have the title "session log", and the instance name
"xsession" for resources. For example, if a user wants to specify the
geometry of the "session log" xterm, the line
"xsession*VT100.geometry:80x10+50+50" could be added to the file
$HOME/XTerm.
In summary, with xdm(1) running on an AViiON host, there will be one
xdm(1) daemon process. For each Xterminal, there will be one "display
control" process. For each Xterminal where a user has logged-on,
there will be one "session log xterm" process.
A common symptom of a problem with the $HOME/.Xsession file is that
after typing the user login name and password into the login window,
the login window disappears and then a few seconds later reappears.
An error is being encountered trying to run the $HOME/.Xsession file.
Note 8 Once the "session log xterm" is started all errors from the
session are written to it. (e.g. errors generated by bad
commands in $HOME/.Xsession). Only error messages from xdm,
the X Server, and /usr/lib/X11/xdm/Xsession are written to
the error log file.
Note 9 The error log file must be specified by either the xdm(1)
-error option or by the DisplayManager.errorLogFile resource
in the /var/X11/Xdm/xdm-config file.
The user should check the error messages and carefully examine what
is occurring in the $HOME/.Xsession file. Some common problems are:
1) xdm executes $HOME/.Xsession using a shell and then waits for
the shell to exit. Upon the shell exiting, xdm cleans up any
left over processes and goes back to waiting for a new XDMCP
request from the Xterminal. Therefore it is necessary that
the last command in the $HOME/.Xsession file be something
that requires user input to exit, (e.g. entering 'logout' in
an xterm running a shell). All other X clients, that are to
be started should be done so in the background, otherwise the
shell will block waiting for that client to exit and will not
start the other clients.
2) Explicit execution of xrdb(1) to load the resources in
$HOME/.Xdefaults is needed in the $HOME/.Xsession file, most
likely as one of the first entries, otherwise the user will
not get his preferences for the X clients.
Note 10 xrdb should not be executed in the background, since we want
to be sure the changes have taken effect before executing any
X clients.
Note 11 /usr/lib/X11/xdm/sample.Xsession is a prototype session file.
This file may be copied to the file .Xsession in a user's
Licensed material--property of copyright holder(s) 6
XDMCP(3X) X11 5.4R3.00 XDMCP(3X)
home directory where it may be customized to the user's
needs. This prototype session file will load resources from
$HOME/.Xdefaults if it exists, and starts a console xterm (if
the display is local), an analog clock, the mail notification
tool, a standard xterm, and the mwm window manager. Since mwm
is the session process the session terminates when mwm exits.
Note 12 Users that wish to use the display manager but wish to retain
many of the xstart features may copy the prototype session
script in /usr/lib/X11/xdm/xstart.Xsession to their session
file.
Note 13 The file /usr/lib/X11/xdm/system.Xsession provides a system
wide default session file. If a session file is not found in
a user's home directory then this script is executed as the
default start-up script. This session file loads the user's
resources from the .Xdefaults file in the user's home
directory, starts the mwm window manager, and executes a
standard terminal emulator. The terminal emulator is the
session process and will cause the session to terminate when
it exits. System administrators that wish to change the
default session should modify this file.
Exiting The Session
There are several methods that can be used to "logout" of an xdm
session. The cleanest way is to force the last client started in the
$HOME/.Xsession (the one left running in the foreground) to
terminate. Another recommended method is to kill the "xsession log"
xterm.
4) MANAGER SHUTDOWN
The second most important function of xdm, after initiating the
session, is providing an automatic mechanism for shutting down the
session should the display fail.
Assume that the user has logged in via xdm and has his session
running some xterms, a window manager, and a clock. Now in this
state, he turns OFF the Xterminal and leaves it off. Any clients
with outstanding data in TCP (e.g. xclock) will eventually be
notified that too many retransmissions have occurred, and the
connection will be reset by the host. Potentially, this can take a
long time. This mechanism does not terminate clients without
outstanding data, including those who never generate anything of
their own accord (e.g. window managers). xdm has two mechanisms for
dead session detection:
1) Keepalives
2) Duplicate Management Requests
Keepalives are sent by the xdm daemon to the display at periodic
intervals, performing an 'Xsync' on the display. Should the display
fail to respond, the xdm daemon sends SIGTERM to the display's
Licensed material--property of copyright holder(s) 7
XDMCP(3X) X11 5.4R3.00 XDMCP(3X)
"session log xterm" which, in turn, send a HUP to its process group
(i.e. all of the processes started out of the $HOME/.Xsession file)
on the host. This cleans up all clients local to the xdm daemon host.
The addition of this feature is a boon to Xterminal users.
Previously, naive users would initiate a number of clients, then
wishing to cleanly and simply exit, turn OFF the Xterminal. Sure
enough, the display would restart with a nice clean root window, but
unknown to the user, clients would linger on the host machine,
occupying virtual memory and other process-related resources.
Note 14 If the Xterminal is left in the setup menus or the window
manager performed a "GrabServer" and did not relinquish
control within the timeout time, xdm will declare the server
dead and terminate the session. This most commonly occurs
when the window manager is painting a wire frame awaiting
positioning of the window and the user leaves the wire frame
active too long.
The second xdm shutdown mechanism, duplicate management requests,
comes into play during short power-cycles. If the Xterminal is turned
OFF, the keepalive timeouts will eventually kill host processes.
However in the case of the power cycle (an X terminal can reboot in
30-60 seconds), the display will respond to keepalives, so the xdm
daemon checks to see if the display is already under management when
a request for management is received, and shuts down any left over
processes from the last session by terminating the "session log
xterm".
5) DISPLAY SHUTDOWN
Dead session detection is performed by the display as well as the
manager. If no client input has been received for a period of time
(typically minutes), the Xterminal uses a keepalive feature of the
XDMCP to occasionally ask the xdm daemon if it is still alive. If the
Xterminal sees input from ANY X client, it assumes everything is OK.
So it is possible for the xdm daemon machine to die, but an xterm(1)
from another machine is still working so the Xterminal will keep
quiet. If however NO client input is detected for "xdm-hibernation-
time" minutes, then XDMCP keepalive packets are sent. The default
value for this parameter is 3 minutes. Once the display begins
sending keepalives (to a responding manager), the keepalive interval
is exponentially increased in order to minimize network activity. IF
however, after "xdm-death-timeout" seconds no keepalive response has
been seen, then the Xterminal will declare the current session dead.
The default value is 30 seconds. This means that all client data
within the Xterminal's X server is destroyed, and the XDMCP
negotiation is started over again.
This scheme for dead session detection on the display allows the user
to keep working in the event of a manager host crash, using clients
on other hosts.
CAVEATS
Dead session detection and shutdown is not perfect. The manager uses
Unix process control mechanisms to kill all clients on the same host
Licensed material--property of copyright holder(s) 8
XDMCP(3X) X11 5.4R3.00 XDMCP(3X)
as the manager, but there is no mechanism to hunt down clients on
other hosts and kill them. This is not really the fault of XDMCP, it
is the lack of distributed process control in the current rsh
implementation. The X server running on the display knows all of its
open connections, but that's not helpful when the display has crashed
(e.g. Xterminal power-cycle). The most common way to establish
clients on remote hosts is to use the 'rsh' command, passing the
client name and display name as arguments, and place the remote shell
in the background. Due to limitations in rsh, killing the local 'rsh'
does not propagate the kill to the remote system. Therefore, even
with the new xdm it is still possible to have defunct "quiet" clients
lying around.
Also csh(1) background commands are not killed by xdm, because they
are in separate process groups. The xterm(1), in which the csh(1) is
running, cannot kill the csh's background commands because it only
kills the foreground process group and the csh(1) does not propagate
the signal to the background process groups.
TELXDM
A program called telxdm has been provided in the standard client
binary area. Telxdm, when run as root, will cause xdm, the display
manager, to reset and reread all of its configuration files. This
ability is useful to system administrators that wish to modify the
display manager's behavior without restarting the system. Telxdm with
the -TERM command line option will signal the display manager and
cause it to terminate. With the -HUP command line option, telxdm will
cause the display manager to reset and rescan its list of servers.
OBSOLESCENCE
xdm(1) no longer supports 'localTransient and 'transient' sessions.
ACKNOWLEDGMENTS
Some of the information in this document has been "borrowed" from the
paper "XDMCP - A First Step in Making it Easier to Get Started in X"
by Ed Basart and Dave Mackie of NCD, and an email message by Dave
Mackie with the Subject: XDMCP info (long).
SEE ALSO
xdm(1), telxdm(1), Xsession(5),
Licensed material--property of copyright holder(s) 9