NAME

xdm − X Display Manager

SYNOPSIS

xdm [-config configuration_file] [-daemon] [-debug debug_level] [-error error_log_file] [-nodaemon] [-resources resource_file] [-server server_entry] [-session session_program] [-xrm resource_specification]

DESCRIPTION

Xdm manages a collection of X displays, both local and possibly remote — the emergence of X terminals guided the design of several parts of this system, along with the development of the X Consortium standard XDMCP, the X Display Manager Control Protocol).  It is designed to provide services similar to that provided by init, getty and login on character terminals:  prompting for login/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 process.  In the xdm context, it is an arbitrary session manager.  This is because in a windowing environment, a user’s login shell process would not necessarily have any terminal-like interface with which to connect. 

Until real session managers become widely available, the typical xdm substitute would be either a window manager with an exit option, or a terminal emulator running a shell - with the condition that the lifetime of the terminal emulator is the lifetime of the shell process that it is running - thus degenerating the X session to an emulation of the character-based terminal session. 

When the session is terminated, xdm resets the X server and (optionally) restarts the whole process. 

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, picking and choosing the things you want to change.  Pay particular attention to the Xsession section, which will describe how to set up the style of session desired. 

OPTIONS

First, note that all of these options, except -config, specify values which can also be specified in the configuration file as resources. 

-config configuration_file
Specifies a resource file which specifies the remaining configuration parameters.  If no file is specified and the file /etc/xdm/xdm-config exists, xdm will use it. 

-daemon
Specifies “true” as the value for the DisplayManager.daemonMode resource.  This makes xdm close all file descriptors, disassociate the controlling terminal and put itself in the background when it first starts up (just like the host of other daemons).  It is the default behavior. 

-debug debug_level
Specifies the numeric value for the DisplayManager.debugLevel resource.  A non-zero value causes xdm to print piles 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. 

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

-nodaemon
Specifies “false” as the value for the DisplayManager.daemonMode resource. 

-resources resource_file
Specifies the value for the DisplayManager∗resources resource.  This file is loaded using xrdb (1) to specify configuration parameters for the authentication widget. 

-server server_entry
Specifies the value for the DisplayManager.servers resource.  See the section below which describes this resource in depth. 

-udpPort port_number
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 probably not be changed except for debugging. 

-session session_program
Specifies the value for the DisplayManager∗session resource.  This indicates the program to run when the user has logged in as the session. 

-xrm resource_specification
This allows an arbitrary resource to be specified, just as most toolkit applications.

RESOURCES

At many stages the actions of xdm can be controlled through the use of the configuration file, which is in the familiar X resource format.  See Jim Fulton’s article on resource files (doc/tutorials/resources.txt) for a description of the format.  Some resources modify the behavior of xdm on all displays, while others modify its behavior on one 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 example, DisplayManager.expo_0.startup is the name of the resource which defines the startup shell file on the “expo:0” display.  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 the dots and colons when generating the resource name. 

DisplayManager.servers
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.  Each entry indicates a display which should constantly be managed and which is not using XDMCP.  Each entry consists of two, three or four parts.  The first field is the display name.  The next field is optional, and is the class string of the display.  The next field is the display type.  Finally for local servers, there may follow a command line to start the server.  A typical entry for local display number 0 would be:

   :0 Acorn-RISC_iX local /usr/bin/X11/X :0
 

If no class string is required, this may be shortened to:

   :0 local /usr/bin/X11/X :0
 

The display types are:

 locala local display, i.e. one which has a server program to run
foreigna remote display, i.e. one which has no server program to run
 

The display name must be something that can be passed in the -display option to any X program.  This string is used in the display-specific resources to specify the particular display, so be careful to match the names (e.g. use ":0 local /usr/bin/X11/X :0" instead of "localhost:0 local /usr/bin/X11/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 portion of the resource.  This is useful if you have a large collection of similar displays (like 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, so perhaps your X terminal documentation describes a reasonably standard display class string for your device. 

DisplayManager.requestPort
This indicates the UDP port number which xdm uses to listen for incoming XDMCP requests.  Unless you need to debug the system, leave this with it’s default value of 177. 

DisplayManager.errorLogFile
Error output is normally directed at the system console.  To redirect it simply set this resource to any file name.  A method to send these messages to syslog should be developed for systems which support it; however the wide variety of "standard" interfaces precludes any system-independent implementation.  This file also contains any output directed to stderr by Xstartup, Xsession and Xreset, so it will contain descriptions of problems in those scripts as well. 

DisplayManager.debugLevel
A non-zero value specified for this integer resource will enable reams of debugging information to be printed.  It also disables daemon mode which would redirect the information into the bit-bucket.  Specifying a non-zero debug level also allows non-root users to run xdm which would normally not be useful. 

DisplayManager.daemonMode
Normally, xdm attempts to make itself into an unassociated daemon process.  This is accomplished by forking and leaving the parent process to exit, then closing file descriptors and mangling the controlling terminal.  When attempting to debug xdm , this is quite bothersome.  Setting this resource to "false" will disable this feature. 

DisplayManager.pidFile
The filename specified will be created to contain an ascii representation of the process-id of the main xdm process.  This is quite useful when reinitializing the system.  Xdm also uses file locking to attempt to eliminate multiple daemons running on the same machine, which would cause quite a bit of havoc. 

DisplayManager.lockPidFile
This is the resource which controls whether xdm uses file locking to keep multiple xdms from running amok.  On SYSV, this uses the lockf library call, while on BSD it uses flock.  The default value is "true". 

DisplayManager.remoteAuthDir
This is a directory name which xdm uses to temporarily store authorization files for displays using XDMCP.  The default value is /etc/xdm. 

DisplayManager.autoRescan
This boolean controls whether xdm rescans the configuration file and servers file 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. 

DisplayManager.removeDomainname
When computing the display name for XDMCP clients, the 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 for the local host when this variable is set.  By default the value is "true". 

DisplayManager.keyFile
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 manufacturer display id and the shared key.  The manufacturer display id is a string which the server transmits to xdm as part of the XDMCP protocol.  It has a format which is defined by the server manufacturer and which will normally match one of:-

     ManufacturerID-ModelNumber-SerialNumber
    -Ethernet-??:??:??:??:??:??
 

The Xarm server uses the second format by default and uses the number from an ethernet card (if attached) or 0.  The number used is that returned by gethostid(2). If an ethernet card is attached this will invariably be a number of the form 00:00:a4:xx:xx:xx, where the xx values depend on the particular ethernet card.  If the Xarm server is given a -serialNo argument on the command line the string used will be of the form Acorn-RISC_iX-<serial number>. 

The shared key is an 8 byte XDMCP authentication key encoded as 16 hex digits − alternatively a simple string may be given enclosed in either single or double quote marks.  In all cases the key is truncated to 8 bytes or (if required) extended with characters of value 0.  Each pair of hex digits is interpreted as a single character value with the first digit being the most significant. 

DisplayManager.DISPLAY.resources
This resource specifies the name of the file to be loaded by xrdb (1) as the resource data-base onto the root window of screen 0 of the display.  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 below on the authentication widget which describes the various resources which are appropriate to place in this file.  There is no default value for this resource, but the conventional name is /etc/xdm/Xresources. 

DisplayManager.DISPLAY.xrdb
Specifies the program used to load the resources.  By default, xdm uses /usr/bin/X11/xrdb. 

DisplayManager.DISPLAY.cpp
This specifies the name of the C preprocessor which is used by xrdb.

DisplayManager.DISPLAY.startup
This 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 Xstartup.  See the Xstartup section below. 

DisplayManager.DISPLAY.session
This specifies the session to be executed (not running as root). By default, /usr/bin/X11/xterm is run.  The conventional name is Xsession.  See the Xsession session below. 

DisplayManager.DISPLAY.reset
This specifies a program which is run (as root) after the session terminates. Again, by default no program is run. The conventional name is Xreset.  See the Xreset section further on in this document. 

DisplayManager.DISPLAY.openDelay

DisplayManager.DISPLAY.openRepeat

DisplayManager.DISPLAY.openTimeout

DisplayManager.DISPLAY.startAttempts
These numeric resources control the behavior of xdm when attempting to open intransigent servers.  openDelay is the length of the pause (in seconds) between successive attempts, openRepeat is the number of attempts to make, openTimeout is the amount of time to wait while actually attempting the open (i.e. the maximum time spent in the connect (2) syscall) and startAttempts 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 time, 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 openTimeout and 4 for startAttempts. 

DisplayManager.DISPLAY.pingInterval

DisplayManager.DISPLAY.pingTimeout
To discover when remote displays disappear, xdm occasionally "pings" them, using an X connection and sending XSync requests.  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.  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. 

DisplayManager.DISPLAY.terminateServer
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".

DisplayManager.DISPLAY.userPath
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.  The default value can be specified in the X system configuration file with DefUserPath, frequently it is set to ":/bin:/usr/bin:/usr/bin/X11:/usr/ucb". 

DisplayManager.DISPLAY.systemPath
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 with the DefaultSystemPath entry in the system configuration file, but it is frequently "/etc:/bin:/usr/bin:/usr/bin/X11:/usr/ucb".  Note the conspicuous absence of "." from this entry.  This is a good practise to follow for root; it avoids many common trojan horse system penetration schemes. 

DisplayManager.DISPLAY.systemShell
Xdm sets the SHELL environment variable for the startup and reset scripts to the value of this resource.  By default, it is "/bin/sh". 

DisplayManager.DISPLAY.failsafeClient
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 "Xsession" below).  By default, /usr/bin/X11/xterm is used. 

DisplayManager.DISPLAY.grabServer

DisplayManager.DISPLAY.grabTimeout
To eliminate obvious security shortcomings in the X protocol, xdm grabs the server and keyboard while reading the name/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 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 spoofed by a look-alike window on the display.  If the grab fails, xdm kills and restarts the server (if possible) and session. 

DisplayManager.DISPLAY.authorize

DisplayManager.DISPLAY.authName
authorize is a boolean resource which controls whether xdm generates and uses authorization for the server connections.  If authorization is used, authName specifies the type to use.  Currently, xdm supports MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1 − the latter uses the DES encryption facilities of the RISC iX operating system.  XDMCP connections specify which authorization types are supported dynamically, so authName may be ignored in this case, however, in the case where the display advises xdm that it supports the requested authorization it will be used.  Notice that when using XDMCP the display class is not known when the authorization protocol is selected and so the class of the resource looked for is DisplayManager.DISPLAY.Authorize (etc).  When authorize is set for a display and authorization is not available, the user is informed by having a different message displayed in the login widget.  By default, authorize is "true"; authName is "XDM_AUTHORIZATION-1". 

DisplayManager.DISPLAY.authFile
This file is used to communicate the authorization data from xdm to local servers, 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. 

DisplayManager.DISPLAY.resetForAuth
The original implementation of authorization in the sample server reread the authorization file at server reset time, instead of when checking the initial connection.  As 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

DisplayManager.DISPLAY.userAuthDir
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.  By default it uses "/tmp". 

CONTROLLING THE SERVER

Xdm controls local servers using POSIX signals.  SIGHUP is expected to reset the server, closing all client connections and performing other clean up duties.  SIGTERM is expected to terminate the server.  If these signals do not perform the expected actions, xdm will not perform properly. 

To control remote servers 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 it’s initial connection, the session is over and the terminal is required to close all other connections. 

CONTROLLING XDM

Xdm responds to two signals: SIGHUP and SIGTERM.  When sent a SIGHUP, xdm rereads the configuration file and the file specified by the DisplayManager.servers resource and 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 the various sub-processes for ps(1) by editing the command line argument list in place.  Because xdm can’t allocate additional space for this task, it is useful to start xdm with a reasonably long command line (15 to 20 characters should be enough).  Each process which is servicing a display is marked "-<Display-Name>". 

AUTHENTICATION WIDGET

The authentication widget is an application which reads a name/password pair from the keyboard.  As this is a toolkit client, 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 have reasonable default values, so it is not necessary to specify any of them. 

xlogin.Login.width, xlogin.Login.height, xlogin.Login.x, xlogin.Login.y
The geometry of the login widget is normally computed automatically.  If you wish to position it elsewhere, specify each of these resources.

xlogin.Login.foreground
The color used to display the typed-in user name.

xlogin.Login.font
The font used to display the typed-in user name.

xlogin.Login.greeting
A string which identifies this window. The default is "Welcome to the X Window System".

xlogin.Login.unsecureGreeting
When X authorization is requested in the configuration file for this display and none is in use, this greeting replaces the standard greeting.  It’s default value is "This is a nonsecure session"

xlogin.Login.greetFont
The font used to display the greeting.

xlogin.Login.greetColor
The color used to display the greeting.

xlogin.Login.namePrompt
The string displayed to prompt for a user name. Xrdb strips trailing white space from resource values, so to add spaces at the end of the prompt (usually a nice thing), add spaces escaped with backslashes.  The default is "Login:  "

xlogin.Login.passwdPrompt
The string displayed to prompt for a password. The default is "Password:  ".

xlogin.Login.promptFont
The font used to display both prompts.

xlogin.Login.promptColor
The color used to display both prompts.

xlogin.Login.fail
A message which is displayed when the authentication fails. The default is "Login Failed, please try again".

xlogin.Login.failFont
The font used to display the failure message.

xlogin.Login.failColor
The color used to display the failure message.

xlogin.Login.failTimeout
The time (in seconds) that the fail message is displayed. The default is 30 seconds.

xlogin.Login.translations
This specifies the translations used for the login widget.  Refer to the X Toolkit documentation for a complete discussion on 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:

delete-previous-character
Erases the character before the cursor.

delete-character
Erases the character after the cursor.

move-backward-character
Moves the cursor backward.

move-forward-character
Moves the cursor forward.

move-to-begining
(Apologies about the spelling error.) Moves the cursor to the beginning of the editable text.

move-to-end
Moves the cursor to the end of the editable text.

erase-to-end-of-line
Erases all text after the cursor.

erase-line
Erases the entire text.

finish-field
If the cursor is in the name field, proceeds to the password field; if the cursor is in the password field, check the current name/password pair.  If the name/password pair are valid, xdm starts the session.  Otherwise the failure message is displayed and the user is prompted to try again. 

abort-session
Terminates and restarts the server.

abort-display
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 shutting the system down. 

restart-session
Resets the X server and starts a new session.  This 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.

insert-char
Inserts the character typed.

set-session-argument
Specifies a single word argument which is passed to the session at startup. See the sections on Xsession and Typical usage. 

allow-all-access
Disables access control in the server, this can be used when the .Xauthority file cannot be created by xdm.  Be very careful using this, it might be better to disconnect the machine from the network before doing this.

The Xstartup file

This file is typically a shell script.  It is run as "root" and should be very careful about security.  This is the place to put commands which make fake entries in /etc/utmp, mount users’ home directories from file servers, display the message of the day, or abort the session if logins are not allowed.  Various environment variables are set for the use of this script:

 DISPLAYis set to the associated display name
HOMEis set to the home directory of the user
USERis set to the user name
PATHis set to the value of DisplayManager.DISPLAY.systemPath
SHELLis set to the value of DisplayManager.DISPLAY.systemShell
XAUTHORITYmay be set to an authority file
 

No arguments of any kind 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 immediately and starts another authentication cycle. 

The Xsession program

This is the command which is run as the user’s session.  It is run with the permissions of the authorized user, and has several environment variables specified:

 DISPLAYis set to the associated display name
HOMEis set to the home directory of the user
USERis set to the user name
PATHis set to the value of DisplayManager.DISPLAY.userPath
SHELLis set to the user’s default shell (from /etc/passwd)
XAUTHORITYmay be set to a non-standard authority file
 

At most installations, Xsession should look in $HOME for a file .xsession which would contain commands that each user would like to use as a session.  This would replace the system default session.  Xsession should also implement the system default session if no user-specified session exists.  See the section Typical Usage below. 

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 very good use of this feature is to allow the user to escape from the ordinary session when it fails.  This would allow users to repair their own .xsession if it fails, without requiring administrative intervention.  The section on typical usage demonstrates this feature. 

The Xreset file

Symmetrical with Xstartup, this script is run after the user session has terminated.  Run as root, it should probably contain commands that undo the effects of commands in Xstartup, removing fake entries from /etc/utmp or unmounting directories from file servers.  The collection of environment variables that were passed to Xstartup are also given to Xreset. 

Typical Usage

Actually, xdm is designed to operate in such a wide variety of environments that "typical" is probably a misnomer.  However, this section will focus on making xdm a superior solution to traditional means of starting X from /etc/ttys or manually. 

First off, the xdm configuration file should be set up.  A good thing to do is to make a directory (/etc/xdm comes immediately to mind) which will contain all of the relevant files.  Here is a reasonable configuration file, which could be named xdm-config :

  DisplayManager.servers:/etc/xdm/Xservers
DisplayManager.errorLogFile:/etc/xdm/xdm-errors
DisplayManager.pidFile:/etc/xdm/xdm-pid
DisplayManager∗resources:/etc/xdm/Xresources
DisplayManager∗session:/etc/xdm/Xsession
DisplayManager._0.authorize:true
DisplayManager∗authorize:false
 

As you can see, this file simply contains references to other files.  Note 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 /etc/xdm/Xservers contains the list of displays to manage.  Most workstations have only one display, numbered 0, so the file will look 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 /etc/xdm/xdm-errors will contain error messages from xdm and anything output to stderr by Xstartup, Xsession or Xreset.  When you have trouble getting xdm working, check this file to see if xdm has any clues to the trouble. 

The next configuration entry, /etc/xdm/Xresources, is loaded onto the display as a resource database using xrdb (1).  As the authentication widget reads this database before starting up, it usually contains parameters for that widget:

 xlogin∗login.translations: #override\
<Key>F1: set-session-argument(failsafe) finish-field()\n\
<Key>Return: set-session-argument() finish-field()
xlogin∗borderWidth: 3
#ifdef COLOR
xlogin∗greetColor: #f63
xlogin∗failColor: red
xlogin∗Foreground: black
xlogin∗Background: #fdc
#else
xlogin∗Foreground: black
xlogin∗Background: white
#endif
 

The various colors specified here look reasonable on several of the displays we have, but may look awful on other monitors.  As X does not currently have any standard color naming scheme, you might need to tune these entries to avoid disgusting results.  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 (like "<Key>: insert-char ()" which responds to normal typing). 

The Xstartup file used here simply prevents login while the file /etc/nologin exists.  As there is no provision for displaying any messages here (there isn’t any core X client which displays files), the user will probably be baffled by this behavior.  I don’t offer this as 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
exit 1
fi
exit 0

The most interesting script is Xsession.  This version recognizes the special "failsafe" mode, specified in the translations in the Xresources file above, to provide an escape from the ordinary session:

 #!/bin/sh
#
# Xsession
#
# This is the program that is run as the client
# for the display manager.  This example is
# quite friendly as it attempts to run a per-user
# .xsession file instead of forcing a particular
# session layout
#

case $# in
1)
case $1 in
failsafe)
exec xterm -geometry 80x24-0-0 -ls
;;
esac
esac

startup=$HOME/.xsession
resources=$HOME/.Xresources

if [ -f $startup ]; then
exec /bin/sh $startup
else
if [ -f $resources ]; then
xrdb -load $resources
fi
twm &
exec xterm -geometry 80x24+10+10 -ls
fi
 

No Xreset script is necessary, so none is provided. 
 

SOME OTHER POSSIBILITIES

You can also use xdm to run a single session at a time, using the 4.3 init options or other suitable daemon by specifying the server on the command line:

 xdm -server ":0 SUN-3/60CG4 local /usr/bin/X :0"
 

Or, you might have a file server and a collection of X terminals.  The configuration for this could look identical to the sample above, except the Xservers file might look like:

 extol:0 VISUAL-19 foreign
exalt:0 NCD-19 foreign
explode:0 NCR-TOWERVIEW3000 foreign
 

This would direct xdm to manage sessions on all three of these terminals.  See the section "Controlling Xdm" above for a description of using signals to enable and disable these terminals in a manner reminiscent of init(8). 

One thing that xdm isn’t very good at doing is coexisting with other window systems.  To use multiple window systems on the same hardware, you’ll probably be more interested in xinit . 

SEE ALSO

X(1), xinit(1) and XDMCP

BUGS

Currently xdm does not implement the IndirectQuery functionality documented in the XDMCP manual. 

COPYRIGHT

Copyright 1988, Massachusetts Institute of Technology. 
See X(1) for a full statement of rights and permissions. 

AUTHOR

Keith Packard, MIT X Consortium

X Version 11  —  Release 4