|XENODM(1)||General Commands Manual||XENODM(1)|
xenodmmanages a collection of X displays on the local host.
xenodmprovides services similar to those provided by getty(8) and login(1) on character terminals: prompting for login name and password, authenticating the user, and running a “session”. A “session” is defined by the lifetime of a particular process; in the traditional character-based terminal world, it is the user's login shell. In the
xenodmcontext, it is an arbitrary session manager. This is because in a windowing environment, a user's login shell process does not necessarily have any terminal-like interface with which to connect. When a real session manager is not available, a window manager or terminal emulator is typically used as the “session manager”, meaning that termination of this process terminates the user's session. When the session is terminated,
xenodmresets the X server and (optionally) restarts the whole process. Because
xenodmprovides the first interface that users will see, it is designed to be simple to use and easy to customize to the needs of a particular site.
xenodmhas many options, most of which have reasonable defaults. Browse through the various sections of this manual, picking and choosing the things you want to change. Pay particular attention to the SESSION PROGRAM section, which will describe how to set up the style of session desired.
xenodmis highly configurable, and most of its behavior can be controlled by resource files and shell scripts. The names of these files themselves are resources read from the file xenodm-config or the file named by the
xenodmcan manage X servers running on the local machine and specified in Xservers. The resources of the X clients run by
xenodmoutside the user's session, including
xenodm's own login window, can be affected by setting resources in the Xresources file. After resetting the X server,
xenodmruns the Xsetup script to assist in setting up the screen the user sees along with the xlogin widget. The xlogin widget, which
xenodmpresents, offers the familiar login and password prompts, unless
autoLoginis set. After the user logs in,
xenodmruns the Xstartup script as root. Then
xenodmruns the Xsession script as the user. This system session file may do some additional startup and typically runs the .xsession script in the user's home directory. When the Xsession script exits, the session is over. At the end of the session, the Xreset script is run to clean up, the X server is reset, and the cycle starts over. The file /var/log/xenodm.log will contain error messages from
xenodmand anything output to
stderrby Xsetup, Xstartup, Xsession or Xreset. When you have trouble getting
xenodmworking, check this file to see if
xenodmhas any clues to the trouble.
-configitself, specify values that can also be specified in the configuration file as resources.
xenodm. /etc/X11/xenodm/xenodm-config is the default. See the section CONFIGURATION FILE.
falseas the value for the
DisplayManager.daemonModeresource. This suppresses the normal daemon behavior, which is for
xenodmto close all file descriptors, disassociate itself from the controlling terminal, and put itself in the background when it first starts up.
DisplayManager.debugLevelresource. A non-zero value causes
xenodmto print lots of debugging statements to the terminal; it also disables the
xenodmto run synchronously. To interpret these debugging messages, a copy of the source code for
xenodmis almost a necessity. No attempt has been made to rationalize or standardize the output.
DisplayManager.errorLogFileresource. This file contains errors from
xenodmas well as anything written to
stderrby the various scripts and programs run during the progress of the session.
DisplayManager*resourcesresource. This file is loaded using xrdb(1) to specify configuration parameters for the authentication widget.
DisplayManager.serversresource. See the section LOCAL SERVER SPECIFICATION for a description of this resource.
DisplayManager*sessionresource. This indicates the program to run as the session after the user has logged in.
xenodmcan be controlled through the use of its configuration file, which is in the X resource format. Some resources modify the behavior of
xenodmon all displays, while others modify its behavior on a single display. Where actions relate to a specific display, the display name is inserted into the resource name between “DisplayManager” and the final resource name segment. For local displays, the resource name and class are as read from the Xservers file. Because the resource manager uses colons to separate the name of the resource from its value and dots to separate resource name parts,
xenodmsubstitutes underscores for both dots and colons when generating the resource name. For example,
DisplayManager.expo_x_org_0.startupis the name of the resource which defines the startup shell file for the “expo.x.org:0” display.
stderrby the Xsetup, Xstartup, Xsession and Xreset files, so it will contain descriptions of problems in those scripts as well.
xenodm, which would normally not be useful.
xenodmattempts to make itself into a daemon process unassociated with any terminal. This is accomplished by forking and leaving the parent process to exit, then closing file descriptors and releasing the controlling terminal. In some environments this is not desired (in particular, when debugging). Setting this resource to
falsewill disable this feature.
xenodmstores authorization files while initializing the session. The default value is /etc/X11/xenodm. Can be overridden for specific displays by
xenodmrescans the configuration, servers, access control and authentication keys files after a session terminates and the files have changed. By default it is
true. You can force
xenodmto reread these files by sending a
SIGHUPto the main process.
xenodmwhen attempting to open intransigent servers.
openDelayis the length of the pause in seconds between successive attempts,
openRepeatis the number of attempts to make,
openTimeoutis the amount of time to wait while actually attempting the open (i.e., the maximum time spent in the connect(2) system call) and
startAttemptsis the number of times this entire process is done before giving up on the server. After
openRepeatattempts have been made, or if
openTimeoutseconds elapse in any particular attempt,
xenodmterminates and restarts the server, attempting to connect again. This process is repeated
startAttemptstimes, at which point the display is declared dead and disabled. Although this behavior may seem arbitrary, it has been empirically developed and works quite well on most systems. The bound
reservAttemptsis the number of times a successful connect is allowed to be followed by a fatal error. When reached, the display is disabled. The default values are
startAttempts: 4 and
PATHenvironment variable for the session to this value. It should be a colon separated list of directories; see sh(1) for a full description. The default value is “/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin”.
PATHenvironment variable for the startup and reset scripts to the value of this resource. The default for this resource is “/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin”. Note the absence of ‘
.’ from this entry. This is a good practice to follow for root; it avoids many common Trojan Horse system penetration schemes.
SHELLenvironment variable for the startup and reset scripts to the value of this resource. It is /bin/sh by default.
xenodmwill fall back to this program. This program is executed with no arguments, but executes using the same environment variables as the session would have had (see the section SESSION PROGRAM). By default, /usr/X11R6/bin/xterm is used.
xenodmgrabs the server and keyboard while reading the login name and password. The
grabServerresource specifies if the server should be held for the duration of the name/password reading. When
false, the server is ungrabbed after the keyboard grab succeeds, otherwise the server is grabbed until just before the session begins. The default is
grabTimeoutresource specifies the maximum time
xenodmwill wait for the grab to succeed. The grab may fail if some other client has the server grabbed, or possibly if the network latencies are very high. This resource has a default value of 3 seconds; you should be cautious when raising it, as a user can be spoofed by a look-alike window on the display. If the grab fails,
xenodmkills and restarts the server (if possible) and the session.
authorizeis a boolean resource which controls whether
xenodmgenerates and uses authorization for the local server connections. If authorization is used,
authNameis a list of authorization mechanisms to use, separated by white space. When
authorizeis set for a display and authorization is not available, the user is informed by having a different message displayed in the login widget. By default,
authNameis “MIT-MAGIC-COOKIE-1”, or, if XDM-AUTHORIZATION-1 is available, “XDM-AUTHORIZATION-1 MIT-MAGIC-COOKIE-1”.
xenodmto the server, using the
-authserver command line option. It should be kept in a directory which is not world-writable as it could easily be removed, disabling the authorization mechanism in the server. If not specified, a name is generated from DisplayManager.authDir and the name of the display.
false, disables the use of the
unsecureGreetingin the login window. See the section AUTHENTICATION WIDGET. The default is
xenodmsends to reset the server. See the section CONTROLLING THE SERVER. The default is 1 (
xenodmsends to terminate the server. See the section CONTROLLING THE SERVER. The default is 15 (
xenodmgenerates the authorization information just before connecting to the display, an old server would not get up-to-date authorization information. This resource causes
SIGHUPto the server after setting up the file, causing an additional server reset to occur, during which time the new authorization information will be read. The default is
false, which will work for all MIT servers.
xenodmis unable to write to the usual user authorization file ($HOME/.Xauthority), it creates a unique file name in this directory and points the environment variable
XAUTHORITYat the created file. It uses /tmp by default.
xenodmconfiguration file should be set up. Make a directory (usually /etc/X11/xenodm) to contain all of the relevant files. Here is a reasonable configuration file, which could be named xenodm-config:
DisplayManager.servers: /etc/X11/xenodm/Xservers DisplayManager.errorLogFile: /var/log/xenodm.log DisplayManager*resources: /etc/X11/xenodm/Xresources DisplayManager*startup: /etc/X11/xenodm/Xstartup DisplayManager*session: /etc/X11/xenodm/Xsession DisplayManager._0.authorize: true DisplayManager*authorize: false
*’ separating the components. These resources can be made unique for each different display, by replacing the ‘
*’ with the display-name, but normally this is not very useful. See the RESOURCES section for a complete discussion.
DisplayManager.serversgives a server specification or, if the value starts with a slash (‘
/’), the name of a file containing server specifications, one per line. Each specification indicates a display which should constantly be managed. If the resource or the file named by the resource is empty,
xenodmwill exit. Each specification consists of at least three parts: a display name, a display class, a display type, and a command line to start the server. A typical entry for local display number 0 would be:
-displayoption to an X program. This string is used to generate the display-specific resource names, so be careful to match the names (e.g., use “:0 local /usr/X11R6/bin/X :0” instead of “localhost:0 local /usr/X11R6/bin/X :0” if your other resources are specified as “DisplayManager._0.session”). The display class portion is also used in the display-specific resources, as the class of the resource. This is useful if you have a large collection of similar displays (such as a corral of X terminals) and would like to set resources for groups of them. When
xenodmstarts a session, it sets up authorization data for the server. For local servers,
-authfilename” on the server's command line to point it at its authorization data. Xresources file is loaded onto the display as a resource database using xrdb(1). As the authentication widget reads this database before starting up, it usually contains parameters for that widget:
xlogin*login.translations: #override\ Ctrl<Key>R: abort-display()\n\ <Key>F1: set-session-argument(failsafe) finish-field()\n\ <Key>Return: set-session-argument() finish-field() xlogin*borderWidth: 3 xlogin*greeting: CLIENTHOST #ifdef COLOR xlogin*greetColor: CadetBlue xlogin*failColor: red #endif
DisplayManager.exportList, the following environment variables are passed:
xenodmgrabs the keyboard, any other windows will not be able to receive keyboard input. They will be able to interact with the mouse, however; beware of potential security holes here. If
.grabServeris set, Xsetup will not be able to connect to the display at all. Resources for this program can be put into the file named by
.resources. Here is a sample Xsetup script:
#!/bin/sh # Xsetup_0 - setup script for one workstation xcmsdb < /etc/X11/xenodm/monitors/alex.0 xconsole -geometry 480x130-0-0 -notify -verbose -exitOnFail &
.resources. All of these have reasonable default values, so it is not necessary to specify any of them. The resource file is loaded with xrdb(1) so it may use the substitutions defined by that program such as CLIENTHOST for the client hostname in the login message, or C pre-processor #ifdef statements to produce different displays depending on color depth or other variables.
xenodmis compiled with support for the Xft(3) library for font rendering. Font faces are specified using the resources with names ending in “face” in the fontconfig face format described in the “Font Names” section of fonts.conf(5).
true, when built with XPM support, attempt to use the X Non-Rectangular Window Shape Extension to set the window shape. The default is
hiColoris the highlight color, used on the top and left sides of the frame, and the bottom and right sides of text input areas.
shdColoris the shadow color, used on the bottom and right sides of the frame, and the top and left sides of text input areas. The default for both is the foreground color, providing a flat appearance.
frameWidthis the width in pixels of the area around the greeter frame drawn in
innerFramesWidthis the width in pixels of the area around text input areas drawn in
sepWidthis the width in pixels of the bezeled line between the greeting and input areas drawn in
false, don't allow root (and any other user with uid = 0) to log in directly. The default is
true. This setting is only checked by some of the authentication backends at this time.
true, allow an otherwise failing password match to succeed if the account does not require a password at all. The default is
false, so only users that have passwords assigned can log in.
true, a placeholder character (
echoPasswdChar) will be shown for fields normally set to not echo, such as password input. The default is
echoPasswdis true. The default is ‘
*’. If set to an empty value, the cursor will advance for each character input, but no text will be drawn.
Ctrl<Key>H: delete-previous-character() \n\ Ctrl<Key>D: delete-character() \n\ Ctrl<Key>B: move-backward-character() \n\ Ctrl<Key>F: move-forward-character() \n\ Ctrl<Key>A: move-to-begining() \n\ Ctrl<Key>E: move-to-end() \n\ Ctrl<Key>K: erase-to-end-of-line() \n\ Ctrl<Key>U: erase-line() \n\ Ctrl<Key>X: erase-line() \n\ Ctrl<Key>C: restart-session() \n\ Ctrl<Key>\\: abort-session() \n\ <Key>BackSpace: delete-previous-character() \n\ <Key>Delete: delete-previous-character() \n\ <Key>Return: finish-field() \n\ <Key>: insert-char() \
xenodmstarts the session. Otherwise the failure message is displayed and the user is prompted again.
xenodmon a system console, such as when shutting the system down, when using xdmshell(1), to start another type of server, or to generally access the console. Sending
SIGHUPwill restart the display. See the section CONTROLLING XENODM.
xenodm. Be very careful using this; it might be better to disconnect the machine from the network before doing this.
DisplayManager.exportList, the following environment variables are passed:
xenodmwaits until this script exits before starting the user session. If the exit value of this script is non-zero,
xenodmdiscontinues the session and starts another authentication cycle. The sample Xstartup file shown here prevents login while the file /etc/nologin exists. Thus this is not a complete example, but simply a demonstration of the available functionality. Here is a sample Xstartup script:
#!/bin/sh # # Xstartup # # This program is run as root after the user is verified # if [ -f /etc/nologin ]; then xmessage -file /etc/nologin -timeout 30 -center exit 1 fi sessreg -a -l $DISPLAY -x /etc/X11/xenodm/Xservers $LOGNAME /etc/X11/xenodm/GiveConsole exit 0
DisplayManager.exportList, the following environment variables are passed:
set-session-argumentaction. This can be used to select different styles of session. One good use of this feature is to allow the user to escape from the ordinary session when it fails. This allows users to repair their own .xsession if it fails, without requiring administrative intervention. The example following demonstrates this feature. This example recognizes the special failsafe mode, specified in the translations in the Xresources file, to provide an escape from the ordinary session. It also requires that the .xsession file be executable so we don't have to guess what shell it wants to use.
#!/bin/sh # # Xsession # # This is the program that is run as the client # for the display manager. case $# in 1) case $1 in failsafe) exec xterm -geometry 80x24-0-0 ;; esac esac startup=$HOME/.xsession resources=$HOME/.Xresources if [ -f "$startup" ]; then exec "$startup" else if [ -f "$resources" ]; then xrdb -load "$resources" fi twm & xman -geometry +10-10 & exec xterm -geometry 80x24+10+10 -ls fi
#! /bin/csh # no -f in the previous line so .cshrc gets run to set $PATH twm & xrdb -merge "$HOME/.Xresources" emacs -geometry +0+50 & xbiff -geometry -430+5 & xterm -geometry -0+50 -ls
#!/bin/sh # # Xreset # # This program is run as root after the session ends # sessreg -d -l $DISPLAY -x /etc/X11/xenodm/Xservers $LOGNAME /etc/X11/xenodm/TakeConsole exit 0
xenodmcontrols local servers using POSIX signals.
SIGHUPis expected to reset the server, closing all client connections and performing other cleanup duties.
SIGTERMis expected to terminate the server. If these signals do not perform the expected actions, the resources
.termSignalcan specify alternate signals.
xenodmresponds to two signals:
SIGTERM. When sent a
xenodmrereads the configuration file, the access control file, and the servers file. For the servers file, it notices if entries have been added or removed. If a new entry has been added,
xenodmstarts a session on the associated display. Entries which have been removed are disabled immediately, meaning that any session in progress will be terminated without notice and no new session will be started. When sent a
xenodmterminates all sessions in progress and exits. This can be used when shutting down the system.
xenodmattempts to mark its various sub-processes for ps(1) by editing the command line argument list in place. Because
xenodmcan't allocate additional space for this task, it is useful to start
xenodmwith a reasonably long command line (using the full path name should be enough). Each process which is servicing a display is marked
-display. Xservers file. (See the section LOCAL SERVER SPECIFICATION.) Examine the display-specific resources in xenodm-config (e.g.,
DisplayManager._0.authorize) and consider which of them should be copied for the new display. The default xenodm-config has all the appropriate lines for displays :0 and :1.
xenodmto run a single session at a time, using the 4.3 init(8) options or other suitable daemon by specifying the server on the command line:
xenodmisn't very good at doing is coexisting with other window systems. To use multiple window systems on the same hardware, you'll probably be more interested in xinit(1).
xenodmstores keys for clients to read
|August 22, 2017||xenodm 0.1 X Version 11|