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. 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 -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 -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 For local displays, the resource name and class are as read from the
159 Xservers file.
160 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
281 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 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 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 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 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 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 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 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 DisplayManager.DISPLAY.xrdb
337 Specifies the program used to load the resources. By default,
338 xdm uses /usr/bin/xrdb.
339 DisplayManager.DISPLAY.cpp
341 This specifies the name of the C preprocessor which is used by
342 xrdb.
343 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 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 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 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 DisplayManager.DISPLAY.openDelay
369 DisplayManager.DISPLAY.openRepeat
371 DisplayManager.DISPLAY.openTimeout
373 DisplayManager.DISPLAY.startAttempts
375 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 DisplayManager.DISPLAY.pingInterval
397 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 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 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 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 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 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 DisplayManager.DISPLAY.grabServer
448 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 DisplayManager.DISPLAY.authorize
466 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 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 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 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 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 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 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 Here is a reasonable configuration file, which could be named xdm-con‐
525 fig:
526 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 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 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 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 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 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 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 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 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 Here is an example Xaccess file:
591 #
593 # Xaccess - XDMCP access control file
594 #
595 #
597 # Direct/Broadcast query entries
598 #
599 !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 *.deshaw.com NOBROADCAST # allow only direct access
605 *.gw.com # allow direct and broadcast
606 #
608 # Indirect query entries
609 #
610 %HOSTS expo.lcs.mit.edu xenon.lcs.mit.edu \
612 excess.lcs.mit.edu kanga.lcs.mit.edu
613 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 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 Examples:
626 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 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 Example Xaccess file using chooser:
646 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 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 Resources for this program can be put into the file named by Display‐
656 Manager.DISPLAY.resources.
657 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 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 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 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 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 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 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 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 :0 Digital-QV local /usr/bin/X :0
721 The display types are:
723 local local display: xdm must run the server
725 foreign remote display: xdm opens an X connection to a running server
726 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 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 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 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 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 In addition to any specified by DisplayManager.exportList, the follow‐
784 ing environment variables are passed:
785 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 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 Here is a sample Xsetup script:
799 #!/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
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 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 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 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 xlogin.Login.foreground
833 The color used to display the input typed by the user.
834 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 xlogin.Login.font
840 The font used to display the input typed by the user when not
841 built with Xft support.
842 xlogin.Login.greeting
844 A string which identifies this window. The default is ``X Win‐
845 dow System.''
846 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 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 xlogin.Login.greetFont
858 The font used to display the greeting when not built with Xft
859 support.
860 xlogin.Login.greetColor
862 The color used to display the greeting.
863 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 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 xlogin.Login.promptFace
876 The face used to display prompts when built with Xft support.
877 The default is ``Serif-18:bold''.
878 xlogin.Login.promptFont
880 The font used to display prompts when not built with Xft sup‐
881 port.
882 xlogin.Login.promptColor
884 The color used to display prompts.
885 xlogin.Login.changePasswdMessage
887 A message which is displayed when the users password has
888 expired. The default is ``Password Change Required''
889 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 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 xlogin.Login.failFont
900 The font used to display the failure message when not built with
901 Xft support.
902 xlogin.Login.failColor
904 The color used to display the failure message.
905 xlogin.Login.failTimeout
907 The number of seconds that the failure message is displayed.
908 The default is 10.
909 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 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 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 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 xlogin.Login.frameWidth
935 frameWidth is the width in pixels of the area around the greeter
936 frame drawn in hiColor and shdColor.
937 xlogin.Login.innerFramesWidth
939 innerFramesWidth is the width in pixels of the area around text
940 input areas drawn in hiColor and shdColor.
941 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 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 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 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 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 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 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 The actions which are supported by the widget are:
991 delete-previous-character
993 Erases the character before the cursor.
994 delete-character
996 Erases the character after the cursor.
997 move-backward-character
999 Moves the cursor backward.
1000 move-forward-character
1002 Moves the cursor forward.
1003 move-to-begining
1005 (Apologies about the spelling error.) Moves the cursor to the
1006 beginning of the editable text.
1007 move-to-end
1009 Moves the cursor to the end of the editable text.
1010 erase-to-end-of-line
1012 Erases all text after the cursor.
1013 erase-line
1015 Erases the entire text.
1016 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 abort-session
1025 Terminates and restarts the server.
1026 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 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 insert-char
1041 Inserts the character typed.
1042 set-session-argument
1044 Specifies a single word argument which is passed to the session
1045 at startup. See the section Session Program.
1046 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 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 In addition to any specified by DisplayManager.exportList, the follow‐
1066 ing environment variables are passed:
1067 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 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 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 Here is a sample Xstartup script:
1088 #!/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 In addition to any specified by DisplayManager.exportList, the follow‐
1108 ing environment variables are passed:
1109 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 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 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 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 #!/bin/sh
1140 #
1141 # Xsession
1142 #
1143 # This is the program that is run as the client
1144 # for the display manager.
1145 case $# in
1147 1)
1148 case $1 in
1149 failsafe)
1150 exec xterm -geometry 80x24-0-0
1151 ;;
1152 esac
1153 esac
1154 startup=$HOME/.xsession
1156 resources=$HOME/.Xresources
1157 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 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 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 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 When sent a SIGTERM, xdm terminates all sessions in progress and exits.
1224 This can be used when shutting down the system.
1225 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 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 xdm -server “:0 SUN-3/60CG4 local /usr/bin/X :0”
1247 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 extol:0 VISUAL-19 foreign
1254 exalt:0 NCD-19 foreign
1255 explode:0 NCR-TOWERVIEW3000 foreign
1256 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 $HOME/.Xauthority user authorization file where xdm stores keys for
1272 clients to read
1273 /usr/libexec/chooser
1275 the default chooser
1276 /usr/bin/xrdb the default resource database loader
1278 /usr/bin/X the default server
1280 /usr/bin/xterm the default session program and failsafe client
1282 /var/lib/xdm/A<display>-<suffix>
1284 the default place for authorization files
1285 /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
1296X Version 11 xdm 1.1.11 XDM(1)