*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> X11/xdm (1)              


     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

     NAME    [Toc]    [Back]
	  xdm -	X Display Manager with support for XDMCP, host chooser

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

     DESCRIPTION    [Toc]    [Back]
	  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
	  standard 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

	  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 typically used	as the
	  ``session manager,'' meaning that termination	of this
	  process terminates the user's	session.

	  When the session is terminated, xdm resets the X server and
	  (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 useful with X terminals that do
	  not offer a host menu	themselves.

	  Because xdm provides the first interface that	users will
	  see, it is designed to be simple to use and easy to
	  customize to the needs of a particular site.	Xdm has	many
	  options, most	of which have reasonable defaults.  Browse
	  through the various sections of this 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    [Toc]    [Back]
	  xdm is highly	configurable, and most of its behavior can be
	  controlled by	resource files and shell scripts located in

     Page 1					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	  the directory	/var/X11/xdm.  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.

	  Xlogin, contains commands which initialize the login screen
	  and provides hooks for alternative login programs.  See the
	  script for details.

	  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

	  Then xdm runs	the Xsession script as the user.  This system
	  session file may do some additional 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 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.

     OPTIONS    [Toc]    [Back]
	  All of these options,	except -config itself, specify values
	  that can also	be specified in	the configuration file as

     Page 2					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	  -config configuration_file
	       Names the configuration file, which specifies resources
	       to control the behavior of xdm. /var/X11/xdm/xdm-config
	       is the default.	See the	section	Configuration 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	descriptors, 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 contains 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
	       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.

     Page 3					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	  -xrm resource_specification
	       Allows an arbitrary resource to be specified, as	in
	       most X Toolkit applications.

     LOGIN DEFAULTS (SGI-specific)    [Toc]    [Back]
	  When xdm's authentication widget is used to perform user
	  authentication, xdm enforces the following login defaults,
	  which	are specified in the file /etc/default/login.

	  CONSOLE=device   If this is set to /dev/console, root	logins
			   are restricted to the first local display
			   in the xservers file.  If this is set to
			   another value, root logins via xdm are
			   disallowed.	If undefined, root can log in
			   on any display.

	  PASSREQ=NO	   Determines whether all accounts must	have
			   passwords.  If YES, and user	has no
			   password, they will be prompted for one at
			   login time.

	  MANDPASS=NO	   Like	PASSREQ, but won't allow users with no
			   password to log in.

	  UMASK=022	   Default umask, in octal.

	  TIMEOUT=60	   If login attempt is not completed within
			   TIMEOUT seconds from	first key press, the
			   session is restarted.

	  SLEEPTIME=1	   Sleep for this many seconds before issuing
			   "login incorrect" message (maximum 60

	  DISABLETIME=0	   After LOGFAILURES or	MAXTRYS	unsuccessful
			   attempts, sleep for DISABLETIME seconds
			   before restarting.

	  MAXTRYS=3	   Restart session after MAXTRYS unsuccessful
			   attempts (0 = unlimited attempts).

	  LOGFAILURES=3	   If there are	LOGFAILURES consecutive
			   unsuccessful	login attempts,	each of	them
			   will	be logged in /var/adm/loginlog,	if it
			   exists.  LOGFAILURES	has a maximum value of
			   20.	Note: Users get	at most	the minimum of
			   (MAXTRYS, LOGFAILURES) unsuccessful

	  IDLEWEEKS=-1	   If non-negative, specify a grace period
			   during which	users with expired passwords
			   will	be allowed to enter a new password.

     Page 4					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

			   In other words, accounts with expired
			   passwords can stay idle up to this long
			   before being	"locked	out".  If IDLEWEEKS is
			   zero, there is no grace period, and expired
			   passwords are the same as invalidated

	  SYSLOG=FAIL	   Log to syslog all login failures
			   (SYSLOG=FAIL) or all	successes and failures
			   (SYSLOG=ALL).  Log entries are written to
			   the LOG_AUTH	facility (see syslog(3)	and
			   syslogd(1M) for details).  No messages are
			   sent	to syslog if not set.  Note that this
			   is separate from the	login log,

	  INITGROUPS=YES   If YES, make	the user session be a member
			   of all of the user's	supplementary groups
			   (see	multgrps(1) or initgroups(3).  Note
			   that	some clients, such as xterm(1) and
			   xwsh(1G) , may call initgroups(3) even if
			   xdm does not.

	  SVR4_SIGNALS=NO  Use the SVR4	semantics for the SIGXCPU and
			   SIGXFSZ signals. If SVR4_SIGNALS=YES, then
			   the SVR4 semantics are preserved and	all
			   processes will ignore SIGXCPU and SIGXFSZ
			   by default.	If SVR4_SIGNALS=NO, then these
			   two signals will retain their default
			   action, which is to cause the receiving
			   process to core dump.  If users intend to
			   make	use of the CPU and filesize resource
			   limits, SVR4_SIGNALS	should be set to NO.
			   Note	that using these signals while
			   SVR4_SIGNALS	is set to YES will cause
			   behavior which varies depending on the
			   login shell.	 This setting has no affect on
			   processes which explicitly alter the
			   behavior of these signals using the
			   signal(2) system call.

	  SITECHECK=	   Use an external program to authenticate
			   users instead of using the encrypted
			   password field.  This allows	sites to
			   implement other means of authentication,
			   such	as card	keys, biometrics, etc.	The
			   program is invoked with user	name as	the
			   first argument, and remote hostname and

     Page 5					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

			   username, if	applicable.  The action	taken
			   depends on exit status, as follows:
			       0      -	success: user was
					authenticated, log in.
			       1 or 2 -	failure; restart the
			       other  -	use normal UNIX
			   If the program is not owned by root,	is
			   writable by others, or cannot be executed,
			   normal password authentication is
			   performed.  It is recommended that the
			   program be given a mode of 500.  A
			   sitecheck program to	be used	with xdm must
			   create and manage its own window.  WARNING!
			   Because this	option has the potential to
			   defeat normal IRIX security,	any program
			   used	in this	way must be designed and
			   tested very carefully.

	  LOCKOUT=0	   If non-zero,	after this number of
			   consecutive unsuccessful login attempts by
			   the same user, by all instances of xdm and
			   login, lock the account by invoking "passwd
			   -l username".

	  LOCKOUTEXEMPT=   If LOCKOUT is greater than zero, the	users
			   listed as LOCKOUTEXEMPT will	NOT be subject
			   to the LOCKOUT option.  Usernames are
			   separated by	spaces,	the list must be
			   terminated by end-of-line, maximum list
			   length is 240 characters. LOCKOUTEXEMPT is
			   ignored unless LOCKOUT is enabled, and the
			   list	is not empty. Including	privileged
			   accounts (such as root) in the
			   LOCKOUTEXEMPT list, is not recommended, as
			   it allows an	indefinite number of attacks
			   on the exempt accounts. Also, if
			   LOCKOUTEXEMPT is enabled, the
			   /etc/default/login file should be given a
			   mode	400 or 600 to prevent unauthorized
			   viewing and/or tampering with the

	  If user authentication is performed by a visual login
	  program such as clogin(1), xdm enforces only UMASK and

     RESOURCES    [Toc]    [Back]
	  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

     Page 6					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	  on all displays, while others	modify its behavior on a
	  single display.  Where actions relate	to a specific display,
	  the display name is inserted into the	resource name between
	  ``DisplayManager'' and the final resource name segment.

	  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, DisplayManager.expo_x_org_0.startup is the name of
	  the resource which defines the startup shell file for	the
	  ``expo.x.org:0'' display.

	       This resource either specifies a	file name full of
	       server entries, one per line (if	the value starts with
	       a slash), or a single server entry.  See	the section
	       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

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

	       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

     Page 7					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	       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 initializing the session.
	       The default value is /var/X11/xdm.  Can be overridden
	       for specific displays by

	       This boolean controls whether xdm rescans the
	       configuration, servers, access control and
	       authentication keys files after a session terminates
	       and the files have changed.  By default it is ``true.''
	       You can force xdm to reread these files by sending a
	       SIGHUP to the main process.

	       When computing the 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	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

     Page 8					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

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

	       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.  Default is
	       libXdmGreet.so.	SGI does not support dynamicallyloadable

	       Number of seconds to wait for display to	respond	after
	       user has	selected a host	from the chooser.  If the
	       display sends an	XDMCP IndirectQuery within this	time,
	       the request is forwarded	to the chosen host.
	       Otherwise, it is	assumed	to be from a new session and
	       the chooser is offered again.  Default is 15.

	       This resource specifies the name	of the file to be
	       loaded by xrdb as the resource database onto the	root
	       window of screen	0 of the display.  The Xsetup 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
	       /var/X11/xdm/Xresources is the conventional name.

     Page 9					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	       Specifies the program run to offer a host menu for
	       Indirect	queries	redirected to the special host name
	       CHOOSER.	 /var/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 /usr/bin/X11/xrdb.

	       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, /usr/bin/X11/xterm is run.  The
	       conventional name is Xsession.  See the section Session

	       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




	       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 number

     Page 10					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	       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
	       disabled.  Although this	behavior may seem arbitrary,
	       it has been empirically developed and works quite well
	       on most systems.	 The default values are	5 for
	       openDelay, 5 for	openRepeat, 30 for openTimeout and 4
	       for startAttempts.


	       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 terminals 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 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/X11/bin:/usr/ucb''	is a common
	       setting.	 The default value can be specified at build
	       time in the X system configuration file with

     Page 11					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)


	       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/X11/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

	       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,
	       /usr/bin/X11/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

     Page 12					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	       is a list of authorization mechanisms to	use, separated
	       by white	space.	XDMCP connections 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 ``off.''  authName is	``MIT-MAGIC-COOKIE-1,''	or, if

	       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
	       DisplayManager.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 ``false.''

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

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

	       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 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 information 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/.Xauthority), it creates a

     Page 13					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	       unique file name	in this	directory and points the
	       environment variable XAUTHORITY at the created file.
	       It uses /tmp by default.

     CONFIGURATION FILE    [Toc]    [Back]
	  First, the xdm configuration file should be set up.  Make a
	  directory (usually /var/X11/xdm).  On	SGI systems, the
	  default configuration	files is /var/X11/xdm/xdm-config.

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

	       DisplayManager.servers:		  /var/X11/xdm/Xservers
	       DisplayManager.errorLogFile:	  /var/X11/xdm/xdm-errors
	       DisplayManager*resources:	  /var/X11/xdm/Xresources
	       DisplayManager*startup:		  /var/X11/xdm/Xstartup
	       DisplayManager*session:		  /var/X11/xdm/Xsession
	       DisplayManager.pidFile:		  /var/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

     XDMCP ACCESS CONTROL    [Toc]    [Back]
	  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 distinguished from a host	name
	  by the inclusion of one or more meta characters (`*' matches
	  any sequence of 0 or more characters,	and `?'	matches	any
	  single character) which are compared against the host	name
	  of the display device.  If the entry is a host name, all
	  comparisons are done using network addresses,	so any name
	  which	converts to the	correct	network	address	may be used.
	  For 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

     Page 14					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	  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

	  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 \
			      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    [Toc]    [Back]
	  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

     Page 15					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	  the first entry in the Indirect host list.  Chooser will
	  send a Query request to each of the remaining	host names in
	  the list and offer a menu of all the hosts that respond.

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

	  Example Xaccess file using chooser:

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

	  The program to use for chooser is specified by the
	  DisplayManager.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 display.

	  Resources for	this program can be put	into the file named by

	  When the user	selects	a host,	chooser	prints the host
	  chosen, which	is read	by the parent xdm, and exits.  xdm
	  closes its connection	to the X server, and the server	resets
	  and sends another Indirect XDMCP request.  xdm remembers the
	  user's choice	(for DisplayManager.choiceTimeout 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

	  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/X11/bin/X :0

	  The display types are:

     Page 16					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	  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 local /usr/X11/bin/X :0''
	  instead of ``localhost:0 local /usr/X11/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 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

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

	       xlogin*login.translations: #override\
		    Ctrl<Key>R:	abort-display()\n\
		    <Key>F1: set-session-argument(failsafe) finish-field()\n\
		    <Key>Return: set-session-argument()	finish-field()
	       xlogin*borderWidth: 3
	       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

     Page 17					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	  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.

     SETUP PROGRAM    [Toc]    [Back]
	  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
	  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

	  Here is a sample Xsetup script:

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

     AUTHENTICATION WIDGET    [Toc]    [Back]
	  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
	  reasonable default values, so	it is not necessary to specify
	  any of them.

	  xlogin.Login.width, xlogin.Login.height, xlogin.Login.x,
	       The geometry of the Login widget	is normally computed

     Page 18					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	       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 incorrect''

	       The font	used to	display	the failure message.

	       The color used to display the failure message.

     Page 19					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	       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() \

	  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.


     Page 20					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	       Erases the entire text.

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

	       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
	       disconnect the machine from the network before doing

     STARTUP PROGRAM    [Toc]    [Back]
	  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.

	  In addition to any specified by DisplayManager.exportList,

     Page 21					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	  the following	environment variables 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
	  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

	  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 /var/X11/xdm/Xservers $LOGNAME
	       exit 0

     SESSION PROGRAM    [Toc]    [Back]
	  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
	       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

     Page 22					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

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

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

	       # 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

     Page 23					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)


	  Note that the	script always ends with	an exec.  This is the
	  standard way to run xdm.  When the execed program exits, the
	  session will end.  SGI also provides another way to control
	  the termination of a session.	 You can finish	your script
	       exec /usr/bin/X11/reaper
	  In that case,	the reaper program places a property,
	  _SGI_SESSION_PROPERTY, on the	root window and	exits.	The
	  session does not end when reaper exits.  Instead, when the
	  _SGI_SESSION_PROPERTY	property is removed, xdm will
	  terminate the	session.  The program endsession will remove
	  that property. So will selecting "Log	out" in	the standard
	  toolchest menu.

	  The user's .xsession file might look something like this
	  example.  Don't forget that the file must have execute
	       #! /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    [Toc]    [Back]
	  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:
	       # Xreset
	       # This program is run as	root after the session ends
	       sessreg -d -l $DISPLAY -x /var/X11/xdm/Xservers $LOGNAME
	       exit 0

     CONTROLLING THE SERVER    [Toc]    [Back]
	  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

     Page 24					     (printed 10/9/01)

     XDM(1)		X Version 11 (Release 6.4)		XDM(1)

	  expected actions, the	resources
	  DisplayManager.DISPLAY.resetSignal and
	  DisplayManager.DISPLAY.termSignal can	specify	alternate

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

 Similar pages
Name OS Title
VkColorChooserDialog IRIX A dialog manager for color chooser dialogs
upl OpenBSD USB support for Prolific based host-to-host adapters
HostManager IRIX Host Manager
tcasic OpenBSD TURBOchannel host bus support
cstm HP-UX Support Tools Manager
xstm HP-UX Support Tools Manager
mstm HP-UX Support Tools Manager
stm HP-UX Support Tools Manager
hostname HP-UX set or display name of current host system
VkInterruptDialog IRIX A dialog manager that support interrupts
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service