<HTML>
<HEAD>
<TITLE> xdm  -  X  Display  Manager  with  support for XDMCP, host chooser </TITLE>
</HEAD>
<BODY>
<PRE>



XDM(1)							   XDM(1)


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  ses_
       sion_program ]

DESCRIPTION
       Xdm  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 Con
       sortium standard XDMCP, the X Display Manager Control Pro_
       tocol.  Xdm provides services similar to those provided by
       init, getty and login on	 character  terminals:	prompting
       for  login name and password, authenticating the user, and
       running a ``session.''

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

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

       When xdm receives an Indirect query via XDMCP, it can  run
       a  chooser  process to perform an XDMCP BroadcastQuery (or
       an XDMCP Query to specified hosts) on behalf of	the  dis
       play  and  offer a menu of possible hosts that offer XDMCP
       display management.  This feature is useful with X  termi
       nals 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  cus
       tomize  to  the	needs of a particular site.  Xdm has many
       options, most of which have reasonable  defaults.   Browse
       through	the  various sections of this manual, 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.

OVERVIEW
       xdm is highly configurable, and most of its  behavior  can
       be  controlled  by  resource files and shell scripts.  The
       names of these files themselves are  resources  read  from



X Version 11		   Release 6.1				1





XDM(1)							   XDM(1)


       the  file  xdm-config  or  the  file  named by the -config
       option.

       xdm offers display management two different ways.  It  can
       manage  X  servers running on the local machine and speci
       fied in Xservers, and it can manage remote X servers (typ
       ically X terminals) using XDMCP (the XDM Control Protocol)
       as specified in the Xaccess file.

       The resources of the X clients  run  by	xdm  outside  the
       user's  session,	 including xdm's own login window, can be
       affected by setting resources in the Xresources file.

       For X terminals that do not offer a menu of hosts  to  get
       display management from, xdm can collect willing hosts and
       run the chooser program to offer the user a menu.   For	X
       displays	 attached  to  a host, this step is typically not
       used, as the local host does the display management.

       After resetting the X server, xdm runs the  Xsetup  script
       to  assist  in  setting	up the screen the user sees along
       with the xlogin widget.

       The xlogin widget, which xdm presents, offers the familiar
       login and password prompts.

       After  the  user	 logs in, xdm runs the Xstartup script as
       root.

       Then xdm runs the Xsession script as the user.  This  sys
       tem  session file may do some additional startup and typi
       cally runs the .xsession script in the user's home  direc
       tory.   When  the  Xsession  script  exits, the session is
       over.

       At the end of the session, the Xreset  script  is  run  to
       clean  up,  the	X  server  is reset, and the cycle starts
       over.

       The file	 /usr/X11R6/lib/X11/xdm/xdm-errors  will  contain
       error  messages	from xdm and anything output to stderr by
       Xsetup, Xstartup, Xsession or Xreset.  When you have trou
       ble getting xdm working, check this file to see if xdm has
       any clues to the trouble.

OPTIONS
       All of these options, except -config itself, specify  val
       ues  that  can also be specified in the configuration file
       as resources.

       -config configuration_file
	      Names  the  configuration	 file,	which	specifies
	      resources	  to   control	 the   behavior	 of  xdm.
	      &lt;XRoot&gt;/lib/X11/xdm/xdm-config is the default.  See



X Version 11		   Release 6.1				2





XDM(1)							   XDM(1)


	      the section Configuration File.

       -nodaemon
	      Specifies	 ``false''  as the value for the Display
	      Manager.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 back
	      ground when it first starts up.

       -debug debug_level
	      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  syn
	      chronously.  To interpret these debugging messages,
	      a copy of the source  code  for  xdm  is	almost	a
	      necessity.  No attempt has been made to rationalize
	      or standardize the output.

       -error error_log_file
	      Specifies	  the	value	for    the    DisplayMan
	      ager.errorLogFile	 resource.   This  file	 contains
	      errors from xdm as  well	as  anything  written  to
	      stderr by the various scripts and programs run dur
	      ing the progress of the session.

       -resources resource_file
	      Specifies	  the	value	for    the    DisplayMan
	      ager*resources resource.	This file is loaded using
	      xrdb to specify configuration  parameters	 for  the
	      authentication widget.

       -server server_entry
	      Specifies	 the value for the DisplayManager.servers
	      resource.	 See the section Local Server  Specifica
	      tion for a description of this resource.

       -udpPort port_number
	      Specifies	   the	  value	  for	the   DisplayMan
	      ager.requestPort resource.   This	 sets  the  port-
	      number  which  xdm will monitor for XDMCP requests.
	      As XDMCP uses the registered  well-known	UDP  port
	      177, this resource should not be changed except for
	      debugging.

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

       -xrm resource_specification
	      Allows an arbitrary resource to be specified, as in



X Version 11		   Release 6.1				3





XDM(1)							   XDM(1)


	      most X Toolkit applications.

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 modify its behavior on a
       single  display.	  Where actions relate to a specific dis
       play, 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  dis
       play.   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.

       DisplayManager.servers
	      This  resource either specifies a file name full of
	      server entries, one per line (if the  value  starts
	      with  a  slash), or a single server entry.  See the
	      section Local Server Specification for the details.

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

       DisplayManager.errorLogFile
	      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 sys_
	      log  should  be developed for systems which support
	      it; however, the wide variety  of	 interfaces  pre
	      cludes any system-independent implementation.  This
	      file also contains any output directed to stderr by
	      the Xsetup, Xstartup, Xsession and Xreset files, so
	      it will contain descriptions of problems	in  those
	      scripts as well.



X Version 11		   Release 6.1				4





XDM(1)							   XDM(1)


       DisplayManager.debugLevel
	      If  the  integer	value of this resource is greater
	      than zero, reams of debugging information	 will  be
	      printed.	It also disables daemon mode, which would
	      redirect the information into the	 bit-bucket,  and
	      allows  non-root users to run xdm, which would nor
	      mally not be useful.

       DisplayManager.daemonMode
	      Normally, xdm attempts to make itself into a daemon
	      process  unassociated  with  any terminal.  This is
	      accomplished by forking and leaving the parent pro
	      cess  to	exit,  then  closing file descriptors and
	      releasing the controlling terminal.  In some  envi
	      ronments	this  is not desired (in particular, when
	      debugging).  Setting  this  resource  to	``false''
	      will disable this feature.

       DisplayManager.pidFile
	      The  filename  specified will be created to contain
	      an ASCII representation of the  process-id  of  the
	      main  xdm	 process.   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.

       DisplayManager.lockPidFile
	      This is the resource  which  controls  whether  xdm
	      uses file locking to keep multiple display managers
	      from running amok.  On  System  V,  this	uses  the
	      lockf library call, while on BSD it uses flock.

       DisplayManager.authDir
	      This  names  a  directory	 under	which  xdm stores
	      authorization files while initializing the session.
	      The  default  value is &lt;XRoot&gt;/lib/X11/xdm.  Can be
	      overridden for  specific	displays  by  DisplayMan
	      ager.DISPLAY.authFile.

       DisplayManager.autoRescan
	      This  boolean controls whether xdm rescans the con
	      figuration, servers, access control and authentica
	      tion  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.

       DisplayManager.removeDomainname
	      When computing the display name for XDMCP	 clients,
	      the  name	 resolver  will	 typically create a fully
	      qualified host name for the terminal.  As	 this  is
	      sometimes	 confusing,  xdm  will	remove the domain
	      name portion of the host name if it is the same  as
	      the  domain  name	 of  the  local	 host  when  this



X Version 11		   Release 6.1				5





XDM(1)							   XDM(1)


	      variable is set.	By default the value is ``true.''

       DisplayManager.keyFile
	      XDM-AUTHENTICATION-1   style  XDMCP  authentication
	      requires that a private key be shared  between  xdm
	      and the terminal.	 This resource specifies the file
	      containing those values.	Each entry  in	the  file
	      consists	of a display name and the shared key.  By
	      default, xdm does	 not  include  support	for  XDM-
	      AUTHENTICATION-1,	 as  it requires DES which is not
	      generally distributable because  of  United  States
	      export restrictions.

       DisplayManager.accessFile
	      To  prevent unauthorized XDMCP service and to allow
	      forwarding of XDMCP  IndirectQuery  requests,  this
	      file  contains  a	 database  of hostnames which are
	      either allowed direct access to  this  machine,  or
	      have  a  list  of	 hosts to which queries should be
	      forwarded to.  The format of this file is described
	      in the section XDMCP Access Control.

       DisplayManager.exportList
	      A	 list  of additional environment variables, sepa
	      rated by white space, to pass  on	 to  the  Xsetup,
	      Xstartup, Xsession, and Xreset programs.

       DisplayManager.randomFile
	      A	 file  to checksum to generate the seed of autho
	      rization keys.  This should be a file that  changes
	      frequently.  The default is /dev/mem.

       DisplayManager.greeterLib
	      On  systems  that	 support  a  dynamically-loadable
	      greeter library, the name of the library.	  Default
	      is &lt;XRoot&gt;/lib/X11/xdm/libXdmGreet.so.

       DisplayManager.choiceTimeout
	      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.

       DisplayManager.DISPLAY.resources
	      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
	      program, the Login widget, and chooser will use the
	      resources	 set  in  this	file.  This resource data
	      base is loaded just before the authentication  pro
	      cedure is started, so it can control the appearance



X Version 11		   Release 6.1				6





XDM(1)							   XDM(1)


	      of the login window.  See the  section  Authentica
	      tion  Widget, which describes the various resources
	      that are appropriate to place in this file.   There
	      is   no	default	 value	for  this  resource,  but
	      &lt;XRoot&gt;/lib/X11/xdm/Xresources is the  conventional
	      name.

       DisplayManager.DISPLAY.chooser
	      Specifies	 the program run to offer a host menu for
	      Indirect queries redirected  to  the  special  host
	      name  CHOOSER.   &lt;XRoot&gt;/lib/X11/xdm/chooser is the
	      default.	See the sections XDMCP Access Control and
	      Chooser.

       DisplayManager.DISPLAY.xrdb
	      Specifies	 the  program used to load the resources.
	      By default, xdm uses &lt;XRoot&gt;/bin/xrdb.

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

       DisplayManager.DISPLAY.setup
	      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 (e.g.,  you
	      may  want	 to  run  xconsole here).  By default, no
	      program is run.  The conventional name for  a  file
	      used  here  is  Xsetup.  See the section Setup Pro
	      gram.

       DisplayManager.DISPLAY.startup
	      This specifies a program which  is  run  (as  root)
	      after  the  authentication  process  succeeds.   By
	      default, no program is run.  The conventional  name
	      for  a file used here is Xstartup.  See the section
	      Startup Program.

       DisplayManager.DISPLAY.session
	      This specifies the session to be executed (not run
	      ning  as	root).	 By default, &lt;XRoot&gt;/bin/xterm is
	      run.  The conventional name is Xsession.	 See  the
	      section Session Program.

       DisplayManager.DISPLAY.reset
	      This  specifies  a  program  which is run (as root)
	      after the session terminates.  By default, no  pro
	      gram is run.  The conventional name is Xreset.  See
	      the section Reset Program.

       DisplayManager.DISPLAY.openDelay





X Version 11		   Release 6.1				7





XDM(1)							   XDM(1)


       DisplayManager.DISPLAY.openRepeat

       DisplayManager.DISPLAY.openTimeout

       DisplayManager.DISPLAY.startAttempts
	      These numeric resources control the behavior of xdm
	      when   attempting	 to  open  intransigent	 servers.
	      openDelay is the length of the pause  (in	 seconds)
	      between successive attempts, openRepeat is the num
	      ber of attempts to make, openTimeout is the  amount
	      of  time to wait while actually attempting the open
	      (i.e., the maximum time  spent  in  the  connect(2)
	      system  call)  and  startAttempts	 is the number of
	      times this entire process is done before giving  up
	      on the server.  After openRepeat attempts have been
	      made, or if openTimeout seconds elapse in any  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  behavior  may  seem	 arbitrary,  it	 has been
	      empirically developed and works quite well on  most
	      systems.	The default values are 5 for openDelay, 5
	      for openRepeat, 30 for openTimeout and 4 for  star
	      tAttempts.

       DisplayManager.DISPLAY.pingInterval

       DisplayManager.DISPLAY.pingTimeout
	      To  discover  when  remote  displays disappear, xdm
	      occasionally pings them, using an X connection  and
	      XSync  calls.   pingInterval specifies the time (in
	      minutes) between	each  ping  attempt,  pingTimeout
	      specifies	 the  maximum amount of time (in minutes)
	      to wait for the terminal to respond to the request.
	      If  the  terminal	 does not respond, the session is
	      declared dead and terminated.  By default, both are
	      set  to  5 minutes.  If you frequently use X termi
	      nals which can become isolated  from  the	 managing
	      host,  you  may  wish  to increase this value.  The
	      only worry is that sessions will continue to  exist
	      after  the terminal has been accidentally disabled.
	      xdm will not  ping  local	 displays.   Although  it
	      would  seem  harmless,  it  is  unpleasant when the
	      workstation session is terminated as  a  result  of
	      the server hanging for NFS service and not respond
	      ing to the ping.

       DisplayManager.DISPLAY.terminateServer
	      This  boolean  resource  specifies  whether  the	X
	      server  should  be terminated when a session termi
	      nates (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



X Version 11		   Release 6.1				8





XDM(1)							   XDM(1)


	      server is run.  The default value is ``false.''

       DisplayManager.DISPLAY.userPath
	      Xdm sets the PATH environment variable for the ses
	      sion to this value.  It should be a colon separated
	      list  of directories; see sh(1) for a full descrip
	      tion.    ``:/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.

       DisplayManager.DISPLAY.systemPath
	      Xdm  sets	 the  PATH  environment	 variable for the
	      startup and reset scripts	 to  the  value	 of  this
	      resource.	  The default for this resource is speci
	      fied at build time by the	 DefaultSystemPath  entry
	      in      the      system	  configuration	    file;
	      ``/etc:/bin:/usr/bin:/usr/X11R6/bin:/usr/ucb'' is a
	      common choice.  Note the absence of ``.'' from this
	      entry.  This is a good practice to follow for root;
	      it  avoids many common Trojan Horse system penetra
	      tion schemes.

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

       DisplayManager.DISPLAY.failsafeClient
	      If the default session fails to execute,	xdm  will
	      fall  back  to  this program.  This program is exe
	      cuted with no arguments,	but  executes  using  the
	      same  environment	 variables  as	the session would
	      have had (see the	 section  Session  Program).   By
	      default, &lt;XRoot&gt;/bin/xterm is used.

       DisplayManager.DISPLAY.grabServer

       DisplayManager.DISPLAY.grabTimeout
	      To  improve security, xdm grabs the server and key
	      board 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, oth
	      erwise  the server is grabbed until just before the
	      session begins.  The  default  is	 ``false.''   The
	      grabTimeout resource specifies the maximum time xdm
	      will wait for the grab to succeed.   The	grab  may
	      fail  if	some other client has the server grabbed,
	      or possibly if the network latencies are very high.
	      This resource has a default value of 3 seconds; you
	      should be cautious when raising it, as a	user  can
	      be  spoofed  by a look-alike window on the display.



X Version 11		   Release 6.1				9





XDM(1)							   XDM(1)


	      If the grab  fails,  xdm	kills  and  restarts  the
	      server (if possible) and the session.

       DisplayManager.DISPLAY.authorize

       DisplayManager.DISPLAY.authName
	      authorize	 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  mecha
	      nisms to use, separated by white space.  XDMCP con
	      nections dynamically  specify  which  authorization
	      mechanisms are supported, so authName is ignored in
	      this case.  When authorize is set for a display and
	      authorization   is   not	available,  the	 user  is
	      informed by having a different message displayed in
	      the   login   widget.   By  default,  authorize  is
	      ``true.''	 authName is ``MIT-MAGIC-COOKIE-1,''  or,
	      if      XDM-AUTHORIZATION-1      is      available,
	      ``XDM-AUTHORIZATION-1 MIT-MAGIC-COOKIE-1.''

       DisplayManager.DISPLAY.authFile
	      This file is used to communicate the  authorization
	      data from xdm to the server, using the -auth server
	      command line option.  It should be kept in a direc
	      tory which is not world-writable as it could easily
	      be removed, disabling the	 authorization	mechanism
	      in  the server.  If not specified, a name is gener
	      ated from DisplayManager.authDir and  the	 name  of
	      the display.

       DisplayManager.DISPLAY.authComplain
	      If  set to ``false,'' disables the use of the unse
	      cureGreeting in the login window.	 See the  section
	      Authentication Widget.  The default is ``true.''

       DisplayManager.DISPLAY.resetSignal
	      The  number  of  the  signal xdm sends to reset the
	      server.  See the section	Controlling  the  Server.
	      The default is 1 (SIGHUP).

       DisplayManager.DISPLAY.termSignal
	      The number of the signal xdm sends to terminate the
	      server.  See the section	Controlling  the  Server.
	      The default is 15 (SIGTERM).

       DisplayManager.DISPLAY.resetForAuth
	      The original implementation of authorization in the
	      sample server  reread  the  authorization	 file  at
	      server  reset  time,  instead  of when checking the
	      initial connection.  As xdm  generates  the  autho
	      rization	information just before connecting to the
	      display, an old server  would  not  get  up-to-date
	      authorization  information.   This  resource causes



X Version 11		   Release 6.1			       10





XDM(1)							   XDM(1)


	      xdm to send SIGHUP to the server after  setting  up
	      the  file,  causing  an  additional server reset to
	      occur, during  which  time  the  new  authorization
	      information   will   be	read.	 The  default  is
	      ``false,'' which will work for all MIT servers.

       DisplayManager.DISPLAY.userAuthDir
	      When xdm is unable  to  write  to	 the  usual  user
	      authorization  file ($HOME/.Xauthority), it creates
	      a unique file name in this directory and points the
	      environment  variable  XAUTHORITY	 at  the  created
	      file.  It uses /tmp by default.

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

       Here is a reasonable configuration file,	 which	could  be
       named xdm-config:


	    DisplayManager.servers:	       /usr/X11R6/lib/X11/xdm/Xservers
	    DisplayManager.errorLogFile:       /usr/X11R6/lib/X11/xdm/xdm-errors
	    DisplayManager*resources:	       /usr/X11R6/lib/X11/xdm/Xresources
	    DisplayManager*startup:	       /usr/X11R6/lib/X11/xdm/Xstartup
	    DisplayManager*session:	       /usr/X11R6/lib/X11/xdm/Xsession
	    DisplayManager.pidFile:	       /usr/X11R6/lib/X11/xdm/xdm-pid
	    DisplayManager._0.authorize:       true
	    DisplayManager*authorize:	       false


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

XDMCP ACCESS CONTROL
       The   database	file   specified   by	the   DisplayMan
       ager.accessFile provides information  which  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 (`*'



X Version 11		   Release 6.1			       11





XDM(1)							   XDM(1)


       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  net
       work  address  may  be used.  For patterns, only canonical
       host names are used in the comparison, so ensure that  you
       do  not attempt to match aliases.  Preceding either a host
       name or a pattern with a `!' character causes hosts  which
       match that entry to be excluded.

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

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

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

       When checking 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 \



X Version 11		   Release 6.1			       12





XDM(1)							   XDM(1)


			   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 Xaccess file, specify ``CHOOSER''
       as the first entry in the  Indirect  host  list.	  Chooser
       will  send  a  Query request to each of the remaining host
       names in the list and offer a menu of all the  hosts  that
       respond.

       The  list  may consist of the word ``BROADCAST,'' in which
       case chooser will send a Broadcast instead, again offering
       a menu of all hosts that respond.  Note that on some oper
       ating 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 Dis
       playManager.DISPLAY.chooser resource.  For more	flexibil
       ity  at	this  step,  the chooser could be a shell script.
       Chooser is the session manager here; it is run instead  of
       a child xdm to manage the display.

       Resources  for this program can be put into the file named
       by DisplayManager.DISPLAY.resources.

       When the user selects a host, chooser prints the host cho
       sen,  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    DisplayMan
       ager.choiceTimeout  seconds)  and  forwards the request to
       the chosen host, which starts a session on that display.

LOCAL SERVER SPECIFICATION
       The resource DisplayManager.servers gives a server  speci
       fication	 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 con
       stantly be managed and which is	not  using  XDMCP.   This
       method  is  used typically for local servers only.  If the
       resource or the file named by the resource is  empty,  xdm
       will offer XDMCP service only.



X Version 11		   Release 6.1			       13





XDM(1)							   XDM(1)


       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 typ
       ical entry for local display number 0 would be:

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

       The display types are:

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


       The display name must be something that can be  passed  in
       the  -display option to an X program.  This string is used
       to generate the display-specific	 resource  names,  so  be
       careful	to  match the names (e.g., use ``:0 Sun-CG3 local
       /usr/X11R6/bin/X :0''  instead  of  ``localhost:0  Sun-CG3
       local  /usr/X11R6/bin/X	:0''  if your other resources are
       specified as ``DisplayManager._0.session'').  The  display
       class   portion	is  also  used	in  the	 display-specific
       resources, as the class of the resource.	 This  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 dis
       play is required to specify the display class, so the man
       ual  for	 your  particular  X terminal should document the
       display class string for your device.  If it doesn't,  you
       can run xdm in debug mode and look at the resource strings
       which it generates for that device, which will include the
       class string.

       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.

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

	    xlogin*login.translations: #override\
		 Ctrl&lt;Key&gt;R: abort-display()\n\
		 &lt;Key&gt;F1: set-session-argument(failsafe) finish-field()\n\
		 &lt;Key&gt;Return: set-session-argument() finish-field()
	    xlogin*borderWidth: 3
	    xlogin*greeting: CLIENTHOST
	    #ifdef COLOR
	    xlogin*greetColor: CadetBlue
	    xlogin*failColor: red



X Version 11		   Release 6.1			       14





XDM(1)							   XDM(1)


	    #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 ``&lt;Key&gt;: insert-
       char ()'' which responds to normal typing).

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

SETUP PROGRAM
       The  Xsetup  file  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 should be careful
       about security.	This is the  place  to	change	the  root
       background or bring up other windows that should appear on
       the screen along with the Login widget.

       In addition to any specified by DisplayManager.exportList,
       the following environment variables are passed:

	    DISPLAY	   the associated display name
	    PATH	   the value of DisplayManager.DISPLAY.systemPath
	    SHELL	   the value of DisplayManager.DISPLAY.systemShell
	    XAUTHORITY	   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.  They will  be
       able to interact with the mouse, however; beware of poten
       tial    security	   holes    here.      If     DisplayMan
       ager.DISPLAY.grabServer is set, Xsetup will not be able to
       connect to the display at all.  Resources for this program
       can   be	  put	into   the   file  named  by  DisplayMan
       ager.DISPLAY.resources.

       Here is a sample Xsetup script:

	    #!/bin/sh
	    # Xsetup_0 - setup script for one workstation
	    xcmsdb &lt; /usr/X11R6/lib/monitors/alex.0
	    xconsole -geometry 480x130-0-0 -notify -verbose -exitOnFail &


AUTHENTICATION WIDGET
       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  DisplayMan
       ager.DISPLAY.resources.	 All  of  these	 have  reasonable



X Version 11		   Release 6.1			       15





XDM(1)							   XDM(1)


       default	values,	 so it is not necessary to specify any of
       them.

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

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

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

       xlogin.Login.greeting
	      A string which identifies this window.  The default
	      is ``X Window System.''

       xlogin.Login.unsecureGreeting
	      When X authorization is requested in the configura
	      tion file for this display and none is in use, this
	      greeting	 replaces  the	standard  greeting.   The
	      default is ``This is an unsecure session''

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

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

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

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

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

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

       xlogin.Login.fail
	      A	 message  which is displayed when the authentica
	      tion fails.  The default is ``Login incorrect''

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



X Version 11		   Release 6.1			       16





XDM(1)							   XDM(1)


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

       xlogin.Login.failTimeout
	      The number of seconds that the failure  message  is
	      displayed.  The default is 30.

       xlogin.Login.translations
	      This  specifies the translations used for the login
	      widget.  Refer to the X Toolkit documentation for a
	      complete	discussion  on translations.  The default
	      translation table is:

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


       The actions which are supported by the widget are:

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

       delete-character
	      Erases the character after the cursor.

       move-backward-character
	      Moves the cursor backward.

       move-forward-character
	      Moves the cursor forward.

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

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

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




X Version 11		   Release 6.1			       17





XDM(1)							   XDM(1)


       erase-line
	      Erases the entire text.

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

       abort-session
	      Terminates and restarts the server.

       abort-display
	      Terminates the server, disabling it.   This  action
	      is  not  accessible  in  the default configuration.
	      There are various reasons to stop xdm on	a  system
	      console,	such  as  when	shutting the system down,
	      when using  xdmshell,  to	 start	another	 type  of
	      server,  or to generally access the console.  Send
	      ing xdm a SIGHUP will restart the display.  See the
	      section Controlling XDM.

       restart-session
	      Resets the X server and starts a new session.  This
	      can be used when the resources  have  been  changed
	      and  you	want  to test them or when the screen has
	      been overwritten with system messages.

       insert-char
	      Inserts the character typed.

       set-session-argument
	      Specifies a single word argument which is passed to
	      the  session  at	startup.  See the section Session
	      Program.

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

STARTUP PROGRAM
       The Xstartup program is run as root when the user logs in.
       It  is typically a shell script.	 Since it is run as root,
       Xstartup should be very careful about security.	 This  is
       the  place  to put commands which add entries to /etc/utmp
       (the sessreg program may be  useful  here),  mount  users'
       home  directories  from file servers, or abort the session
       if logins are not allowed.




X Version 11		   Release 6.1			       18





XDM(1)							   XDM(1)


       In addition to any specified by DisplayManager.exportList,
       the following environment variables are passed:

	    DISPLAY	   the associated display name
	    HOME	   the initial working directory of the user
	    USER	   the user name
	    PATH	   the value of DisplayManager.DISPLAY.systemPath
	    SHELL	   the value of DisplayManager.DISPLAY.systemShell
	    XAUTHORITY	   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 discontin
       ues 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 func
       tionality.

       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 -timeout 30 -center
		 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  is the command which is run as the
       user's session.	It is run with	the  permissions  of  the
       authorized user.

       In addition to any specified by DisplayManager.exportList,
       the following environment variables are passed:

	    DISPLAY	   the associated display name
	    HOME	   the initial working directory of the user
	    USER	   the user name
	    PATH	   the value of DisplayManager.DISPLAY.userPath
	    SHELL	   the user's default shell (from getpwnam)
	    XAUTHORITY	   may be set to a non-standard authority file
	    KRB5CCNAME	   may be set to a Kerberos credentials cache name





X Version 11		   Release 6.1			       19





XDM(1)							   XDM(1)


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

       An argument may be passed to this program from the authen
       tication	 widget	 using the `set-session-argument' action.
       This can be used to select different  styles  of	 session.
       One  good  use  of  this	 feature  is to allow the user to
       escape from the ordinary	 session  when	it  fails.   This
       allows  users  to  repair their own .xsession if it fails,
       without requiring administrative intervention.  The  exam
       ple following demonstrates this feature.

       This  example  recognizes  the  special ``failsafe'' mode,
       specified in the translations in the Xresources	file,  to
       provide	an  escape  from  the  ordinary session.  It also
       requires that the .xsession file be executable so we don't
       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  .xsession file might look something like this
       example.	 Don't forget that the	file  must  have  execute



X Version 11		   Release 6.1			       20





XDM(1)							   XDM(1)


       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 Xstartup, the Xreset script 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 Xstartup are also passed to Xreset.

       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 connec
       tions 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	      DisplayMan
       ager.DISPLAY.termSignal can specify alternate signals.

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

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 ses
       sion on the associated display.	Entries which  have  been
       removed are disabled immediately, meaning that any session



X Version 11		   Release 6.1			       21





XDM(1)							   XDM(1)


       in progress will be terminated without notice and  no  new
       session will be started.

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

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

ADDITIONAL LOCAL DISPLAYS
       To add an additional local display, add a line for  it  to
       the Xservers file.  (See the section Local Server Specifi
       cation.)

       Examine	the  display-specific  resources  in   xdm-config
       (e.g.,  DisplayManager._0.authorize) and consider which of
       them should be copied for the new  display.   The  default
       xdm-config  has	all the appropriate lines for displays :0
       and :1.

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 specify
       ing the server on the command line:

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


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

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


       This directs xdm to manage sessions on all three of  these
       terminals.  See the section Controlling Xdm for a descrip
       tion of using signals to enable and disable  these  termi
       nals in a manner reminiscent of init(8).

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





X Version 11		   Release 6.1			       22





XDM(1)							   XDM(1)


FILES
       &lt;XRoot&gt;/lib/X11/xdm/xdm-config
			   the default configuration file

       $HOME/.Xauthority   user	 authorization	file  where   xdm
			   stores keys for clients to read

       &lt;XRoot&gt;/lib/X11/xdm/chooser
			   the default chooser

       &lt;XRoot&gt;/bin/xrdb	   the default resource database loader

       &lt;XRoot&gt;/bin/X	   the default server

       &lt;XRoot&gt;/bin/xterm   the	default session program and fail
			   safe client

       &lt;XRoot&gt;/lib/X11/xdm/A&lt;display&gt;-&lt;suffix&gt;
			   the default	place  for  authorization
			   files

       /tmp/K5C&lt;display&gt;   Kerberos credentials cache

       Note:  &lt;XRoot&gt; refers to the root of the X11 install tree.

SEE ALSO
       X(1),  xinit(1),	  xauth(1),   Xsecurity(1),   sessreg(1),
       Xserver(1),
       X Display Manager Control Protocol

AUTHOR
       Keith Packard, MIT X Consortium

























X Version 11		   Release 6.1			       23


</PRE>
</BODY>
</HTML>
