−session session_program Specifies the value for the session
resource. This indicates the program to run when the user has logged in as the
session.
−xrm resource_specification This allows an arbitrary resource to be
specified, just as most toolkit applications only for xdm.
xdmdtlogin was designed to operate in a wide variety of environments, and to determine its typical usage is probably a misnomer. Nevertheless, this section focuses on configuring
xdmdtlogin for a quite typical environment.
First, the xdmdtlogin configuration file should be set up. For xdm, the master configuration file, named xdm−config contains references to all other files. A good idea is to locate all these files in the
same directory; usually, this is usrlibX11xdm which would contain all of the relevant files. For dtlogin, the master configuration file, named Xconfig, also contains references to all other files. Its
default location is in the directory usrdtconfig; however, it could take several other locations.
xdm was introduced with X11R3 and had a serious problem related to X terminals that are turned off and on again during an active X session. The problem was solved with X11R4, introducing the
XDM Control Protocol XDMCP. XDMCP changed the concept of a static X11 configuration into the dynamic one, where X servers and xdm are negotiating the connection, and exchanging status
messages during the session. dtlogin knows only the concept of dynamic configuration.
xdmdtlogin could be executed from the command line at any time; however, it was mostly running as the daemon at the client host. The start of xdmdtlogin became a regular part of the rc
initialization script files, and it is activated as a daemon during the system startup.
While the concept, and the descriptions of two programs, xdm and dtlogin, match, their configuration is slightly different. The differences are in the names of the configuration files, their
locations, as well as their contents. How to configure two programs is discussed and presented separately.
22.2.2 xdm Configuration Files
xdm is configured through a set of editable ASCII files; the files reside usually in the usrlibX11xdm directory and the users home directory. A simplified graphic presentation of the
xdm configuration is given in the Figure 22.5. Keep in mind that the listed names are usual, but they could be renamed in the master configuration file xdm−config.
524
Figure 22.5: The xdm configuration files. Let us check the existing xdm files on Solaris 2.6. platform although, on this platform the CDE is
the primary X support:
ls usropenwinlibX11xdm
GiveConsole TakeConsole Xaccess Xresources Xservers Xsession Xsetup_0 chooser xdm−config libXdmGreet.so
libXdmGreet.so.1.0
Most of the files link to the corresponding files in usropenwinlibxdm:
ls usropenwinlibxdm
GiveConsole Reset StartOW Startup TakeConsole Xaccess Xresources Xservers Xsession Xsetup_0
chooser xdm−config
The configuration files of the interest are:
xdm−config The master configuration file; it specifies all configuration files for xdm. Xservers
A list of X servers to be explicitly managed by xdm. The local display server usually needs to be listed also.
Xaccess
Configures an access control for XDMCP, specifying different behavior according to the sort of query used will be discussed later, with security issues.
Xresources Resources to be loaded via xrdb the client that loads resources directly into the X
server by servers managed by xdm. GiveConsole A shell script that changes the ownership of the console to the user.
TakeConsole A shell script that changes the ownership of the console back to the root. Xsetup_0
A shell script used for display set up specific to the local console server.
Xsession
The initial startup script used by each individual X session. The script itself invokes other individual dot script files from the users home directory: .xsession and
.Xresources.
Xsetup
A shell script to assist in setting up the login screen the user sees, along with the xlogin widget.
Xstartup
A shell script executed since the user logs in.
Xreset
A shell script executed at the end of the session to clean up and reset X server.
In the users home directory, the following files are used by xdm in its default configuration:
525
HOME.xsession
HOME.Xresources
User−specific resources read by the systemwide Xsession script if HOME.xsession does not exist otherwise, the HOME.xsession script is
responsible for their loading.
Additional individual files in use are:
HOME.xsession−errors
Reports errors specific to a users X session — not to be edited.
HOME.Xauthority
Machine−readable authorization codes for the users server — not to be edited.
It is not mandatory that all configuration files are used and exist; the existing configuration files are specified in the xdm−config file.
Here is an old, but workable, example from an Xhost running xdm; SunOS 4.1.x has supported only xdm.
cat usrlibX11xdmxdm−config
DisplayManager.servers: usrlibX11xdmXservers DisplayManager.errorLogFile: usr libX11xdmxdm−errors
DisplayManager.pidFile: usrlibX11xdmxdm−pid DisplayManagerresources: usrlibX11xdmXresources
DisplayManagersession: usrlibX11xdmXsession DisplayManager._0.authorize: true
DisplayManagerauthorize: false
All listed files reside in the directory usrlibX11xdm; this is recommended, but not mandatory. The next example presents the listing of this directory the example is from SunOS 4.1.3 which
supported only xdm:
ls usrlibX11xdm
Xresources Xservers Xsession xdm−config xdm−errors xdm−pid
Another example includes several files more Silicon Graphics, Inc., IRIX 4.x — also supported only xdm:
ls usrlibX11xdm
Xlogin Xservers Xstartup xdm−errors Xreset Xsession Xstartup−remote xdm−pid Xresources Xsession−remote
xdm−config
Additional files are supposed to support the start of a remote session, as well as the way to log in and to reset the session; xdm−errors is the xdm error−log file, while xdm−pid contains the xdm
process ID.
526
Having in mind the general idea of xdmand how to get it going on, we will discuss in more detail the way to customize xdm. These skills are transparent in the CDE environment. To be able to
customize xdm means first to understand basic configuration files.
22.2.2.1.1 The xdm−config File
Let us start with the master configuration file xdm−config. The master configuration file for the xdm client program, it specifies esential configuration data, i.e., all other important files. Its syntax follows
standard resource specification syntax. The keyword DisplayManager is starting each resource entry in the file. In particular, resource specification follows one of the three forms:
DisplayManager.variable: value
This is a resource that makes sense only when applied to xdm proper; for
example, the entry:
DisplayManager.servers: pathfilename specifies which file
should be used for listing the X servers to be managed by xdm.
•
DisplayManager.DISPLAY.variable: value
This is a resource that applies only to a s ingle display server, specified by
DISPLAY; for example, the entry:
DisplayManager._0.authorize: true enables access control on
the local server. •
DisplayManagervariable: value
This is a generalization of the previous form. By putting an asterisk instead of
display name dots are also omitted, all servers not specifically defined otherwise
are specified. Here is an example:
DisplayManagerauthorize: false •
DisplayManager._0.authorize:true •
identifies only the local server that will use access control.
Here is another example — the configuration file xdm−config on IRIX platform an old, but illustrative example:
cat usrlibX11xdmxdm−config == === === === === === === === === === === === ===
DisplayManager.servers: usrlibX11xdmXservers DisplayManager.errorLogFile: usrlibX11xdmxdm−errors
DisplayManager.pidFile: usrlibX11xdmxdm−pid == === === === === === === === === === === === ===
DisplayManagerresources: usrlibX11xdmXresources DisplayManagerreset: usrlibX11xdmXreset
DisplayManagerauthorize: off DisplayManagerstartup: usrlibX11xdmXstartup−remote
DisplayManagersession: usrlibX11xdmXsession−remote == === === === === === === === === === === === ===
527
In this example recognize all entry formats, including the general way to start remote X sessions. Most entries are self−explanatory for more detailed explanations, the manual pages are always
available. We will briefly discuss some of them.
The first three entries point to the files that define X servers i.e., X server programs, to the log−file, and to the xdm PID file. Then, a list of entries with the asterisk following, identifying other
configuration files and data we are already familiar with.
The entries:
DisplayManager._0.startup: usrlibX11xdmXstartup DisplayManager._0.session: usrlibX11xdmXsession
specify the program which is executed as root after the authentication process succeeds. The conventional name for the script used is Xstartup by default there is no a startup program, and the
script to be executed as the user to start an X session is conventionally named Xsession by default, the X terminal emulator usrbinX11xterm is supposed. Both entries refer to the first local
X server 0. However, two local servers are foreseen, 0 and 1; two other entries refer to the local X server 1. Other X servers are supposed to be remote, and they are identified by the
previous entries with an asterisk.
The remaining entries refer also to the local X server 0, specifying additional configuration data; for example, the entries
DisplayManager._0.authFile: usrlibX11xdmxdm−auth DisplayManager._0.loginProgram: usrlibX11xdmXlogin
specify the file that is used for authentication, and the corresponding login program.
Other entries specify numeric resources that control xdm behavior when attempting to open X server, the timeout period, and how many times the attempting process should be repeated.
Watch for the possible appearance of the resource entry not existing in this example
DisplayManager.autoRescan: false
that disables the xdm to reread the configuration file on its own. By default, this entry is true and the xdm is configured to reread the configuration file after the session terminates and the files have
been changed. If this entry exists after any modification of configuration files, xdm must be recycled re−invoked.
528
The Xservers file was designed in X11R3, to define the X11 configuration staticly; it listed all X servers to be managed by xdm. It meant that each X server had to have an appropriate entry in the
file; xdm has read the file at the startup and has learned about all existing X servers. Since the XDMCP was introduced, the X servers X terminals became responsible for querying the host for
an xdm connection; the xdm connection became negotiable between an eligible X server and xdmeligible X servers are defined in the other configuration file Xaccess. The consequence was
that previously required data were no longer needed. Nevertheless, the Xservers file is not obsolete; it is still used to start the X session on the local console display which does not normally support
XDMCP, as well as for old−fashioned pre−X11R4 remote X servers that do not know about XDMCP today it is very unlikely to find such X servers; however….
Here is an example:
cat usrlibX11xdmXservers
:0 local usrbinX11X
The only entry tells the xdm that the console display name:0 is on the local machine, and that the command usrlibX11X should be used to start the corresponding X server; the command is
executed when xdm is started up. Usually, usrlibX11X is a symbolic link to the actual server program a server program is machine dependent; for example, Xsun could be the corresponding
program on the Sun platform. Here is an example from Solaris 2.6, where the X server program lives in the other directory usropenwinbin:
ls −l usropenwinbin | grep X
lrwxrwxrwx 1 root root 6 May 28 1998 X − .Xsun −rwxr−sr−x 1 root root 903512 Jul 7 1997 Xsun
For X servers that run on other XDMCP noncompliant machines, the entries are of the form:
xthostname:0 foreign Old Pre−X11R4 XTerminal
where, xthostname:0 specifies the machine and display where the X server is running, and foreign identifies the X server as the remote not local one. Other fields are ignored, i.e., treated
as comments.
A logical question is: How does an X client application know, during an X session, how to address the appropriate X server among many eligible X servers?. Here, X11 relies on the UNIX
environment variable DISPLAY. In a similar way as the variable TERM identifies a character−based terminal, the DISPLAY variable identifies the X server for the invoked X clients. If this variable is not
defined or wrongly defined, the started X client will display an error message: Cant open display.
Another way to identify the X server and, indirectly to define the DISPLAY variable is by starting an X client program with −display option and specified X server.
This is, probably, the right moment to elaborate how an X server is specified; an X server is identified by:
Hostname:DisplayNumber.ScreenNumber
where
529
DisplayNumber
Numerically identifies a corresponding display server running on the server machine could be more displays, followed by dot .
ScreenNumber
Numerically identifies a screen of the specified display a display with multiple screen is possible
In real life, the most common X servers are X terminals, with a single running display server, and a single screen. Consequently, the most common X server identification is: hostname:0.0. Later in the
text, we will return to this issue.
22.2.2.1.3 The Xresources File
The Xresources file is loaded into each individual X server as it is connected to xdm. In that way, the X server learns about clients resource needs and becomes ready to provide an appropriate X
service. The most important function of the Xresources file is to set resources for clients or widgets that are run before the user actually logs in. At least, it is necessary to load the xlogin widget the
xlogin box since it is run before the user logs in at all if you are not happy about the login box appearance, this is the place to look for a modification. The resources specified in the Xresources
file are loaded by the server via another client, the xrdb client. Here is an example:
cat usrlibX11xdmXresources
xloginlogin.translations: override\ KeyF1: set−session−argumentfailsafe finish−field\n\
KeyReturn: set−session−argument finish−field xlogingreeting: CLIENTHOST
xloginborderWidth: 3 ifdef COLOR
xlogingreetColor: f63 xloginfailColor: red
xloginForeground:black xloginBackground: fdc
else xloginForeground: black
xloginBackground: white endif
The resources starting with the string xlogin practically all here−included resources are used by the xlogin box. xlogin sends the box to the display, prompting the user for a name and password.
The box also displays the actual client hostname specified here as CLIENTHOST; this could be replaced by any arbitrary greeting message string. By editing the resource:
xlogingreeting: Welcome to CLIENTHOST
the greeting message will become friendlier than just the hostname, as it used to be. The syntax of the Xresources file is slightly different from other configuration files. The reason is that
the xrdb runs the resource file through a C preprocessor cpp by default. It gives extra flexibility, because the appropriate cpp commands like ifdef, else, and endif could be used; the pound
character is reserved for this purpose and cannot be used for comment lines. For comments, the bang character, is used as the leading character in the comment lines.
In the presented example, the first entry resource for xlogin is a translation table, used to define how special keystrokes might be used within the client pay attention, the entry contains several
lines terminating with the back−slash \ which indicates that the resource specification continues. This entry defines the F1 key as the failsafe key; by pressing F1, the so−called failsafe X session
530
The various colors specified here are more or less reasonable for most of the displays; otherwise, they can be tuned. COLOR is one of the variables that is predefined in xrdb, as well as
CLIENTHOST. Colors themselves can be specified by their commonly used names red, black, white, etc., or RGB values directly those color resources start with character and number
following it. The server translates these names into appropriate screen color using a RGB color database usually can be found in usrlibX11rgb.txt. The RGB values are expressed as
hexadecimal numbers, with one, two, three, or four digits for each field R, G, and B. Fields that have fewer than four digits are padded out with zeros following each digit. The hexadecimal
numbers indicate how much red R, green G, or blue B should be displayed zero being none, and ffff being on full
22.2.2.1.4 The Xsession File
The Xsession file is the script executed since a user logs in. This is a systemwide script, and each modification on the file must be performed extremely carefully. To customize an individual users
session, the HOME.xsession file is available. The file is pointed by the session resource for that display in the master configuration file. We will return to this file later, when we talk about
user−specific X environment.
22.2.2.1.5 The Xreset File
The Xreset file is a script that is executed after the session terminates. This script is not a must, so most often none is provided. Sometimes, it is provided as an empty script, ready to be customized if
necessary, as in the next example:
cat usrlibX11xdmXreset
binsh Xreset
This program is run as root after the session terminates but before the display is closed
22.2.3 CDE Configuration Files
