1XDM(1) General Commands Manual XDM(1)
2
6 xdm - X Display Manager with support for XDMCP, host chooser
7
9 xdm [ -config configuration_file ] [ -nodaemon ] [ -debug debug_level ]
10 [ -error error_log_file ] [ -resources resource_file ] [ -server
11 server_entry ] [ -session session_program ]
12
14 Xdm manages a collection of X displays, which may be on the local host
15 or remote servers. The design of xdm was guided by the needs of X ter‐
16 minals as well as The Open Group standard XDMCP, the X Display Manager
17 Control Protocol. Xdm provides services similar to those provided by
18 init, getty and login on character terminals: prompting for login name
19 and password, authenticating the user, and running a ``session.''
20 A ``session'' is defined by the lifetime of a particular process; in
22 the traditional character-based terminal world, it is the user's login
23 shell. In the xdm context, it is an arbitrary session manager. This
24 is because in a windowing environment, a user's login shell process
25 does not necessarily have any terminal-like interface with which to
26 connect. When a real session manager is not available, a window man‐
27 ager or terminal emulator is typically used as the ``session manager,''
28 meaning that termination of this process terminates the user's session.
29 When the session is terminated, xdm resets the X server and (option‐
31 ally) restarts the whole process.
32 When xdm receives an Indirect query via XDMCP, it can run a chooser
34 process to perform an XDMCP BroadcastQuery (or an XDMCP Query to speci‐
35 fied hosts) on behalf of the display and offer a menu of possible hosts
36 that offer XDMCP display management. This feature is useful with X
37 terminals that do not offer a host menu themselves.
38 Xdm can be configured to ignore BroadcastQuery messages from selected
40 hosts. This is useful when you don't want the host to appear in menus
41 produced by chooser or X terminals themselves.
42 Because xdm provides the first interface that users will see, it is
44 designed to be simple to use and easy to customize to the needs of a
45 particular site. Xdm has many options, most of which have reasonable
46 defaults. Browse through the various sections of this manual, picking
47 and choosing the things you want to change. Pay particular attention
48 to the Session Program section, which will describe how to set up the
49 style of session desired.
50
52 xdm is highly configurable, and most of its behavior can be controlled
53 by resource files and shell scripts. The names of these files them‐
54 selves are resources read from the file xdm-config or the file named by
55 the -config option.
56 xdm offers display management two different ways. It can manage X
58 servers running on the local machine and specified in Xservers, and it
59 can manage remote X servers (typically X terminals) using XDMCP (the
60 XDM Control Protocol) as specified in the Xaccess file.
61 The resources of the X clients run by xdm outside the user's session,
63 including xdm's own login window, can be affected by setting resources
64 in the Xresources file.
65 For X terminals that do not offer a menu of hosts to get display man‐
67 agement from, xdm can collect willing hosts and run the chooser program
68 to offer the user a menu. For X displays attached to a host, this step
69 is typically not used, as the local host does the display management.
70 After resetting the X server, xdm runs the Xsetup script to assist in
72 setting up the screen the user sees along with the xlogin widget.
73 The xlogin widget, which xdm presents, offers the familiar login and
75 password prompts.
76 After the user logs in, xdm runs the Xstartup script as root.
78 Then xdm runs the Xsession script as the user. This system session
80 file may do some additional startup and typically runs the .xsession
81 script in the user's home directory. When the Xsession script exits,
82 the session is over.
83 At the end of the session, the Xreset script is run to clean up, the X
85 server is reset, and the cycle starts over.
86 The file /var/log/xdm.log will contain error messages from xdm and
88 anything output to stderr by Xsetup, Xstartup, Xsession or Xreset.
89 When you have trouble getting xdm working, check this file to see if
90 xdm has any clues to the trouble.
91
93 All of these options, except -config itself, specify values that can
94 also be specified in the configuration file as resources.
95 -config configuration_file
97 Names the configuration file, which specifies resources to con‐
98 trol the behavior of xdm. /etc/X11/xdm/xdm-config is the
99 default. See the section Configuration File.
100 -nodaemon
102 Specifies ``false'' as the value for the DisplayManager.daemon‐
103 Mode resource. This suppresses the normal daemon behavior,
104 which is for xdm to close all file descriptors, disassociate
105 itself from the controlling terminal, and put itself in the
106 background when it first starts up.
107 -debug debug_level
109 Specifies the numeric value for the DisplayManager.debugLevel
110 resource. A non-zero value causes xdm to print lots of debug‐
111 ging statements to the terminal; it also disables the Display‐
112 Manager.daemonMode resource, forcing xdm to run synchronously.
113 To interpret these debugging messages, a copy of the source code
114 for xdm is almost a necessity. No attempt has been made to
115 rationalize or standardize the output.
116 -error error_log_file
118 Specifies the value for the DisplayManager.errorLogFile
119 resource. This file contains errors from xdm as well as any‐
120 thing written to stderr by the various scripts and programs run
121 during the progress of the session.
122 -resources resource_file
124 Specifies the value for the DisplayManager*resources resource.
125 This file is loaded using xrdb to specify configuration parame‐
126 ters for the authentication widget.
127 -server server_entry
129 Specifies the value for the DisplayManager.servers resource.
130 See the section Local Server Specification for a description of
131 this resource.
132 -udpPort port_number
134 Specifies the value for the DisplayManager.requestPort resource.
135 This sets the port-number which xdm will monitor for XDMCP
136 requests. As XDMCP uses the registered well-known UDP port 177,
137 this resource should not be changed except for debugging. If set
138 to 0 xdm will not listen for XDMCP or Chooser requests.
139 -session session_program
141 Specifies the value for the DisplayManager*session resource.
142 This indicates the program to run as the session after the user
143 has logged in.
144 -xrm resource_specification
146 Allows an arbitrary resource to be specified, as in most X Tool‐
147 kit applications.
148
150 At many stages the actions of xdm can be controlled through the use of
151 its configuration file, which is in the X resource format. Some
152 resources modify the behavior of xdm on all displays, while others mod‐
153 ify its behavior on a single display. Where actions relate to a spe‐
154 cific display, the display name is inserted into the resource name
155 between ``DisplayManager'' and the final resource name segment.
156 For local displays, the resource name and class are as read from the
158 Xservers file.
159 For remote displays, the resource name is what the network address of
161 the display resolves to. See the removeDomain resource. The name must
162 match exactly; xdm is not aware of all the network aliases that might
163 reach a given display. If the name resolve fails, the address is used.
164 The resource class is as sent by the display in the XDMCP Manage
165 request.
166 Because the resource manager uses colons to separate the name of the
168 resource from its value and dots to separate resource name parts, xdm
169 substitutes underscores for both dots and colons when generating the
170 resource name. For example, DisplayManager.expo_x_org_0.startup is the
171 name of the resource which defines the startup shell file for the
172 ``expo.x.org:0'' display.
173 DisplayManager.servers
175 This resource either specifies a file name full of server
176 entries, one per line (if the value starts with a slash), or a
177 single server entry. See the section Local Server Specification
178 for the details.
179 DisplayManager.requestPort
181 This indicates the UDP port number which xdm uses to listen for
182 incoming XDMCP requests. Unless you need to debug the system,
183 leave this with its default value of 177.
184 DisplayManager.errorLogFile
186 Error output is normally directed at the system console. To re‐
187 direct it, set this resource to a file name. A method to send
188 these messages to syslog should be developed for systems which
189 support it; however, the wide variety of interfaces precludes
190 any system-independent implementation. This file also contains
191 any output directed to stderr by the Xsetup, Xstartup, Xsession
192 and Xreset files, so it will contain descriptions of problems in
193 those scripts as well.
194 DisplayManager.debugLevel
196 If the integer value of this resource is greater than zero,
197 reams of debugging information will be printed. It also dis‐
198 ables daemon mode, which would redirect the information into the
199 bit-bucket, and allows non-root users to run xdm, which would
200 normally not be useful.
201 DisplayManager.daemonMode
203 Normally, xdm attempts to make itself into a daemon process
204 unassociated with any terminal. This is accomplished by forking
205 and leaving the parent process to exit, then closing file
206 descriptors and releasing the controlling terminal. In some
207 environments this is not desired (in particular, when debug‐
208 ging). Setting this resource to ``false'' will disable this
209 feature.
210 DisplayManager.pidFile
212 The filename specified will be created to contain an ASCII rep‐
213 resentation of the process-id of the main xdm process. Xdm also
214 uses file locking on this file to attempt to eliminate multiple
215 daemons running on the same machine, which would cause quite a
216 bit of havoc.
217 DisplayManager.lockPidFile
219 This is the resource which controls whether xdm uses file lock‐
220 ing to keep multiple display managers from running amok. On
221 System V, this uses the lockf library call, while on BSD it uses
222 flock.
223 DisplayManager.authDir
225 This names a directory under which xdm stores authorization
226 files while initializing the session. The default value is
227 /etc/X11/xdm. Can be overridden for specific displays by Dis‐
228 playManager.DISPLAY.authFile.
229 DisplayManager.autoRescan
231 This boolean controls whether xdm rescans the configuration,
232 servers, access control and authentication keys files after a
233 session terminates and the files have changed. By default it is
234 ``true.'' You can force xdm to reread these files by sending a
235 SIGHUP to the main process.
236 DisplayManager.removeDomainname
238 When computing the display name for XDMCP clients, the name
239 resolver will typically create a fully qualified host name for
240 the terminal. As this is sometimes confusing, xdm will remove
241 the domain name portion of the host name if it is the same as
242 the domain name of the local host when this variable is set. By
243 default the value is ``true.''
244 DisplayManager.keyFile
246 XDM-AUTHENTICATION-1 style XDMCP authentication requires that a
247 private key be shared between xdm and the terminal. This
248 resource specifies the file containing those values. Each entry
249 in the file consists of a display name and the shared key. By
250 default, xdm does not include support for XDM-AUTHENTICATION-1,
251 as it requires DES which is not generally distributable because
252 of United States export restrictions.
253 DisplayManager.accessFile
255 To prevent unauthorized XDMCP service and to allow forwarding of
256 XDMCP IndirectQuery requests, this file contains a database of
257 hostnames which are either allowed direct access to this
258 machine, or have a list of hosts to which queries should be for‐
259 warded to. The format of this file is described in the section
260 XDMCP Access Control.
261 DisplayManager.exportList
263 A list of additional environment variables, separated by white
264 space, to pass on to the Xsetup, Xstartup, Xsession, and Xreset
265 programs.
266 DisplayManager.randomFile
268 A file to checksum to generate the seed of authorization keys.
269 This should be a file that changes frequently. The default is
270 /dev/mem.
271 DisplayManager.randomDevice
274 A file to read 8 bytes from to generate the seed of authoriza‐
275 tion keys. The default is "/dev/urandom" . If this file cannot
276 be read, or if a read blocks for more than 5 seconds, xdm falls
277 back to using a checksum of DisplayManager.randomFile to gener‐
278 ate the seed.
279 DisplayManager.prngdSocket
283 DisplayManager.prngPort
285 A UNIX domain socket name or a TCP socket port number on local
286 host on which a Pseudo-Random Number Generator Daemon, like EGD
287 (http://egd.sourceforge.net) is listening, in order to generate
288 the autorization keys. Either a non null port or a valid socket
289 name must be specified. The default is to use the Unix-domain
290 socket /tmp/entropy.
291 On systems that don't have such a daemon, a fall-back entropy gathering
293 system, based on various log file contents hashed by the MD5 algorithm
294 is used instead.
295 DisplayManager.greeterLib
298 On systems that support a dynamically-loadable greeter library,
299 the name of the library. The default is
300 /etc/X11/xdm/libXdmGreet.so.
301 DisplayManager.choiceTimeout
303 Number of seconds to wait for display to respond after user has
304 selected a host from the chooser. If the display sends an XDMCP
305 IndirectQuery within this time, the request is forwarded to the
306 chosen host. Otherwise, it is assumed to be from a new session
307 and the chooser is offered again. Default is 15.
308 DisplayManager.sourceAddress
310 Use the numeric IP address of the incoming connection on multi‐
311 homed hosts instead of the host name. This is to avoid trying to
312 connect on the wrong interface which might be down at this time.
313 DisplayManager.willing
315 This specifies a program which is run (as) root when an an XDMCP
316 BroadcastQuery is received and this host is configured to offer
317 XDMCP display management. The output of this program may be dis‐
318 played on a chooser window. If no program is specified, the
319 string Willing to manage is sent.
320 DisplayManager.DISPLAY.resources
322 This resource specifies the name of the file to be loaded by
323 xrdb as the resource database onto the root window of screen 0
324 of the display. The Xsetup program, the Login widget, and
325 chooser will use the resources set in this file. This resource
326 data base is loaded just before the authentication procedure is
327 started, so it can control the appearance of the login window.
328 See the section Authentication Widget, which describes the vari‐
329 ous resources that are appropriate to place in this file. There
330 is no default value for this resource, but
331 /etc/X11/xdm/Xresources is the conventional name.
332 DisplayManager.DISPLAY.chooser
334 Specifies the program run to offer a host menu for Indirect
335 queries redirected to the special host name CHOOSER.
336 /usr/lib64/X11/xdm/chooser is the default. See the sections
337 XDMCP Access Control and Chooser.
338 DisplayManager.DISPLAY.xrdb
340 Specifies the program used to load the resources. By default,
341 xdm uses /usr/bin/xrdb.
342 DisplayManager.DISPLAY.cpp
344 This specifies the name of the C preprocessor which is used by
345 xrdb.
346 DisplayManager.DISPLAY.setup
348 This specifies a program which is run (as root) before offering
349 the Login window. This may be used to change the appearance of
350 the screen around the Login window or to put up other windows
351 (e.g., you may want to run xconsole here). By default, no pro‐
352 gram is run. The conventional name for a file used here is
353 Xsetup. See the section Setup Program.
354 DisplayManager.DISPLAY.startup
356 This specifies a program which is run (as root) after the
357 authentication process succeeds. By default, no program is run.
358 The conventional name for a file used here is Xstartup. See the
359 section Startup Program.
360 DisplayManager.DISPLAY.session
362 This specifies the session to be executed (not running as root).
363 By default, /usr/bin/xterm is run. The conventional name is
364 Xsession. See the section Session Program.
365 DisplayManager.DISPLAY.reset
367 This specifies a program which is run (as root) after the ses‐
368 sion terminates. By default, no program is run. The conven‐
369 tional name is Xreset. See the section Reset Program.
370 DisplayManager.DISPLAY.openDelay
372 DisplayManager.DISPLAY.openRepeat
374 DisplayManager.DISPLAY.openTimeout
376 DisplayManager.DISPLAY.startAttempts
378 These numeric resources control the behavior of xdm when
379 attempting to open intransigent servers. openDelay is the
380 length of the pause (in seconds) between successive attempts,
381 openRepeat is the number of attempts to make, openTimeout is the
382 amount of time to wait while actually attempting the open (i.e.,
383 the maximum time spent in the connect(2) system call) and star‐
384 tAttempts is the number of times this entire process is done
385 before giving up on the server. After openRepeat attempts have
386 been made, or if openTimeout seconds elapse in any particular
387 attempt, xdm terminates and restarts the server, attempting to
388 connect again. This process is repeated startAttempts times, at
389 which point the display is declared dead and disabled. Although
390 this behavior may seem arbitrary, it has been empirically devel‐
391 oped and works quite well on most systems. The default values
392 are 5 for openDelay, 5 for openRepeat, 30 for openTimeout and 4
393 for startAttempts.
394 DisplayManager.DISPLAY.pingInterval
396 DisplayManager.DISPLAY.pingTimeout
398 To discover when remote displays disappear, xdm occasionally
399 pings them, using an X connection and XSync calls. pingInterval
400 specifies the time (in minutes) between each ping attempt, ping‐
401 Timeout specifies the maximum amount of time (in minutes) to
402 wait for the terminal to respond to the request. If the termi‐
403 nal does not respond, the session is declared dead and termi‐
404 nated. By default, both are set to 5 minutes. If you fre‐
405 quently use X terminals which can become isolated from the man‐
406 aging host, you may wish to increase this value. The only worry
407 is that sessions will continue to exist after the terminal has
408 been accidentally disabled. xdm will not ping local displays.
409 Although it would seem harmless, it is unpleasant when the work‐
410 station session is terminated as a result of the server hanging
411 for NFS service and not responding to the ping.
412 DisplayManager.DISPLAY.terminateServer
414 This boolean resource specifies whether the X server should be
415 terminated when a session terminates (instead of resetting it).
416 This option can be used when the server tends to grow without
417 bound over time, in order to limit the amount of time the server
418 is run. The default value is ``false.''
419 DisplayManager.DISPLAY.userPath
421 Xdm sets the PATH environment variable for the session to this
422 value. It should be a colon separated list of directories; see
423 sh(1) for a full description.
424 ``:/bin:/usr/bin:/usr/bin:/usr/ucb'' is a common setting. The
425 default value can be specified at build time in the X system
426 configuration file with DefaultUserPath.
427 DisplayManager.DISPLAY.systemPath
429 Xdm sets the PATH environment variable for the startup and reset
430 scripts to the value of this resource. The default for this
431 resource is specified at build time by the DefaultSystemPath
432 entry in the system configuration file;
433 ``/etc:/bin:/usr/bin:/usr/bin:/usr/ucb'' is a common choice.
434 Note the absence of ``.'' from this entry. This is a good prac‐
435 tice to follow for root; it avoids many common Trojan Horse sys‐
436 tem penetration schemes.
437 DisplayManager.DISPLAY.systemShell
439 Xdm sets the SHELL environment variable for the startup and
440 reset scripts to the value of this resource. It is /bin/sh by
441 default.
442 DisplayManager.DISPLAY.failsafeClient
444 If the default session fails to execute, xdm will fall back to
445 this program. This program is executed with no arguments, but
446 executes using the same environment variables as the session
447 would have had (see the section Session Program). By default,
448 /usr/bin/xterm is used.
449 DisplayManager.DISPLAY.grabServer
451 DisplayManager.DISPLAY.grabTimeout
453 To improve security, xdm grabs the server and keyboard while
454 reading the login name and password. The grabServer resource
455 specifies if the server should be held for the duration of the
456 name/password reading. When ``false,'' the server is ungrabbed
457 after the keyboard grab succeeds, otherwise the server is
458 grabbed until just before the session begins. The default is
459 ``false.'' The grabTimeout resource specifies the maximum time
460 xdm will wait for the grab to succeed. The grab may fail if
461 some other client has the server grabbed, or possibly if the
462 network latencies are very high. This resource has a default
463 value of 3 seconds; you should be cautious when raising it, as a
464 user can be spoofed by a look-alike window on the display. If
465 the grab fails, xdm kills and restarts the server (if possible)
466 and the session.
467 DisplayManager.DISPLAY.authorize
469 DisplayManager.DISPLAY.authName
471 authorize is a boolean resource which controls whether xdm gen‐
472 erates and uses authorization for the local server connections.
473 If authorization is used, authName is a list of authorization
474 mechanisms to use, separated by white space. XDMCP connections
475 dynamically specify which authorization mechanisms are sup‐
476 ported, so authName is ignored in this case. When authorize is
477 set for a display and authorization is not available, the user
478 is informed by having a different message displayed in the login
479 widget. By default, authorize is ``true.'' authName is ``MIT-
480 MAGIC-COOKIE-1,'' or, if XDM-AUTHORIZATION-1 is available,
481 ``XDM-AUTHORIZATION-1 MIT-MAGIC-COOKIE-1.''
482 DisplayManager.DISPLAY.authFile
484 This file is used to communicate the authorization data from xdm
485 to the server, using the -auth server command line option. It
486 should be kept in a directory which is not world-writable as it
487 could easily be removed, disabling the authorization mechanism
488 in the server. If not specified, a name is generated from Dis‐
489 playManager.authDir and the name of the display.
490 DisplayManager.DISPLAY.authComplain
492 If set to ``false,'' disables the use of the unsecureGreeting in
493 the login window. See the section Authentication Widget. The
494 default is ``true.''
495 DisplayManager.DISPLAY.resetSignal
497 The number of the signal xdm sends to reset the server. See the
498 section Controlling the Server. The default is 1 (SIGHUP).
499 DisplayManager.DISPLAY.termSignal
501 The number of the signal xdm sends to terminate the server. See
502 the section Controlling the Server. The default is 15
503 (SIGTERM).
504 DisplayManager.DISPLAY.resetForAuth
506 The original implementation of authorization in the sample
507 server reread the authorization file at server reset time,
508 instead of when checking the initial connection. As xdm gener‐
509 ates the authorization information just before connecting to the
510 display, an old server would not get up-to-date authorization
511 information. This resource causes xdm to send SIGHUP to the
512 server after setting up the file, causing an additional server
513 reset to occur, during which time the new authorization informa‐
514 tion will be read. The default is ``false,'' which will work
515 for all MIT servers.
516 DisplayManager.DISPLAY.userAuthDir
518 When xdm is unable to write to the usual user authorization file
519 ($HOME/.Xauthority), it creates a unique file name in this
520 directory and points the environment variable XAUTHORITY at the
521 created file. It uses /tmp by default.
522
524 First, the xdm configuration file should be set up. Make a directory
525 (usually /etc/X11/xdm) to contain all of the relevant files.
526 Here is a reasonable configuration file, which could be named xdm-con‐
528 fig:
529 DisplayManager.servers: /etc/X11/xdm/Xservers
532 DisplayManager.errorLogFile: /var/log/xdm.log
533 DisplayManager*resources: /etc/X11/xdm/Xresources
534 DisplayManager*startup: /etc/X11/xdm/Xstartup
535 DisplayManager*session: /etc/X11/xdm/Xsession
536 DisplayManager.pidFile: /var/run/xdm-pid
537 DisplayManager._0.authorize: true
538 DisplayManager*authorize: false
539 Note that this file mostly contains references to other files. Note
542 also that some of the resources are specified with ``*'' separating the
543 components. These resources can be made unique for each different dis‐
544 play, by replacing the ``*'' with the display-name, but normally this
545 is not very useful. See the Resources section for a complete discus‐
546 sion.
547
549 The database file specified by the DisplayManager.accessFile provides
550 information which xdm uses to control access from displays requesting
551 XDMCP service. This file contains three types of entries: entries
552 which control the response to Direct and Broadcast queries, entries
553 which control the response to Indirect queries, and macro definitions.
554 The format of the Direct entries is simple, either a host name or a
556 pattern, which is distinguished from a host name by the inclusion of
557 one or more meta characters (`*' matches any sequence of 0 or more
558 characters, and `?' matches any single character) which are compared
559 against the host name of the display device. If the entry is a host
560 name, all comparisons are done using network addresses, so any name
561 which converts to the correct network address may be used. For pat‐
562 terns, only canonical host names are used in the comparison, so ensure
563 that you do not attempt to match aliases. Preceding either a host name
564 or a pattern with a `!' character causes hosts which match that entry
565 to be excluded.
566 To only respond to Direct queries for a host or pattern, it can be fol‐
568 lowed by the optional ``NOBROADCAST'' keyword. This can be used to
569 prevent an xdm server from appearing on menus based on Broadcast
570 queries.
571 An Indirect entry also contains a host name or pattern, but follows it
573 with a list of host names or macros to which indirect queries should be
574 sent.
575 A macro definition contains a macro name and a list of host names and
577 other macros that the macro expands to. To distinguish macros from
578 hostnames, macro names start with a `%' character. Macros may be
579 nested.
580 Indirect entries may also specify to have xdm run chooser to offer a
582 menu of hosts to connect to. See the section Chooser.
583 When checking access for a particular display host, each entry is
585 scanned in turn and the first matching entry determines the response.
586 Direct and Broadcast entries are ignored when scanning for an Indirect
587 entry and vice-versa.
588 Blank lines are ignored, `#' is treated as a comment delimiter causing
590 the rest of that line to be ignored, and `\newline' causes the newline
591 to be ignored, allowing indirect host lists to span multiple lines.
592 Here is an example Xaccess file:
594 #
596 # Xaccess - XDMCP access control file
597 #
598 #
600 # Direct/Broadcast query entries
601 #
602 !xtra.lcs.mit.edu # disallow direct/broadcast service for xtra
604 bambi.ogi.edu # allow access from this particular display
605 *.lcs.mit.edu # allow access from any display in LCS
606 *.deshaw.com NOBROADCAST # allow only direct access
608 *.gw.com # allow direct and broadcast
609 #
611 # Indirect query entries
612 #
613 %HOSTS expo.lcs.mit.edu xenon.lcs.mit.edu excess.lcs.mit.edu kanga.lcs.mit.edu
615 extract.lcs.mit.edu xenon.lcs.mit.edu #force extract to contact xenon
618 !xtra.lcs.mit.edu dummy #disallow indirect access
619 *.lcs.mit.edu %HOSTS #all others get to choose
620 If compiled with IPv6 support, multicast address groups may also be
622 included in the list of addresses indirect queries are set to. Multi‐
623 cast addresses may be followed by an optional / character and hop
624 count. If no hop count is specified, the multicast hop count defaults
625 to 1, keeping the packet on the local network. For IPv4 multicasting,
626 the hop count is used as the TTL.
627 Examples:
629 rincewind.sample.net ff02::1 #IPv6 Multicast to ff02::1
631 #with a hop count of 1
632 ponder.sample.net CHOOSER 239.192.1.1/16 #Offer a menu of hosts
633 #who respond to IPv4 Multicast
634 # to 239.192.1.1 with a TTL of 16
635
637 For X terminals that do not offer a host menu for use with Broadcast or
638 Indirect queries, the chooser program can do this for them. In the
639 Xaccess file, specify ``CHOOSER'' as the first entry in the Indirect
640 host list. Chooser will send a Query request to each of the remaining
641 host names in the list and offer a menu of all the hosts that respond.
642 The list may consist of the word ``BROADCAST,'' in which case chooser
644 will send a Broadcast instead, again offering a menu of all hosts that
645 respond. Note that on some operating systems, UDP packets cannot be
646 broadcast, so this feature will not work.
647 Example Xaccess file using chooser:
649 extract.lcs.mit.edu CHOOSER %HOSTS #offer a menu of these hosts
651 xtra.lcs.mit.edu CHOOSER BROADCAST #offer a menu of all hosts
652 The program to use for chooser is specified by the DisplayManager.DIS‐
654 PLAY.chooser resource. For more flexibility at this step, the chooser
655 could be a shell script. Chooser is the session manager here; it is
656 run instead of a child xdm to manage the display.
657 Resources for this program can be put into the file named by Display‐
659 Manager.DISPLAY.resources.
660 When the user selects a host, chooser prints the host chosen, which is
662 read by the parent xdm, and exits. xdm closes its connection to the X
663 server, and the server resets and sends another Indirect XDMCP request.
664 xdm remembers the user's choice (for DisplayManager.choiceTimeout sec‐
665 onds) and forwards the request to the chosen host, which starts a ses‐
666 sion on that display.
667
669 The following configuration directive is also defined for the Xaccess
670 configuration file:
671 LISTEN interface [list of multicast group addresses]
673 interface may be a hostname or IP addresss representing a net‐
674 work interface on this machine, or the wildcard * to represent
675 all available network interfaces.
676 If one or more LISTEN lines are specified, xdm only listens for XDMCP
678 connections on the specified interfaces. If multicast group addresses
679 are listed on a listen line, xdm joins the multicast groups on the
680 given interface.
681 If no LISTEN lines are given, the original behavior of listening on all
683 interfaces is preserved for backwards compatibility. Additionally, if
684 no LISTEN is specified, xdm joins the default XDMCP IPv6 multicast
685 group, when compiled with IPv6 support.
686 To disable listening for XDMCP connections altogther, a line of LISTEN
688 with no addresses may be specified, or the previously supported method
689 of setting DisplayManager.requestPort to 0 may be used.
690 Examples:
692 LISTEN * ff02::1 # Listen on all interfaces and to the
693 # ff02::1 IPv6 multicast group.
694 LISTEN 10.11.12.13 # Listen only on this interface, as long
695 # as no other listen directives appear in
696 # file.
697
699 The Internet Assigned Numbers Authority has has assigned
700 ff0X:0:0:0:0:0:0:12b as the permanently assigned range of multicast
701 addresses for XDMCP. The X in the prefix may be replaced by any valid
702 scope identifier, such as 1 for Node-Local, 2 for Link-Local, 5 for
703 Site-Local, and so on. (See IETF RFC 2373 or its replacement for fur‐
704 ther details and scope definitions.) xdm defaults to listening on the
705 Link-Local scope address ff02:0:0:0:0:0:0:12b to most closely match the
706 old IPv4 subnet broadcast behavior.
707
709 The resource DisplayManager.servers gives a server specification or, if
710 the values starts with a slash (/), the name of a file containing
711 server specifications, one per line.
712 Each specification indicates a display which should constantly be man‐
714 aged and which is not using XDMCP. This method is used typically for
715 local servers only. If the resource or the file named by the resource
716 is empty, xdm will offer XDMCP service only.
717 Each specification consists of at least three parts: a display name, a
719 display class, a display type, and (for local servers) a command line
720 to start the server. A typical entry for local display number 0 would
721 be:
722 :0 Digital-QV local /usr/bin/X :0
724 The display types are:
726 local local display: xdm must run the server
728 foreign remote display: xdm opens an X connection to a running server
729 The display name must be something that can be passed in the -display
732 option to an X program. This string is used to generate the display-
733 specific resource names, so be careful to match the names (e.g., use
734 ``:0 Sun-CG3 local /usr/bin/X :0'' instead of ``localhost:0 Sun-CG3
735 local /usr/bin/X :0'' if your other resources are specified as ``Dis‐
736 playManager._0.session''). The display class portion is also used in
737 the display-specific resources, as the class of the resource. This is
738 useful if you have a large collection of similar displays (such as a
739 corral of X terminals) and would like to set resources for groups of
740 them. When using XDMCP, the display is required to specify the display
741 class, so the manual for your particular X terminal should document the
742 display class string for your device. If it doesn't, you can run xdm
743 in debug mode and look at the resource strings which it generates for
744 that device, which will include the class string.
745 When xdm starts a session, it sets up authorization data for the
747 server. For local servers, xdm passes ``-auth filename'' on the
748 server's command line to point it at its authorization data. For XDMCP
749 servers, xdm passes the authorization data to the server via the Accept
750 XDMCP request.
751
753 The Xresources file is loaded onto the display as a resource database
754 using xrdb. As the authentication widget reads this database before
755 starting up, it usually contains parameters for that widget:
756 xlogin*login.translations: #overrideCtrl<Key>R: abort-display()\n<Key>F1: set-session-argument(failsafe) finish-field()\n<Key>Return: set-session-argument() finish-field()
758 xlogin*borderWidth: 3
762 xlogin*greeting: CLIENTHOST
763 #ifdef COLOR
764 xlogin*greetColor: CadetBlue
765 xlogin*failColor: red
766 #endif
767 Please note the translations entry; it specifies a few new translations
770 for the widget which allow users to escape from the default session
771 (and avoid troubles that may occur in it). Note that if #override is
772 not specified, the default translations are removed and replaced by the
773 new value, not a very useful result as some of the default translations
774 are quite useful (such as ``<Key>: insert-char ()'' which responds to
775 normal typing).
776 This file may also contain resources for the setup program and chooser.
778
780 The Xsetup file is run after the server is reset, but before the Login
781 window is offered. The file is typically a shell script. It is run as
782 root, so should be careful about security. This is the place to change
783 the root background or bring up other windows that should appear on the
784 screen along with the Login widget.
785 In addition to any specified by DisplayManager.exportList, the follow‐
787 ing environment variables are passed:
788 DISPLAY the associated display name
790 PATH the value of DisplayManager.DISPLAY.systemPath
791 SHELL the value of DisplayManager.DISPLAY.systemShell
792 XAUTHORITY may be set to an authority file
793 Note that since xdm grabs the keyboard, any other windows will not be
795 able to receive keyboard input. They will be able to interact with the
796 mouse, however; beware of potential security holes here. If Display‐
797 Manager.DISPLAY.grabServer is set, Xsetup will not be able to connect
798 to the display at all. Resources for this program can be put into the
799 file named by DisplayManager.DISPLAY.resources.
800 Here is a sample Xsetup script:
802 #!/bin/sh
804 # Xsetup_0 - setup script for one workstation
805 xcmsdb < /etc/X11/xdm/monitors/alex.0
806 xconsole -geometry 480x130-0-0 -notify -verbose -exitOnFail &
807
810 The authentication widget reads a name/password pair from the keyboard.
811 Nearly every imaginable parameter can be controlled with a resource.
812 Resources for this widget should be put into the file named by Display‐
813 Manager.DISPLAY.resources. All of these have reasonable default val‐
814 ues, so it is not necessary to specify any of them.
815 xlogin.Login.width, xlogin.Login.height, xlogin.Login.x, xlogin.Login.y
817 The geometry of the Login widget is normally computed automati‐
818 cally. If you wish to position it elsewhere, specify each of
819 these resources.
820 xlogin.Login.foreground
822 The color used to display the typed-in user name.
823 xlogin.Login.font
825 The font used to display the typed-in user name.
826 xlogin.Login.greeting
828 A string which identifies this window. The default is ``X Win‐
829 dow System.''
830 xlogin.Login.unsecureGreeting
832 When X authorization is requested in the configuration file for
833 this display and none is in use, this greeting replaces the
834 standard greeting. The default is ``This is an unsecure ses‐
835 sion''
836 xlogin.Login.greetFont
838 The font used to display the greeting.
839 xlogin.Login.greetColor
841 The color used to display the greeting.
842 xlogin.Login.namePrompt
844 The string displayed to prompt for a user name. Xrdb strips
845 trailing white space from resource values, so to add spaces at
846 the end of the prompt (usually a nice thing), add spaces escaped
847 with backslashes. The default is ``Login: ''
848 xlogin.Login.passwdPrompt
850 The string displayed to prompt for a password. The default is
851 ``Password: ''
852 xlogin.Login.promptFont
854 The font used to display both prompts.
855 xlogin.Login.promptColor
857 The color used to display both prompts.
858 xlogin.Login.fail
860 A message which is displayed when the authentication fails. The
861 default is ``Login incorrect''
862 xlogin.Login.failFont
864 The font used to display the failure message.
865 xlogin.Login.failColor
867 The color used to display the failure message.
868 xlogin.Login.failTimeout
870 The number of seconds that the failure message is displayed.
871 The default is 30.
872 xlogin.Login.allowRootLogin
874 If set to ``false'', don't allow root (and any other user with
875 uid = 0) to log in directly. The default is ``true''.
876 xlogin.Login.allowNullPasswd
878 If set to ``true'', allow an otherwise failing password match to
879 succeed if the account does not require a password at all. The
880 default is ``false'', so only users that have passwords assigned
881 can log in.
882 xlogin.Login.translations
884 This specifies the translations used for the login widget.
885 Refer to the X Toolkit documentation for a complete discussion
886 on translations. The default translation table is:
887 Ctrl<Key>H: delete-previous-character() \nCtrl<Key>D:delete-character() \nCtrl<Key>B:move-backward-character() \nCtrl<Key>F:move-forward-character() \nCtrl<Key>A:move-to-begining() \nCtrl<Key>E:move-to-end() \nCtrl<Key>K:erase-to-end-of-line() \nCtrl<Key>U:erase-line() \nCtrl<Key>X:erase-line() \nCtrl<Key>C:restart-session() \nCtrl<Key>\\:abort-session() \n<Key>BackSpace:delete-previous-character() \n<Key>Delete:delete-previous-character() \n<Key>Return:finish-field() \n<Key>:insert-char() .fi
889 The actions which are supported by the widget are:
891 delete-previous-character
893 Erases the character before the cursor.
894 delete-character
896 Erases the character after the cursor.
897 move-backward-character
899 Moves the cursor backward.
900 move-forward-character
902 Moves the cursor forward.
903 move-to-begining
905 (Apologies about the spelling error.)
906 Moves the cursor to the beginning of the editable text.
907 move-to-end
909 Moves the cursor to the end of the editable text.
910 erase-to-end-of-line
912 Erases all text after the cursor.
913 erase-line
915 Erases the entire text.
916 finish-field
918 If the cursor is in the name field, proceeds to the password field; if the
919 cursor is in the password field, checks the current name/password pair. If
920 the name/password pair is valid, xdm
921 starts the session. Otherwise the failure message is displayed and
922 the user is prompted again.
923 abort-session
925 Terminates and restarts the server.
926 abort-display
928 Terminates the server, disabling it. This action
929 is not accessible in the default configuration.
930 There are various reasons to stop xdm on a system console, such as
931 when shutting the system down, when using xdmshell,
932 to start another type of server, or to generally access the console.
933 Sending xdm a SIGHUP will restart the display. See the section
934 Controlling XDM.
935 restart-session
937 Resets the X server and starts a new session. This can be used when
938 the resources have been changed and you want to test them or when
939 the screen has been overwritten with system messages.
940 insert-char
942 Inserts the character typed.
943 set-session-argument
945 Specifies a single word argument which is passed to the session at startup.
946 See the section Session Program.
947 allow-all-access
949 Disables access control in the server. This can be used when
950 the .Xauthority file cannot be created by
951 xdm.
952 Be very careful using this;
953 it might be better to disconnect the machine from the network
954 before doing this.
955 On some systems (OpenBSD) the user's shell must be listed in
957 /etc/shells
958 to allow login through xdm. The normal password and account expiration
959 dates are enforced too.
960
962 The Xstartup program is run as root when the user logs in. It is typi‐
963 cally a shell script. Since it is run as root, Xstartup should be very
964 careful about security. This is the place to put commands which add
965 entries to /etc/utmp (the sessreg program may be useful here), mount
966 users' home directories from file servers, or abort the session if
967 logins are not allowed.
968 In addition to any specified by DisplayManager.exportList, the follow‐
970 ing environment variables are passed:
971 DISPLAY the associated display name
973 HOME the initial working directory of the user
974 LOGNAME the user name
975 USER the user name
976 PATH the value of DisplayManager.DISPLAY.systemPath
977 SHELL the value of DisplayManager.DISPLAY.systemShell
978 XAUTHORITY may be set to an authority file
979 No arguments are passed to the script. Xdm waits until this script
982 exits before starting the user session. If the exit value of this
983 script is non-zero, xdm discontinues the session and starts another
984 authentication cycle.
985 The sample Xstartup file shown here prevents login while the file
987 /etc/nologin exists. Thus this is not a complete example, but simply a
988 demonstration of the available functionality.
989 Here is a sample Xstartup script:
991 #!/bin/sh
993 #
994 # Xstartup
995 #
996 # This program is run as root after the user is verified
997 #
998 if [ -f /etc/nologin ]; then
999 xmessage -file /etc/nologin -timeout 30 -center
1000 exit 1
1001 fi
1002 sessreg -a -l $DISPLAY -x /etc/X11/xdm/Xservers $LOGNAME
1003 /etc/X11/xdm/GiveConsole
1004 exit 0
1005
1007 The Xsession program is the command which is run as the user's session.
1008 It is run with the permissions of the authorized user.
1009 In addition to any specified by DisplayManager.exportList, the follow‐
1011 ing environment variables are passed:
1012 DISPLAY the associated display name
1014 HOME the initial working directory of the user
1015 LOGNAME the user name
1016 USER the user name
1017 PATH the value of DisplayManager.DISPLAY.userPath
1018 SHELL the user's default shell (from getpwnam)
1019 XAUTHORITY may be set to a non-standard authority file
1020 KRB5CCNAME may be set to a Kerberos credentials cache name
1021 At most installations, Xsession should look in $HOME for a file .xses‐
1024 sion, which contains commands that each user would like to use as a
1025 session. Xsession should also implement a system default session if no
1026 user-specified session exists. See the section Typical Usage.
1027 An argument may be passed to this program from the authentication wid‐
1029 get using the `set-session-argument' action. This can be used to
1030 select different styles of session. One good use of this feature is to
1031 allow the user to escape from the ordinary session when it fails. This
1032 allows users to repair their own .xsession if it fails, without requir‐
1033 ing administrative intervention. The example following demonstrates
1034 this feature.
1035 This example recognizes the special ``failsafe'' mode, specified in the
1037 translations in the Xresources file, to provide an escape from the
1038 ordinary session. It also requires that the .xsession file be exe‐
1039 cutable so we don't have to guess what shell it wants to use.
1040 #!/bin/sh
1042 #
1043 # Xsession
1044 #
1045 # This is the program that is run as the client
1046 # for the display manager.
1047 case $# in
1049 1)
1050 case $1 in
1051 failsafe)
1052 exec xterm -geometry 80x24-0-0
1053 ;;
1054 esac
1055 esac
1056 startup=$HOME/.xsession
1058 resources=$HOME/.Xresources
1059 if [ -f "$startup" ]; then
1061 exec "$startup"
1062 else
1063 if [ -f "$resources" ]; then
1064 xrdb -load "$resources"
1065 fi
1066 twm &
1067 xman -geometry +10-10 &
1068 exec xterm -geometry 80x24+10+10 -ls
1069 fi
1070 The user's .xsession file might look something like this example.
1073 Don't forget that the file must have execute permission.
1074 #! /bin/csh
1075 # no -f in the previous line so .cshrc gets run to set $PATH
1076 twm &
1077 xrdb -merge "$HOME/.Xresources"
1078 emacs -geometry +0+50 &
1079 xbiff -geometry -430+5 &
1080 xterm -geometry -0+50 -ls
1081
1083 Symmetrical with Xstartup, the Xreset script is run after the user ses‐
1084 sion has terminated. Run as root, it should contain commands that undo
1085 the effects of commands in Xstartup, removing entries from /etc/utmp or
1086 unmounting directories from file servers. The environment variables
1087 that were passed to Xstartup are also passed to Xreset.
1088 A sample Xreset script:
1090 #!/bin/sh
1091 #
1092 # Xreset
1093 #
1094 # This program is run as root after the session ends
1095 #
1096 sessreg -d -l $DISPLAY -x /etc/X11/xdm/Xservers $LOGNAME
1097 /etc/X11/xdm/TakeConsole
1098 exit 0
1099
1101 Xdm controls local servers using POSIX signals. SIGHUP is expected to
1102 reset the server, closing all client connections and performing other
1103 cleanup duties. SIGTERM is expected to terminate the server. If these
1104 signals do not perform the expected actions, the resources DisplayMan‐
1105 ager.DISPLAY.resetSignal and DisplayManager.DISPLAY.termSignal can
1106 specify alternate signals.
1107 To control remote terminals not using XDMCP, xdm searches the window
1109 hierarchy on the display and uses the protocol request KillClient in an
1110 attempt to clean up the terminal for the next session. This may not
1111 actually kill all of the clients, as only those which have created win‐
1112 dows will be noticed. XDMCP provides a more sure mechanism; when xdm
1113 closes its initial connection, the session is over and the terminal is
1114 required to close all other connections.
1115
1117 Xdm responds to two signals: SIGHUP and SIGTERM. When sent a SIGHUP,
1118 xdm rereads the configuration file, the access control file, and the
1119 servers file. For the servers file, it notices if entries have been
1120 added or removed. If a new entry has been added, xdm starts a session
1121 on the associated display. Entries which have been removed are dis‐
1122 abled immediately, meaning that any session in progress will be termi‐
1123 nated without notice and no new session will be started.
1124 When sent a SIGTERM, xdm terminates all sessions in progress and exits.
1126 This can be used when shutting down the system.
1127 Xdm attempts to mark its various sub-processes for ps(1) by editing the
1129 command line argument list in place. Because xdm can't allocate addi‐
1130 tional space for this task, it is useful to start xdm with a reasonably
1131 long command line (using the full path name should be enough). Each
1132 process which is servicing a display is marked -display.
1133
1135 To add an additional local display, add a line for it to the Xservers
1136 file. (See the section Local Server Specification.)
1137 Examine the display-specific resources in xdm-config (e.g., DisplayMan‐
1139 ager._0.authorize) and consider which of them should be copied for the
1140 new display. The default xdm-config has all the appropriate lines for
1141 displays :0 and :1.
1142
1144 You can use xdm to run a single session at a time, using the 4.3 init
1145 options or other suitable daemon by specifying the server on the com‐
1146 mand line:
1147 xdm -server “:0 SUN-3/60CG4 local /usr/bin/X :0”
1149 Or, you might have a file server and a collection of X terminals. The
1152 configuration for this is identical to the sample above, except the
1153 Xservers file would look like
1154 extol:0 VISUAL-19 foreign
1156 exalt:0 NCD-19 foreign
1157 explode:0 NCR-TOWERVIEW3000 foreign
1158 This directs xdm to manage sessions on all three of these terminals.
1161 See the section Controlling Xdm for a description of using signals to
1162 enable and disable these terminals in a manner reminiscent of init(8).
1163
1165 One thing that xdm isn't very good at doing is coexisting with other
1166 window systems. To use multiple window systems on the same hardware,
1167 you'll probably be more interested in xinit.
1168
1170 /etc/X11/xdm/xdm-config
1171 the default configuration file
1172 $HOME/.Xauthority user authorization file where xdm stores keys for
1174 clients to read
1175 /usr/lib64/X11/xdm/chooser
1177 the default chooser
1178 /usr/bin/xrdb the default resource database loader
1180 /usr/bin/X the default server
1182 /usr/bin/xterm the default session program and failsafe client
1184 /etc/X11/xdm/A<display>-<suffix>
1186 the default place for authorization files
1187 /tmp/K5C<display> Kerberos credentials cache
1189
1191 X(7), xinit(1), xauth(1), Xsecurity(7), sessreg(1), Xserver(1),
1192 X Display Manager Control Protocol
1193
1195 Keith Packard, MIT X Consortium
1196X Version 11 xdm 1.1.3 XDM(1)