1XDM(1) General Commands Manual XDM(1)
2
3
4
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
21 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
30 When the session is terminated, xdm resets the X server and (option‐
31 ally) restarts the whole process.
32
33 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
39 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
43 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
57 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
62 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
66 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
71 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
74 The xlogin widget, which xdm presents, offers the familiar login and
75 password prompts.
76
77 After the user logs in, xdm runs the Xstartup script as root.
78
79 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
84 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
87 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
96 -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
101 -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
108 -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
117 -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
123 -resources resource_file
124 Specifies the value for the DisplayManager*resources resource.
125 This file is loaded using xrdb(1) to specify configuration
126 parameters for the authentication widget.
127
128 -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
133 -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. If set to 0, xdm will not listen for XDMCP or Chooser
137 requests. As XDMCP uses the registered well-known UDP port 177,
138 this resource should not be changed to a value other than 0,
139 except for debugging.
140
141 -session session_program
142 Specifies the value for the DisplayManager*session resource.
143 This indicates the program to run as the session after the user
144 has logged in.
145
146 -xrm resource_specification
147 Allows an arbitrary resource to be specified, as in most X Tool‐
148 kit applications.
149
151 At many stages the actions of xdm can be controlled through the use of
152 its configuration file, which is in the X resource format. Some
153 resources modify the behavior of xdm on all displays, while others mod‐
154 ify its behavior on a single display. Where actions relate to a spe‐
155 cific display, the display name is inserted into the resource name
156 between ``DisplayManager'' and the final resource name segment.
157
158 For local displays, the resource name and class are as read from the
159 Xservers file.
160
161 For remote displays, the resource name is what the network address of
162 the display resolves to. See the removeDomain resource. The name must
163 match exactly; xdm is not aware of all the network aliases that might
164 reach a given display. If the name resolve fails, the address is used.
165 The resource class is as sent by the display in the XDMCP Manage
166 request.
167
168 Because the resource manager uses colons to separate the name of the
169 resource from its value and dots to separate resource name parts, xdm
170 substitutes underscores for both dots and colons when generating the
171 resource name. For example, DisplayManager.expo_x_org_0.startup is the
172 name of the resource which defines the startup shell file for the
173 ``expo.x.org:0'' display.
174
175 DisplayManager.servers
176 This resource either specifies a file name full of server
177 entries, one per line (if the value starts with a slash), or a
178 single server entry. See the section Local Server Specification
179 for the details.
180
181 DisplayManager.requestPort
182 This indicates the UDP port number which xdm uses to listen for
183 incoming XDMCP requests. Unless you need to debug the system,
184 leave this with its default value of 177.
185
186 DisplayManager.errorLogFile
187 Error output is normally directed at the system console. To re‐
188 direct it, set this resource to a file name. A method to send
189 these messages to syslog should be developed for systems which
190 support it; however, the wide variety of interfaces precludes
191 any system-independent implementation. This file also contains
192 any output directed to stderr by the Xsetup, Xstartup, Xsession
193 and Xreset files, so it will contain descriptions of problems in
194 those scripts as well.
195
196 DisplayManager.debugLevel
197 If the integer value of this resource is greater than zero,
198 reams of debugging information will be printed. It also dis‐
199 ables daemon mode, which would redirect the information into the
200 bit-bucket, and allows non-root users to run xdm, which would
201 normally not be useful.
202
203 DisplayManager.daemonMode
204 Normally, xdm attempts to make itself into a daemon process
205 unassociated with any terminal. This is accomplished by forking
206 and leaving the parent process to exit, then closing file
207 descriptors and releasing the controlling terminal. In some
208 environments this is not desired (in particular, when debug‐
209 ging). Setting this resource to ``false'' will disable this
210 feature.
211
212 DisplayManager.pidFile
213 The filename specified will be created to contain an ASCII rep‐
214 resentation of the process-id of the main xdm process. Xdm also
215 uses file locking on this file to attempt to eliminate multiple
216 daemons running on the same machine, which would cause quite a
217 bit of havoc.
218
219 DisplayManager.lockPidFile
220 This is the resource which controls whether xdm uses file lock‐
221 ing to keep multiple display managers from running amok. On
222 System V, this uses the lockf library call, while on BSD it uses
223 flock.
224
225 DisplayManager.authDir
226 This names a directory under which xdm stores authorization
227 files while initializing the session. The default value is
228 /var/lib/xdm. Can be overridden for specific displays by Dis‐
229 playManager.DISPLAY.authFile.
230
231 DisplayManager.autoRescan
232 This boolean controls whether xdm rescans the configuration,
233 servers, access control and authentication keys files after a
234 session terminates and the files have changed. By default it is
235 ``true.'' You can force xdm to reread these files by sending a
236 SIGHUP to the main process.
237
238 DisplayManager.removeDomainname
239 When computing the display name for XDMCP clients, the name
240 resolver will typically create a fully qualified host name for
241 the terminal. As this is sometimes confusing, xdm will remove
242 the domain name portion of the host name if it is the same as
243 the domain name of the local host when this variable is set. By
244 default the value is ``true.''
245
246 DisplayManager.keyFile
247 XDM-AUTHENTICATION-1 style XDMCP authentication requires that a
248 private key be shared between xdm and the terminal. This
249 resource specifies the file containing those values. Each entry
250 in the file consists of a display name and the shared key. By
251 default, xdm does not include support for XDM-AUTHENTICATION-1,
252 as it requires DES which is not generally distributable because
253 of United States export restrictions.
254
255 DisplayManager.accessFile
256 To prevent unauthorized XDMCP service and to allow forwarding of
257 XDMCP IndirectQuery requests, this file contains a database of
258 hostnames which are either allowed direct access to this
259 machine, or have a list of hosts to which queries should be for‐
260 warded to. The format of this file is described in the section
261 XDMCP Access Control.
262
263 DisplayManager.exportList
264 A list of additional environment variables, separated by white
265 space, to pass on to the Xsetup, Xstartup, Xsession, and Xreset
266 programs.
267
268 DisplayManager.randomFile
269 A file to checksum to generate the seed of authorization keys.
270 This should be a file that changes frequently. The default is
271 /dev/mem.
272
273 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
280 DisplayManager.prngdSocket
281
282 DisplayManager.prngPort
283 A UNIX domain socket name or a TCP socket port number on local
284 host on which a Pseudo-Random Number Generator Daemon, like EGD
285 (http://egd.sourceforge.net) is listening, in order to generate
286 the autorization keys. Either a non null port or a valid socket
287 name must be specified. The default is to use the Unix-domain
288 socket /tmp/entropy.
289
290 On systems that don't have such a daemon, a fall-back entropy gathering
291 system, based on various log file contents hashed by the MD5 algorithm
292 is used instead.
293
294 DisplayManager.greeterLib
295 On systems that support a dynamically-loadable greeter library,
296 the name of the library. The default is
297 /usr/libexec/libXdmGreet.so.
298
299 DisplayManager.choiceTimeout
300 Number of seconds to wait for display to respond after user has
301 selected a host from the chooser. If the display sends an XDMCP
302 IndirectQuery within this time, the request is forwarded to the
303 chosen host. Otherwise, it is assumed to be from a new session
304 and the chooser is offered again. Default is 15.
305
306 DisplayManager.sourceAddress
307 Use the numeric IP address of the incoming connection on multi‐
308 homed hosts instead of the host name. This is to avoid trying to
309 connect on the wrong interface which might be down at this time.
310
311 DisplayManager.willing
312 This specifies a program which is run (as) root when an an XDMCP
313 BroadcastQuery is received and this host is configured to offer
314 XDMCP display management. The output of this program may be dis‐
315 played on a chooser window. If no program is specified, the
316 string Willing to manage is sent.
317
318 DisplayManager.DISPLAY.resources
319 This resource specifies the name of the file to be loaded by
320 xrdb as the resource database onto the root window of screen 0
321 of the display. The Xsetup program, the Login widget, and
322 chooser will use the resources set in this file. This resource
323 data base is loaded just before the authentication procedure is
324 started, so it can control the appearance of the login window.
325 See the section Authentication Widget, which describes the vari‐
326 ous resources that are appropriate to place in this file. There
327 is no default value for this resource, but
328 /etc/X11/xdm/Xresources is the conventional name.
329
330 DisplayManager.DISPLAY.chooser
331 Specifies the program run to offer a host menu for Indirect
332 queries redirected to the special host name CHOOSER.
333 /usr/libexec/chooser is the default. See the sections XDMCP
334 Access Control and Chooser.
335
336 DisplayManager.DISPLAY.xrdb
337 Specifies the program used to load the resources. By default,
338 xdm uses /usr/bin/xrdb.
339
340 DisplayManager.DISPLAY.cpp
341 This specifies the name of the C preprocessor which is used by
342 xrdb.
343
344 DisplayManager.DISPLAY.setup
345 This specifies a program which is run (as root) before offering
346 the Login window. This may be used to change the appearance of
347 the screen around the Login window or to put up other windows
348 (e.g., you may want to run xconsole here). By default, no pro‐
349 gram is run. The conventional name for a file used here is
350 Xsetup. See the section Setup Program.
351
352 DisplayManager.DISPLAY.startup
353 This specifies a program which is run (as root) after the
354 authentication process succeeds. By default, no program is run.
355 The conventional name for a file used here is Xstartup. See the
356 section Startup Program.
357
358 DisplayManager.DISPLAY.session
359 This specifies the session to be executed (not running as root).
360 By default, /usr/bin/xterm is run. The conventional name is
361 Xsession. See the section Session Program.
362
363 DisplayManager.DISPLAY.reset
364 This specifies a program which is run (as root) after the ses‐
365 sion terminates. By default, no program is run. The conven‐
366 tional name is Xreset. See the section Reset Program.
367
368 DisplayManager.DISPLAY.openDelay
369
370 DisplayManager.DISPLAY.openRepeat
371
372 DisplayManager.DISPLAY.openTimeout
373
374 DisplayManager.DISPLAY.startAttempts
375
376 DisplayManager.DISPLAY.reservAttempts
377 These numeric resources control the behavior of xdm when
378 attempting to open intransigent servers. openDelay is the
379 length of the pause in seconds between successive attempts,
380 openRepeat is the number of attempts to make, openTimeout is the
381 amount of time to wait while actually attempting the open (i.e.,
382 the maximum time spent in the connect(2) system call) and star‐
383 tAttempts is the number of times this entire process is done
384 before giving up on the server. After openRepeat attempts have
385 been made, or if openTimeout seconds elapse in any particular
386 attempt, xdm terminates and restarts the server, attempting to
387 connect again. This process is repeated startAttempts times, at
388 which point the display is declared dead and disabled. Although
389 this behavior may seem arbitrary, it has been empirically devel‐
390 oped and works quite well on most systems. The bound reservAt‐
391 tempts is the number of times a successful connect is allowed to
392 be followed by a fatal error. When reached, the display is dis‐
393 abled. The default values are openDelay: 15, openRepeat: 5,
394 openTimeout: 120, startAttempts: 4 and reservAttempts: 2.
395
396 DisplayManager.DISPLAY.pingInterval
397
398 DisplayManager.DISPLAY.pingTimeout
399 To discover when remote displays disappear, xdm occasionally
400 pings them, using an X connection and XSync calls. pingInterval
401 specifies the time (in minutes) between each ping attempt, ping‐
402 Timeout specifies the maximum amount of time (in minutes) to
403 wait for the terminal to respond to the request. If the termi‐
404 nal does not respond, the session is declared dead and termi‐
405 nated. By default, both are set to 5 minutes. If you fre‐
406 quently use X terminals which can become isolated from the man‐
407 aging host, you may wish to increase this value. The only worry
408 is that sessions will continue to exist after the terminal has
409 been accidentally disabled. xdm will not ping local displays.
410 Although it would seem harmless, it is unpleasant when the work‐
411 station session is terminated as a result of the server hanging
412 for NFS service and not responding to the ping.
413
414 DisplayManager.DISPLAY.terminateServer
415 This boolean resource specifies whether the X server should be
416 terminated when a session terminates (instead of resetting it).
417 This option can be used when the server tends to grow without
418 bound over time, in order to limit the amount of time the server
419 is run. The default value is ``false.''
420
421 DisplayManager.DISPLAY.userPath
422 Xdm sets the PATH environment variable for the session to this
423 value. It should be a colon separated list of directories; see
424 sh(1) for a full description. The default value is
425 ``/bin:/usr/bin:/usr/bin:/usr/ucb''.
426
427 DisplayManager.DISPLAY.systemPath
428 Xdm sets the PATH environment variable for the startup and reset
429 scripts to the value of this resource. The default for this
430 resource is ``/etc:/bin:/usr/bin:/usr/bin:/usr/ucb''. Note the
431 absence of ``.'' from this entry. This is a good practice to
432 follow for root; it avoids many common Trojan Horse system pene‐
433 tration schemes.
434
435 DisplayManager.DISPLAY.systemShell
436 Xdm sets the SHELL environment variable for the startup and
437 reset scripts to the value of this resource. It is /bin/sh by
438 default.
439
440 DisplayManager.DISPLAY.failsafeClient
441 If the default session fails to execute, xdm will fall back to
442 this program. This program is executed with no arguments, but
443 executes using the same environment variables as the session
444 would have had (see the section Session Program). By default,
445 /usr/bin/xterm is used.
446
447 DisplayManager.DISPLAY.grabServer
448
449 DisplayManager.DISPLAY.grabTimeout
450 To improve security, xdm grabs the server and keyboard while
451 reading the login name and password. The grabServer resource
452 specifies if the server should be held for the duration of the
453 name/password reading. When ``false,'' the server is ungrabbed
454 after the keyboard grab succeeds, otherwise the server is
455 grabbed until just before the session begins. The default is
456 ``false.'' The grabTimeout resource specifies the maximum time
457 xdm will wait for the grab to succeed. The grab may fail if
458 some other client has the server grabbed, or possibly if the
459 network latencies are very high. This resource has a default
460 value of 3 seconds; you should be cautious when raising it, as a
461 user can be spoofed by a look-alike window on the display. If
462 the grab fails, xdm kills and restarts the server (if possible)
463 and the session.
464
465 DisplayManager.DISPLAY.authorize
466
467 DisplayManager.DISPLAY.authName
468 authorize is a boolean resource which controls whether xdm gen‐
469 erates and uses authorization for the local server connections.
470 If authorization is used, authName is a list of authorization
471 mechanisms to use, separated by white space. XDMCP connections
472 dynamically specify which authorization mechanisms are sup‐
473 ported, so authName is ignored in this case. When authorize is
474 set for a display and authorization is not available, the user
475 is informed by having a different message displayed in the login
476 widget. By default, authorize is ``true,'' authName is ``MIT-
477 MAGIC-COOKIE-1,'' or, if XDM-AUTHORIZATION-1 is available,
478 ``XDM-AUTHORIZATION-1 MIT-MAGIC-COOKIE-1.''
479
480 DisplayManager.DISPLAY.authFile
481 This file is used to communicate the authorization data from xdm
482 to the server, using the -auth server command line option. It
483 should be kept in a directory which is not world-writable as it
484 could easily be removed, disabling the authorization mechanism
485 in the server. If not specified, a name is generated from Dis‐
486 playManager.authDir and the name of the display.
487
488 DisplayManager.DISPLAY.authComplain
489 If set to ``false,'' disables the use of the unsecureGreeting in
490 the login window. See the section Authentication Widget. The
491 default is ``true.''
492
493 DisplayManager.DISPLAY.resetSignal
494 The number of the signal xdm sends to reset the server. See the
495 section Controlling the Server. The default is 1 (SIGHUP).
496
497 DisplayManager.DISPLAY.termSignal
498 The number of the signal xdm sends to terminate the server. See
499 the section Controlling the Server. The default is 15
500 (SIGTERM).
501
502 DisplayManager.DISPLAY.resetForAuth
503 The original implementation of authorization in the sample
504 server reread the authorization file at server reset time,
505 instead of when checking the initial connection. As xdm gener‐
506 ates the authorization information just before connecting to the
507 display, an old server would not get up-to-date authorization
508 information. This resource causes xdm to send SIGHUP to the
509 server after setting up the file, causing an additional server
510 reset to occur, during which time the new authorization informa‐
511 tion will be read. The default is ``false,'' which will work
512 for all MIT servers.
513
514 DisplayManager.DISPLAY.userAuthDir
515 When xdm is unable to write to the usual user authorization file
516 ($HOME/.Xauthority), it creates a unique file name in this
517 directory and points the environment variable XAUTHORITY at the
518 created file. It uses /tmp by default.
519
521 First, the xdm configuration file should be set up. Make a directory
522 (usually /etc/X11/xdm) to contain all of the relevant files.
523
524 Here is a reasonable configuration file, which could be named xdm-con‐
525 fig:
526
527
528 DisplayManager.servers: /etc/X11/xdm/Xservers
529 DisplayManager.errorLogFile: /var/log/xdm.log
530 DisplayManager*resources: /etc/X11/xdm/Xresources
531 DisplayManager*startup: /etc/X11/xdm/Xstartup
532 DisplayManager*session: /etc/X11/xdm/Xsession
533 DisplayManager.pidFile: /var/run/xdm-pid
534 DisplayManager._0.authorize: true
535 DisplayManager*authorize: false
536
537
538 Note that this file mostly contains references to other files. Note
539 also that some of the resources are specified with ``*'' separating the
540 components. These resources can be made unique for each different dis‐
541 play, by replacing the ``*'' with the display-name, but normally this
542 is not very useful. See the Resources section for a complete discus‐
543 sion.
544
546 The database file specified by the DisplayManager.accessFile provides
547 information which xdm uses to control access from displays requesting
548 XDMCP service. This file contains three types of entries: entries
549 which control the response to Direct and Broadcast queries, entries
550 which control the response to Indirect queries, and macro definitions.
551
552 The format of the Direct entries is simple, either a host name or a
553 pattern, which is distinguished from a host name by the inclusion of
554 one or more meta characters (`*' matches any sequence of 0 or more
555 characters, and `?' matches any single character) which are compared
556 against the host name of the display device. If the entry is a host
557 name, all comparisons are done using network addresses, so any name
558 which converts to the correct network address may be used. For pat‐
559 terns, only canonical host names are used in the comparison, so ensure
560 that you do not attempt to match aliases. Preceding either a host name
561 or a pattern with a `!' character causes hosts which match that entry
562 to be excluded.
563
564 To only respond to Direct queries for a host or pattern, it can be fol‐
565 lowed by the optional ``NOBROADCAST'' keyword. This can be used to
566 prevent an xdm server from appearing on menus based on Broadcast
567 queries.
568
569 An Indirect entry also contains a host name or pattern, but follows it
570 with a list of host names or macros to which indirect queries should be
571 sent.
572
573 A macro definition contains a macro name and a list of host names and
574 other macros that the macro expands to. To distinguish macros from
575 hostnames, macro names start with a `%' character. Macros may be
576 nested.
577
578 Indirect entries may also specify to have xdm run chooser to offer a
579 menu of hosts to connect to. See the section Chooser.
580
581 When checking access for a particular display host, each entry is
582 scanned in turn and the first matching entry determines the response.
583 Direct and Broadcast entries are ignored when scanning for an Indirect
584 entry and vice-versa.
585
586 Blank lines are ignored, `#' is treated as a comment delimiter causing
587 the rest of that line to be ignored, and `\newline' causes the newline
588 to be ignored, allowing indirect host lists to span multiple lines.
589
590 Here is an example Xaccess file:
591
592 #
593 # Xaccess - XDMCP access control file
594 #
595
596 #
597 # Direct/Broadcast query entries
598 #
599
600 !xtra.lcs.mit.edu # disallow direct/broadcast service for xtra
601 bambi.ogi.edu # allow access from this particular display
602 *.lcs.mit.edu # allow access from any display in LCS
603
604 *.deshaw.com NOBROADCAST # allow only direct access
605 *.gw.com # allow direct and broadcast
606
607 #
608 # Indirect query entries
609 #
610
611 %HOSTS expo.lcs.mit.edu xenon.lcs.mit.edu \
612 excess.lcs.mit.edu kanga.lcs.mit.edu
613
614 extract.lcs.mit.edu xenon.lcs.mit.edu #force extract to contact xenon
615 !xtra.lcs.mit.edu dummy #disallow indirect access
616 *.lcs.mit.edu %HOSTS #all others get to choose
617
618 If compiled with IPv6 support, multicast address groups may also be
619 included in the list of addresses indirect queries are set to. Multi‐
620 cast addresses may be followed by an optional / character and hop
621 count. If no hop count is specified, the multicast hop count defaults
622 to 1, keeping the packet on the local network. For IPv4 multicasting,
623 the hop count is used as the TTL.
624
625 Examples:
626
627 rincewind.sample.net ff02::1 #IPv6 Multicast to ff02::1
628 #with a hop count of 1
629 ponder.sample.net CHOOSER 239.192.1.1/16 #Offer a menu of hosts
630 #who respond to IPv4 Multicast
631 # to 239.192.1.1 with a TTL of 16
632
634 For X terminals that do not offer a host menu for use with Broadcast or
635 Indirect queries, the chooser program can do this for them. In the
636 Xaccess file, specify ``CHOOSER'' as the first entry in the Indirect
637 host list. Chooser will send a Query request to each of the remaining
638 host names in the list and offer a menu of all the hosts that respond.
639
640 The list may consist of the word ``BROADCAST,'' in which case chooser
641 will send a Broadcast instead, again offering a menu of all hosts that
642 respond. Note that on some operating systems, UDP packets cannot be
643 broadcast, so this feature will not work.
644
645 Example Xaccess file using chooser:
646
647 extract.lcs.mit.edu CHOOSER %HOSTS #offer a menu of these hosts
648 xtra.lcs.mit.edu CHOOSER BROADCAST #offer a menu of all hosts
649
650 The program to use for chooser is specified by the DisplayManager.DIS‐
651 PLAY.chooser resource. For more flexibility at this step, the chooser
652 could be a shell script. Chooser is the session manager here; it is
653 run instead of a child xdm to manage the display.
654
655 Resources for this program can be put into the file named by Display‐
656 Manager.DISPLAY.resources.
657
658 When the user selects a host, chooser prints the host chosen, which is
659 read by the parent xdm, and exits. xdm closes its connection to the X
660 server, and the server resets and sends another Indirect XDMCP request.
661 xdm remembers the user's choice (for DisplayManager.choiceTimeout sec‐
662 onds) and forwards the request to the chosen host, which starts a ses‐
663 sion on that display.
664
666 The following configuration directive is also defined for the Xaccess
667 configuration file:
668
669 LISTEN interface [list of multicast group addresses]
670 interface may be a hostname or IP address representing a network
671 interface on this machine, or the wildcard * to represent all
672 available network interfaces.
673
674 If one or more LISTEN lines are specified, xdm only listens for XDMCP
675 connections on the specified interfaces. If multicast group addresses
676 are listed on a listen line, xdm joins the multicast groups on the
677 given interface.
678
679 If no LISTEN lines are given, the original behavior of listening on all
680 interfaces is preserved for backwards compatibility. Additionally, if
681 no LISTEN is specified, xdm joins the default XDMCP IPv6 multicast
682 group, when compiled with IPv6 support.
683
684 To disable listening for XDMCP connections altogther, a line of LISTEN
685 with no addresses may be specified, or the previously supported method
686 of setting DisplayManager.requestPort to 0 may be used.
687
688 Examples:
689 LISTEN * ff02::1 # Listen on all interfaces and to the
690 # ff02::1 IPv6 multicast group.
691 LISTEN 10.11.12.13 # Listen only on this interface, as long
692 # as no other listen directives appear in
693 # file.
694
696 The Internet Assigned Numbers Authority has has assigned
697 ff0X:0:0:0:0:0:0:12b as the permanently assigned range of multicast
698 addresses for XDMCP. The X in the prefix may be replaced by any valid
699 scope identifier, such as 1 for Interface-Local, 2 for Link-Local, 5
700 for Site-Local, and so on. (See IETF RFC 4291 or its replacement for
701 further details and scope definitions.) xdm defaults to listening on
702 the Link-Local scope address ff02:0:0:0:0:0:0:12b to most closely match
703 the old IPv4 subnet broadcast behavior.
704
706 The resource DisplayManager.servers gives a server specification or, if
707 the values starts with a slash (/), the name of a file containing
708 server specifications, one per line.
709
710 Each specification indicates a display which should constantly be man‐
711 aged and which is not using XDMCP. This method is used typically for
712 local servers only. If the resource or the file named by the resource
713 is empty, xdm will offer XDMCP service only.
714
715 Each specification consists of at least three parts: a display name, a
716 display class, a display type, and (for local servers) a command line
717 to start the server. A typical entry for local display number 0 would
718 be:
719
720 :0 Digital-QV local /usr/bin/X :0
721
722 The display types are:
723
724 local local display: xdm must run the server
725 foreign remote display: xdm opens an X connection to a running server
726
727
728 The display name must be something that can be passed in the -display
729 option to an X program. This string is used to generate the display-
730 specific resource names, so be careful to match the names (e.g., use
731 ``:0 Sun-CG3 local /usr/bin/X :0'' instead of ``localhost:0 Sun-CG3
732 local /usr/bin/X :0'' if your other resources are specified as ``Dis‐
733 playManager._0.session''). The display class portion is also used in
734 the display-specific resources, as the class of the resource. This is
735 useful if you have a large collection of similar displays (such as a
736 corral of X terminals) and would like to set resources for groups of
737 them. When using XDMCP, the display is required to specify the display
738 class, so the manual for your particular X terminal should document the
739 display class string for your device. If it doesn't, you can run xdm
740 in debug mode and look at the resource strings which it generates for
741 that device, which will include the class string.
742
743 When xdm starts a session, it sets up authorization data for the
744 server. For local servers, xdm passes ``-auth filename'' on the
745 server's command line to point it at its authorization data. For XDMCP
746 servers, xdm passes the authorization data to the server via the Accept
747 XDMCP request.
748
750 The Xresources file is loaded onto the display as a resource database
751 using xrdb. As the authentication widget reads this database before
752 starting up, it usually contains parameters for that widget:
753
754 xlogin*login.translations: #override\
755 Ctrl<Key>R: abort-display()\n\
756 <Key>F1: set-session-argument(failsafe) finish-field()\n\
757 <Key>Return: set-session-argument() finish-field()
758 xlogin*borderWidth: 3
759 xlogin*greeting: CLIENTHOST
760 #ifdef COLOR
761 xlogin*greetColor: CadetBlue
762 xlogin*failColor: red
763 #endif
764
765
766 Please note the translations entry; it specifies a few new translations
767 for the widget which allow users to escape from the default session
768 (and avoid troubles that may occur in it). Note that if #override is
769 not specified, the default translations are removed and replaced by the
770 new value, not a very useful result as some of the default translations
771 are quite useful (such as ``<Key>: insert-char ()'' which responds to
772 normal typing).
773
774 This file may also contain resources for the setup program and chooser.
775
777 The Xsetup file is run after the server is reset, but before the Login
778 window is offered. The file is typically a shell script. It is run as
779 root, so should be careful about security. This is the place to change
780 the root background or bring up other windows that should appear on the
781 screen along with the Login widget.
782
783 In addition to any specified by DisplayManager.exportList, the follow‐
784 ing environment variables are passed:
785
786 DISPLAY the associated display name
787 PATH the value of DisplayManager.DISPLAY.systemPath
788 SHELL the value of DisplayManager.DISPLAY.systemShell
789 XAUTHORITY may be set to an authority file
790
791 Note that since xdm grabs the keyboard, any other windows will not be
792 able to receive keyboard input. They will be able to interact with the
793 mouse, however; beware of potential security holes here. If Display‐
794 Manager.DISPLAY.grabServer is set, Xsetup will not be able to connect
795 to the display at all. Resources for this program can be put into the
796 file named by DisplayManager.DISPLAY.resources.
797
798 Here is a sample Xsetup script:
799
800 #!/bin/sh
801 # Xsetup_0 - setup script for one workstation
802 xcmsdb < /etc/X11/xdm/monitors/alex.0
803 xconsole -geometry 480x130-0-0 -notify -verbose -exitOnFail &
804
805
807 The authentication widget prompts the user for the username, password,
808 and/or other required authentication data from the keyboard. Nearly
809 every imaginable parameter can be controlled with a resource.
810 Resources for this widget should be put into the file named by Display‐
811 Manager.DISPLAY.resources. All of these have reasonable default val‐
812 ues, so it is not necessary to specify any of them.
813
814 The resource file is loaded with xrdb(1) so it may use the substitu‐
815 tions defined by that program such as CLIENTHOST for the client host‐
816 name in the login message, or C pre-processor #ifdef statements to pro‐
817 duce different displays depending on color depth or other variables.
818
819 Xdm can be compiled with support for the Xft(3) library for font ren‐
820 dering. If this support is present, font faces are specified using
821 the resources with names ending in ``face'' in the fontconfig face for‐
822 mat described in the Font Names section of fonts.conf(5). If not, then
823 fonts are specified using the resources with names ending in ``font''
824 in the traditional X Logical Font Description format described in the
825 Font Names section of X(7).
826
827 xlogin.Login.width, xlogin.Login.height, xlogin.Login.x, xlogin.Login.y
828 The geometry of the Login widget is normally computed automati‐
829 cally. If you wish to position it elsewhere, specify each of
830 these resources.
831
832 xlogin.Login.foreground
833 The color used to display the input typed by the user.
834
835 xlogin.Login.face
836 The face used to display the input typed by the user when built
837 with Xft support. The default is ``Serif-18''.
838
839 xlogin.Login.font
840 The font used to display the input typed by the user when not
841 built with Xft support.
842
843 xlogin.Login.greeting
844 A string which identifies this window. The default is ``X Win‐
845 dow System.''
846
847 xlogin.Login.unsecureGreeting
848 When X authorization is requested in the configuration file for
849 this display and none is in use, this greeting replaces the
850 standard greeting. The default is ``This is an unsecure ses‐
851 sion''
852
853 xlogin.Login.greetFace
854 The face used to display the greeting when built with Xft sup‐
855 port. The default is ``Serif-24:italic''.
856
857 xlogin.Login.greetFont
858 The font used to display the greeting when not built with Xft
859 support.
860
861 xlogin.Login.greetColor
862 The color used to display the greeting.
863
864 xlogin.Login.namePrompt
865 The string displayed to prompt for a user name. Xrdb strips
866 trailing white space from resource values, so to add spaces at
867 the end of the prompt (usually a nice thing), add spaces escaped
868 with backslashes. The default is ``Login: ''
869
870 xlogin.Login.passwdPrompt
871 The string displayed to prompt for a password, when not using an
872 authentication system such as PAM that provides its own prompts.
873 The default is ``Password: ''
874
875 xlogin.Login.promptFace
876 The face used to display prompts when built with Xft support.
877 The default is ``Serif-18:bold''.
878
879 xlogin.Login.promptFont
880 The font used to display prompts when not built with Xft sup‐
881 port.
882
883 xlogin.Login.promptColor
884 The color used to display prompts.
885
886 xlogin.Login.changePasswdMessage
887 A message which is displayed when the users password has
888 expired. The default is ``Password Change Required''
889
890 xlogin.Login.fail
891 A message which is displayed when the authentication fails, when
892 not using an authentication system such as PAM that provides its
893 own prompts. The default is ``Login incorrect''
894
895 xlogin.Login.failFace
896 The face used to display the failure message when built with Xft
897 support. The default is ``Serif-18:bold''.
898
899 xlogin.Login.failFont
900 The font used to display the failure message when not built with
901 Xft support.
902
903 xlogin.Login.failColor
904 The color used to display the failure message.
905
906 xlogin.Login.failTimeout
907 The number of seconds that the failure message is displayed.
908 The default is 10.
909
910 xlogin.Login.logoFileName
911 Name of an XPM format pixmap to display in the greeter window,
912 if built with XPM support. The default is no pixmap.
913
914 xlogin.Login.logoPadding
915 Number of pixels of space between the logo pixmap and other ele‐
916 ments of the greeter window, if the pixmap is displayed. The
917 default is 5.
918
919 xlogin.Login.useShape
920 If set to ``true'', when built with XPM support, attempt to use
921 the X Non-Rectangular Window Shape Extension to set the window
922 shape. The default is ``true''.
923
924 xlogin.Login.hiColor, xlogin.Login.shdColor
925 Raised appearance bezels may be drawn around the greeter frame
926 and text input boxes by setting these resources. hiColor is the
927 highlight color, used on the top and left sides of the frame,
928 and the bottom and right sides of text input areas. shdColor
929 is the shadow color, used on the bottom and right sides of the
930 frame, and the top and left sides of text input areas. The
931 default for both is the foreground color, providing a flat
932 appearance.
933
934 xlogin.Login.frameWidth
935 frameWidth is the width in pixels of the area around the greeter
936 frame drawn in hiColor and shdColor.
937
938 xlogin.Login.innerFramesWidth
939 innerFramesWidth is the width in pixels of the area around text
940 input areas drawn in hiColor and shdColor.
941
942 xlogin.Login.sepWidth
943 sepWidth is the width in pixels of the bezeled line between the
944 greeting and input areas drawn in hiColor and shdColor.
945
946 xlogin.Login.allowRootLogin
947 If set to ``false'', don't allow root (and any other user with
948 uid = 0) to log in directly. The default is ``true''. This
949 setting is only checked by some of the authentication backends
950 at this time.
951
952 xlogin.Login.allowNullPasswd
953 If set to ``true'', allow an otherwise failing password match to
954 succeed if the account does not require a password at all. The
955 default is ``false'', so only users that have passwords assigned
956 can log in.
957
958 xlogin.Login.echoPasswd
959 If set to ``true'', a placeholder character (echoPasswdChar)
960 will be shown for fields normally set to not echo, such as pass‐
961 word input. The default is ``false''.
962
963 xlogin.Login.echoPasswdChar
964 Character to display if echoPasswd is true. The default is
965 ``*''. If set to an empty value, the cursor will advance for
966 each character input, but no text will be drawn.
967
968 xlogin.Login.translations
969 This specifies the translations used for the login widget.
970 Refer to the X Toolkit documentation for a complete discussion
971 on translations. The default translation table is:
972
973 Ctrl<Key>H: delete-previous-character() \n\
974 Ctrl<Key>D: delete-character() \n\
975 Ctrl<Key>B: move-backward-character() \n\
976 Ctrl<Key>F: move-forward-character() \n\
977 Ctrl<Key>A: move-to-begining() \n\
978 Ctrl<Key>E: move-to-end() \n\
979 Ctrl<Key>K: erase-to-end-of-line() \n\
980 Ctrl<Key>U: erase-line() \n\
981 Ctrl<Key>X: erase-line() \n\
982 Ctrl<Key>C: restart-session() \n\
983 Ctrl<Key>\\: abort-session() \n\
984 <Key>BackSpace:delete-previous-character() \n\
985 <Key>Delete: delete-previous-character() \n\
986 <Key>Return: finish-field() \n\
987 <Key>: insert-char() \
988
989
990 The actions which are supported by the widget are:
991
992 delete-previous-character
993 Erases the character before the cursor.
994
995 delete-character
996 Erases the character after the cursor.
997
998 move-backward-character
999 Moves the cursor backward.
1000
1001 move-forward-character
1002 Moves the cursor forward.
1003
1004 move-to-begining
1005 (Apologies about the spelling error.) Moves the cursor to the
1006 beginning of the editable text.
1007
1008 move-to-end
1009 Moves the cursor to the end of the editable text.
1010
1011 erase-to-end-of-line
1012 Erases all text after the cursor.
1013
1014 erase-line
1015 Erases the entire text.
1016
1017 finish-field
1018 If the cursor is in the name field, proceeds to the password
1019 field; if the cursor is in the password field, checks the cur‐
1020 rent name/password pair. If the name/password pair is valid,
1021 xdm starts the session. Otherwise the failure message is dis‐
1022 played and the user is prompted again.
1023
1024 abort-session
1025 Terminates and restarts the server.
1026
1027 abort-display
1028 Terminates the server, disabling it. This action is not acces‐
1029 sible in the default configuration. There are various reasons
1030 to stop xdm on a system console, such as when shutting the sys‐
1031 tem down, when using xdmshell, to start another type of server,
1032 or to generally access the console. Sending xdm a SIGHUP will
1033 restart the display. See the section Controlling XDM.
1034
1035 restart-session
1036 Resets the X server and starts a new session. This can be used
1037 when the resources have been changed and you want to test them
1038 or when the screen has been overwritten with system messages.
1039
1040 insert-char
1041 Inserts the character typed.
1042
1043 set-session-argument
1044 Specifies a single word argument which is passed to the session
1045 at startup. See the section Session Program.
1046
1047 allow-all-access
1048 Disables access control in the server. This can be used when
1049 the .Xauthority file cannot be created by xdm. Be very careful
1050 using this; it might be better to disconnect the machine from
1051 the network before doing this.
1052
1053 On some systems (OpenBSD) the user's shell must be listed in
1054 /etc/shells to allow login through xdm. The normal password and account
1055 expiration dates are enforced too.
1056
1058 The Xstartup program is run as root when the user logs in. It is typi‐
1059 cally a shell script. Since it is run as root, Xstartup should be very
1060 careful about security. This is the place to put commands which add
1061 entries to utmp or wtmp files, (the sessreg program may be useful
1062 here), mount users' home directories from file servers, or abort the
1063 session if logins are not allowed.
1064
1065 In addition to any specified by DisplayManager.exportList, the follow‐
1066 ing environment variables are passed:
1067
1068 DISPLAY the associated display name
1069 HOME the initial working directory of the user
1070 LOGNAME the user name
1071 USER the user name
1072 PATH the value of DisplayManager.DISPLAY.systemPath
1073 SHELL the value of DisplayManager.DISPLAY.systemShell
1074 XAUTHORITY may be set to an authority file
1075 WINDOWPATH may be set to the "window path" leading to the X server
1076
1077
1078 No arguments are passed to the script. Xdm waits until this script
1079 exits before starting the user session. If the exit value of this
1080 script is non-zero, xdm discontinues the session and starts another
1081 authentication cycle.
1082
1083 The sample Xstartup file shown here prevents login while the file
1084 /etc/nologin exists. Thus this is not a complete example, but simply a
1085 demonstration of the available functionality.
1086
1087 Here is a sample Xstartup script:
1088
1089 #!/bin/sh
1090 #
1091 # Xstartup
1092 #
1093 # This program is run as root after the user is verified
1094 #
1095 if [ -f /etc/nologin ]; then
1096 xmessage -file /etc/nologin -timeout 30 -center
1097 exit 1
1098 fi
1099 sessreg -a -l $DISPLAY -x /etc/X11/xdm/Xservers $LOGNAME
1100 /etc/X11/xdm/GiveConsole
1101 exit 0
1102
1104 The Xsession program is the command which is run as the user's session.
1105 It is run with the permissions of the authorized user.
1106
1107 In addition to any specified by DisplayManager.exportList, the follow‐
1108 ing environment variables are passed:
1109
1110 DISPLAY the associated display name
1111 HOME the initial working directory of the user
1112 LOGNAME the user name
1113 USER the user name
1114 PATH the value of DisplayManager.DISPLAY.userPath
1115 SHELL the user's default shell (from getpwnam)
1116 XAUTHORITY may be set to a non-standard authority file
1117 KRB5CCNAME may be set to a Kerberos credentials cache name
1118 WINDOWPATH may be set to the "window path" leading to the X server
1119
1120
1121 At most installations, Xsession should look in $HOME for a file .xses‐
1122 sion, which contains commands that each user would like to use as a
1123 session. Xsession should also implement a system default session if no
1124 user-specified session exists.
1125
1126 An argument may be passed to this program from the authentication wid‐
1127 get using the `set-session-argument' action. This can be used to
1128 select different styles of session. One good use of this feature is to
1129 allow the user to escape from the ordinary session when it fails. This
1130 allows users to repair their own .xsession if it fails, without requir‐
1131 ing administrative intervention. The example following demonstrates
1132 this feature.
1133
1134 This example recognizes the special ``failsafe'' mode, specified in the
1135 translations in the Xresources file, to provide an escape from the
1136 ordinary session. It also requires that the .xsession file be exe‐
1137 cutable so we don't have to guess what shell it wants to use.
1138
1139 #!/bin/sh
1140 #
1141 # Xsession
1142 #
1143 # This is the program that is run as the client
1144 # for the display manager.
1145
1146 case $# in
1147 1)
1148 case $1 in
1149 failsafe)
1150 exec xterm -geometry 80x24-0-0
1151 ;;
1152 esac
1153 esac
1154
1155 startup=$HOME/.xsession
1156 resources=$HOME/.Xresources
1157
1158 if [ -f "$startup" ]; then
1159 exec "$startup"
1160 else
1161 if [ -f "$resources" ]; then
1162 xrdb -load "$resources"
1163 fi
1164 twm &
1165 xman -geometry +10-10 &
1166 exec xterm -geometry 80x24+10+10 -ls
1167 fi
1168
1169
1170 The user's .xsession file might look something like this example.
1171 Don't forget that the file must have execute permission.
1172 #! /bin/csh
1173 # no -f in the previous line so .cshrc gets run to set $PATH
1174 twm &
1175 xrdb -merge "$HOME/.Xresources"
1176 emacs -geometry +0+50 &
1177 xbiff -geometry -430+5 &
1178 xterm -geometry -0+50 -ls
1179
1181 Symmetrical with Xstartup, the Xreset script is run after the user ses‐
1182 sion has terminated. Run as root, it should contain commands that undo
1183 the effects of commands in Xstartup, updating entries in utmp or wtmp
1184 files, or unmounting directories from file servers. The environment
1185 variables that were passed to Xstartup are also passed to Xreset.
1186
1187 A sample Xreset script:
1188 #!/bin/sh
1189 #
1190 # Xreset
1191 #
1192 # This program is run as root after the session ends
1193 #
1194 sessreg -d -l $DISPLAY -x /etc/X11/xdm/Xservers $LOGNAME
1195 /etc/X11/xdm/TakeConsole
1196 exit 0
1197
1199 Xdm controls local servers using POSIX signals. SIGHUP is expected to
1200 reset the server, closing all client connections and performing other
1201 cleanup duties. SIGTERM is expected to terminate the server. If these
1202 signals do not perform the expected actions, the resources DisplayMan‐
1203 ager.DISPLAY.resetSignal and DisplayManager.DISPLAY.termSignal can
1204 specify alternate signals.
1205
1206 To control remote terminals not using XDMCP, xdm searches the window
1207 hierarchy on the display and uses the protocol request KillClient in an
1208 attempt to clean up the terminal for the next session. This may not
1209 actually kill all of the clients, as only those which have created win‐
1210 dows will be noticed. XDMCP provides a more sure mechanism; when xdm
1211 closes its initial connection, the session is over and the terminal is
1212 required to close all other connections.
1213
1215 Xdm responds to two signals: SIGHUP and SIGTERM. When sent a SIGHUP,
1216 xdm rereads the configuration file, the access control file, and the
1217 servers file. For the servers file, it notices if entries have been
1218 added or removed. If a new entry has been added, xdm starts a session
1219 on the associated display. Entries which have been removed are dis‐
1220 abled immediately, meaning that any session in progress will be termi‐
1221 nated without notice and no new session will be started.
1222
1223 When sent a SIGTERM, xdm terminates all sessions in progress and exits.
1224 This can be used when shutting down the system.
1225
1226 Xdm attempts to mark its various sub-processes for ps(1) by editing the
1227 command line argument list in place. Because xdm can't allocate addi‐
1228 tional space for this task, it is useful to start xdm with a reasonably
1229 long command line (using the full path name should be enough). Each
1230 process which is servicing a display is marked -display.
1231
1233 To add an additional local display, add a line for it to the Xservers
1234 file. (See the section Local Server Specification.)
1235
1236 Examine the display-specific resources in xdm-config (e.g., DisplayMan‐
1237 ager._0.authorize) and consider which of them should be copied for the
1238 new display. The default xdm-config has all the appropriate lines for
1239 displays :0 and :1.
1240
1242 You can use xdm to run a single session at a time, using the 4.3 init
1243 options or other suitable daemon by specifying the server on the com‐
1244 mand line:
1245
1246 xdm -server “:0 SUN-3/60CG4 local /usr/bin/X :0”
1247
1248
1249 Or, you might have a file server and a collection of X terminals. The
1250 configuration for this is identical to the sample above, except the
1251 Xservers file would look like
1252
1253 extol:0 VISUAL-19 foreign
1254 exalt:0 NCD-19 foreign
1255 explode:0 NCR-TOWERVIEW3000 foreign
1256
1257
1258 This directs xdm to manage sessions on all three of these terminals.
1259 See the section Controlling Xdm for a description of using signals to
1260 enable and disable these terminals in a manner reminiscent of init(8).
1261
1263 One thing that xdm isn't very good at doing is coexisting with other
1264 window systems. To use multiple window systems on the same hardware,
1265 you'll probably be more interested in xinit.
1266
1268 /etc/X11/xdm/xdm-config
1269 the default configuration file
1270
1271 $HOME/.Xauthority user authorization file where xdm stores keys for
1272 clients to read
1273
1274 /usr/libexec/chooser
1275 the default chooser
1276
1277 /usr/bin/xrdb the default resource database loader
1278
1279 /usr/bin/X the default server
1280
1281 /usr/bin/xterm the default session program and failsafe client
1282
1283 /var/lib/xdm/A<display>-<suffix>
1284 the default place for authorization files
1285
1286 /tmp/K5C<display> Kerberos credentials cache
1287
1289 X(7), xinit(1), xauth(1), xrdb(1), Xsecurity(7), sessreg(1),
1290 Xserver(1), xdmshell(1), fonts.conf(5).
1291 X Display Manager Control Protocol
1292 IETF RFC 4291: IP Version 6 Addressing Architecture.
1293
1295 Keith Packard, MIT X Consortium
1296
1297
1298
1299X Version 11 xdm 1.1.11 XDM(1)