XDMCP(3X) UNIX System V 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.
Licensed material--property of copyright holder(s) Page 1
XDMCP(3X) UNIX System V XDMCP(3X)
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 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
Licensed material--property of copyright holder(s) Page 2
XDMCP(3X) UNIX System V XDMCP(3X)
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 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.
Licensed material--property of copyright holder(s) Page 3
XDMCP(3X) UNIX System V XDMCP(3X)
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
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
Licensed material--property of copyright holder(s) Page 4
XDMCP(3X) UNIX System V XDMCP(3X)
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 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
Licensed material--property of copyright holder(s) Page 5
XDMCP(3X) UNIX System V XDMCP(3X)
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 loggin-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:
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.
Licensed material--property of copyright holder(s) Page 6
XDMCP(3X) UNIX System V XDMCP(3X)
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 occuring 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
Licensed material--property of copyright holder(s) Page 7
XDMCP(3X) UNIX System V XDMCP(3X)
session
file. This file may be copied to the file .Xsession
in a user's 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 occured, 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
Licensed material--property of copyright holder(s) Page 8
XDMCP(3X) UNIX System V XDMCP(3X)
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 "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
Licensed material--property of copyright holder(s) Page 9
XDMCP(3X) UNIX System V XDMCP(3X)
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 resonse 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 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.
Licensed material--property of copyright holder(s) Page 10
XDMCP(3X) UNIX System V XDMCP(3X)
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) Page 11