Digital

NAME

dxdm − X Display Manager

SYNOPSIS

dxdm [-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

The dxdm program manages a collection of X displays, both local and possibly remote.  It is designed to provide services similar to those 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 dxdm 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. 

Digital provides a simple session manager that is started for the user by default. See dxsession(1X) for more information.  Other possibilities for session managers include 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, dxdm resets the X server and (optionally) restarts the whole process. 

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

FLAGS

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 /usr/lib/X11/dxdm/dxdm-config exists, dxdm will use it. 

-daemon
Specifies “true” as the value for the DisplayManager.daemonMode resource. This makes dxdm 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). This is the default behavior. 

-debug debug_level
Specifies the numeric value for the DisplayManager.debugLevel resource. A non-zero value causes dxdm to print piles of debugging statements to the terminal; it also disables the DisplayManager.daemonMode resource, forcing dxdm to run synchronously. To interpret these debugging messages, a copy of the source code for dxdm 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 dxdm 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 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 a DisplayManager resource to be specified; attempts to set other resources will be ignored.

Resources

At many stages the actions of dxdm can be controlled through the use of the configuration file, which is in the X resource format.  Some resources modify the behavior of dxdm 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, you must substitute underscores for dots and colons in the display name to avoid ambiguity; dxdm will translate the underscores into the correct characters.)  See the description of DisplayManager.servers for how to specify the display 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 displays which should constantly be managed and which is not using XDMCP. Each entry 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 Digital-QV local /usr/bin/X11/X :0

The display types are:

local	Local display, that is, a display that has a server program to run
foreign	Remote display, that is, a display that 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. For example, if the servers file says:

    :0 Digital-QV local /usr/bin/X11/X :0

DISPLAY must be _0. Whereas if the servers file says:

    expo:0 Digital-QV local /usr/bin/X11/X :0

DISPLAY must be expo_0

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 dxdm uses to listen for incoming XDMCP requests. Unless you need to debug the system, leave this with its 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 and restart dxdm. 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 cause 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 dxdm, which would normally not be useful. 

DisplayManager.daemonMode
Normally, dxdm 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 dxdm, this is quite bothersome.  Setting this resource to “FALSE” will disable this feature. 

DisplayManager.pidFile
The filename specified is created to contain an ASCII representation of the process-id of the main dxdm process. This is quite useful when reinitializing the system.  dxdm 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 dxdm uses file locking to keep multiple dxdms from running amok. On SYSV, this uses the lockf library call, while on BSD and OSF it uses flock. The default value is "true". 

DisplayManager.remoteAuthDir
This is a directory name which dxdm uses to temporarily store authorization files for displays using XDMCP. The default value is /usr/lib/X11/dxdm. 

DisplayManager.autoRescan
This boolean controls whether dxdm rescans the configuration file and servers file after a session terminates and the files have changed.  By default it is "true". You can force dxdm 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, dxdm 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 dxdm 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. By default, dxdm does not include support for XDM-AUTHENTICATION-1, as it requires DES, which is not generally distributable. 

DisplayManager.DISPLAY.resources
This resource specifies the name of the file to be loaded by xrdb 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 /usr/lib/X11/dxdm/Xresources. 

DisplayManager.DISPLAY.xrdb
Specifies the program used to load the resources. By default, dxdm 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. The conventional name is Xstartup. If this resource is not specified, no startup program is run. See the Xstartup section below. 

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

DisplayManager.DISPLAY.reset
This specifies a program which is run (as root) after the session ter- minates. The conventional name is Xreset. If this resource is not specified, no reset program is run. See the Xreset section below. 

DisplayManager.DISPLAY.openDelay

DisplayManager.DISPLAY.openRepeat

DisplayManager.DISPLAY.openTimeout

DisplayManager.DISPLAY.startAttempts
These numeric resources control the behavior of dxdm 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 (that is, the maximum time spent in the connect 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, dxdm 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, dxdm 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. dxdm 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 "TRUE".

DisplayManager.DISPLAY.userPath
The dxdm program sets the PATH environment variable for the session to the value of this resource. It should be a colon separated list of directories, see sh(1) for a full description. The default value is "/usr/bin/X11:/usr/bin:.". 

DisplayManager.DISPLAY.systemPath
The dxdm program sets the PATH environment variable for the startup and reset scripts to the value of this resource. The default value is "/usr/bin/X11:/usr/bin:/usr/sbin".  Note the conspicuous absence of "." from this entry. This is a good practice to follow for root; it avoids many common trojan horse system penetration schemes. 

DisplayManager.DISPLAY.systemShell
The dxdm program 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, dxdm 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, dxdm 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 dxdm 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, dxdm kills and restarts the server (if possible) and session. 

DisplayManager.DISPLAY.authorize

DisplayManager.DISPLAY.authName
authorize is a boolean resource which controls whether dxdm generates and uses authorization for the server connections. If authorization is used, authName specifies the type to use. Currently, dxdm supports only MIT-MAGIC-COOKIE-1 authorization, XDM-AUTHORIZATION-1 could be supported as well, but DES is not generally distributable. XDMCP connections specify which authorization types are supported dynamically, so authName is ignored in this case. 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 "MIT-MAGIC-COOKIE-1". 

DisplayManager.DISPLAY.authFile"
This file is used to communicate the authorization data from dxdm 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. 

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 dxdm generates the authorization information just before connecting to the display, an old server would not get up-to-date authorization information.  This resource causes dxdm 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 dxdm 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

The dxdm program 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, dxdm will not perform properly. 

To control remote servers not using XDMCP, dxdm 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 dxdm closes its initial connection, the session is over and the terminal is required to close all other connections. 

Controlling dxdm

On Digital OSF/1 workstations, dxdm is started by the init process based on an entry appearing in /etc/inittab.  This entry is:

dxdm:23:respawn:/sbin/sh /sbin/dxdm.init respawn >/dev/console 2>&1

/sbin/dxdm.init is a Digital-supplied shell script that chooses the correct server and graphics option for the workstation, and passes this information to dxdm by indicating an option-specific configuration file.  The option-specific configuration files are in the directory /usr/lib/X11/dxdm and have names of the form "xdm-config.<option>", for example: "xdm-config.standard". This file, in turn, uses the appropriate option-specific server configuration file, which is also in that directory, and which is named "Xservers.<option>", for example: "Xservers.standard". 

The configuration of the workstation graphics option is controlled by the DISPLAYTYPE environment variable set in the file /etc/rc.config. 

All of the above configuration, including the appropriate entry in /etc/inittab, the correct configuration setting in /etc/rc.local, and the various configuration and server files are provided by Digital at installation of the WS software. 

The dxdm responds to two signals: SIGHUP and SIGTERM.  When sent a SIGHUP, dxdm 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, dxdm 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, dxdm terminates all sessions in progress and exits. This can be used when shutting down the system. 

dxdm attempts to mark the various sub-processes for ps by editing the command line argument list in place. Because dxdm cannot allocate additional space for this task, it is useful to start dxdm 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∗GpiLoginPrompt.foreground
The color used to display the typed-in user name.

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

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

xlogin∗GpiLoginPrompt.greetFont
The font used to display the greeting.

xlogin∗GpiLoginPrompt.greetColor
The color used to display the greeting.

xlogin∗GpiLoginPrompt.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∗GpiLoginPrompt.passwdPrompt
The string displayed to prompt for a password. The default is "Password: ".

xlogin∗GpiLoginPrompt.promptFont
The font used to display both prompts.

xlogin∗GpiLoginPrompt.promptColor
The color used to display both prompts.

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

xlogin∗GpiLoginFail.failFont
The font used to display the failure message.

xlogin∗GpiLoginFail.failColor
The color used to display the failure message.

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

xlogin∗GpiLoginPrompt.NameField.translations
This field is a standard Motif text field and all default translations for this field apply. Additional translations may be specified in the resource file(s). These are generally:

 :<Key>F1:activate() next-tab-group()
:<Key>F2:activate() next-tab-group()
:<Key>Return:activate() next-tab-group()
:Ctrl<Key>c:abort-login()
:Ctrl<Key>u:end-of-line() delete-to-start-of-line()
:Ctrl<Key>plus:allow-all-access()
 

Additional actions which are supported by the name widget are:

abort-login
Terminates and restarts the server.

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

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

xlogin∗GpiLoginPrompt.PasswordField.translations
This specifies the translations used for the user password. This is a special non-echoing widget. The default translations for this field are:

 ~Ctrl ~Meta ~Alt <Key>osfDelete:   delete-previous-character()
~Meta ~Alt <Key>osfBackSpace:    delete-previous-character()
Shift ~Meta ~Alt <Key>Tab:    prev-tab-group()
~Meta ~Alt <Key>Tab:    next-tab-group()
~Shift ~Meta ~Alt Ctrl<Key>u:    clear()
~Ctrl ~Meta ~Alt <Key>:       self-insert()
 

Additional translations may be specified in the resource file(s). These are generally:

 :<Key>F1:set-session-argument(failsafe) activate()
:<Key>F2:set-session-argument(failsafe) activate()
:<Key>Return:set-session-argument() activate()
:Ctrl<Key>c:abort-login()
:Ctrl<Key>plus:allow-all-access()
 

The actions which are supported by the no-echo text field widget are:

abort-login
Terminates and restarts the server.

activate
Causes the name and password to be evaluated.

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

cleardeletes all charactes typed into the password field. 

delete-previous-character
Erases the last character entered.

next-tab-group
Moves to the next data field.

prev-tab-group
Moves to the previous data field.

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

Logo Controls

The Digital logo has the following resources which may be used to control appearance in a limited manner. Most parameters of the logo are computed automatically. 

xlogin.LogoY
The vertical position of the logo.

xlogin.LogoColor
The color of the logo.

xlogin.LogoBW
The color of the logo on a monochrome monitor, either Black or White.

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 typically used by this script:

DISPLAY	Set to the associated display name
HOME	Set to the home directory of the user
USER	Set to the user name
TERM	Set to "none"
XAUTHORITY	May be set to an authority file
PATH	Set to the value of DisplayManager.DISPLAY.systemPath
SHELL	Set to the value of DisplayManager.DISPLAY.systemShell

No arguments of any kind are passed to the script.  dxdm waits until this script exits before starting the user session. If the exit value of this script is non-zero, dxdm 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 typeically uses several environment variables:

DISPLAY	Set to the associated display name
HOME	Set to the home directory of the user
USER	Set to the user name
TERM	Set to "none"
XAUTHORITY	May be set to a non-standard authority file
PATH	Set to the value of DisplayManager.DISPLAY.userPath
SHELL	Set to the user’s default shell (from /etc/passwd)

As mentioned previously, Digital supplies a default session manager called dxsession. However, an installation or user may prefer to replace this by means of the Xsession feature. For example, Xsession might be a file named .xsession in $HOME which invoked a desktop manager utility. Or, Xsession might be set up to try to invoke $HOME/.xsession, and then invoke dxsession if $HOME/.xsession does not exist. 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 dxdm/Xsession loop if the Xsession script contains errors; for example, the user could set the failsafe option to start a simple terminal emulator. The section on typical usage demonstrates this feature. It is important to note that without the use of this escape mechanism, the user or system administrator might have to take the system down to single user mode to replace/edit a bad Xsession file. Of course, a bad Xsession file which causes a loop within itself cannot be helped by the failsafe 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, dxdm is designed to operate in such a wide variety of environments that "typical" is probably a misnomer.  However, this section will focus on making dxdm a superior solution to traditional means of starting X from /etc/ttys or manually. 

It’s instructive to look at the default files that Digital ships.  In one version of the system, the configuration file xdm-config.standard contained the following:

DisplayManager.servers:	/usr/lib/X11/dxdm/Xservers
DisplayManager.errorLogFile:	/usr/lib/X11/dxdm/dxdm-errors
DisplayManager.pidFile:	/usr/lib/X11/dxdm/dxdm-pid
DisplayManager∗resources:	/usr/lib/X11/dxdm/Xresources
DisplayManager∗session:	/usr/lib/X11/dxdm/Xsession
DisplayManager∗authorize:	False

As you can see, this file largely contains references to other files. Note that some of the resources are specified with “∗” separating the com- ponents. 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/lib/X11/dxdm/Xservers contains the list of displays to manage. Most workstations have only one display, numbered 0, so the file might look like this:

:0 secure /usr/bin/Xws bc

The file /usr/lib/X11/dxdm/dxdm-errors will contain error messages from dxdm and anything output to stderr by Xstartup, Xsession or Xreset. When you have trouble getting dxdm to work, check this file for clues to the trouble; if there are not sufficient clues, you might want to edit the xdm.init file to invoke dxdm with the debug switch set, to obtain more detailed output; do not forget to remove that edit once debugging is finished. (You can read the xdm-errors file even if dxdm cannot run successfully -- just login by some method that bypasses dxdm, such as rlogin, or bring the system up in single user mode.)  The configuration entry, /usr/lib/X11/dxdm/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, for example:

Name (ftp-gw.pa.dec.com:):
xlogin∗GpiLoginPrompt.NameField.translations: #override\n\
  :<Key>F1: activate() next-tab-group()\n\
  :<Key>F2: activate() next-tab-group()\n\
  :<Key>Return: activate() next-tab-group()\n\
  :Ctrl<Key>c: abort-login()\n\
  :Ctrl<Key>u: end-of-line() delete-to-start-of-line()\n\
  :Ctrl<Key>plus: allow-all-access()
 xlogin∗GpiLoginPrompt.PasswordField.translations: #override\n\
  :<Key>F1: set-session-argument(failsafe) activate()\n\
  :<Key>F2: set-session-argument(failsafe) activate()\n\
  :<Key>Return: set-session-argument() activate()\n\
  :Ctrl<Key>c: abort-login()\n\
  :Ctrl<Key>plus: allow-all-access()
 #ifdef COLOR
xlogin∗greetColor:           Black
xlogin∗failColor:            red3
#endif
xlogin∗GpiLoginPrompt.greeting:     DEC OSF/1: %hostname%
xlogin∗GpiLoginPrompt.namePrompt:    Name:
xlogin∗GpiLoginPrompt.passwdPrompt:   Password:
xlogin∗GpiLoginFail.fail:        Invalid attempt to login.
xlogin.LogoY:              100

Note the translations entry; it specifies a few new translations for the widget which may allow users to escape from errors in the session, as previously discussed. 

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>: self-insert()" which corresponds to normal typing). 

The following Xsession script recognizes the special "failsafe" mode, specified in the translations in the Xresources file above, to provide an escape from the ordinary session:

# Xsession
#
# This is the program that is run as the client for the display
# manager. This example attempts to run a per-user .xsession file.
 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 $startup
 exec /bin/sh $startup
else
 if [ -f $resources ]; then
  xrdb -load $resources
 fi
 twm &
 exec xterm -geometry 80x24+10+10 -ls
fi

Here is a copy of the Xsession file which shipped with one version of the Digital system. 

#!/sbin/sh
set -x
 # NB. -x only works with OSF test, not ULTRIX test
 term="/usr/bin/X11/xterm"
[ "$#" = "1" -a \
 "$1" = "failsafe" ] && exec $term -geometry 80x24+50+50
 startup="$HOME/.xsession"
[ -x "$startup" ] && exec $startup
 sm="/usr/bin/dxsession"
[ -x "$sm" -a \
 -f /usr/lib/X11/app-defaults/DXsession -a \
 -f /usr/lib/X11/uid/DXsession -a \
 -x /usr/lib/X11/xconsole -a \
 -x /usr/lib/X11/getcons ] && exec $sm
 resources="$HOME/.Xdefaults"
[ -f "$resources" ] && /usr/bin/X11/xrdb -load $resources
 wm="/usr/bin/mwm"
if [ -f "$wm" ]
then
    $term -ls &
    $wm
else
    $term -ls
fi

Other Options

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

dxdm -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 dxdm to manage sessions on all three of these terminals. See the section "Controlling dxdm" above for a description of using signals to enable and disable these terminals in a manner reminiscent of init(8). 

One thing that dxdm is not 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. 

RELATED INFORMATION

init(8), dxsession(1X), X(1X), xinit(1X), XDMCP.