xdm(1X) xdm(1X)NAME xdm - manages X displays SYNOPSIS xdm [-config configuration-file] [-daemon] [-debug debug-level] [-error error-log-file] [-nodaemon] [-resources resource-file] [-server server-entry] [-session session-program] [-udpPort port-number] [-xrm resource-specification] DESCRIPTION xdm manages a collection of X displays, both local and pos- sibly remote. The emergence of X terminals has guided the design of several parts of this system, along with the development of the X Display Manager Control Protocol (XDMCP) by the X Consortium. It is designed to provide ser- vices similar to that provided by init, getty, and login on character terminals: prompting for login name and password, authenticating the user and running a session.rA session is defined by the lifetime of a particular UNIXprocess; in the traditional character-based terminal world, it is the user's login shell process. In the context of xdm, 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. If the substitute is a terminal emulator, the lifetime of the terminal emulator is the lifetime of the shell process that it is running. In this case, the X session is an emulation of the character-based terminal session. When the session is terminated, xdm resets the X server and (optionally) res- tarts the whole process. Because xdm provides the first interface that users see, it is designed to be simple to use and easy to customize to the needs of a particular site. The xdm command has many op- tions, 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 section ``The Xsession Command'' later in the ``Descrip- tion'' section, which describes how to set up the style of session desired. Options All the options listed below, except for -config, specify values that can also be specified in the configuration file as resources. November, 1990 1
xdm(1X) xdm(1X)-config configuration_file Specifies a resource file that specifies the remain- ing configuration parameters. If no file is speci- fied and the file /usr/lib/X11/xdm/xdm-config ex- ists, xdm uses it. -daemon Specifies TRUE as the value for the resource DisplayManager.daemonMode. This makes xdm close all file descriptors, disassociate the controlling ter- minal, and put itself in the background when it first starts up (just like the host of other dae- mons). It is the default behavior. -debug debug_level Specifies the numeric value for the resource DisplayManager.debugLevel. A nonzero value causes xdm to print debugging statements to the terminal; it also disables the resource DisplayManager.daemonMode, forcing xdm to run syn- chronously. -error error_log_file Specifies the value for the resource DisplayManager.errorLogFile. This file contains er- rors from xdm as well as anything written to the standard error by the various scripts and commands run during the session. -nodaemon Specifies FALSE as the value for the resource DisplayManager.daemonMode. -resources resource_file Specifies the value for the resource DisplayManager*resources. This file is loaded with the xrdb(1X) command to specify configuration param- eters for the authentication widget. -server server_entry Specifies the value for the resource DisplayManager.servers. See the next section, ``Resources'', which describes this resource in depth. -session session_program Specifies the value for the DisplayManager*session resource, which is the commands to run as the ses- sion when the user logs in. -udpPort port_number Specifies the value for the DisplayManager.requestPort resource, which is the 2 November, 1990
xdm(1X) xdm(1X)port number that xdm monitors for XDMCP requests. Because XDMCP uses the registered, well-known UDP port 177, you should specify another port number only for debugging. -xrm resource_specification Allows an arbitrary resource to be specified, just as most X 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 ``Using the Resource Manager'' in Chapter 10, ``Application Utility Functions,'' in Xlib - C Language Interface for information on resource files and a description of the 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. As an example, the name of the resource de- fining the startup script on the expo:0 display is DisplayManager.expo.0.startup. Because the resource manager uses colons to separate the name of the resource from its value and dots to separate resource name parts, xdm substi- tutes underscores for the dots and colons when generating the resource name. DisplayManager.autoRescan Specifies whether xdm rescans the configuration file and server file after a session terminates and the files have changed. The default value is TRUE. You can force xdm to reread these files by sending a SIGHUP to the main process. DisplayManager.daemonMode If FALSE, prevents xdm from becoming an unassociated daemon process. Specifying FALSE is useful when de- bugging xdm. DisplayManager.debugLevel Prints debugging information if you specify a nonzero value for this integer resource. A nonzero value also disables daemon mode, which would normal- ly redirect the information into the bit bucket. A nonzero value also allows non-root users to run xdm, which normally would not be useful. DisplayManager.DISPLAY.authFile Specifies a file used to communicate the authoriza- tion data from xdm to the server, using the -auth server command-line option. It should be kept in a November, 1990 3
xdm(1X) xdm(1X)directory that is not world-writable because it could easily be removed, disabling the authorization mechanism in the server. DisplayManager.DISPLAY.authorizeDisplayManager.DISPLAY.authNameControls whether xdm generates and uses authoriza-tion for the server connections. If authorizationis used, authName specifies the type to use.Currently, xdm supports only MIT-MAGIC-COOKIE-1 au-thorization. XDM-AUTHORIZATION-1 could be supportedas well, but DES is not generally distributable.XDMCP connections specify which authorization typesare supported dynamically, so authName is ignored inthis case. When authorize is set for a display andauthorization is not available, the user is informedby having a different message displayed in the loginwidget. By default, authorize is TRUE; authName isMIT-MAGIC-COOKIE-1.DisplayManager.DISPLAY.cppSpecifies the name of the C preprocessor that isused by xrdb.DisplayManager.DISPLAY.failsafeClientSpecifies the program that xdm falls back to if thedefault session fails to execute. This command isexecuted with no arguments, but executes using thesame environment variables as the session would havehad. See ``The Xsession Command'' later in the``Description'' section. By default,/usr/bin/X11/xterm is used.DisplayManager.DISPLAY.grabServerDisplayManager.DISPLAY.grabTimeout Specifies that xdm grab the keyboard and, optional- ly, the server, while reading the login name and password. This eliminates obvious security shortcomings in the X protocol. When the grabServer resource is TRUE, xdm grabs the server and keyboard; when the resource is FALSE, xdm only grabs the key- board. The grabTimeout resource specifies the maximum time for xdm to wait for the grab to succeed. The grab may fail if some other client has grabbed the server or if network latencies are high. This resource has a default value of 3 seconds; you should be cautious when raising it because a user can be fooled by a look-alike window on the display. If the grab fails, xdm terminates and restarts the server (if possible) and session. 4 November, 1990
xdm(1X) xdm(1X)DisplayManager.DISPLAY.openDelayDisplayManager.DISPLAY.openRepeatDisplayManager.DISPLAY.openTimeoutDisplayManager.DISPLAY.startAttemptsControl the behavior of xdm when attempting to openintransigent servers. The openDelay resource is thelength of the pause (in seconds) between successiveattempts. The openRepeat resource is the number ofattempts to make. The openTimeout resource is theamount of time to wait while actually attempting theopen (that is, the maximum time spent in theconnect(2) system call), and the startAttemptsresource is the number of times this entire processis repeated before giving up on the server. AfteropenRepeat attempts have been made or ifopenTimeout seconds elapse in any particular at-tempt, xdm terminates and restarts the server, at-tempting to connect again. This process is repeatedstartAttempts times, at which point the display isdeclared dead and disabled. Although this behaviormight seem arbitrary, it has been empiricallydeveloped and works quite well on most systems. Thedefault values are 5 for openDelay, 5 for open-Repeat, 30 for openTimeout, and 4 for startAttempts.DisplayManager.DISPLAY.pingIntervalDisplayManager.DISPLAY.pingTimeout Specifies values that are used to discover when re- mote displays disappear. xdm uses an X connection and sends periodic XSync requests. The pingInterval resource specifies the time (in minutes) between each ``ping'' attempt and 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 values are set to 5 minutes. Local displays are not pinged. Although it would seem harmless, it is unpleasant when the workstation session is terminated as a result of the server hanging for Network File System (NFS) service and not responding to the ping. DisplayManager.DISPLAY.reset Specifies a command that is run (as root) after the session terminates. By default, no command is run. The conventional name is Xreset. See ``The Xreset Script'' later in the ``Description'' section. DisplayManager.DISPLAY.resetForAuth Causes xdm to send SIGHUP to the server after set- November, 1990 5
xdm(1X) xdm(1X)ting up the file, which causes an additional server reset to occur, during which time any new authoriza- tion information is read. The original implementa- tion 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 be- fore connecting to the display, an old server would not get up-to-date authorization information. This resource solves the problem. DisplayManager.DISPLAY.resources Specifies the name of the file to be loaded by xrdb(1X) as the resource database onto the root win- dow of screen 0 of the display. This resource data- base is loaded just before the authentication pro- cedure is started, so it can control the appearance of the login window. See ``Authentication Widget'' later in the ``Description'' section, for a descrip- tion of the various resources that are appropriate to place in this file. There is no default value for this resource, but the conventional name is /usr/lib/X11/xdm/Xresources. DisplayManager.DISPLAY.session 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 Command'' later in the ``Description'' section. DisplayManager.DISPLAY.startup Specifies a command that is run (as root) after the authentication process succeeds. By default, no command is run. The conventional name for a startup file is Xstartup. See ``The Xstartup Script'' later in the ``Description'' section. DisplayManager.DISPLAY.systemPath 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 configuration file, but it is frequently /etc:/bin:/usr/bin:/usr/bin/X11:/usr/ucb. Note the conspicuous absence of the dot separator (.) from this entry. This is a good practice to follow for root; it avoids many common ``trojan horse'' system penetration schemes. DisplayManager.DISPLAY.systemShell Sets the SHELL environment variable for the startup and reset scripts to the value of this resource. By 6 November, 1990
xdm(1X) xdm(1X)default, it is /bin/sh. DisplayManager.DISPLAY.terminateServer 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.userAuthDir Creates a unique filename in the specified directory and points the environment variable XAUTHORITY at the created file. This is used when xdm is unable to write to the usual user authorization file ($HOME/.Xauthority). By default, xdm uses /tmp. DisplayManager.DISPLAY.userPath Sets the PATH environment variable for the session to this value, which should be a colon-separated list of directories (see sh(1) for details). The de- fault value can be specified in the X system confi- guration file with DefUserPath, frequently it is set to :/bin:/usr/bin:/usr/bin/X11:/usr/ucb. DisplayManager.DISPLAY.xrdb Specifies the command used to load the resources. By default, xdm uses /usr/bin/X11/xrdb. DisplayManager.errorLogFile Sends to a file the error output that is normally directed at the system console. Simply set this resource to any filename. A method to send these messages to syslog should be developed for systems that support it; however, the wide variety of ``standard'' interfaces precludes any system- independent implementation. This file also contains any output directed to the standard error by Xstart- up, Xsession, and Xreset, so it will also contain descriptions of problems in those scripts. DisplayManager.keyFile Specifies a file that contains a private key that is shared between xdm and the terminal, which is re- quired by XDM-AUTHENTICATION-1-style XDMCP authenti- cation. Each entry in the file consists of a display name and the shared key. By default, xdm does not include support for XDM-AUTHENTICATION-1 because it requires Data Encryption Standard (DES) support, which is not generally distributable. November, 1990 7
xdm(1X) xdm(1X)DisplayManager.lockPidFile Specifies whether xdm uses file locking to prevent multiple copies of xdm conflicting with each other.rOn System V systems, such as A/UX , xdm uses thelockf(3C) library call, while on BSD, xdm uses flock. The default value is TRUE. DisplayManager.pidFile Specifies a file into which an ASCII representation of the PID of the main xdm process is written. This information is quite useful when reinitializing the system. The xdm client application also uses file locking to eliminate multiple daemons running on the same machine, which would cause quite a bit of ha- voc. DisplayManager.remoteAuthDir Specifies a directory name that xdm uses to tem- porarily store authorization files for displays us- ing XDMCP. The default value is /usr/lib/X11/xdm. DisplayManager.removeDomainname Specifies that xdm remove the domain name portion of the host name if it is the same as the domain name for the local host. This avoids the confusion that can result when the resolver computes a fully quali- fied host name for the terminal. By default, the value is TRUE. DisplayManager.requestPort Specifies the UDP port number for xdm to monitor for incoming XDMCP requests. Unless you need to debug the system, use the default value of 177. DisplayManager.servers Specifies either a single server entry or the abso- lute pathname of a file that contains server en- tries, one per line. Each entry indicates a display that should constantly be managed and that is not using XDMCP. Each entry consists of three parts: a display name, a display type, and, for local servers, a command line to start the server. A typ- ical entry for local display number 0 would be: :0 local /usr/bin/X11/XmacII :0 The display types are: local Specifies a local display that has a server program to run. foreign Specifies a remote display that has no 8 November, 1990
xdm(1X) xdm(1X)server program to run. The display name must be something that can be passed in the -display option to any X command. This string is used in the display-specific resources to specify the particular display, so be careful to match the names. For example, use :0 local /usr/bin/X11/XmacII :0 instead of unix:0 local /usr/bin/X11/XmacII :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 collec- tion of similar displays 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. Controlling the server The xdm client application controls local servers using PO- SIX signals. SIGHUP is expected to reset the server by 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, xdm does not perform properly. To control remote servers not using XDMCP, xdm searches the window hierarchy on the display and uses the protocol re- quest KillClient in an attempt to clean up the terminal for the next session. This may not actually terminate all the clients, because only those that have created windows are 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. This is expected to change when better X terminal support is designed. Controlling xdm The xdm client application responds to two signals: SIGHUP and SIGTERM. When sent a SIGHUP, xdm rereads the configura- tion 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 that have been removed are disabled immediately, which means that any session in progress is terminated without notice and no new session is started. When sent a SIGTERM, xdm terminates all sessions in progress and exits. This can be used when shutting down the system. November, 1990 9
xdm(1X) xdm(1X)The xdm command attempts to mark the various subprocesses 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 com- mand line (15 to 20 characters should be enough). Each pro- cess that is servicing a display is marked -<display_name>. Authentication widget The authentication widget is an application that reads a name and password pair from the keyboard. Because xdm is an X Toolkit client application, nearly every imaginable param- eter 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 reason- able default values, so it is not necessary to specify any of them. xlogin.Login.fail Specifies a message that is displayed when the au- thentication fails. The default is: Login Failed, please try again. xlogin.Login.failFont Specifies the font to use for the failure message. xlogin.Login.failColor Specifies the color to use for the failure message. xlogin.Login.failTimeout Specifies in seconds the time that the failure mes- sage is displayed. The default is 30 seconds. xlogin.Login.font Specifies the font to use for the typed-in user name. xlogin.Login.foreground Specifies the color to use for the typed-in user name. xlogin.Login.greetColor Specifies the color to use for the greeting. xlogin.Login.greetFont Specifies the font to use for the greeting. xlogin.Login.greeting Specifies a string that identifies this window. The default value is: Welcome to the X Window System. xlogin.Login.height 10 November, 1990
xdm(1X) xdm(1X)xlogin.Login.widthxlogin.Login.xxlogin.Login.y Specify the size and position of the login widget whose geometry is normally computed automatically. If you wish to position it elsewhere, specify each of these resources. xlogin.Login.namePrompt Specifies the string to display when prompting for a user name. The xrdb(1X) command strips trailing white space from resource values, so to add spaces at the end of the prompt, add spaces escaped by backslashes. The default is Login:. xlogin.Login.passwdPrompt Specifies the string to display when prompting for a password. The default is Password:. xlogin.Login.promptColor Specifies the color to use for both prompts. xlogin.Login.promptFont Specifies the font to use for both prompts. xlogin.Login.translations Specifies the translations used for the login widg- et. Refer to the X Toolkit documentation for a com- plete discussion on translations. The default translation table is as follows: 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-beginning() \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() \ xlogin.Login.unsecureGreeting Replaces the standard greeting with the specified string when X authorization is requested in the con- figuration file for the display and none is in use. November, 1990 11
xdm(1X) xdm(1X)The default value is: This is an unsecure session. Actions supported by the widget are as follows: abort-display Terminates the server, disabling it. This is a rash action and is not accessible in the default confi- guration. It can be used to stop xdm when shutting the system down or when using xdmshell. abort-session 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 xdm. Caution: disconnect the machine from the network be- fore using this action. delete-character Erases the character after the cursor. delete-previous-character Erases the character before the cursor. erase-line Erases the entire text. erase-to-end-of-line Erases all text after the cursor. finish-field 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 and password. If the name and password are valid, xdm starts the session. Otherwise, the failure message is displayed and the user is prompted to try again. insert-char Inserts the character typed. move-backward-character Moves the cursor backward. move-forward-character Moves the cursor forward. move-to-beginning Moves the cursor to the beginning of the editable 12 November, 1990
xdm(1X) xdm(1X)text. move-to-end Moves the cursor to the end of the editable text. 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. set-session-argument Specifies a single word argument that is passed to the session at startup. See ``The Xsession Com- mand'' and ``Typical Usage'' later in the ``Descrip- tion'' section. The Xstartup script The Xstartup script is run as root and should be very care- ful about security. This is the place to put commands that make fake entries in /etc/utmp, mount users' home direc- tories from file servers, display the message of the day, or terminate the session if logins are not allowed. You can set the following environment variables for this script: DISPLAY Specifies the associated display name. HOME Specifies the home directory of the user. PATH Specifies a value that is the same as the value of DisplayManager.DISPLAY.systemPath. SHELL Specifies a value that is the same as the value of DisplayManager.DISPLAY.systemShell. USER Specifies the user's login name. XAUTHORITY Specifies an authority file, if any. No arguments of any kind are passed to this script. The xdm command waits until this script exits before starting the user session. If the exit value of this script is nonzero, xdm discontinues the session immediately and starts another authentication cycle. The Xsession command The Xsession command is run as the user's session. It is run with the permissions of the authorized user, and uses the following environment variables: DISPLAY Specifies the associated display name. November, 1990 13
xdm(1X) xdm(1X)HOME Specifies the home directory of the user. PATH Specifies a value that is the same as the value of DisplayManager.DISPLAY.userPath. SHELL Specifies the user's default shell (from /etc/passwd). USER Specifies user's login name. XAUTHORITY Specifies an authority file that may be nonstandard. At most installations, Xsession should look in $HOME for the file .xsession which would contain commands that each user would like to use as a session. This would replace the sys- tem default session. Xsession should also implement the sys- tem default session if no user-specified session exists. See ``Typical Usage'' later in the ``Description'' section. An argument may be passed to this command from the authenti- cation widget by 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 allows users to repair their own .xsession if it fails, without requiring administrative intervention. See ``Typical Usage'' later in the ``Description'' section for information this feature. The Xreset script You can run an Xreset script after the user session has ter- minated. 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 Because xdm is designed to operate in such a wide variety of environments, there is probably no real ``typical'' usage. However, this section focuses on making xdm a superior solu- tion to traditional means of starting X from /etc/inittab or manually. First, the xdm configuration file should be set up. A good thing to do is to make a directory (/usr/lib/X11/xdm comes immediately to mind) to contain all relevant files. The fol- lowing example is a listing of a configuration file, which could be named xdm-config: DisplayManager.servers: /usr/lib/X11/xdm/Xservers 14 November, 1990
xdm(1X) xdm(1X)DisplayManager.errorLogFile: /usr/lib/X11/xdm/xdm-errors DisplayManager.pidFile: /usr/lib/X11/xdm/xdm-pid DisplayManager*resources: /usr/lib/X11/xdm/Xresources DisplayManager*startup: /usr/lib/X11/xdm/Xstartup DisplayManager*session: /usr/lib/X11/xdm/Xsession DisplayManager._0.authorize: TRUE DisplayManager*authorize: FALSE As you can see, this file simply contains references to oth- er files. Note that some of the resources are specified with an asterisk (*) separating the components. These resources can be made unique for each different display, by replacing the asterisk with the display-name, but normally this is not very useful. See ``Resources'' earlier in the ``Descrip- tion'' section for a complete discussion. The first file /usr/lib/X11/xdm/Xservers contains the list of displays to manage. Most workstations have only one display, numbered 0, so the file looks like this: :0 local /usr/bin/X11/XmacII :0 This keeps /usr/bin/X11/XmacII running on this display and managing a continuous cycle of sessions. The file /usr/lib/X11/xdm/xdm-errors contains error messages from xdm and any other output to the standard error by Xstartup, Xsession, or Xreset. If you have trouble getting xdm to work, check this file to see if xdm has any clues to the trouble. The file /usr/lib/X11/xdm/Xresources is the next configura- tion entry and is loaded onto the display as a resource da- tabase using xrdb(1X). Because the authentication widget reads this database before starting up, it usually contains parameters for that widget, as in this example: 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 November, 1990 15
xdm(1X) xdm(1X)The various colors specified here look pleasing on many displays, but still may look awful on some. Because X does not currently have any standard color-naming scheme, you might need to tune these entries to avoid unexpected results. Please note the translations entry; it specifies a few new translations for the widget that allow users to es- cape 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. This is not a very useful result because some of the default translations are quite useful, such as <Key>: insert-char (), which responds to normal typing. The following Xstartup script simply prevents login while the file /etc/nologin exists. Because there is no provision for displaying any messages (there isn't any core X client that displays files), the user will probably be baffled by this behavior. This Xstartup script is not offered as a complete example, but simply as a demonstration of func- tionality. #!/bin/sh # # Xstartup # # This program is run as root after the user is verified. # 16 November, 1990
xdm(1X) xdm(1X)if [ -f /etc/nologin ]; then exit 1 fi exit 0 The most interesting script is Xsession. The following version recognizes the special ``failsafe'' mode, specified previously in the translations in the Xresources file, to provide an escape from the ordinary session. #!/bin/sh # # Xsession # # # Check to see if the failsafe option is desired. # case $# in 1) case $1 in failsafe) # # This is about as failsafe as possible. # Unfortunately, xterm frequently fails, but # no other client will be as useful # generally. # exec xterm -geometry 80x24+50+50 ;; esac esac startup=$HOME/.xsession resources=$HOME/.Xresources # # Check for a user-specific session and execute it. # # Note: The -x flag to test is not supported in all versions # of UNIX. Check with local authorities before # proceeding. # November, 1990 17
xdm(1X) xdm(1X)if [ -f $startup ]; then if [ -x $startup ]; then exec $startup else exec /bin/sh $startup fi else # # a simple default session. Check to see # if the user has created a default resource file # and load it. Then start the ugly window manager, # and use xterm as the session control process. # if [ -f $resources ]; then xrdb -load $resources fi twm & exec xterm -geometry 80x24+10+10 -ls fi No Xreset script is required, so none is provided. See ``The Xreset Script'' earlier in the ``Description'' section if you want to write a custom Xreset script. Other possibilities You can also use xdm to run a single session at a time, by using the 4.3 init options or another suitable daemon and specifying the server on the command line. Here are two ex- amples: xdm -server ":0 localTransient /usr/bin/X :0" xdm -server ":0 SUN-3/60CG4 local /usr/bin/X :0" You could also have a file server and a collection of X ter- minals. The configuration for this could be identical to the above sample, except that the Xservers file might look like the following: extol:0 foreign X terminal on Keith's desk exalt:0 foreign X terminal on Jim's desk explode:0 foreign X terminal on Bob's desk This file directs xdm to manage sessions on all three of these terminals. See ``Controlling xdm'' earlier in the ``Description'' section for a description of using signals to enable and disable these terminals in a manner reminis- cent of init(1M). 18 November, 1990
xdm(1X) xdm(1X)One thing that xdm is not very good at doing is coexisting with other window systems. To use multiple window systems on the same hardware, you would probably be more interested in xinit(1X). NOTES Copyright 1988, Massachusetts Institute of Technology. See X(1X) for a full statement of rights and permissions. Author: Keith Packard, MIT X Consortium SEE ALSO X(1X), xinit(1X) X Display Manager Control Protocol November, 1990 19