xdm man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

xdm(1X)								       xdm(1X)

NAME
       xdm - X Display Manager with support for XDMCP, host chooser

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

OPTIONS
       All  of	these  options, except -config itself, specify values that can
       also be specified in the configuration file as  resources.   Names  the
       configuration  file,  which specifies resources to control the behavior
       of xdm.	<XRoot>/lib/X11/xdm/xdm-config is the default. See the section
       CONFIGURATION FILE.  Specifies “false” as the value for the DisplayMan‐
       ager.daemonMode resource. This suppresses the normal  daemon  behavior,
       which  is  for  xdm  to close all file descriptors, disassociate itself
       from the controlling terminal, and put itself in the background when it
       first  starts  up.   Specifies  the  numeric  value for the DisplayMan‐
       ager.debugLevel resource.  A non-zero value causes xdm to print lots of
       debugging  statements to the terminal; it also disables the DisplayMan‐
       ager.daemonMode resource, forcing xdm to run synchronously.  To	inter‐
       pret  these  debugging  messages,  a copy of the source code for xdm is
       almost a necessity.  No attempt has been made to rationalize  or	 stan‐
       dardize	the output.  Specifies the value for the DisplayManager.error‐
       LogFile resource. This file contains errors from xdm as	well  as  any‐
       thing  written to stderr by the various scripts and programs run during
       the progress of the session.  Specifies the value for  the  DisplayMan‐
       ager*resources resource. This file is loaded using xrdb to specify con‐
       figuration parameters for the  authentication  widget.	Specifies  the
       value  for  the DisplayManager.servers resource. See the section SERVER
       SPECIFICATION for a description of this resource.  Specifies the	 value
       for  the DisplayManager.requestPort resource. This sets the port-number
       which xdm will monitor for XDMCP requests.  As XDMCP  uses  the	regis‐
       tered  well-known  UDP  port  177,  this resource should not be changed
       except for debugging.  Specifies the value for the  DisplayManager*ses‐
       sion  resource.	This indicates the program to run as the session after
       the user has logged in.	Allows an arbitrary resource to be  specified,
       as in most X Toolkit applications.

DESCRIPTION
       The xdm program manages a collection of X displays, which may be on the
       local host or remote servers.  The design of  xdm  was  guided  by  the
       needs  of X terminals as well as the X Consortium standard XDMCP, the X
       Display Manager Control Protocol.  xdm  provides	 services  similar  to
       those provided by init, getty and login on character terminals: prompt‐
       ing for login name and password, authenticating the user, and running a
       “session.”

       A  “session” is defined by the lifetime of a particular process; in the
       traditional character-based terminal world,  it	is  the	 user's	 login
       shell. In the xdm context, it is an arbitrary session manager.  This is
       because in a windowing environment, a user's login shell	 process  does
       not necessarily have any terminal-like interface with which to connect.
       When a real session manager is not available, a window manager or  ter‐
       minal emulator is typically used as the “session manager,” meaning that
       termination of this process terminates the user's session.

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

       When  xdm  receives  an	Indirect query via XDMCP, it can run a chooser
       process to perform an XDMCP BroadcastQuery (or an XDMCP Query to speci‐
       fied hosts) on behalf of the display and offer a menu of possible hosts
       that offer XDMCP display management. This feature is useful with X ter‐
       minals that do not offer a host menu themselves.

       Because	xdm  provides  the  first interface that users will see, it is
       designed to be simple to use and easy to customize to the  needs	 of  a
       particular  site.   xdm has many options, most of which have reasonable
       defaults.  Browse through the various sections of this reference	 page,
       picking	and  choosing  the  things  you want to change. Pay particular
       attention to the Session Program section, which will  describe  how  to
       set up the style of session desired.

       In  handling  a user's login to the X display, xdm records the login in
       the /var/adm/utmp file, the same way that a normal, non-X  login	 does.
       This  allows  the finger and who commands to show the user logged in to
       the X display.

TYPICAL USAGE
       Actually, xdm is designed to operate in such a wide variety of environ‐
       ments that typical is probably a misnomer.

       First,  the  xdm	 configuration file should be set up. Make a directory
       (usually /usr/var/X11/xdmr or /usr/lib/X11/xdm) to contain all  of  the
       relevant	 files.	  Here is a reasonable configuration file, which could
       be named xdm-config:

       DisplayManager.errorLogFile:    /usr/var/X11/xdm/xdm-errors DisplayMan‐
       ager.pidFile:	      /usr/var/X11/xdm/xdm-pid DisplayManager.keyFile:
       /usr/var/X11/xdm/xdm-keys		       DisplayManager.servers:
       /usr/var/X11/xdm/Xservers		    DisplayManager.accessFile:
       /usr/var/X11/xdm/Xaccess			    DisplayManager.greeterLib:
       /usr/shlib/X11/libXdmDecGreet.so	 DisplayManager._0.authorize:	  true
       DisplayManager._0.authName: \
		 XDM-AUTHORIZATION-1 MIT-MAGIC-COOKIE-1 DisplayManager._0.set‐
       up:	      /usr/var/X11/xdm/Xsetup_0	    DisplayManager._0.startup:
       /usr/var/X11/xdm/GiveConsole		      DisplayManager._0.reset:
       /usr/var/X11/xdm/TakeConsole   DisplayManager.local_0.authorize:	  true
       DisplayManager.local_0.authName: \
		 XDM-AUTHORIZATION-1	  MIT-MAGIC-COOKIE-1	   DisplayMan‐
       ager.local_0.setup:	   /usr/var/X11/xdm/Xsetup_0	   DisplayMan‐
       ager.local_0.startup:	 /usr/var/X11/xdm/GiveConsole	   DisplayMan‐
       ager.local_0.reset:	  /usr/var/X11/xdm/TakeConsole	   DisplayMan‐
       ager*resources:	      /usr/var/X11/xdm/Xresources  DisplayManager*ses‐
       sion:	       /usr/var/X11/xdm/Xsession  DisplayManager*authComplain:
       false DisplayManager*chooser:	     /usr/bin/X11/chooser  DisplayMan‐
       ager*keymaps:	       /usr/var/X11/xdm/Xkeymaps  !DisplayManager*lan‐
       guage:	    C

       Note that this file mainly contains references to  other	 files.	  Note
       also  that  some of the resources are specified with “*” separating the
       components.  These resources can be made unique for each different dis‐
       play,  by replacing the “*” with the display-name, but normally this is
       not very useful.	 See the RESOURCES section for a complete discussion.

       The first file, /usr/var/X11/xdm/Xservers, contains the	list  of  dis‐
       plays  to  manage that are not using XDMCP. Most workstations have only
       one display, numbered 0, so the file will look something like this:

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

       This will keep /usr/bin/X11/X running on this display and manage a con‐
       tinuous cycle of sessions.

       The  file  /usr/var/X11/xdm/xdm-errors will contain error messages from
       xdm and anything output to stderr by Xsetup_0,  GiveConsole,  Xsession,
       or  TakeConsole.	 When you have trouble getting xdm working, check this
       file to see if xdm has any clues to the trouble.

       GiveConsole assigns ownership of the console to the user.  Here	is  an
       example GiveConsole file:

	     #!/bin/sh
	     # Assign ownership of the console to the invoking user.
	     #
	     # By convention, both xconsole and xterm -C check that the
	     # console is owned by the invoking user and is readable before
	     # attaching the console output.  This way, a random user can
	     # invoke xterm -C without causing serious problems.
	     #
	     # However, don't give up ownership of the console if the
	     # alternate console is in use, that is, if the graphics
	     # display device is not the console.
	     #
	     case `/usr/sbin/sizer -wc` in
	     1)
	       ;;
	     *)
	       chown $USER /dev/console
	       ;;
	     esac

       TakeConsole  assigns  ownership back to root.  Here is an example Take‐
       Console file:

	     #!/bin/sh
	     # Reassign ownership of the console to root -- this
	     # should disallow assignment of console output to any
	     # random users's xterm
	     #
	     chmod 622 /dev/console
	     chown root /dev/console

       The next configuration entry,  /usr/lib/X11/xdm/Xresources,  is	loaded
       onto the display as a resource database using xrdb. Since the authenti‐
       cation widget reads this database before starting up, it	 usually  con‐
       tains parameters for that widget.

       The  most  interesting  script is Xsession.  It establishes the default
       login session for all users of the workstation.	 Here  is  an  example
       Xsession file:

       #!/bin/sh

       if [ -d $HOME -a -w $HOME ] then
	     exec > $HOME/.xsession-errors 2>&1 else
	     echo "Xsession: $HOME directory not writable by $USER" \
		     > /dev/console
	     exec dxterm -geometry 80x40+0+0
	     # exec xterm -geometry 80x24+0+0 fi

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

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

       if [ -f $startup ]; then
	     if [ -x $startup ]
	     then
		     exec $startup
	     else
		     exec /bin/sh $startup
	     fi else
	     if [ -f $resources ]; then
		     xrdb -load -retain $resources
	     fi
	     #
	     # Motif/DECWindows Version
	     #
	     #dxsession

	     #
	     # MIT/Athena Version
	     #
	     # For a MIT/Athena version,
	     # uncomment the following lines and comment the Motif
	     # lines above

	     xconsole -geometry 480x130-0-0 -daemon -notify -verbose \
		   -fn fixed -exitOnFail
	     twm &
	     exec xterm -geometry 80x24+10+10 -ls fi

       The  preceding  version	of  the Xsession script recognizes the special
       “failsafe” mode, specified in the translations in the  Xresources  file
       above,  to  provide  an escape from the ordinary session. Failsafe mode
       enables you to start a dxterm even when your Xsession  or  $HOME/.xses‐
       sion  script is faulty. To enter failsafe mode, enter your username and
       password at the login prompt and then press either the F1 key or the F2
       key, instead of pressing the carriage return key.  This sequence initi‐
       ates a dxterm session, enabling you to  edit  the  faulty  Xsession  or
       $HOME/.xsession	file. Also, if you do not have a login directory or if
       your login directory is not writable (as in the case of a login	direc‐
       tory that belongs to someone else), failsafe mode is invoked and brings
       up a dxterm session to allow you to make adjustments.

       The file /usr/var/X11/xdm/Xkeymaps defines the keymaps that are	loaded
       into the Xserver for the various languages and keyboards. These keymaps
       are loaded by the Xsetup_0 script using the xmodmap command. The	 table
       in  the	following file defines the correspondence between the value of
       the console's language variable, the keyboard types,  and  the  default
       keymaps loaded into the Xserver:

       #  #  This  file	 defines the language-keymap mapping # # #   The first
       line contains the name of the #	 link to be  created  to  the  default
       keymap.	 # /usr/var/X11/xdm/keymap_default # #	 This is the directory
       where the keymap files are to be found.	#  /usr/lib/X11/keymaps/  #  #
       The  following  lines must contain: #			      <number>
       <language> <keymap-filename> # # The <number> field  is	a  2-byte  hex
       value  where the first byte # represents the keyboard type and the sec‐
       ond byte is the value of the # console's language variable.  The values
       for  the	 keyboard  types  are:	#	 LK401	 0 #	   PCXAL   1 #
       LK201   2 #	 LK421	 3 #	   LK443/4 4 #	      LK411    5  #  #
       Don't put any 8-bit characters in the language names or the # isspace()
       function used in parsing this may think they're spaces  #  causing  the
       lines  to be parsed incorrectly.	 # # If the <keymap-filename> field is
       blank, this has the special # meaning that no keymap_default link  will
       be  created,  nor  will any # existing keymap_default be modified.  # #
       The keymap specified for the "fallback" lines is used for  any  #  lan‐
       guage  value  missing  from  the table for the corresponding # keyboard
       type.  # 000	fallback	       us_lk401aa.keymap 030	 Dansk
       danish_lk401ad_tw.keymap	 032	  Deutsch		 austrian_ger‐
       man_lk401ag.keymap    034	 Deutsch(Schweiz)	    swiss_ger‐
       man_lk401al_tw.keymap  036     English(American)	     us_lk401aa.keymap
       038	English(British/Irish)	  uk_lk401aa.keymap  03a       Espanol
       spanish_lk401as_tw.keymap     03c	Francais		  bel‐
       gian_french_lk401ap_tw.keymap  03e	Francais(Canadien)	 cana‐
       dian_french_lk401ac_tw.keymap	  040	       Francais(SuisseRomande)
       swiss_french_lk401ak_tw.keymap  042	Italiano		 ital‐
       ian_lk401ai_tw.keymap		     044		    Nederlands
       dutch_us_lk401ah.keymap	  046	     Norsk			norwe‐
       gian_lk401an_tw.keymap	   048	       Portugues		  por‐
       tuguese_lk401av.keymap		       04a			 Suomi
       finnish_lk401af_tw.keymap		04c		       Svenska
       swedish_lk401am_tw.keymap    04e	       Vlaams			 flem‐
       ish_lk401ab_tw.keymap

       100	  fallback		   us_pcxalka.keymap   130	 Dansk
       danish_pcxalkd.keymap  132	Deutsch			 austrian_ger‐
       man_pcxalkg.keymap
	       .
	       .
	       .   14c	    Svenska		    swedish_pcxalma.keymap 14e
       Vlaams		      belgian_pcxalkb.keymap

       200	 fallback		  us_lk201re.keymap   230	 Dansk
       danish_lk201ld_tw.keymap * 232	  Deutsch		 austrian_ger‐
       man_lk201lg_tw.keymap *
	       .
	       .
	       .  24c	  Svenska		  swedish_lk201lm_tw.keymap  *
       24e     Vlaams		      flemish_lk201lb_tw.keymap

       300     fallback		      us_lk421aa.keymap 336	English(Ameri‐
       can)	     us_lk421aa.keymap	   338		English(British/Irish)
       uk_lk421aa.keymap

       400	  fallback		   us_lk443aa.keymap   430	 Dansk
       danish_lk444kd.keymap  432	Deutsch			 austrian_ger‐
       man_lk444kg.keymap
	       .
	       .
	       .  44c	  Svenska		 swedish_lk444ma.keymap
	       .
	       .
	       .    500	      fallback		       us_lk411aa.keymap   530
       Dansk			 danish_lk411ad.keymap	   532	       Deutsch
       austrian_german_lk411ag.keymap
	       .
	       .
	       .   54c	    Svenska		    swedish_lk411am.keymap 54e
       Vlaams		      belgian_lk411ab.keymap

RESOURCES
       At many stages the actions of xdm can be controlled through the use  of
       its  configuration  file,  which	 is  in	 the  X resource format.  Some
       resources modify the behavior of xdm on all displays, while others mod‐
       ify  its	 behavior on a single display.	Where actions relate to a spe‐
       cific display, the display name is  inserted  into  the	resource  name
       between “DisplayManager” and the final resource name segment.

       For  local  displays,  the resource name and class are as read from the
       Xservers file.

       For remote displays, the resource name is what the network  address  of
       the display resolves to.	 See the removeDomain resource.	 The name must
       match exactly; xdm is not aware of all the network aliases  that	 might
       reach a given display.  If the name resolve fails, the address is used.
       The resource class is as sent  by  the  display	in  the	 XDMCP	Manage
       request.

       Because	the  resource  manager uses colons to separate the name of the
       resource from its value and dots to separate resource name  parts,  xdm
       substitutes  underscores	 for  both dots and colons when generating the
       resource name. For example, DisplayManager.expo_x_org_0.startup is  the
       name  of	 the  resource	which  defines	the startup shell file for the
       “expo.x.org:0” display.	This resource either  specifies	 a  file  name
       full  of	 server	 entries,  one	per  line  (if the value starts with a
       slash), or a single server entry. See the section SERVER	 SPECIFICATION
       for the details.	 This resource indicates the UDP port number which xdm
       uses to listen for incoming XDMCP requests.  Unless you need  to	 debug
       the  system, leave this with its default value of 177.  Error output is
       normally directed at the system console.	  To  redirect	it,  set  this
       resource	 to  a	file  name.  A method to send these messages to syslog
       should be developed for systems which support  it;  however,  the  wide
       variety	of interfaces precludes any system-independent implementation.
       This file also contains any output directed to stderr  by  the  Xsetup,
       GiveConsole,  Xsession  and  TakeConsole	 files,	 so  it	 will  contain
       descriptions of problems in those scripts  as  well.   If  the  integer
       value  of this resource is greater than zero, reams of debugging infor‐
       mation will be printed.	It also disables daemon mode, which would  re‐
       direct  the  information into the bit-bucket, and allows non-root users
       to run xdm, which would normally not be useful.	Normally, xdm attempts
       to  make	 itself	 into a daemon process unassociated with any terminal.
       This is accomplished by forking and leaving the parent process to exit,
       then  closing  file descriptors and releasing the controlling terminal.
       In some environments this is not desired (in  particular,  when	debug‐
       ging).	Setting	 this  resource	 to “false” will disable this feature.
       The filename specified will be created to contain an ASCII  representa‐
       tion  of	 the  process-id  of the main xdm process.  xdm also uses file
       locking on this file to attempt to eliminate multiple  daemons  running
       on  the	same machine, which would cause quite a bit of havoc.  This is
       the resource which controls whether xdm uses file locking to keep  mul‐
       tiple  display  managers	 from running amok. On System V, this uses the
       lockf library call, while on BSD it uses flock.	This names a directory
       in which xdm stores authorization files while initializing the session.
       The  default  value  is	<XRoot>/lib/X11/xdm.   This  boolean  controls
       whether	xdm  rescans  the  configuration,  servers, access control and
       authentication keys files after a session terminates and the files have
       changed.	  By  default it is “true.”  You can force xdm to reread these
       files by sending a SIGHUP to the main process.  When computing the dis‐
       play  name for XDMCP clients, the name resolver will typically create a
       fully qualified host name for the terminal.  As this is sometimes  con‐
       fusing,	xdm will remove the domain name portion of the host name if it
       is the same as the domain name of the local host when this variable  is
       set.  By default the value is “true.”  XDM-AUTHENTICATION-1 style XDMCP
       authentication requires that a private key be shared  between  xdm  and
       the  terminal.	This resource specifies the file containing those val‐
       ues.  Each entry in the file consists of a display name and the	shared
       key.   To prevent unauthorized XDMCP service and to allow forwarding of
       XDMCP IndirectQuery requests, this file contains a  database  of	 host‐
       names which are either allowed direct access to this machine, or have a
       list of hosts to which queries should be forwarded to.  The  format  of
       this  file is described in the section XDMCP ACCESS CONTROL.  A list of
       additional environment variables, separated by white space, to pass  on
       to the Xsetup_0, GiveConsole, Xsession, and TakeConsole programs.  This
       resource is the name of the loadable greeter library.  The  greeter  is
       the  component  that  displays the login box, collects the username and
       password from the user, and authenticates the user.  The default	 value
       for  this  resource  is	/usr/shlib/X11/libXdmDecGreet.so  which is the
       Motif login interface.  The /usr/shlib/X11/libXdmGreet.so library  con‐
       tains the Athena-style login interface.	A file to checksum to generate
       the seed of authorization keys.	This should be	a  file	 that  changes
       frequently.  The	 default  is  /dev/mem.	 Number of seconds to wait for
       display to respond after user has selected a host from the chooser.  If
       the  display sends an XDMCP IndirectQuery within this time, the request
       is forwarded to the chosen host.	 Otherwise, it is assumed to be from a
       new  session  and  the  chooser	is offered again. Default is 15.  This
       resource specifies the name of the file to be loaded  by	 xrdb  as  the
       resource	 database onto the root window of screen 0 of the display. The
       Xsetup_0 program, the Login widget, and chooser will use the  resources
       set  in	this  file.  This resource data base is loaded just before the
       authentication procedure is started, so it can control  the  appearance
       of  the	login  window.	 See  the section AUTHENTICATION WIDGET, which
       describes the various resources that are appropriate to place  in  this
       file.   There   is   no	 default   value   for	 this	resource,  but
       <XRoot>/lib/X11/xdm/Xresources is the conventional name.	 Specifies the
       program run to offer a host menu for Indirect queries redirected to the
       special host name CHOOSER.  <XRoot>/lib/X11/xdm/chooser is the default.
       See the sections XDMCP ACCESS CONTROL and CHOOSER.  This resource spec‐
       ifies the program used to load the resources.   By  default,  xdm  uses
       <XRoot>/bin/xrdb.   This	 specifies  a  program	which is run (as root)
       before offering the Login window.  This	may  be	 used  to  change  the
       appearance  of  the  screen  around the Login window or to put up other
       windows.	 For example, you may want to run xconsole here.  By  default,
       no  program  is	run.   The  conventional  name for a file used here is
       Xsetup_0.  See the section SETUP PROGRAM.  This	resource  specifies  a
       program	which  is  run (as root) after the authentication process suc‐
       ceeds.  By default, no program is run.  The  conventional  name	for  a
       file  used here is GiveConsole.	See the section STARTUP PROGRAM.  This
       resource specifies the session to be executed (not running as root). By
       default,	 <XRoot>/bin/xterm is run.  The conventional name is Xsession.
       See the section BSESSION PROGRAM.  This specifies a  program  which  is
       run  (as	 root) after the session terminates. Again, by default no pro‐
       gram is run. The conventional name  is  TakeConsole.  See  the  section
       RESET  PROGRAM.	 These	numeric	 resources control the behavior of xdm
       when attempting to open intransigent servers.  The  openDelay  resource
       is  the	length	of the pause (in seconds) between successive attempts.
       The openRepeat resource is the number of attempts to  make.  The	 open‐
       Timeout	resource is the amount of time to wait while actually attempt‐
       ing the open (that is, the maximum time spent in the connect(2)	system
       call).	The  startAttempts resource is the number of times this entire
       process is done before giving  up  on  the  server.   After  openRepeat
       attempts	 have  been made, or if openTimeout seconds elapse in any par‐
       ticular attempt, xdm terminates and restarts the server, attempting  to
       connect	again.	This process is repeated startAttempts times, at which
       point the display is declared dead and disabled.	 Although this	behav‐
       ior  may	 seem  arbitrary,  it has been empirically developed and works
       quite well on most systems.  The default values are 5 for openDelay,  5
       for  openRepeat,	 30 for VopenTimeout and 4 for startAttempts.  To dis‐
       cover when remote displays  disappear,  xdm  occasionally  pings	 them,
       using an X connection and XSync calls.  pingInterval specifies the time
       (in minutes) between each ping attempt, pingTimeout specifies the maxi‐
       mum  amount of time (in minutes) to wait for the terminal to respond to
       the request.  If the terminal does not respond, the session is declared
       dead  and  terminated.	By default, both are set to 5 minutes.	If you
       frequently use X terminals which can become isolated from the  managing
       host,  you  may wish to increase this value.  The only drawback is that
       sessions will continue to exist after the terminal  has	been  acciden‐
       tally  disabled.	  xdm will not ping local displays.  Although it would
       seem harmless, it is unpleasant when the workstation session is	termi‐
       nated  as  a  result  of	 the  server  hanging  for NFS service and not
       responding to the ping.	This boolean resource specifies whether the  X
       server  should  be  terminated  when  a	session terminates (instead of
       resetting it).  This option can be used when the server tends  to  grow
       without	bound  over  time,  in	order  to limit the amount of time the
       server is run.  The default value is “false.”  xdm sets the PATH	 envi‐
       ronment	variable  for the session to this value.  It should be a colon
       separated list of  directories;	see  sh(1)  for	 a  full  description.
       “:/bin:/usr/bin:/usr/X11R6/bin:/usr/ucb”	  is  a	 common	 setting.  The
       default value can be specified at build time in the X system configura‐
       tion file with DefaultUserPath.	xdm sets the PATH environment variable
       for the startup and reset scripts to the value of this  resource.   The
       default for this resource is specified at build time by the DefaultSys‐
       temPath	   entry     in	    the	    system     configuration	 file;
       “/etc:/bin:/usr/bin:/usr/X11R6/bin:/usr/ucb”  is	 a common choice. Note
       the absence of “.” from this entry.  This is a good practice to	follow
       for  root;  it  avoids  many  common  Trojan  Horse  system penetration
       schemes.	 xdm sets the SHELL environment variable for the  startup  and
       reset scripts to the value of this resource.  It is /bin/sh by default.
       If the default session fails to execute, xdm will  fall	back  to  this
       program.	  This	program	 is  executed  with no arguments, but executes
       using the same environment variables as the session would have had (see
       the  section  SESSION  PROGRAM). By default, <XRoot>/bin/xterm is used.
       To improve security, xdm grabs the server and  keyboard	while  reading
       the  login  name and password. The grabServer resource specifies if the
       server should be held for the duration of  the  name/password  reading.
       When “false,” the server is ungrabbed after the keyboard grab succeeds,
       otherwise the server is grabbed until just before the  session  begins.
       The default is “false.”	The grabTimeout resource specifies the maximum
       time xdm will wait for the grab to succeed.  The grab may fail if  some
       other  client has the server grabbed, or possibly if the network laten‐
       cies are very high.  This resource has a default value  of  3  seconds.
       You  should be cautious when raising it, as a user can be confused by a
       look-alike window on the display.  If the grab  fails,  xdm  kills  and
       restarts	 the  server  (if  possible)  and  the session.	 The authorize
       resource is a boolean resource which controls whether xdm generates and
       uses  authorization for the local server connections.  If authorization
       is used, authName is a list of authorization mechanisms to  use,	 sepa‐
       rated  by  white	 space.	 XDMCP	connections  dynamically specify which
       authorization mechanisms are supported, so authName is ignored in  this
       case.  By  default,  authorize  is  “true.”   authName  is  “MIT-MAGIC-
       COOKIE-1,” or, if  XDM-AUTHORIZATION-1  is  available,  “XDM-AUTHORIZA‐
       TION-1 MIT-MAGIC-COOKIE-1.”   This  file	 is  used  to  communicate the
       authorization data from xdm to the server, using the -auth server  com‐
       mand  line option. It should be kept in a directory which is not world-
       writable as it could easily be  removed,	 disabling  the	 authorization
       mechanism in the server. If this resource is not specified, unique file
       names are generated and written into the	 directory  specified  by  the
       DisplayManager.authDir  resource.   Not	used.  This resource specifies
       the number of the signal xdm sends to reset the server. See the section
       CONTROLLING THE SERVER. The default is 1 (SIGHUP).  This resource spec‐
       ifies number of the signal xdm sends to terminate the server.  See  the
       section CONTROLLING THE SERVER. The default is 15 (SIGTERM).  The orig‐
       inal implementation of authorization in the sample  server  reread  the
       authorization  file  at server reset time, instead of when checking the
       initial connection.  Because xdm generates the  authorization  informa‐
       tion 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 informa‐
       tion  will be read. The default is “false,” which will work for all MIT
       servers.	 When xdm is unable to write to the usual  user	 authorization
       file  ($HOME/.Xauthority), it creates a unique file name in this direc‐
       tory and points the environment	variable  XAUTHORITY  at  the  created
       file.   It  uses	 /tmp  by  default.  This resource defines the default
       keymap that the local Xserver uses and maps the value of the  console's
       language	 variable  to  a  keymap  name.	 This resource applies only to
       local displays.	This resource defines the value of the	LANG  environ‐
       ment  variable.	If this resource is defined, the LANG variable will be
       set for the xdm process controlling the display	as  well  as  for  the
       user's X session.

CONFIGURATION FILE
       First,  the  xdm configuration file should be set up.  Make a directory
       (usually <XRoot>/lib/X11/xdm, where <XRoot> refers to the root  of  the
       X11  install  tree) to contain all of the relevant files.  In the exam‐
       ples that follow, we use /usr/X11R6 as the value of <XRoot>.

       Here is a reasonable configuration file, which could be named  xdm-con‐
       fig:

	       DisplayManager.errorLogFile:   /usr/lib/X11/xdm/xdm-errors
	       DisplayManager.pidFile:	      /usr/lib/X11/xdm/xdm-pid
	       DisplayManager.keyFile:	      /usr/lib/X11/xdm/xdm-keys
	       DisplayManager.servers:	      /usr/lib/X11/xdm/Xservers
	       DisplayManager.accessFile:     /usr/lib/X11/xdm/Xaccess
	       DisplayManager._0.authorize:   true
	       DisplayManager._0.setup:	      /usr/lib/X11/xdm/Xsetup_0
	       DisplayManager._0.startup:     /usr/lib/X11/xdm/GiveConsole
	       DisplayManager._0.reset:	      /usr/lib/X11/xdm/TakeConsole
	       DisplayManager*resources:      /usr/lib/X11/xdm/Xresources
	       DisplayManager*session:	      /usr/lib/X11/xdm/Xsession
	       DisplayManager*authComplain:   false

       Note  that  this	 file mostly contains references to other files.  Note
       also that some of the resources are specified with “*”  separating  the
       components.  These resources can be made unique for each different dis‐
       play, by replacing the “*” with the display-name, but normally this  is
       not very useful.	 See the RESOURCES section for a complete discussion.

XDMCP ACCESS CONTROL
       The  database  file specified by the DisplayManager.accessFile provides
       information that xdm uses to control access  from  displays  requesting
       XDMCP  service.	 This  file  contains three types of entries:  entries
       which control the response to Direct  and  Broadcast  queries,  entries
       which control the response to Indirect queries, and macro definitions.

       The  format  of	the  Direct entries is simple, either a host name or a
       pattern, which is distinguished from a host name by  the	 inclusion  of
       one  or	more  meta  characters	(`*' matches any sequence of 0 or more
       characters, and `?' matches any single character)  which	 are  compared
       against	the  host  name	 of the display device. If the entry is a host
       name, all comparisons are done using network  addresses,	 so  any  name
       which  converts	to  the	 correct network address may be used. For pat‐
       terns, only canonical host names are used in the comparison, so	ensure
       that  you do not attempt to match aliases. Preceding either a host name
       or a pattern with a `!' character causes hosts which match  that	 entry
       to be excluded.

       An  Indirect entry also contains a host name or pattern, but follows it
       with a list of host names or macros to which indirect queries should be
       sent.

       A  macro	 definition contains a macro name and a list of host names and
       other macros that the macro expands to.	 To  distinguish  macros  from
       hostnames,  macro  names	 start	with  a	 `%' character.	 Macros can be
       nested.

       Indirect entries can also specify to have xdm run chooser  to  offer  a
       menu of hosts to connect to.  See the section CHOOSER.

       When xdm checks the access for a particular display host, each entry is
       scanned in turn and the first matching entry determines	the  response.
       Direct  and Broadcast entries are ignored when scanning for an Indirect
       entry and vice-versa.

       Blank lines are ignored, `#' is treated as a comment delimiter  causing
       the  rest of that line to be ignored, and `\newline' causes the newline
       to be ignored, allowing indirect host lists to span multiple lines.

       Here is an example Xaccess file:

       # # Xaccess - XDMCP access control file #

       # # Direct/Broadcast query entries #

       !xtra.lcs.mit.edu   #  disallow	direct/broadcast  service   for	  xtra
       bambi.ogi.edu  #	   allow   access   from   this	  particular   display
       *.lcs.mit.edu  # allow access from any display in LCS

       # # Indirect query entries #

       %HOSTS	 expo.lcs.mit.edu xenon.lcs.mit.edu \	    excess.lcs.mit.edu
       kanga.lcs.mit.edu

       extract.lcs.mit.edu xenon.lcs.mit.edu   #force extract to contact xenon
       !xtra.lcs.mit.edu   dummy     #disallow	       indirect		access
       *.lcs.mit.edu  %HOSTS	#all others get to choose

CHOOSER
       For X terminals that do not offer a host menu for use with Broadcast or
       Indirect queries, the chooser program can do this for them. In the Xac‐
       cess  file,  specify  “CHOOSER” as the first entry in the Indirect host
       list.  Chooser will send a Query request to each of the remaining  host
       names in the list and offer a menu of all the hosts that respond.

       The  list  may  consist	of the word “BROADCAST,” in which case chooser
       will send a Broadcast instead, again offering a menu of all hosts  that
       respond.	  Note	that  on some operating systems, UDP packets cannot be
       broadcast, so this feature will not work.

       Example Xaccess file using chooser:

       extract.lcs.mit.edu CHOOSER  %HOSTS #offer  a  menu  of	 these	 hosts
       xtra.lcs.mit.edu	   CHOOSER BROADCAST #offer a menu of all hosts

       The  program to use for chooser is specified by the DisplayManager.DIS‐
       PLAY.chooser resource.  For more flexibility at this step, the  chooser
       could  be  a  shell script.  Chooser is the session manager here; it is
       run instead of a child xdm to manage the display.

       Resources for this program can be put into the file named  by  Display‐
       Manager.DISPLAY.resources.

       When  the user selects a host, chooser prints the host chosen, which is
       read by the parent xdm, and exits.  xdm closes its connection to the  X
       server, and the server resets and sends another Indirect XDMCP request.
       xdm remembers the user's choice (for DisplayManager.choiceTimeout  sec‐
       onds)  and forwards the request to the chosen host, which starts a ses‐
       sion on that display.

SERVER SPECIFICATION
       The resource DisplayManager.servers gives a server specification or, if
       the  values  starts  with  a  slash  (/), the name of a file containing
       server specifications, one per line.

       Each specification indicates a display which should constantly be  man‐
       aged  and  which	 is not using XDMCP. This method is used typically for
       local servers only.  If the resource or the file named by the  resource
       is empty, xdm will offer XDMCP service only.

       Each specification consists of at least three parts:  a display name, a
       display class, a display type, and (for local servers) a	 command  line
       to  start the server.  A typical entry for local display number 0 would
       be:

	 :0 local /usr/bin/X11/X

       The display types are:

       local	      local  display:	xdm   must   run   the	 server	  for‐
       eign	   remote  display:  xdm  opens	 an  X connection to a running
       server

       The display name must be something that can be passed in	 the  -display
       option  to  an X program.  This string is used to generate the display-
       specific resource names, so be careful to match the names (for example,
       use   “:0  Sun-CG3  local  /usr/X11R6/bin/X :0” instead of “localhost:0
       Sun-CG3 local /usr/X11R6/bin/X :0” if your other resources  are	speci‐
       fied  as	 “DisplayManager._0.session”).	 The  display class portion is
       also used in the	 display-specific  resources,  as  the	class  of  the
       resource.   This	 feature  is  useful if you have a large collection of
       similar displays (such as a corral of X terminals) and  would  like  to
       set  resources  for  groups  of them.  When using XDMCP, the display is
       required to specify the display class.  The manual for your  particular
       X  terminal  should  document the display class string for your device.
       If it does not, you can run xdm in debug mode and look at the  resource
       strings that it generates for that device.  One of these strings is the
       class string.

       To use the Shared Memory Transport as the default transport for	commu‐
       nication between the X server and local clients, specify the local dis‐
       play as local:0, in which case the entry in  the	 Xservers  file	 might
       read as follows:

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

       When  xdm  starts  a  session,  it  sets	 up authorization data for the
       server.	For  local  servers,  xdm  passes  “-auth  filename''  on  the
       server's	 command line to point it at its authorization data. For XDMCP
       servers, xdm passes the authorization data to the server via the Accept
       XDMCP request.

ATHENA-STYLE AUTHENTICATION WIDGET
       This    login	widget	  is	used   when   the   greeter   library,
       /usr/lib/X11/xdm/libXdmGreet.so, is specified as the value of the  Dis‐
       playManager.greeterLib resource.

       Note  that  you cannot use the Athena-style greeter if you have enabled
       enhanced security on your system.  The Athena-style  greeter  does  not
       use the necessary security mechanisms.  See secsetup(8).

       The authentication widget reads a name/password pair from the keyboard.
       Nearly every imaginable parameter can be controlled  with  a  resource.
       Resources for this widget should be put into the file named by Display‐
       Manager.DISPLAY.resources.  All	of  these  resources  have  reasonable
       default	values,	 so  it	 is not necessary to specify any of them.  The
       geometry of the Login widget is normally	 computed  automatically.   If
       you  wish  to  position	it elsewhere, specify each of these resources.
       The color used to display the typed-in user name.   The	font  used  to
       display	the typed-in user name.	 A string that identifies this window.
       The default is “X Window System”.  When X authorization is requested in
       the configuration file for this display and none is in use, this greet‐
       ing replaces the standard greeting.  The default is “This is  an	 unse‐
       cure  session”.	The font used to display the greeting.	The color used
       to display the greeting.	 The string displayed to  prompt  for  a  user
       name.   The xrdb utility strips trailing white space from resource val‐
       ues.  To add spaces at the end of the prompt to make it more  readable,
       add  spaces  escaped  with backslashes. The default is “Login:  ”.  The
       string displayed to prompt for a password.  The default	is  “Password:
       ”.   The	 font used to display both prompts.  The color used to display
       both prompts.  A message that  is  displayed  when  the	authentication
       fails.  The default is “Login incorrect”.  The font used to display the
       failure message.	 The color used to display the failure	message.   The
       number  of  seconds that the failure message is displayed.  The default
       is 30.  This resource specifies the translations	 used  for  the	 login
       widget.	Refer to the X Toolkit documentation for a complete discussion
       of translations. The default translation table is:

		      Ctrl<Key>H:    delete-previous-character() \n\
		      Ctrl<Key>D:    delete-character() \n\
		      Ctrl<Key>B:    move-backward-character() \n\
		      Ctrl<Key>F:    move-forward-character() \n\
		      Ctrl<Key>A:    move-to-begining() \n\
		      Ctrl<Key>E:    move-to-end() \n\
		      Ctrl<Key>K:    erase-to-end-of-line() \n\
		      Ctrl<Key>U:    erase-line() \n\
		      Ctrl<Key>X:    erase-line() \n\
		      Ctrl<Key>C:    restart-session() \n\
		      Ctrl<Key>\:   abort-session() \n\
		      <Key>BackSpace:delete-previous-character() \n\
		      <Key>Delete:   delete-previous-character() \n\
		      <Key>Return:   finish-field() \n\
		      <Key>:	     insert-char() \

       The actions which are supported by the widget are: Erases the character
       before  the  cursor.  Erases the character after the cursor.  Moves the
       cursor backward.	 Moves	the  cursor  forward.	(Apologies  about  the
       spelling	 error.)   Moves  the  cursor to the beginning of the editable
       text.  Moves the cursor to the end of the editable  text.   Erases  all
       text  after  the	 cursor.  Erases the entire text.  If the cursor is in
       the name field, proceeds to the password field.	If the	cursor	is  in
       the  password  field,  checks  the  current name/password pair.	If the
       name/password pair is valid, xdm starts	the  session.  Otherwise,  the
       failure	message	 is  displayed and the user is prompted again.	Termi‐
       nates and restarts the server.  Terminates the  server,	disabling  it.
       This  is	 a rash action and is not accessible in the default configura‐
       tion.   It can be used to stop xdm when you  are	 shutting  the	system
       down  or using xdmshell.	 Resets the X server and starts a new session.
       This action can be used when the resources have been  changed  and  you
       want  to	 test them or when the screen has been overwritten with system
       messages.  Inserts the character typed.	Specifies a single word	 argu‐
       ment  that  is passed to the session at startup.	 See the sections SES‐
       SION PROGRAM and TYPICAL USAGE.	Disables access control in the server.
       This  action  can  be used when the file cannot be created by xdm.  Use
       this action with caution; you should probably  disconnect  the  machine
       from the network before using this action.

MOTIF AUTHENTICATION WIDGET
       This    login	widget	  is	used   when   the   greeter   library,
       /usr/lib/X11/xdm/libXdmDecGreet.so, is specified as the	value  of  the
       DisplayManager.greeterLib resource.

       The authentication widget reads a name/password pair from the keyboard.
       Many parameters can be controlled with resources.  Resources  for  this
       widget  should  be  put	into  the  file	 named	by DisplayManager.DIS‐
       PLAY.resources. All these resources have reasonable default values,  so
       it  is not necessary to specify any of them.  The coordinates in pixels
       of the upper left corner of the logo displayed on the login screen.   A
       value of -1 for LogoX or LogoY causes an appropriate default to be cal‐
       culated.	 The foreground color of the logo displayed across the top  of
       the  login  screen.  The default color is rgb:8182/0604/2c28.  The logo
       background color.  The default is White.	 The foreground color  of  the
       logo on monochrome systems.  The default is Black.  The logo background
       color on monochrome systems.  The default is White.  If	set  to	 True,
       the root window will be painted the specified solid color and, when the
       login widget is destroyed, the root window  will	 be  restored  to  its
       default	pattern.  The default value is True.  The root window color in
       the login screen.  The default value is rgb:3030/5050/6060.   The  name
       of the file containing a bitmap in X bitmap format that is displayed in
       place of the default logo.  The name of the file containing  the	 shape
       mask  bitmap  to	 use  when displaying the logo.	 The color of the text
       displayed in a message box on a failed login.  The greeting  text  dis‐
       played  as  a title in the login box.  The default value is "Tru64 UNIX
       on CLIENTHOST".	'CLIENTHOST' is a macro that xrdb  replaces  with  the
       name  of	 the  xdm  host.   The	greeting text displayed as a secondary
       (smaller) title in the login  box.   The	 default  value	 is  "formerly
       \D\E\C  OSF/1".	 'DEC' must be escaped or else the xrdb cpp will treat
       it as a macro.  The color of the greeting text in the login  box.   The
       default	is  Black.  The color of the text of the prompt strings in the
       login box.  The default is Black.  The color of the  response  text  in
       the  login  box.	  The  default is Black.  The font used to display the
       greeting text in the login box.	The default is '*-new century  school‐
       book-bold-i-normal-*-240-*'.   The  font used to display the strings in
       the login box.  The default is '*-new century  schoolbook-medium-r-nor‐
       mal-*-180-*'.   The font used to display the response text in the login
       box.   The   default   is   '*-new   century   schoolbook-medium-r-nor‐
       mal-*-180-*'.

SETUP PROGRAM
       The  program  named in the DisplayManager.DISPLAY.setup resource is run
       after the server is reset, but before the Login window is offered.  The
       file  is	 typically a shell script. It is run as root, so you should be
       careful about security. This is the place to change the root background
       or  bring  up other windows that should appear on the screen along with
       the Login widget.

       In addition to any specified by DisplayManager.exportList, the  follow‐
       ing environment variables are passed: Sets the associated display name.
       Sets the value of DisplayManager.DISPLAY.systemPath.  Sets the value of
       DisplayManager.DISPLAY.systemShell.  May be set to an authority file.

       Note  that  since xdm grabs the keyboard, any other windows will not be
       able to receive keyboard input.	However, they will be able to interact
       with  the  mouse,  so check for potential security holes here.  If Dis‐
       playManager.DISPLAY.grabServer is set, Xsetup_0 will  not  be  able  to
       connect	to  the	 display at all. Resources for this program can be put
       into the file named by DisplayManager.DISPLAY.resources.

RESOURCES FILE
       The Xresources file is loaded onto the display as a  resource  database
       using  xrdb.  As	 the  authentication widget reads this database before
       starting up, it usually contains parameters for that widget:

       xlogin*login.translations:  #override\  Ctrl<Key>R:  abort-display()\n\
       <Key>F1:	 set-session-argument(failsafe) finish-field()\n\ <Key>Return:
       set-session-argument()  finish-field()	xlogin*borderWidth:   3	  xlo‐
       gin*greeting: CLIENTHOST #ifdef COLOR xlogin*greetColor: CadetBlue xlo‐
       gin*failColor: red #endif

       Please note the translations entry; it specifies a few new translations
       for  the	 widget	 which	allow users to escape from the default session
       (and avoid troubles that may occur in it).  Note that if	 #override  is
       not specified, the default translations are removed and replaced by the
       new value, not a very useful result as some of the default translations
       are  quite  useful  (such  as “<Key>: insert-char ()” which responds to
       normal typing).

       This file may also contain resources for the setup program and chooser.

STARTUP PROGRAM
       The program specified by the DisplayManager.DISPLAY.startup resource is
       typically shell script. It is run as root and needs to be careful about
       security.  This is the place  to	 put  commands	that  add  entries  to
       /etc/utmp  (the	sessreg program may be useful here), mount users' home
       directories from file servers, display the message of the day, or abort
       the session if logins are not allowed.

       In  addition to any specified by DisplayManager.exportList, the follow‐
       ing environment variables are passed: Sets the associated display name.
       Sets  the  initial  working directory of the user.  Sets The user name.
       Sets the value of DisplayManager.DISPLAY.systemPath.  Sets the value of
       DisplayManager.DISPLAY.systemShell.  May be set to an authority file.

       No  arguments  are  passed  to the script.  xdm waits until this script
       exits before starting the user session.	If  the	 exit  value  of  this
       script  is  non-zero,  xdm  discontinues the session and starts another
       authentication cycle.

       The sample Xstartup file shown  here  prevents  login  while  the  file
       /etc/nologin  exists. Thus this is not a complete example, but simply a
       demonstration of the available functionality.

       Here is a sample Xstartup script:

	    #!/bin/sh	   #	  # Xstartup	  #	 # This program is run
       as  root after the user is verified	#      if [ -f /etc/nologin ];
       then	       xmessage-file  /etc/nologin	      exit  1	    fi
	    sessreg-a-l	    $DISPLAY-x	  /usr/X11R6/lib/xdm/Xservers	 $USER
	    /usr/X11R6/lib/xdm/GiveConsole	exit 0

SESSION PROGRAM
       The Xsession program (specified by  the	DisplayManager.DISPLAY.session
       resource)  is  the command that is run as the user's session. It is run
       with the permissions of the authorized user.

       In addition to any specified by DisplayManager.exportList, the  follow‐
       ing environment variables are passed: Sets the associated display name.
       Sets the initial working directory of the user.	Sets  the  user	 name.
       PATH  sets  the	value  of  DisplayManager.DISPLAY.userPath.   Sets the
       user's default shell (from getpwnam).  XAUTHORITY may be set to a  non-
       standard	 authority  file.  KRB5CCNAME may be set to a Kerberos creden‐
       tials cache file.

       At most installations, Xsession should look in $HOME for a  file	 which
       contains commands that each user would like to use as a session.	 Xses‐
       sion should also implement a system default session if  no  user-speci‐
       fied session exists. See the section Typical Usage.

       An  argument may be passed to this program from the authentication wid‐
       get using the `set-session-argument'  action.   This  can  be  used  to
       select different styles of session.  One good use of this feature is to
       allow the user to escape from the ordinary session when it fails.  This
       allows  users to repair their own if it fails, without requiring admin‐
       istrative intervention. The example following  demonstrates  this  fea‐
       ture.

       This  example  recognizes the special “failsafe” mode, specified in the
       translations in the Xresources file, to	provide	 an  escape  from  the
       ordinary	 session.   It also requires that the file be executable so we
       do not have to guess what shell it wants to use.

	    #!/bin/sh	   #	  # Xsession	  #	 # This is the program
       that is run as the client      # for the display manager.

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

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

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

       The user's file might look something like this example.	Do not	forget
       that the file must have execute permission.

	    #!	/bin/csh       # no -f in the previous line so .cshrc gets run
       to set $PATH	 twm &	    xrdb -merge "$HOME/.Xresources"	 emacs
       -geometry  +0+50	 &	 xbiff -geometry -430+5 &      xterm -geometry
       -0+50 -ls

RESET PROGRAM
       Symmetrical with the startup program, the program specified by the Dis‐
       playManager.DISPLAY.startup  resource is run after the user session has
       terminated. Run as root, it  should  contain  commands  that  undo  the
       effects	of  commands  in  Xstartup, removing entries from /etc/utmp or
       unmounting directories from file servers.   The	environment  variables
       that  were passed to the startup program are also passed to the program
       specified by the DisplayManager.DISPLAY.startup resource.

       A sample Xreset script:

	    #!/bin/sh	   #	  # Xreset	#      # This program  is  run
       as  root	 after	the  session  ends	 #	sessreg-d-l $DISPLAY-x
       /usr/X11R6/lib/xdm/Xservers  $USER	/usr/X11R6/lib/xdm/TakeConsole
	    exit 0

CONTROLLING THE SERVER
       xdm  controls local servers using POSIX signals.	 SIGHUP is expected to
       reset the server, closing all client connections and  performing	 other
       cleanup duties.	SIGTERM is expected to terminate the server.  If these
       signals do not perform the expected actions, the resources  DisplayMan‐
       ager.DISPLAY.resetSignal	  and	DisplayManager.DISPLAY.termSignal  can
       specify alternate signals.

       To control remote terminals not using XDMCP, xdm	 searches  the	window
       hierarchy on the display and uses the protocol request KillClient in an
       attempt to clean up the terminal for the next session.	This  may  not
       actually kill all of the clients, as only those which have created win‐
       dows will be noticed.  XDMCP provides a more sure mechanism;  when  xdm
       closes  its initial connection, the session is over and the terminal is
       required to close all other connections.

CONTROLLING XDM
       xdm responds to two signals: SIGHUP and SIGTERM.	 When sent  a  SIGHUP,
       xdm  rereads  the  configuration file, the access control file, and the
       servers file.  For the servers file, it notices if  entries  have  been
       added  or removed.  If a new entry has been added, xdm starts a session
       on the associated display.  Entries which have been  removed  are  dis‐
       abled  immediately, meaning that any session in progress will be termi‐
       nated without notice and no new session will be started.

       When sent a SIGTERM, xdm terminates all sessions in progress and exits.
       This can be used when shutting down the system.

       xdm attempts to mark its various sub-processes for ps(1) by editing the
       command line argument list in place.  Because xdm cannot allocate addi‐
       tional space for this task, it is useful to start xdm with a reasonably
       long command line (using the full path name  should  be	enough).  Each
       process which is servicing a display is marked -display.

OTHER POSSIBILITIES
       You  can	 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  com‐
       mand line: xdm -server ":0 SUN-3/60CG4 local /usr/X11R6/bin/X :0"

       Suppose	you  might have a file server and a collection of X terminals.
       The configuration for this  is  identical  to  the  preceding  example,
       except the Xservers file would be as follows:

       extol:0	VISUAL-19  foreign  exalt:0  NCD-19 foreign explode:0 NCR-TOW‐
       ERVIEW3000 foreign

       This directs xdm to manage sessions on all three	 of  these  terminals.
       See  the	 section CONTROLLING XDM for a description of using signals to
       enable and disable these terminals in a manner similar to init(8).

LIMITATIONS
       The xdm program does not coexist well with other window systems.

FILES
       Default configuration file Default access file, listing authorized dis‐
       plays  Default  server  file,  listing non-XDMCP servers to manage User
       authorization file where xdm stores keys for clients  to	 read  Default
       chooser	Motif  loadable	 greeter Athena-style loadable greeter Default
       resource database loader Default server	Default	 session  program  and
       failsafe	 client Default location for authorization files Kerberos cre‐
       dentials cache

					Note

       <XRoot> refers to the root of the X11 install tree.

SEE ALSO
       X(1X), xauth(1X), XSecurity(1X), Xdec(1X), X  Display  Manager  Control
       Protocol

AUTHOR
       Keith Packard, MIT X Consortium

								       xdm(1X)
[top]

List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net