Unix/Linux Go Back    

RedHat 9 (Linux i386) - man page for xdm (redhat section 1)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

XDM(1)											   XDM(1)

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

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

       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 Open  Group  stan-
       dard  XDMCP,  the  X  Display  Manager Control Protocol.  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 char-
       acter-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
       typically used as the ``session manager,'' meaning that termination of this process termi-
       nates 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 display and
       offer a menu of possible hosts that offer XDMCP display management.  This feature is  use-
       ful with X terminals that do not offer a host menu themselves.

       Xdm can be configured to ignore BroadcastQuery messages from selected hosts.  This is use-
       ful when you don't want the host to appear in menus produced by	chooser  or  X	terminals

       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 man-
       ual, 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.

       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	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 specified in Xservers, and it can manage remote X servers  (typically	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 dis-
       plays attached to a host, this step is typically not used, as the local host does the dis-
       play 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 system session file may do some addi-
       tional startup and typically runs the .xsession script in the user's home directory.  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  __projectroot__/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  trouble
       getting xdm working, check this file to see if xdm has any clues to the trouble.

       All  of these options, except -config itself, specify values 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.  /usr/X11R6/lib/X11/xdm/xdm-config is the default.  See the section Configura-
	      tion File.

	      Specifies ``false'' as the value for the DisplayManager.daemonMode resource.   This
	      suppresses  the normal daemon behavior, which is for xdm to close all file descrip-
	      tors, disassociate itself from the controlling terminal,	and  put  itself  in  the
	      background when it first starts up.

       -debug debug_level
	      Specifies the numeric value for the DisplayManager.debugLevel resource.  A non-zero
	      value causes xdm to print lots of debugging statements to  the  terminal;  it  also
	      disables	the DisplayManager.daemonMode resource, forcing xdm to run synchronously.
	      To interpret these debugging messages, a copy of the source code for xdm is  almost
	      a necessity.  No attempt has been made to rationalize or standardize the output.

       -error error_log_file
	      Specifies  the  value for the DisplayManager.errorLogFile resource.  This file con-
	      tains errors from xdm as well as anything written to stderr by the various  scripts
	      and programs run during the progress of the session.

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

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

       -udpPort port_number
	      Specifies  the  value  for  the DisplayManager.requestPort resource.  This sets the
	      port-number which xdm will monitor for XDMCP requests.  As XDMCP	uses  the  regis-
	      tered  well-known  UDP  port  177,  this	resource should not be changed except for
	      debugging. If set to 0 xdm will not listen for XDMCP or Chooser requests.

       -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 most X Toolkit applications.

       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 display, the display name is inserted into the resource name  between  ``Display-
       Manager'' 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

       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,   DisplayMan-
       ager.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  Local
	      Server Specification for the details.

	      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.

	      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  out-
	      put  directed  to  stderr by the Xsetup, Xstartup, Xsession and Xreset 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
	      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 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  debugging).   Setting  this
	      resource to ``false'' will disable this feature.

	      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.

	      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.

	      This names a directory under which xdm stores authorization files while  initializ-
	      ing  the	session.  The default value is __projectroot__/lib/X11/xdm.  Can be over-
	      ridden for specific displays by DisplayManager.DISPLAY.authFile.

	      This boolean controls whether xdm rescans the configuration, servers,  access  con-
	      trol  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 display name for XDMCP clients, the name resolver will typically
	      create a fully qualified host name for the terminal.  As this is sometimes  confus-
	      ing,  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  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

	      To prevent unauthorized XDMCP service and to allow forwarding  of  XDMCP	Indirect-
	      Query 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

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

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

	      On systems that support a dynamically-loadable greeter library,  the  name  of  the
	      library.	The default is __projectroot__/lib/X11/xdm/libXdmGreet.so.

	      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.

	      Use the numeric IP address of the incoming connection on multihomed  hosts  instead
	      of  the  host name. This is to avoid trying to connect on the wrong interface which
	      might be down at this time.

	      This specifies a program which is run (as) root when an an XDMCP BroadcastQuery  is
	      received	and this host is configured to offer XDMCP display management. The output
	      of this program may be displayed on a chooser window.  If no program is  specified,
	      the string Willing to manage is sent.

	      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 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 __projectroot__/lib/X11/xdm/Xre-
	      sources is the conventional name.

	      Specifies the program run to offer a host menu for Indirect queries  redirected  to
	      the special host name CHOOSER.  __projectroot__/lib/X11/xdm/chooser is the default.
	      See the sections XDMCP Access Control and Chooser.

	      Specifies the program used to load the resources.  By default, xdm uses  __project-

	      This specifies the name of the C preprocessor which is used by 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 (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 Program.

	      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.

	      This  specifies  the  session  to  be  executed (not running as root).  By default,
	      __projectroot__/bin/xterm is run.  The conventional name is Xsession.  See the sec-
	      tion Session Program.

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




	      These numeric resources control the behavior of xdm when attempting to open intran-
	      sigent servers.  openDelay is the length of the pause (in seconds) between  succes-
	      sive  attempts,  openRepeat  is  the number of attempts to make, openTimeout is the
	      amount of time to wait while actually attempting the open (i.e., the  maximum  time
	      spent  in the connect(2) 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 particular 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 dis-
	      abled.  Although this behavior may seem arbitrary, it has been  empirically  devel-
	      oped and works quite well on most systems.  The default values are 5 for openDelay,
	      5 for openRepeat, 30 for openTimeout and 4 for startAttempts.


	      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  min-
	      utes.   If you frequently use X terminals which can become isolated from the manag-
	      ing 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 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 environment 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 configuration file with DefaultUser-

	      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    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 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, __projectroot__/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 latencies are  very
	      high.   This resource has a default value of 3 seconds; you should be cautious when
	      raising it, as a user can be spoofed by a look-alike window on the display.  If the
	      grab fails, xdm kills and restarts the server (if possible) and the session.


	      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 mechanisms to use, separated by white space.  XDMCP con-
	      nections dynamically specify which authorization mechanisms are supported, so auth-
	      Name  is	ignored in this case.  When authorize is set for a display and authoriza-
	      tion 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-

	      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 directory which
	      is  not  world-writable  as it could easily be removed, disabling the authorization
	      mechanism in the server.	If not specified, a name is  generated	from  DisplayMan-
	      ager.authDir and the name of the display.

	      If  set to ``false,'' disables the use of the unsecureGreeting in the login window.
	      See the section Authentication Widget.  The default is ``true.''

	      The number of the signal xdm sends to reset the server.  See the	section  Control-
	      ling the Server.	The default is 1 (SIGHUP).

	      The  number  of the signal xdm sends to terminate the server.  See the section Con-
	      trolling the Server.  The default is 15 (SIGTERM).

	      The original implementation of authorization in the sample server reread the autho-
	      rization	file  at  server reset time, instead of when checking the initial connec-
	      tion.  As xdm generates the authorization information just before connecting to the
	      display,	an  old  server would not get up-to-date authorization information.  This
	      resource causes xdm to send SIGHUP to the server after setting up the file, causing
	      an additional server reset to occur, during which time the new authorization infor-
	      mation will be read.  The default  is  ``false,''  which	will  work  for  all  MIT

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

       First,  the xdm configuration file should be set up.  Make a directory (usually __project-
       root__/lib/X11/xdm) to contain all of the relevant files.

       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  nor-
       mally this is not very useful.  See the Resources section for a complete discussion.

       The  database  file  specified by the DisplayManager.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 dis-
       tinguished  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 com-
       pared  against the host name of the display device.  If the entry is a host name, all com-
       parisons 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 compar-
       ison, 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.

       To  only  respond  to  Direct  queries  for  a  host or pattern, it can be followed by the
       optional ``NOBROADCAST'' keyword.  This can be used to prevent an xdm server from  appear-
       ing on menus based on Broadcast queries.

       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 con-
       nect 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

       *.deshaw.com	   NOBROADCAST	       # allow only direct access
       *.gw.com 			       # allow direct and broadcast

       # 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

       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  Broad-
       cast  instead, again offering a menu of all hosts that respond.	Note that on some operat-
       ing 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.DISPLAY.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  dis-

       Resources  for  this  program  can  be  put  into  the  file  named by DisplayManager.DIS-

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

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

       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 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 pro-
       gram.  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 ``local-
       host:0 Sun-CG3 local /usr/X11R6/bin/X :0'' if your other resources are specified as ``Dis-
       playManager._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 display is required to specify the  display  class,
       so  the manual 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.

       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 parame-
       ters 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
	    xlogin*greeting: CLIENTHOST
	    #ifdef COLOR
	    xlogin*greetColor: CadetBlue
	    xlogin*failColor: red

       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.

       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 secu-
       rity.  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 vari-
       ables 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 key-
       board  input.   They will be able to interact with the mouse, however; beware of potential
       security holes here.  If DisplayManager.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 DisplayManager.DISPLAY.resources.

       Here is a sample Xsetup script:

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

       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 DisplayManager.DISPLAY.resources.	All of these have reason-
       able default values, so it is not necessary to specify any of them.

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

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

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

	      A string which 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	greeting  replaces the standard greeting.  The default is
	      ``This is an unsecure session''

	      The font used to display the greeting.

	      The color used to display the greeting.

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

	      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 which is displayed when the authentication fails.  The default is ``Login

	      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  specifies the translations used for the login widget.  Refer to the X Toolkit
	      documentation for a complete discussion on translations.	The  default  translation
	      table is:

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

	      If  set  to ``false'', don't allow root (and any other user with uid = 0) to log in
	      directly.  The default is ``true''.

	      If set to ``true'', allow an otherwise failing password match  to  succeed  if  the
	      account  does  not  require  a  password at all.	The default is ``false'', so only
	      users that have passwords assigned can log in.

       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/pass-
	      word  pair is valid, xdm starts the session.  Otherwise the failure message is dis-
	      played and the user is prompted again.

	      Terminates and restarts the server.

	      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.  Sending xdm a SIGHUP will restart the
	      display.	See the section Controlling XDM.

	      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.

	      Inserts the character typed.

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

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

       On  some  systems  (OpenBSD) the user's shell must be listed in /etc/shells to allow login
       through xdm. The normal password and account expiration dates are enforced too.

       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  use-
       ful here), mount users' home directories from file servers, or abort the session if logins
       are not allowed.

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

	    DISPLAY	   the associated display name
	    HOME	   the initial working directory of the user
	    LOGNAME	   the user name
	    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 discontinues the ses-
       sion 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 function-

       Here is a sample Xstartup script:

	    # 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
	    sessreg -a -l $DISPLAY -x /usr/X11R6/lib/xdm/Xservers $LOGNAME
	    exit 0

       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 vari-
       ables are passed:

	    DISPLAY	   the associated display name
	    HOME	   the initial working directory of the user
	    LOGNAME	   the user name
	    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

       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

       An argument may be passed to this program from the authentication widget using  the  `set-
       session-argument'  action.   This  can be used to select different styles of session.  One
       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 example 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

	    # Xsession
	    # This is the program that is run as the client
	    # for the display manager.

	    case $# in
		 case $1 in
		      exec xterm -geometry 80x24-0-0


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

       The  user's  .xsession file might look something like this example.  Don't 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

       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 environ-
       ment variables that were passed to Xstartup are also passed to Xreset.

       A sample Xreset script:
	    # Xreset
	    # This program is run as root after the session ends
	    sessreg -d -l $DISPLAY -x /usr/X11R6/lib/xdm/Xservers $LOGNAME
	    exit 0

       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  DisplayManager.DISPLAY.resetSignal  and  DisplayManager.DISPLAY.termSignal  can
       specify alternate signals.

       To control remote terminals not using XDMCP, xdm searches the window hierarchy on the dis-
       play 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.

       Xdm responds to two signals: SIGHUP and SIGTERM.  When sent a SIGHUP, xdm rereads the con-
       figuration  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 disabled immedi-
       ately, meaning that any session in progress will be terminated without notice and  no  new
       session will be started.

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

       Xdm attempts to mark its various sub-processes for ps(1) by editing the command line argu-
       ment list in place.  Because xdm can't allocate additional space for this task, it is use-
       ful 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.

       To add an additional local display, add a line for it to the Xservers file.  (See the sec-
       tion Local Server Specification.)

       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.

       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 command line:

	    xdm -server ":0 SUN-3/60CG4 local __projectroot__/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 Con-
       trolling Xdm for a description of using signals to enable and disable these terminals in a
       manner reminiscent of init(8).

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

			   the default configuration file

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

			   the default chooser

       /usr/X11R6/bin/xrdb the default resource database loader

       /usr/X11R6/bin/X    the default server

			   the default session program and failsafe client

			   the default place for authorization files

       /tmp/K5C<display>   Kerberos credentials cache

       X(7x), xinit(1), xauth(1), Xsecurity(7x), sessreg(1), Xserver(1),
       X Display Manager Control Protocol

       Keith Packard, MIT X Consortium

X Version 11				   Release 6.6					   XDM(1)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 05:00 AM.