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(1) to specify configuration
126 parameters 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 prompts the user for the username, password,
811 and/or other required authentication data from the keyboard. Nearly
812 every imaginable parameter can be controlled with a resource.
813 Resources for this widget should be put into the file named by Display‐
814 Manager.DISPLAY.resources. All of these have reasonable default val‐
815 ues, so it is not necessary to specify any of them.
816 The resource file is loaded with xrdb(1) so it may use the substitu‐
818 tions defined by that program such as CLIENTHOST for the client host‐
819 name in the login message, or C pre-processor #ifdef statements to pro‐
820 duce different displays depending on color depth or other variables.
821 Xdm can be compiled with support for the Xft(3) library for font ren‐
823 dering. If this support is present, font faces are specified using
824 the resources with names ending in "face" in the fontconfig face format
825 described in the Font Names section of fonts.conf(5). If not, then
826 fonts are specified using the resources with names ending in "font" in
827 the traditional X Logical Font Description format described in the Font
828 Names section of X(7).
829 xlogin.Login.width, xlogin.Login.height, xlogin.Login.x, xlogin.Login.y
831 The geometry of the Login widget is normally computed automati‐
832 cally. If you wish to position it elsewhere, specify each of
833 these resources.
834 xlogin.Login.foreground
836 The color used to display the input typed by the user.
837 xlogin.Login.face
839 The face used to display the input typed by the user when built
840 with Xft support. The default is ``Serif-18''.
841 xlogin.Login.font
843 The font used to display the input typed by the user when not
844 built with Xft support.
845 xlogin.Login.greeting
847 A string which identifies this window. The default is ``X Win‐
848 dow System.''
849 xlogin.Login.unsecureGreeting
851 When X authorization is requested in the configuration file for
852 this display and none is in use, this greeting replaces the
853 standard greeting. The default is ``This is an unsecure ses‐
854 sion''
855 xlogin.Login.greetFace
857 The face used to display the greeting when built with Xft sup‐
858 port. The default is ``Serif-24:italic''.
859 xlogin.Login.greetFont
861 The font used to display the greeting when not built with Xft
862 support.
863 xlogin.Login.greetColor
865 The color used to display the greeting.
866 xlogin.Login.namePrompt
868 The string displayed to prompt for a user name. Xrdb strips
869 trailing white space from resource values, so to add spaces at
870 the end of the prompt (usually a nice thing), add spaces escaped
871 with backslashes. The default is ``Login: ''
872 xlogin.Login.passwdPrompt
874 The string displayed to prompt for a password, when not using an
875 authentication system such as PAM that provides its own prompts.
876 The default is ``Password: ''
877 xlogin.Login.promptFace
879 The face used to display prompts when built with Xft support.
880 The default is ``Serif-18:bold''.
881 xlogin.Login.promptFont
883 The font used to display prompts when not built with Xft sup‐
884 port.
885 xlogin.Login.promptColor
887 The color used to display prompts.
888 xlogin.Login.changePasswdMessage
890 A message which is displayed when the users password has
891 expired. The default is ``Password Change Required''
892 xlogin.Login.fail
894 A message which is displayed when the authentication fails, when
895 not using an authentication system such as PAM that provides its
896 own prompts. The default is ``Login incorrect''
897 xlogin.Login.failFace
899 The face used to display the failure message when built with Xft
900 support. The default is ``Serif-18:bold''.
901 xlogin.Login.failFont
903 The font used to display the failure message when not built with
904 Xft support.
905 xlogin.Login.failColor
907 The color used to display the failure message.
908 xlogin.Login.failTimeout
910 The number of seconds that the failure message is displayed.
911 The default is 10.
912 xlogin.Login.logoFileName
914 Name of an XPM format pixmap to display in the greeter window,
915 if built with XPM support. The default is no pixmap.
916 xlogin.Login.logoPadding
918 Number of pixels of space between the logo pixmap and other ele‐
919 ments of the greeter window, if the pixmap is displayed. The
920 default is 5.
921 xlogin.Login.useShape
923 If set to ``true'', when built with XPM support, attempt to use
924 the X Non-Rectangular Window Shape Extension to set the window
925 shape. The default is ``true''.
926 xlogin.Login.hiColor, xlogin.Login.shdColor
928 Raised appearance bezels may be drawn around the greeter frame
929 and text input boxes by setting these resources. hiColor is the
930 highlight color, used on the top and left sides of the frame,
931 and the bottom and right sides of text input areas. shdColor
932 is the shadow color, used on the bottom and right sides of the
933 frame, and the top and left sides of text input areas. The
934 default for both is the foreground color, providing a flat
935 appearance.
936 xlogin.Login.frameWidth
938 frameWidth is the width in pixels of the area around the greeter
939 frame drawn in hiColor and shdColor.
940 xlogin.Login.innerFramesWidth
942 innerFramesWidth is the width in pixels of the area around text
943 input areas drawn in hiColor and shdColor.
944 xlogin.Login.sepWidth
946 sepWidth is the width in pixels of the bezeled line between the
947 greeting and input areas drawn in hiColor and shdColor.
948 xlogin.Login.allowRootLogin
950 If set to ``false'', don't allow root (and any other user with
951 uid = 0) to log in directly. The default is ``true''.
952 xlogin.Login.allowNullPasswd
954 If set to ``true'', allow an otherwise failing password match to
955 succeed if the account does not require a password at all. The
956 default is ``false'', so only users that have passwords assigned
957 can log in.
958 xlogin.Login.translations
960 This specifies the translations used for the login widget.
961 Refer to the X Toolkit documentation for a complete discussion
962 on translations. The default translation table is:
963 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
965 The actions which are supported by the widget are:
967 delete-previous-character
969 Erases the character before the cursor.
970 delete-character
972 Erases the character after the cursor.
973 move-backward-character
975 Moves the cursor backward.
976 move-forward-character
978 Moves the cursor forward.
979 move-to-begining
981 (Apologies about the spelling error.)
982 Moves the cursor to the beginning of the editable text.
983 move-to-end
985 Moves the cursor to the end of the editable text.
986 erase-to-end-of-line
988 Erases all text after the cursor.
989 erase-line
991 Erases the entire text.
992 finish-field
994 If the cursor is in the name field, proceeds to the password field; if the
995 cursor is in the password field, checks the current name/password pair. If
996 the name/password pair is valid, xdm
997 starts the session. Otherwise the failure message is displayed and
998 the user is prompted again.
999 abort-session
1001 Terminates and restarts the server.
1002 abort-display
1004 Terminates the server, disabling it. This action
1005 is not accessible in the default configuration.
1006 There are various reasons to stop xdm on a system console, such as
1007 when shutting the system down, when using xdmshell,
1008 to start another type of server, or to generally access the console.
1009 Sending xdm a SIGHUP will restart the display. See the section
1010 Controlling XDM.
1011 restart-session
1013 Resets the X server and starts a new session. This can be used when
1014 the resources have been changed and you want to test them or when
1015 the screen has been overwritten with system messages.
1016 insert-char
1018 Inserts the character typed.
1019 set-session-argument
1021 Specifies a single word argument which is passed to the session at startup.
1022 See the section Session Program.
1023 allow-all-access
1025 Disables access control in the server. This can be used when
1026 the .Xauthority file cannot be created by
1027 xdm.
1028 Be very careful using this;
1029 it might be better to disconnect the machine from the network
1030 before doing this.
1031 On some systems (OpenBSD) the user's shell must be listed in
1033 /etc/shells
1034 to allow login through xdm. The normal password and account expiration
1035 dates are enforced too.
1036
1038 The Xstartup program is run as root when the user logs in. It is typi‐
1039 cally a shell script. Since it is run as root, Xstartup should be very
1040 careful about security. This is the place to put commands which add
1041 entries to /etc/utmp (the sessreg program may be useful here), mount
1042 users' home directories from file servers, or abort the session if
1043 logins are not allowed.
1044 In addition to any specified by DisplayManager.exportList, the follow‐
1046 ing environment variables are passed:
1047 DISPLAY the associated display name
1049 HOME the initial working directory of the user
1050 LOGNAME the user name
1051 USER the user name
1052 PATH the value of DisplayManager.DISPLAY.systemPath
1053 SHELL the value of DisplayManager.DISPLAY.systemShell
1054 XAUTHORITY may be set to an authority file
1055 WINDOWPATH may be set to the "window path" leading to the X server
1056 No arguments are passed to the script. Xdm waits until this script
1059 exits before starting the user session. If the exit value of this
1060 script is non-zero, xdm discontinues the session and starts another
1061 authentication cycle.
1062 The sample Xstartup file shown here prevents login while the file
1064 /etc/nologin exists. Thus this is not a complete example, but simply a
1065 demonstration of the available functionality.
1066 Here is a sample Xstartup script:
1068 #!/bin/sh
1070 #
1071 # Xstartup
1072 #
1073 # This program is run as root after the user is verified
1074 #
1075 if [ -f /etc/nologin ]; then
1076 xmessage -file /etc/nologin -timeout 30 -center
1077 exit 1
1078 fi
1079 sessreg -a -l $DISPLAY -x /etc/X11/xdm/Xservers $LOGNAME
1080 /etc/X11/xdm/GiveConsole
1081 exit 0
1082
1084 The Xsession program is the command which is run as the user's session.
1085 It is run with the permissions of the authorized user.
1086 In addition to any specified by DisplayManager.exportList, the follow‐
1088 ing environment variables are passed:
1089 DISPLAY the associated display name
1091 HOME the initial working directory of the user
1092 LOGNAME the user name
1093 USER the user name
1094 PATH the value of DisplayManager.DISPLAY.userPath
1095 SHELL the user's default shell (from getpwnam)
1096 XAUTHORITY may be set to a non-standard authority file
1097 KRB5CCNAME may be set to a Kerberos credentials cache name
1098 WINDOWPATH may be set to the "window path" leading to the X server
1099 At most installations, Xsession should look in $HOME for a file .xses‐
1102 sion, which contains commands that each user would like to use as a
1103 session. Xsession should also implement a system default session if no
1104 user-specified session exists.
1105 An argument may be passed to this program from the authentication wid‐
1107 get using the `set-session-argument' action. This can be used to
1108 select different styles of session. One good use of this feature is to
1109 allow the user to escape from the ordinary session when it fails. This
1110 allows users to repair their own .xsession if it fails, without requir‐
1111 ing administrative intervention. The example following demonstrates
1112 this feature.
1113 This example recognizes the special ``failsafe'' mode, specified in the
1115 translations in the Xresources file, to provide an escape from the
1116 ordinary session. It also requires that the .xsession file be exe‐
1117 cutable so we don't have to guess what shell it wants to use.
1118 #!/bin/sh
1120 #
1121 # Xsession
1122 #
1123 # This is the program that is run as the client
1124 # for the display manager.
1125 case $# in
1127 1)
1128 case $1 in
1129 failsafe)
1130 exec xterm -geometry 80x24-0-0
1131 ;;
1132 esac
1133 esac
1134 startup=$HOME/.xsession
1136 resources=$HOME/.Xresources
1137 if [ -f "$startup" ]; then
1139 exec "$startup"
1140 else
1141 if [ -f "$resources" ]; then
1142 xrdb -load "$resources"
1143 fi
1144 twm &
1145 xman -geometry +10-10 &
1146 exec xterm -geometry 80x24+10+10 -ls
1147 fi
1148 The user's .xsession file might look something like this example.
1151 Don't forget that the file must have execute permission.
1152 #! /bin/csh
1153 # no -f in the previous line so .cshrc gets run to set $PATH
1154 twm &
1155 xrdb -merge "$HOME/.Xresources"
1156 emacs -geometry +0+50 &
1157 xbiff -geometry -430+5 &
1158 xterm -geometry -0+50 -ls
1159
1161 Symmetrical with Xstartup, the Xreset script is run after the user ses‐
1162 sion has terminated. Run as root, it should contain commands that undo
1163 the effects of commands in Xstartup, removing entries from /etc/utmp or
1164 unmounting directories from file servers. The environment variables
1165 that were passed to Xstartup are also passed to Xreset.
1166 A sample Xreset script:
1168 #!/bin/sh
1169 #
1170 # Xreset
1171 #
1172 # This program is run as root after the session ends
1173 #
1174 sessreg -d -l $DISPLAY -x /etc/X11/xdm/Xservers $LOGNAME
1175 /etc/X11/xdm/TakeConsole
1176 exit 0
1177
1179 Xdm controls local servers using POSIX signals. SIGHUP is expected to
1180 reset the server, closing all client connections and performing other
1181 cleanup duties. SIGTERM is expected to terminate the server. If these
1182 signals do not perform the expected actions, the resources DisplayMan‐
1183 ager.DISPLAY.resetSignal and DisplayManager.DISPLAY.termSignal can
1184 specify alternate signals.
1185 To control remote terminals not using XDMCP, xdm searches the window
1187 hierarchy on the display and uses the protocol request KillClient in an
1188 attempt to clean up the terminal for the next session. This may not
1189 actually kill all of the clients, as only those which have created win‐
1190 dows will be noticed. XDMCP provides a more sure mechanism; when xdm
1191 closes its initial connection, the session is over and the terminal is
1192 required to close all other connections.
1193
1195 Xdm responds to two signals: SIGHUP and SIGTERM. When sent a SIGHUP,
1196 xdm rereads the configuration file, the access control file, and the
1197 servers file. For the servers file, it notices if entries have been
1198 added or removed. If a new entry has been added, xdm starts a session
1199 on the associated display. Entries which have been removed are dis‐
1200 abled immediately, meaning that any session in progress will be termi‐
1201 nated without notice and no new session will be started.
1202 When sent a SIGTERM, xdm terminates all sessions in progress and exits.
1204 This can be used when shutting down the system.
1205 Xdm attempts to mark its various sub-processes for ps(1) by editing the
1207 command line argument list in place. Because xdm can't allocate addi‐
1208 tional space for this task, it is useful to start xdm with a reasonably
1209 long command line (using the full path name should be enough). Each
1210 process which is servicing a display is marked -display.
1211
1213 To add an additional local display, add a line for it to the Xservers
1214 file. (See the section Local Server Specification.)
1215 Examine the display-specific resources in xdm-config (e.g., DisplayMan‐
1217 ager._0.authorize) and consider which of them should be copied for the
1218 new display. The default xdm-config has all the appropriate lines for
1219 displays :0 and :1.
1220
1222 You can use xdm to run a single session at a time, using the 4.3 init
1223 options or other suitable daemon by specifying the server on the com‐
1224 mand line:
1225 xdm -server “:0 SUN-3/60CG4 local /usr/bin/X :0”
1227 Or, you might have a file server and a collection of X terminals. The
1230 configuration for this is identical to the sample above, except the
1231 Xservers file would look like
1232 extol:0 VISUAL-19 foreign
1234 exalt:0 NCD-19 foreign
1235 explode:0 NCR-TOWERVIEW3000 foreign
1236 This directs xdm to manage sessions on all three of these terminals.
1239 See the section Controlling Xdm for a description of using signals to
1240 enable and disable these terminals in a manner reminiscent of init(8).
1241
1243 One thing that xdm isn't very good at doing is coexisting with other
1244 window systems. To use multiple window systems on the same hardware,
1245 you'll probably be more interested in xinit.
1246
1248 /etc/X11/xdm/xdm-config
1249 the default configuration file
1250 $HOME/.Xauthority user authorization file where xdm stores keys for
1252 clients to read
1253 /usr/lib64/X11/xdm/chooser
1255 the default chooser
1256 /usr/bin/xrdb the default resource database loader
1258 /usr/bin/X the default server
1260 /usr/bin/xterm the default session program and failsafe client
1262 /etc/X11/xdm/A<display>-<suffix>
1264 the default place for authorization files
1265 /tmp/K5C<display> Kerberos credentials cache
1267
1269 X(7), xinit(1), xauth(1), xrdb(1), Xsecurity(7), sessreg(1),
1270 Xserver(1), fonts.conf(5).
1271 X Display Manager Control Protocol
1272
1274 Keith Packard, MIT X Consortium
1275X Version 11 xdm 1.1.6 XDM(1)