xdm - X Display Manager with support for XDMCP, host
chooser
xdm [-config configuration_file] [-nodaemon] [-debug
debug_level] [-error error_log_file] [-resources
resource_file] [-server server_entry] [-session session_program]
All of these options, except -config itself, specify values
that can also be specified in the configuration file
as resources. Names the configuration file, which specifies
resources to control the behavior of xdm.
<XRoot>/lib/X11/xdm/xdm-config is the default. See the
section CONFIGURATION FILE. Specifies "false" as the
value for the DisplayManager.daemonMode resource. This
suppresses the normal daemon behavior, which is for xdm to
close all file descriptors, disassociate itself from the
controlling terminal, and put itself in the background
when it first starts up. Specifies the numeric value for
the DisplayManager.debugLevel resource. A non-zero value
causes xdm to print lots of debugging statements to the
terminal; it also disables the DisplayManager.daemonMode
resource, forcing xdm to run synchronously. To interpret
these debugging messages, a copy of the source code for
xdm is almost a necessity. No attempt has been made to
rationalize or standardize the output. Specifies the
value for the DisplayManager.errorLogFile resource. This
file contains errors from xdm as well as anything written
to stderr by the various scripts and programs run during
the progress of the session. Specifies the value for the
DisplayManager*resources resource. This file is loaded
using xrdb to specify configuration parameters for the
authentication widget. Specifies the value for the DisplayManager.servers
resource. See the section SERVER SPECIFICATION
for a description of this resource. Specifies
the value for the DisplayManager.requestPort resource.
This sets the port-number which xdm will monitor for XDMCP
requests. As XDMCP uses the registered well-known UDP
port 177, this resource should not be changed except for
debugging. Specifies the value for the DisplayManager*session
resource. This indicates the program to run
as the session after the user has logged in. Allows an
arbitrary resource to be specified, as in most X Toolkit
applications.
The xdm program manages a collection of X displays, which
may be on the local host or remote servers. The design of
xdm was guided by the needs of X terminals as well as the
X Consortium standard XDMCP, the X Display Manager Control
Protocol. xdm provides services similar to those provided
by init, getty and login on character terminals: prompting
for login name and password, authenticating the user, and
running a "session."
A "session" is defined by the lifetime of a particular
process; in the traditional character-based terminal
world, it is the user's login shell. In the xdm context,
it is an arbitrary session manager. This is because in a
windowing environment, a user's login shell process does
not necessarily have any terminal-like interface with
which to connect. When a real session manager is not
available, a window manager or terminal emulator is typically
used as the "session manager," meaning that termination
of this process terminates the user's session.
When the session is terminated, xdm resets the X server
and (optionally) restarts the whole process.
When xdm receives an Indirect query via XDMCP, it can run
a chooser process to perform an XDMCP BroadcastQuery (or
an XDMCP Query to specified hosts) on behalf of the display
and offer a menu of possible hosts that offer XDMCP
display management. This feature is useful with X terminals
that do not offer a host menu themselves.
Because xdm provides the first interface that users will
see, it is designed to be simple to use and easy to customize
to the needs of a particular site. xdm has many
options, most of which have reasonable defaults. Browse
through the various sections of this reference page, picking
and choosing the things you want to change. Pay particular
attention to the Session Program section, which
will describe how to set up the style of session desired.
In handling a user's login to the X display, xdm records
the login in the /var/adm/utmp file, the same way that a
normal, non-X login does. This allows the finger and who
commands to show the user logged in to the X display.
Actually, xdm is designed to operate in such a wide variety
of environments that typical is probably a misnomer.
First, the xdm configuration file should be set up. Make a
directory (usually /usr/var/X11/xdmr or /usr/lib/X11/xdm)
to contain all of the relevant files. Here is a reasonable
configuration file, which could be named xdm-config:
DisplayManager.errorLogFile: /usr/var/X11/xdm/xdmerrors
DisplayManager.pidFile:
/usr/var/X11/xdm/xdm-pid DisplayManager.keyFile:
/usr/var/X11/xdm/xdm-keys DisplayManager.servers:
/usr/var/X11/xdm/Xservers DisplayManager.accessFile:
/usr/var/X11/xdm/Xaccess DisplayManager.greeterLib:
/usr/shlib/X11/libXdmDecGreet.so DisplayManager._0.authorize:
true DisplayManager._0.authName: \
XDM-AUTHORIZATION-1 MIT-MAGIC-COOKIE-1 DisplayManager._0.setup:
/usr/var/X11/xdm/Xsetup_0 DisplayManager._0.startup:
/usr/var/X11/xdm/GiveConsole
DisplayManager._0.reset: /usr/var/X11/xdm/TakeConsole
DisplayManager.local_0.authorize: true DisplayManager.local_0.authName:
\
XDM-AUTHORIZATION-1 MIT-MAGIC-COOKIE-1 DisplayManager.local_0.setup:
/usr/var/X11/xdm/Xsetup_0 DisplayManager.local_0.startup:
/usr/var/X11/xdm/GiveConsole
DisplayManager.local_0.reset: /usr/var/X11/xdm/TakeConsole
DisplayManager*resources: /usr/var/X11/xdm/Xresources
DisplayManager*session:
/usr/var/X11/xdm/Xsession DisplayManager*authComplain:
false DisplayManager*chooser: /usr/bin/X11/chooser
DisplayManager*keymaps: /usr/var/X11/xdm/Xkeymaps
!DisplayManager*language: C
Note that this file mainly contains references to other
files. Note also that some of the resources are specified
with "*" separating the components. These resources can
be made unique for each different display, by replacing
the "*" with the display-name, but normally this is not
very useful. See the RESOURCES section for a complete
discussion.
The first file, /usr/var/X11/xdm/Xservers, contains the
list of displays to manage that are not using XDMCP. Most
workstations have only one display, numbered 0, so the
file will look something like this:
:0 Local local /usr/bin/X11/X :0
This will keep /usr/bin/X11/X running on this display and
manage a continuous cycle of sessions.
The file /usr/var/X11/xdm/xdm-errors will contain error
messages from xdm and anything output to stderr by
Xsetup_0, GiveConsole, Xsession, or TakeConsole. When you
have trouble getting xdm working, check this file to see
if xdm has any clues to the trouble.
GiveConsole assigns ownership of the console to the user.
Here is an example GiveConsole file:
#!/bin/sh
# Assign ownership of the console to the invoking
user.
#
# 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 problems.
#
# However, don't give up ownership of the console if
the
# alternate console is in use, that is, if the
graphics
# display device is not the console.
#
case `/usr/sbin/sizer -wc` in
1)
;;
*)
chown $USER /dev/console
;;
esac
TakeConsole assigns ownership back to root. Here is an
example TakeConsole file:
#!/bin/sh
# Reassign ownership of the console to root -- this
# should disallow assignment of console output to
any
# random users's xterm
#
chmod 622 /dev/console
chown root /dev/console
The next configuration entry, /usr/lib/X11/xdm/Xresources,
is loaded onto the display as a resource database using
xrdb. Since the authentication widget reads this database
before starting up, it usually contains parameters for
that widget.
The most interesting script is Xsession. It establishes
the default login session for all users of the workstation.
Here is an example Xsession file:
#!/bin/sh
if [ -d $HOME -a -w $HOME ] then
exec > $HOME/.xsession-errors 2>&1 else
echo "Xsession: $HOME directory not writable by
$USER" \
> /dev/console
exec dxterm -geometry 80x40+0+0
# exec xterm -geometry 80x24+0+0 fi
case $# in 1)
case $1 in
failsafe)
exec dxterm -geometry 80x40+0+0
# exec xterm -geometry 80x24+0+0
;;
esac esac
startup=$HOME/.xsession resources=$HOME/.Xresources
if [ -f $startup ]; then
if [ -x $startup ]
then
exec $startup
else
exec /bin/sh $startup
fi else
if [ -f $resources ]; then
xrdb -load -retain $resources
fi
#
# Motif/DECWindows Version
#
#dxsession
#
# MIT/Athena Version
#
# For a MIT/Athena version,
# uncomment the following lines and comment the
Motif
# lines above
xconsole -geometry 480x130-0-0 -daemon -notify -verbose
\
-fn fixed -exitOnFail
twm &
exec xterm -geometry 80x24+10+10 -ls fi
The preceding version of the Xsession script recognizes
the special "failsafe" mode, specified in the translations
in the Xresources file above, to provide an escape from
the ordinary session. Failsafe mode enables you to start a
dxterm even when your Xsession or $HOME/.xsession script
is faulty. To enter failsafe mode, enter your username and
password at the login prompt and then press either the F1
key or the F2 key, instead of pressing the carriage return
key. This sequence initiates a dxterm session, enabling
you to edit the faulty Xsession or $HOME/.xsession file.
Also, if you do not have a login directory or if your
login directory is not writable (as in the case of a login
directory that belongs to someone else), failsafe mode is
invoked and brings up a dxterm session to allow you to
make adjustments.
The file /usr/var/X11/xdm/Xkeymaps defines the keymaps
that are loaded into the Xserver for the various languages
and keyboards. These keymaps are loaded by the Xsetup_0
script using the xmodmap command. The table in the following
file defines the correspondence between the value of
the console's language variable, the keyboard types, and
the default keymaps loaded into the Xserver:
# # This file defines the language-keymap mapping # # #
The first line contains the name of the # link to be
created to the default keymap. #
/usr/var/X11/xdm/keymap_default # # This is the directory
where the keymap files are to be found. #
/usr/lib/X11/keymaps/ # # The following lines must contain:
# <number> <language>
<keymap-filename> # # The <number> field is a 2-byte hex
value where the first byte # represents the keyboard type
and the second byte is the value of the # console's language
variable. The values for the keyboard types are: #
LK401 0 # PCXAL 1 # LK201 2 #
LK421 3 # LK443/4 4 # LK411 5 # # Don't
put any 8-bit characters in the language names or the #
isspace() function used in parsing this may think they're
spaces # causing the lines to be parsed incorrectly. # #
If the <keymap-filename> field is blank, this has the special
# meaning that no keymap_default link will be created,
nor will any # existing keymap_default be modified.
# # The keymap specified for the "fallback" lines is used
for any # language value missing from the table for the
corresponding # keyboard type. # 000 fallback
us_lk401aa.keymap 030 Dansk danish_lk401ad_tw.keymap
032 Deutsch austrian_german_lk401ag.keymap
034 Deutsch(Schweiz)
swiss_german_lk401al_tw.keymap 036 English(American)
us_lk401aa.keymap 038 English(British/Irish)
uk_lk401aa.keymap 03a Espanol spanish_lk401as_tw.keymap
03c Francais belgian_french_lk401ap_tw.keymap
03e Francais(Canadien)
canadian_french_lk401ac_tw.keymap 040 Francais(SuisseRomande)
swiss_french_lk401ak_tw.keymap 042 Italiano
italian_lk401ai_tw.keymap 044 Nederlands
dutch_us_lk401ah.keymap 046 Norsk
norwegian_lk401an_tw.keymap 048 Portugues
portuguese_lk401av.keymap 04a Suomi
finnish_lk401af_tw.keymap 04c Svenska
swedish_lk401am_tw.keymap 04e Vlaams
flemish_lk401ab_tw.keymap
100 fallback us_pcxalka.keymap 130
Dansk danish_pcxalkd.keymap 132
Deutsch austrian_german_pcxalkg.keymap
.
.
. 14c Svenska
swedish_pcxalma.keymap 14e Vlaams belgian_pcxalkb.keymap
200 fallback us_lk201re.keymap 230
Dansk danish_lk201ld_tw.keymap * 232
Deutsch austrian_german_lk201lg_tw.keymap *
.
.
. 24c Svenska
swedish_lk201lm_tw.keymap * 24e Vlaams
flemish_lk201lb_tw.keymap
300 fallback us_lk421aa.keymap 336
English(American) us_lk421aa.keymap 338
English(British/Irish) uk_lk421aa.keymap
400 fallback us_lk443aa.keymap 430
Dansk danish_lk444kd.keymap 432
Deutsch austrian_german_lk444kg.keymap
.
.
. 44c Svenska
swedish_lk444ma.keymap
.
.
. 500 fallback
us_lk411aa.keymap 530 Dansk danish_lk411ad.keymap
532 Deutsch austrian_german_lk411ag.keymap
.
.
. 54c Svenska
swedish_lk411am.keymap 54e Vlaams belgian_lk411ab.keymap
At many stages the actions of xdm can be controlled
through the use of its configuration file, which is in the
X resource format. Some resources modify the behavior of
xdm on all displays, while others modify its behavior on a
single display. Where actions relate to a specific display,
the display name is inserted into the resource name
between "DisplayManager" and the final resource name segment.
For local displays, the resource name and class are as
read from the Xservers file.
For remote displays, the resource name is what the network
address of the display resolves to. See the removeDomain
resource. The name must match exactly; xdm is not aware
of all the network aliases that might reach a given display.
If the name resolve fails, the address is used.
The resource class is as sent by the display in the XDMCP
Manage request.
Because the resource manager uses colons to separate the
name of the resource from its value and dots to separate
resource name parts, xdm substitutes underscores for both
dots and colons when generating the resource name. For
example, DisplayManager.expo_x_org_0.startup is the name
of the resource which defines the startup shell file for
the "expo.x.org:0" display. This resource either specifies
a file name full of server entries, one per line (if
the value starts with a slash), or a single server entry.
See the section SERVER SPECIFICATION for the details.
This resource indicates the UDP port number which xdm uses
to listen for incoming XDMCP requests. Unless you need to
debug the system, leave this with its default value of
177. Error output is normally directed at the system console.
To redirect it, set this resource to a file name.
A method to send these messages to syslog should be developed
for systems which support it; however, the wide variety
of interfaces precludes any system-independent implementation.
This file also contains any output directed to
stderr by the Xsetup, GiveConsole, Xsession and TakeConsole
files, so it will contain descriptions of problems in
those scripts as well. If the integer value of this
resource is greater than zero, reams of debugging information
will be printed. It also disables daemon mode, which
would redirect the information into the bit-bucket, and
allows non-root users to run xdm, which would normally not
be useful. Normally, xdm attempts to make itself into a
daemon process unassociated with any terminal. This is
accomplished by forking and leaving the parent process to
exit, then closing file descriptors and releasing the controlling
terminal. In some environments this is not
desired (in particular, when debugging). Setting this
resource to "false" will disable this feature. The filename
specified will be created to contain an ASCII representation
of the process-id of the main xdm process. xdm
also uses file locking on this file to attempt to eliminate
multiple daemons running on the same machine, which
would cause quite a bit of havoc. This is the resource
which controls whether xdm uses file locking to keep multiple
display managers from running amok. On System V,
this uses the lockf library call, while on BSD it uses
flock. This names a directory in which xdm stores authorization
files while initializing the session. The
default value is <XRoot>/lib/X11/xdm. This boolean controls
whether xdm rescans the configuration, servers,
access control and authentication keys files after a session
terminates and the files have changed. By default it
is "true." You can force xdm to reread these files by
sending a SIGHUP to the main process. When computing the
display name for XDMCP clients, the name resolver will
typically create a fully qualified host name for the terminal.
As this is sometimes confusing, xdm will remove
the domain name portion of the host name if it is the same
as the domain name of the local host when this variable is
set. By default the value is "true." XDM-AUTHENTICATION-1
style XDMCP authentication requires that a private
key be shared between xdm and the terminal. This resource
specifies the file containing those values. Each entry in
the file consists of a display name and the shared key.
To prevent unauthorized XDMCP service and to allow forwarding
of XDMCP IndirectQuery requests, this file contains
a database of hostnames which are either allowed
direct access to this machine, or have a list of hosts to
which queries should be forwarded to. The format of this
file is described in the section XDMCP ACCESS CONTROL. A
list of additional environment variables, separated by
white space, to pass on to the Xsetup_0, GiveConsole,
Xsession, and TakeConsole programs. This resource is the
name of the loadable greeter library. The greeter is the
component that displays the login box, collects the username
and password from the user, and authenticates the
user. The default value for this resource is
/usr/shlib/X11/libXdmDecGreet.so which is the Motif login
interface. The /usr/shlib/X11/libXdmGreet.so library contains
the Athena-style login interface. A file to checksum
to generate the seed of authorization keys. This
should be a file that changes frequently. The default is
/dev/mem. Number of seconds to wait for display to
respond after user has selected a host from the chooser.
If the display sends an XDMCP IndirectQuery within this
time, the request is forwarded to the chosen host. Otherwise,
it is assumed to be from a new session and the
chooser is offered again. Default is 15. This resource
specifies the name of the file to be loaded by xrdb as the
resource database onto the root window of screen 0 of the
display. The Xsetup_0 program, the Login widget, and
chooser will use the resources set in this file. This
resource data base is loaded just before the authentication
procedure is started, so it can control the appearance
of the login window. See the section AUTHENTICATION
WIDGET, which describes the various resources that are
appropriate to place in this file. There is no default
value for this resource, but <XRoot>/lib/X11/xdm/Xresources
is the conventional name. Specifies the program
run to offer a host menu for Indirect queries redirected
to the special host name CHOOSER.
<XRoot>/lib/X11/xdm/chooser is the default. See the sections
XDMCP ACCESS CONTROL and CHOOSER. This resource
specifies the program used to load the resources. By
default, xdm uses <XRoot>/bin/xrdb. This specifies a program
which is run (as root) before offering the Login window.
This may be used to change the appearance of the
screen around the Login window or to put up other windows.
For example, you may want to run xconsole here. By
default, no program is run. The conventional name for a
file used here is Xsetup_0. See the section SETUP PROGRAM.
This resource specifies a program which is run (as
root) after the authentication process succeeds. By
default, no program is run. The conventional name for a
file used here is GiveConsole. See the section STARTUP
PROGRAM. This resource specifies the session to be executed
(not running as root). By default, <XRoot>/bin/xterm
is run. The conventional name is Xsession. See the section
BSESSION PROGRAM. This specifies a program which is
run (as root) after the session terminates. Again, by
default no program is run. The conventional name is TakeConsole.
See the section RESET PROGRAM. These numeric
resources control the behavior of xdm when attempting to
open intransigent servers. The openDelay resource is the
length of the pause (in seconds) between successive
attempts. The openRepeat resource is the number of
attempts to make. The openTimeout resource is the amount
of time to wait while actually attempting the open (that
is, the maximum time spent in the connect(2) system call).
The startAttempts resource is the number of times this
entire process is done before giving up on the server.
After openRepeat attempts have been made, or if openTimeout
seconds elapse in any particular attempt, xdm terminates
and restarts the server, attempting to connect
again. This process is repeated startAttempts times, at
which point the display is declared dead and disabled.
Although this behavior may seem arbitrary, it has been
empirically developed and works quite well on most systems.
The default values are 5 for openDelay, 5 for openRepeat,
30 for VopenTimeout and 4 for startAttempts. To
discover when remote displays disappear, xdm occasionally
pings them, using an X connection and XSync calls. pingInterval
specifies the time (in minutes) between each ping
attempt, pingTimeout specifies the maximum amount of time
(in minutes) to wait for the terminal to respond to the
request. If the terminal does not respond, the session is
declared dead and terminated. By default, both are set to
5 minutes. If you frequently use X terminals which can
become isolated from the managing host, you may wish to
increase this value. The only drawback is that sessions
will continue to exist after the terminal has been accidentally
disabled. xdm will not ping local displays.
Although it would seem harmless, it is unpleasant when the
workstation session is terminated as a result of the
server hanging for NFS service and not responding to the
ping. This boolean resource specifies whether the X
server should be terminated when a session terminates
(instead of resetting it). This option can be used when
the server tends to grow without bound over time, in order
to limit the amount of time the server is run. The
default value is "false." xdm sets the PATH environment
variable for the session to this value. It should be a
colon separated list of directories; see sh(1) for a full
description. ":/bin:/usr/bin:/usr/X11R6/bin:/usr/ucb" is a
common setting. The default value can be specified at
build time in the X system configuration file with DefaultUserPath.
xdm sets the PATH environment variable for the
startup and reset scripts to the value of this resource.
The default for this resource is specified at build time
by the DefaultSystemPath entry in the system configuration
file; "/etc:/bin:/usr/bin:/usr/X11R6/bin:/usr/ucb" is a
common choice. Note the absence of "." from this entry.
This is a good practice to follow for root; it avoids many
common Trojan Horse system penetration schemes. xdm sets
the SHELL environment variable for the startup and reset
scripts to the value of this resource. It is /bin/sh by
default. If the default session fails to execute, xdm
will fall back to this program. This program is executed
with no arguments, but executes using the same environment
variables as the session would have had (see the section
SESSION PROGRAM). By default, <XRoot>/bin/xterm is used.
To improve security, xdm grabs the server and keyboard
while reading the login name and password. The grabServer
resource specifies if the server should be held for the
duration of the name/password reading. When "false," the
server is ungrabbed after the keyboard grab succeeds, otherwise
the server is grabbed until just before the session
begins. The default is "false." The grabTimeout resource
specifies the maximum time xdm will wait for the grab to
succeed. The grab may fail if some other client has the
server grabbed, or possibly if the network latencies are
very high. This resource has a default value of 3 seconds.
You should be cautious when raising it, as a user
can be confused by a look-alike window on the display. If
the grab fails, xdm kills and restarts the server (if possible)
and the session. The authorize resource is a
boolean resource which controls whether xdm generates and
uses authorization for the local server connections. If
authorization is used, authName is a list of authorization
mechanisms to use, separated by white space. XDMCP connections
dynamically specify which authorization mechanisms
are supported, so authName is ignored in this case. By
default, authorize is "true." authName is "MIT-MAGICCOOKIE-1,"
or, if XDM-AUTHORIZATION-1 is available, "XDMAUTHORIZATION-1
MIT-MAGIC-COOKIE-1." This file is used to
communicate the authorization data from xdm to the server,
using the -auth server command line option. It should be
kept in a directory which is not world-writable as it
could easily be removed, disabling the authorization mechanism
in the server. If this resource is not specified,
unique file names are generated and written into the
directory specified by the DisplayManager.authDir
resource. Not used. This resource specifies the number
of the signal xdm sends to reset the server. See the
section CONTROLLING THE SERVER. The default is 1 (SIGHUP).
This resource specifies number of the signal xdm sends to
terminate the server. See the section CONTROLLING THE
SERVER. The default is 15 (SIGTERM). The original implementation
of authorization in the sample server reread the
authorization file at server reset time, instead of when
checking the initial connection. Because xdm generates
the authorization information just before connecting to
the display, an old server would not get up-to-date authorization
information. This resource causes xdm to send
SIGHUP to the server after setting up the file, causing an
additional server reset to occur, during which time the
new authorization information will be read. The default is
"false," which will work for all MIT servers. When xdm is
unable to write to the usual user authorization file
($HOME/.Xauthority), it creates a unique file name in this
directory and points the environment variable XAUTHORITY
at the created file. It uses /tmp by default. This
resource defines the default keymap that the local Xserver
uses and maps the value of the console's language variable
to a keymap name. This resource applies only to local
displays. This resource defines the value of the LANG
environment variable. If this resource is defined, the
LANG variable will be set for the xdm process controlling
the display as well as for the user's X session.
First, the xdm configuration file should be set up. Make
a directory (usually <XRoot>/lib/X11/xdm, where <XRoot>
refers to the root of the X11 install tree) to contain all
of the relevant files. In the examples that follow, we
use /usr/X11R6 as the value of <XRoot>.
Here is a reasonable configuration file, which could be
named xdm-config:
DisplayManager.errorLogFile:
/usr/lib/X11/xdm/xdm-errors
DisplayManager.pidFile:
/usr/lib/X11/xdm/xdm-pid
DisplayManager.keyFile:
/usr/lib/X11/xdm/xdm-keys
DisplayManager.servers:
/usr/lib/X11/xdm/Xservers
DisplayManager.accessFile:
/usr/lib/X11/xdm/Xaccess
DisplayManager._0.authorize: true
DisplayManager._0.setup:
/usr/lib/X11/xdm/Xsetup_0
DisplayManager._0.startup:
/usr/lib/X11/xdm/GiveConsole
DisplayManager._0.reset:
/usr/lib/X11/xdm/TakeConsole
DisplayManager*resources:
/usr/lib/X11/xdm/Xresources
DisplayManager*session:
/usr/lib/X11/xdm/Xsession
DisplayManager*authComplain: false
Note that this file mostly contains references to other
files. Note also that some of the resources are specified
with "*" separating the components. These resources can
be made unique for each different display, by replacing
the "*" with the display-name, but normally this is not
very useful. See the RESOURCES section for a complete
discussion.
The database file specified by the DisplayManager.accessFile
provides information that xdm uses to control access
from displays requesting XDMCP service. This file contains
three types of entries: entries which control the
response to Direct and Broadcast queries, entries which
control the response to Indirect queries, and macro definitions.
The format of the Direct entries is simple, either a host
name or a pattern, which is distinguished from a host name
by the inclusion of one or more meta characters (`*'
matches any sequence of 0 or more characters, and `?'
matches any single character) which are compared against
the host name of the display device. If the entry is a
host name, all comparisons are done using network
addresses, so any name which converts to the correct network
address may be used. For patterns, only canonical
host names are used in the comparison, so ensure that you
do not attempt to match aliases. Preceding either a host
name or a pattern with a `!' character causes hosts which
match that entry to be excluded.
An Indirect entry also contains a host name or pattern,
but follows it with a list of host names or macros to
which indirect queries should be sent.
A macro definition contains a macro name and a list of
host names and other macros that the macro expands to. To
distinguish macros from hostnames, macro names start with
a `%' character. Macros can be nested.
Indirect entries can also specify to have xdm run chooser
to offer a menu of hosts to connect to. See the section
CHOOSER.
When xdm checks the access for a particular display host,
each entry is scanned in turn and the first matching entry
determines the response. Direct and Broadcast entries are
ignored when scanning for an Indirect entry and viceversa.
Blank lines are ignored, `#' is treated as a comment
delimiter causing the rest of that line to be ignored, and
`\newline' causes the newline to be ignored, allowing
indirect host lists to span multiple lines.
Here is an example Xaccess file:
# # Xaccess - XDMCP access control file #
# # Direct/Broadcast query entries #
!xtra.lcs.mit.edu # disallow direct/broadcast service
for xtra bambi.ogi.edu # allow access from this particular
display *.lcs.mit.edu # allow access from any display
in LCS
# # Indirect query entries #
%HOSTS expo.lcs.mit.edu xenon.lcs.mit.edu \
excess.lcs.mit.edu kanga.lcs.mit.edu
extract.lcs.mit.edu xenon.lcs.mit.edu #force extract to
contact xenon !xtra.lcs.mit.edu dummy #disallow
indirect access *.lcs.mit.edu %HOSTS #all others get
to choose
For X terminals that do not offer a host menu for use with
Broadcast or Indirect queries, the chooser program can do
this for them. In the Xaccess file, specify "CHOOSER" as
the first entry in the Indirect host list. Chooser will
send a Query request to each of the remaining host names
in the list and offer a menu of all the hosts that
respond.
The list may consist of the word "BROADCAST," in which
case chooser will send a Broadcast instead, again offering
a menu of all hosts that respond. Note that on some operating
systems, UDP packets cannot be broadcast, so this
feature will not work.
Example Xaccess file using chooser:
extract.lcs.mit.edu CHOOSER %HOSTS #offer a menu of these
hosts xtra.lcs.mit.edu CHOOSER BROADCAST #offer a
menu of all hosts
The program to use for chooser is specified by the DisplayManager.DISPLAY.chooser
resource. For more flexibility
at this step, the chooser could be a shell script.
Chooser is the session manager here; it is run instead of
a child xdm to manage the display.
Resources for this program can be put into the file named
by DisplayManager.DISPLAY.resources.
When the user selects a host, chooser prints the host chosen,
which is read by the parent xdm, and exits. xdm
closes its connection to the X server, and the server
resets and sends another Indirect XDMCP request. xdm
remembers the user's choice (for DisplayManager.choiceTimeout
seconds) and forwards the request to the chosen
host, which starts a session on that display.
The resource DisplayManager.servers gives a server specification
or, if the values starts with a slash (/), the
name of a file containing server specifications, one per
line.
Each specification indicates a display which should constantly
be managed and which is not using XDMCP. This
method is used typically for local servers only. If the
resource or the file named by the resource is empty, xdm
will offer XDMCP service only.
Each specification consists of at least three parts: a
display name, a display class, a display type, and (for
local servers) a command line to start the server. A typical
entry for local display number 0 would be:
:0 local /usr/bin/X11/X
The display types are:
local local display: xdm must run the server foreign
remote display: xdm opens an X connection to a
running server
The display name must be something that can be passed in
the -display option to an X program. This string is used
to generate the display-specific resource names, so be
careful to match the names (for example, use ":0 Sun-CG3
local /usr/X11R6/bin/X :0" instead of "localhost:0 Sun-CG3
local /usr/X11R6/bin/X :0" if your other resources are
specified as "DisplayManager._0.session"). The display
class portion is also used in the display-specific
resources, as the class of the resource. This feature is
useful if you have a large collection of similar displays
(such as a corral of X terminals) and would like to set
resources for groups of them. When using XDMCP, the display
is required to specify the display class. The manual
for your particular X terminal should document the display
class string for your device. If it does not, you can run
xdm in debug mode and look at the resource strings that it
generates for that device. One of these strings is the
class string.
To use the Shared Memory Transport as the default transport
for communication between the X server and local
clients, specify the local display as local:0, in which
case the entry in the Xservers file might read as follows:
local:0 local /usr/bin/X11/X
When xdm starts a session, it sets up authorization data
for the server. For local servers, xdm passes "-auth
filename'' on the server's command line to point it at its
authorization data. For XDMCP servers, xdm passes the
authorization data to the server via the Accept XDMCP
request.
ATHENA-STYLE AUTHENTICATION WIDGET [Toc] [Back] This login widget is used when the greeter library,
/usr/lib/X11/xdm/libXdmGreet.so, is specified as the value
of the DisplayManager.greeterLib resource.
Note that you cannot use the Athena-style greeter if you
have enabled enhanced security on your system. The
Athena-style greeter does not use the necessary security
mechanisms. See secsetup(8).
The authentication widget reads a name/password pair from
the keyboard. Nearly every imaginable parameter can be
controlled with a resource. Resources for this widget
should be put into the file named by DisplayManager.DISPLAY.resources.
All of these resources have reasonable
default values, so it is not necessary to specify any of
them. The geometry of the Login widget is normally computed
automatically. If you wish to position it elsewhere,
specify each of these resources. The color used to
display the typed-in user name. The font used to display
the typed-in user name. A string that identifies this
window. The default is "X Window System". When X authorization
is requested in the configuration file for this
display and none is in use, this greeting replaces the
standard greeting. The default is "This is an unsecure
session". The font used to display the greeting. The
color used to display the greeting. The string displayed
to prompt for a user name. The xrdb utility strips trailing
white space from resource values. To add spaces at
the end of the prompt to make it more readable, add spaces
escaped with backslashes. The default is "Login: ". The
string displayed to prompt for a password. The default is
"Password: ". The font used to display both prompts.
The color used to display both prompts. A message that is
displayed when the authentication fails. The default is
"Login incorrect". The font used to display the failure
message. The color used to display the failure message.
The number of seconds that the failure message is displayed.
The default is 30. This resource specifies the
translations used for the login widget. Refer to the X
Toolkit documentation for a complete discussion of translations.
The default translation table is:
Ctrl<Key>H: delete-previous-character()
\n\
Ctrl<Key>D: delete-character() \n\
Ctrl<Key>B: move-backward-character()
\n\
Ctrl<Key>F: move-forward-character() \n\
Ctrl<Key>A: move-to-begining() \n\
Ctrl<Key>E: move-to-end() \n\
Ctrl<Key>K: erase-to-end-of-line() \n\
Ctrl<Key>U: erase-line() \n\
Ctrl<Key>X: erase-line() \n\
Ctrl<Key>C: restart-session() \n\
Ctrl<Key>\: abort-session() \n\
<Key>BackSpace:delete-previous-character()
\n\
<Key>Delete: delete-previous-character()
\n\
<Key>Return: finish-field() \n\
<Key>: insert-char() \
The actions which are supported by the widget are: Erases
the character before the cursor. Erases the character
after the cursor. Moves the cursor backward. Moves the
cursor forward. (Apologies about the spelling error.)
Moves the cursor to the beginning of the editable text.
Moves the cursor to the end of the editable text. Erases
all text after the cursor. Erases the entire text. If
the cursor is in the name field, proceeds to the password
field. If the cursor is in the password field, checks the
current name/password pair. If the name/password pair is
valid, xdm starts the session. Otherwise, the failure message
is displayed and the user is prompted again. Terminates
and restarts the server. Terminates the server,
disabling it. This is a rash action and is not accessible
in the default configuration. It can be used to stop xdm
when you are shutting the system down or using xdmshell.
Resets the X server and starts a new session. This action
can be used when the resources have been changed and you
want to test them or when the screen has been overwritten
with system messages. Inserts the character typed. Specifies
a single word argument that is passed to the session
at startup. See the sections SESSION PROGRAM and TYPICAL
USAGE. Disables access control in the server. This
action can be used when the file cannot be created by xdm.
Use this action with caution; you should probably disconnect
the machine from the network before using this
action.
MOTIF AUTHENTICATION WIDGET [Toc] [Back] This login widget is used when the greeter library,
/usr/lib/X11/xdm/libXdmDecGreet.so, is specified as the
value of the DisplayManager.greeterLib resource.
The authentication widget reads a name/password pair from
the keyboard. Many parameters can be controlled with
resources. Resources for this widget should be put into
the file named by DisplayManager.DISPLAY.resources. All
these resources have reasonable default values, so it is
not necessary to specify any of them. The coordinates in
pixels of the upper left corner of the logo displayed on
the login screen. A value of -1 for LogoX or LogoY causes
an appropriate default to be calculated. The foreground
color of the logo displayed across the top of the login
screen. The default color is rgb:8182/0604/2c28. The
logo background color. The default is White. The foreground
color of the logo on monochrome systems. The
default is Black. The logo background color on monochrome
systems. The default is White. If set to True, the root
window will be painted the specified solid color and, when
the login widget is destroyed, the root window will be
restored to its default pattern. The default value is
True. The root window color in the login screen. The
default value is rgb:3030/5050/6060. The name of the file
containing a bitmap in X bitmap format that is displayed
in place of the default logo. The name of the file containing
the shape mask bitmap to use when displaying the
logo. The color of the text displayed in a message box on
a failed login. The greeting text displayed as a title in
the login box. The default value is "Tru64 UNIX on CLIENTHOST".
'CLIENTHOST' is a macro that xrdb replaces with
the name of the xdm host. The greeting text displayed as
a secondary (smaller) title in the login box. The default
value is "formerly \D\E\C OSF/1". 'DEC' must be escaped
or else the xrdb cpp will treat it as a macro. The color
of the greeting text in the login box. The default is
Black. The color of the text of the prompt strings in the
login box. The default is Black. The color of the
response text in the login box. The default is Black.
The font used to display the greeting text in the login
box. The default is '*-new century schoolbook-bold-i-normal-*-240-*'.
The font used to display the strings in the
login box. The default is '*-new century schoolbookmedium-r-normal-*-180-*'.
The font used to display the
response text in the login box. The default is '*-new
century schoolbook-medium-r-normal-*-180-*'.
The program named in the DisplayManager.DISPLAY.setup
resource is run after the server is reset, but before the
Login window is offered. The file is typically a shell
script. It is run as root, so you should be careful about
security. This is the place to change the root background
or bring up other windows that should appear on the screen
along with the Login widget.
In addition to any specified by DisplayManager.exportList,
the following environment variables are passed: Sets the
associated display name. Sets the value of DisplayManager.DISPLAY.systemPath.
Sets the value of DisplayManager.DISPLAY.systemShell.
May be set to an authority
file.
Note that since xdm grabs the keyboard, any other windows
will not be able to receive keyboard input. However, they
will be able to interact with the mouse, so check for
potential security holes here. If DisplayManager.DISPLAY.grabServer
is set, Xsetup_0 will not be able to connect
to the display at all. Resources for this program can
be put into the file named by DisplayManager.DISPLAY.resources.
The Xresources file is loaded onto the display as a
resource database using xrdb. As the authentication widget
reads this database before starting up, it usually contains
parameters for that widget:
xlogin*login.translations: #override\ Ctrl<Key>R: abortdisplay()\n\
<Key>F1: set-session-argument(failsafe) finish-field()\n\
<Key>Return: set-session-argument() finishfield()
xlogin*borderWidth: 3 xlogin*greeting: CLIENTHOST
#ifdef COLOR xlogin*greetColor: CadetBlue xlogin*failColor:
red #endif
Please note the translations entry; it specifies a few new
translations for the widget which allow users to escape
from the default session (and avoid troubles that may
occur in it). Note that if #override is not specified,
the default translations are removed and replaced by the
new value, not a very useful result as some of the default
translations are quite useful (such as "<Key>: insert-char
()" which responds to normal typing).
This file may also contain resources for the setup program
and chooser.
The program specified by the DisplayManager.DISPLAY.startup
resource is typically shell script. It is run
as root and needs to be careful about security. This is
the place to put commands that add entries to /etc/utmp
(the sessreg program may be useful here), mount users'
home directories from file servers, display the message of
the day, or abort the session if logins are not allowed.
In addition to any specified by DisplayManager.exportList,
the following environment variables are passed: Sets the
associated display name. Sets the initial working directory
of the user. Sets The user name. Sets the value of
DisplayManager.DISPLAY.systemPath. Sets the value of DisplayManager.DISPLAY.systemShell.
May be set to an authority
file.
No arguments are passed to the script. xdm waits until
this script exits before starting the user session. If
the exit value of this script is non-zero, xdm discontinues
the session and starts another authentication cycle.
The sample Xstartup file shown here prevents login while
the file /etc/nologin exists. Thus this is not a complete
example, but simply a demonstration of the available functionality.
Here is a sample Xstartup script:
#!/bin/sh # # Xstartup # # This
program is run as root after the user is verified #
if [ -f /etc/nologin ]; then xmessage-file
/etc/nologin exit 1 fi sessreg-a-l
$DISPLAY-x /usr/X11R6/lib/xdm/Xservers $USER
/usr/X11R6/lib/xdm/GiveConsole exit 0
The Xsession program (specified by the DisplayManager.DISPLAY.session
resource) is the command that is run as the
user's session. It is run with the permissions of the
authorized user.
In addition to any specified by DisplayManager.exportList,
the following environment variables are passed: Sets the
associated display name. Sets the initial working directory
of the user. Sets the user name. PATH sets the
value of DisplayManager.DISPLAY.userPath. Sets the user's
default shell (from getpwnam). XAUTHORITY may be set to a
non-standard authority file. KRB5CCNAME may be set to a
Kerberos credentials cache file.
At most installations, Xsession should look in $HOME for a
file which contains commands that each user would like to
use as a session. Xsession should also implement a system
default session if no user-specified session exists. See
the section Typical Usage.
An argument may be passed to this program from the authentication
widget using the `set-session-argument' action.
This can be used to select different styles of session.
One good use of this feature is to allow the user to
escape from the ordinary session when it fails. This
allows users to repair their own if it fails, without
requiring administrative intervention. The example following
demonstrates this feature.
This example recognizes the special "failsafe" mode, specified
in the translations in the Xresources file, to provide
an escape from the ordinary session. It also
requires that the file be executable so we do not have to
guess what shell it wants to use.
#!/bin/sh # # Xsession # # This
is the program that is run as the client # for the
display manager.
case $# in 1) case $1 in
failsafe) exec xterm -geometry
80x24-0-0 ;; esac esac
startup=$HOME/.xsession resources=$HOME/.Xresources
if [ -f "$startup" ]; then exec "$startup"
else if [ -f "$resources" ]; then
xrdb -load "$resources" fi
twm & xman -geometry +10-10 &
exec xterm -geometry 80x24+10+10 -ls fi
The user's file might look something like this example.
Do not forget that the file must have execute permission.
#! /bin/csh # no -f in the previous line so
.cshrc gets run to set $PATH twm & xrdb -merge
"$HOME/.Xresources" emacs -geometry +0+50 &
xbiff -geometry -430+5 & xterm -geometry -0+50
-ls
Symmetrical with the startup program, the program specified
by the DisplayManager.DISPLAY.startup resource is run
after the user session has terminated. Run as root, it
should contain commands that undo the effects of commands
in Xstartup, removing entries from /etc/utmp or unmounting
directories from file servers. The environment variables
that were passed to the startup program are also passed to
the program specified by the DisplayManager.DISPLAY.startup
resource.
A sample Xreset script:
#!/bin/sh # # Xreset # # This
program is run as root after the session ends #
sessreg-d-l $DISPLAY-x /usr/X11R6/lib/xdm/Xservers
$USER /usr/X11R6/lib/xdm/TakeConsole exit 0
CONTROLLING THE SERVER [Toc] [Back] xdm controls local servers using POSIX signals. SIGHUP is
expected to reset the server, closing all client connections
and performing other cleanup duties. SIGTERM is
expected to terminate the server. If these signals do not
perform the expected actions, the resources DisplayManager.DISPLAY.resetSignal
and DisplayManager.DISPLAY.termSignal
can specify alternate signals.
To control remote terminals not using XDMCP, xdm searches
the window hierarchy on the display and uses the protocol
request KillClient in an attempt to clean up the terminal
for the next session. This may not actually kill all of
the clients, as only those which have created windows will
be noticed. XDMCP provides a more sure mechanism; when
xdm closes its initial connection, the session is over and
the terminal is required to close all other connections.
xdm responds to two signals: SIGHUP and SIGTERM. When
sent a SIGHUP, xdm rereads the configuration file, the
access control file, and the servers file. For the
servers file, it notices if entries have been added or
removed. If a new entry has been added, xdm starts a session
on the associated display. Entries which have been
removed are disabled immediately, meaning that any session
in progress will be terminated without notice and no new
session will be started.
When sent a SIGTERM, xdm terminates all sessions in
progress and exits. This can be used when shutting down
the system.
xdm attempts to mark its various sub-processes for ps(1)
by editing the command line argument list in place.
Because xdm cannot allocate additional space for this
task, it is useful to start xdm with a reasonably long
command line (using the full path name should be enough).
Each process which is servicing a display is marked -display.
|
