This chapter explains how to configure the MultiNet XDM (X Display Manager) server to manage remote systems running X (X Window System) servers. The MultiNet XDM server is based on X11R6.
The MultiNet XDM server provides login services to X servers through graphical dialog boxes. From a user's perspective, logging in at a MultiNet XDM-managed X server is no different than logging in at an OpenVMS system console.
Initially, the user sees the standard DECwindows banner and login dialog. After the user supplies a valid user name and password, the DECwindows Session Manager starts and launches any applications configured for automatic startup. After the user logs out from the Session Manager, the banner and login dialog reappear.
Users of X11R4 (and later) servers benefit from XDM because they can take advantage of the DECwindows Session Manager as if they were using a host.
Users can also specify which host they want to use. This feature is provided by XDMCP (X Display Management Communications Protocol), used for communication between X servers and XDM servers.
From a system manager's perspective, XDM provides a convenient way to extend the LOGINOUT service to users on remote X servers and to specify which X servers are managed by each XDM server host.
Before an X server can be managed, you must grant it access to your XDM server. In a network of dozens or hundreds of X servers, it may not be practical to manage every X server that requests XDM service. In these cases, you can restrict access to your XDM server. The manner in which access is granted depends on the version of the X server and how it requests XDM service.
X11R4 (and later) X servers can generate three basic types of management requests, as explained in the table below.
|
Request Type |
Description |
XDM Server Response |
|
|
Direct |
Sent by X server to a specific host |
If the XDM server is configured to accept requests from the user's X server, the host produces a login dialog on that server. If the XDM server is configured to refuse service to the user's X server, no login dialog appears, and the user must try a different host. For information on selectively rejecting XDMCP direct requests, see the Handling Direct and Broadcast Requests section. |
|
|
Broadcast |
Broadcast by X server to all hosts on the local network |
The XDM server responds to broadcast requests as if they were direct requests. Broadcasts can result in several XDM servers accepting the request; it is then up to the X server to determine which host to use. Some X servers simply use the first host to respond. Others present a list of responding hosts in a chooser dialog box, and the user selects a host from the list. |
|
|
Indirect |
Sent by X server to a specific host |
If the host's XDM server is configured to handle indirect requests from the X server, the host either forwards the request to another XDM server host or returns a list of XDM servers from which the user can choose.
The MultiNet XDM server does not handle indirect requests. |
From the user's perspective, broadcast and indirect requests provide similar benefits. From an administrator's perspective, however, indirect requests allow the XDM server administrator to select an XDM server for users.
Consider a situation in which BROWN.EXAMPLE.COM, an X terminal, is configured to make indirect requests for display management to an OpenVMS host, WHORFIN.EXAMPLE.COM, running the MultiNet XDM server. The administrator of WHORFIN can specify which XDM servers will manage BROWN by forwarding inquiries to another XDM server.
X11R3 servers cannot take advantage of XDMCP, which was not introduced until X11R4. Instead, X11R3 servers do not allow users to choose a host. For information on managing X11R3 servers, see the Managing X11R3 Displays section.
Unlike many XDM servers, the MultiNet XDM server does not control X sessions after users have logged in. Instead, it starts the processes that produce the login dialog and authenticate the user, then passes control to the DECwindows Session Manager. When the user terminates the session using the Session Manager, the X session ends and XDM starts a new login cycle. This method allows you to change XDM server configuration, stop the XDM server, and restart the XDM server without interrupting any X sessions already in progress.
Configuration of a remote user's session is identical to the customization of a local DECwindows user's session. Traditionally, XDM servers on UNIX systems allow user environments to be configured by scripts (command procedures) that are run before, during, and upon ending each X session. The MultiNet XDM server, however, takes advantage of the DECwindows STARTLOGIN and LOGINOUT processes to eliminate the need for extra command procedures.
The MultiNet XDM server does not handle indirect requests.
The following are common administrative tasks for the XDM server:
· Enabling the XDM server (see the Enabling and Starting the XDM Server section).
· Modifying the XDM server configuration (see the Modifying the XDM Server Configuration section).
· Controlling the XDM server (see the Controlling the XDM Server section).
· Controlling access to the XDM server (see the Controlling Access to the XDM Server section).
· Managing X11R3 displays (see the Managing X11R3 Displays section).
With the exception of controlling the XDM server, each task requires you to modify XDM configuration files and update the XDM server with the new information (as described in the Controlling the XDM Server section).
When MultiNet is first installed, the XDM server is disabled, and you must enable it. After the server is enabled, it starts automatically when MultiNet starts.
1. Issue the following DCL command:
$ MULTINET CONFIGURE /SERVER
2. At the SERVER-CONFIG prompt, enter:
SERVER-CONFIG>ENABLE XDM
3. To verify that the XDM server is enabled, enter:
SERVER-CONFIG>SHOW XDM
If no asterisk (*) appears to the left of XDM in the output, the service is enabled.
4. To exit the configuration utility, enter:
SERVER-CONFIG>EXIT
5. Restart the master server:
$ @MULTINET:START_SERVER.COM
XDM is configured through X resources and files specified through X resources. When the XDM server starts or you reload its configuration, it configures itself according to the contents of its master configuration file, MULTINET:XDM.CONFIGURATION, including reading the contents of files specified in the master configuration file.
Resource parameters for MultiNet XDM are listed in the below tables.
These resources modify the global behavior of XDM. Because the resource manager uses colons to separate the name of the resource from its value and dots to separate resource name parts, XDM substitutes underscores for both dots and colons when generating the resource name.
|
Note: If you import an XDM configuration file from a UNIX system, the startup, session, and authorize resources have no effect on the MultiNet XDM server.
|
The following is a sample XDM.CONFIGURATION file:
DisplayManager.logFile:
multinet:xdm-errors.log
DisplayManager.servers: multinet:xdm.servers
DisplayManager.accessFile: multinet:xdm.access
DisplayManager.removeDomainname: false
|
Configuration File Resource |
Description |
|
DisplayManager.accessFile |
Specifies a file containing a database of host names that are either allowed direct access to this host or to which queries should be forwarded. For details, see the Controlling Access to the XDM Server section. The equivalent file on UNIX systems is /usr/lib/X11/xdm/Xaccess.
Default: MULTINET:XDM.ACCESS. |
|
DisplayManager.debugLevel |
Sets the debug output level. Default: 0. You can also set this value while the XDM server is running with the command MULTINET NETCONTROL XDM DEBUG. |
|
DisplayManager.logFile |
Specifies the file in which errors are logged when the logType resource is FILE. The equivalent file on UNIX systems is /usr/lib/X11/xdm/xdm-errors.
Default: MULTINET:XDM.LOG. |
|
DisplayManager.logType |
Specifies where XDM server messages are logged: OPCOM, SYSLOG, FILE, or STDOUT.
Default: OPCOM. |
|
DisplayManager.removeDomainName |
Specifies whether XDM removes the domain name portion of host names if they are the same as the domain name of the local host. Removing the domain name is useful because name resolvers typically create fully qualified host names when computing display names for XDMCP clients.
Default: TRUE. |
|
DisplayManager.requestPort |
Specifies the UDP port number to which the XDM server listens for incoming XDMCP requests. Unless you need to debug the system, do not change the value from the default.
Default: 177 (the standard for XDMCP). |
|
DisplayManager.servers |
Specifies a
file containing a list of foreign X servers to manage. If the file
specification is prefixed with an @ sign, it contains one listing per line. A
foreign X server is an X display that does not support the XDMCP protocol.
The equivalent file on UNIX systems is /usr/lib/X11/xdm/Xservers Default: MULTINET:XDM.SERVERS. |
You can use the configuration parameters in the below table to adjust the way
the XDM server transfers control of the X terminal to a DECwindows process. The
default values for these parameters should be suitable for ordinary DECwindows
usage.
Under normal operation, the XDM server creates an X connection to the managed display before starting a process to invoke the DECwindows login screen. When the login completes and the DECwindows Session Manager starts, it hands off the initial X connection to the process. The initial X connection closes down automatically when the session ends, causing the X display to reset and either shut down or restart the XDM login chooser (depending on how the X terminal or software is configured).
|
Configuration Resource |
Description |
|
DisplayManager.loginCheckInterval |
The number of seconds the XDM server waits between checks to see if the DECwindows login process has begun. Default: 5 |
|
DisplayManager.loginTries |
The number of checks the XDM server makes to see if the DECwindows login process has begun. Default: 12 |
|
DisplayManager.sessionCheckInterval |
The number of seconds the XDM server waits between checks to see if the DECwindows login process has handed control to the user's Session Manager. Default: 10 |
|
DisplayManager.sessionTries |
The number of checks the XDM server makes to see if the user's Session Manager started. Default: 30 |
|
DisplayManager.bypassSessionCheck |
If set to true, the check for the start of a Session Manager is bypassed. Default: false |
|
DisplayManager.sessionManagers |
A comma-separated list of image names, without device or directory specifications, that the XDM server should consider to be Session Managers for a DECwindows session. Default: DECW$SESSION.EXE |
This section describes the following XDM tasks:
· Checking the status of the XDM server
· Starting the XDM server
· Stopping the XDM server
· Restarting the XDM server
· Reloading the XDM configuration
For most of these tasks, you use the MULTINET NETCONTROL utility.
To check the status of the MultiNet XDM server, enter:
$ MULTINET NETCONTROL XDM SHOW
The following example shows the information generated by this command on a system named WHORFIN that manages three X terminals, BANZAI, BROWN, and MIGUEL. When the terminal is displaying a DECwindows login screen, the following command output changes to show the words "not logged in" instead of a process identifier number.
$ MULTINET
NETCONTROL XDM SHOW
Connected to NETCONTROL server on "WHORFIN"
< WHORFIN.EXAMPLE.COM
< Network Control 5.6 at Wed 8-Oct-2019 11:37AM-EST
< XDM Current Managed Displays:
< Display BANZAI.EXAMPLE.COM:0.0 Type XDMCP Process 20E002A8
< Display BROWN.EXAMPLE.COM:0.0 Type XDMCP Process 20E00289
< Display MIGUEL.EXAMPLE.COM:2005.0 Type XDMCP Process 20E00242
< OK
This section describes how to start the MultiNet XDM server.
|
Note: The XDM server is automatically started when MultiNet starts.
|
Before starting the MultiNet XDM server, make sure it is enabled. For details, see the Enabling and Starting the XDM Server section.
To start the MultiNet XDM server, enter:
$ MULTINET NETCONTROL XDM START
When the XDM server starts, it reads the master configuration file, MULTINET:XDM.CONFIGURATION, to determine which configuration files to read, then reads them. (For information on modifying the master configuration file, see the Modifying the XDM Server Configuration section). You can specify other configuration files simply by modifying the contents of the master configuration file and then restarting the XDM server (see Restarting the XDM Server), or by reloading the XDM configuration files (see the Reloading the XDM Configuration section).
The following example shows the information generated by this command:
$ MULTINET
NETCONTROL XDM START
< XDM Server Started, process id pid
To stop the MultiNet XDM server, enter:
$ MULTINET NETCONTROL XDM SHUTDOWN
The following example shows the information generated by this command:
$ MULTINET
NETCONTROL XDM SHUTDOWN
< XDM Server Shutdown
Restarting the XDM server is a convenient alternative to stopping and starting the XDM server as described in the Starting the XDM Server section and the Stopping the XDM Server section.
When the XDM server restarts, it reads the master configuration file MULTINET:XDM.CONFIGURATION to determine which configuration files to read, then reads them.
To restart the XDM server, enter:
$ MULTINET NETCONTROL XDM RESTART
The following example shows the information generated by this command:
$ MULTINET
NETCONTROL XDM RESTART
Connected to NETCONTROL server on "LOCALHOST"
< WHORFIN.EXAMPLE.COM Network Control 5.6 at Tue 30-Sep-2019 12:47AM-EST
< XDM Server Started, process id 2040024B
$
For information on modifying the master configuration file, see the Modifying the XDM Server Configuration section.
Changes to XDM server configuration take effect when the XDM server is started or restarted or when the configuration files are reloaded. Reloading the XDM server allows you to reload the XDM server configuration files without restarting the XDM server and interrupting connections between X servers and the XDM server.
When the XDM server reloads its configuration, it first reads the MULTINET:XDM.CONFIGURATION master configuration file to determine which other files to read, then reads them. For information on modifying the master configuration file, see the Modifying the XDM Server Configuration section.
To reload the XDM configuration files, enter:
$ MULTINET NETCONTROL XDM RELOAD
The following example shows the information generated by this command produces:
$ MULTINET
NETCONTROL XDM RELOAD
< OK: XDM server configuration reloading
Access to the MultiNet XDM server by X11R4 (and later) servers is controlled through the MULTINET:XDM.ACCESS file. This file contains the following information:
· Displays the XDM server will manage
· Displays the XDM server will not manage
· Displays and the XDM servers that will manage them
· Macro definitions
The following sections explain how to edit XDM.ACCESS to handle direct, broadcast, and indirect requests.
To manage X servers that make direct or broadcast requests, add their names to the XDM.ACCESS file as follows:
· To manage a specific X server, include a line with the server host name.
· To reject a specific X server, include a line with the server host name preceded by an exclamation point (!).
· To manage any X server that requests management, include a line consisting of an asterisk (*).
For convenience, you can define lists of hosts in macros in XDM.ACCESS. To define a macro, include a line at the top of the file in the following format:
%macroname host_list
You can then use the macro name (including the leading percent sign (%)) in the file.
The following sample XDM.ACCESS file allows any host to be managed by the XDM server.
# Access control file for
XDMCP connections
#
* #any host can get a login window
Although X11R3 X servers do not allow users to select the host they are going to log into, they can still be managed by the MultiNet XDM server. Once an X server is managed by one host, however, the user has limited ability to change to another host.
To configure the MultiNet XDM server to manage a specific X11R3 display:
1. Add the X11R3 display to the MultiNet XDM server's XDM.SERVERS file (see the Specifying X11R3 Displays section).
2. Configure the X11R3 display to grant access to the MultiNet host (see the Setting Up Host Access on the Display section).
3. Make sure the X11R3 display is not already managed by another XDM server (see the Ensuring No Other Host Is Managing the Display section).
4. Reload the XDM server configuration (see the Reloading the XDM.SERVERS File section).
The XDM server obtains a list of X displays to manage from the MULTINET:XDM.SERVERS file whenever it starts or you reload its configuration files. The XDM server obtains its list of X11R3 servers from the file specified in the DisplayManager.servers resource in the XDM master configuration file, MULTINET:XDM.CONFIGURATION.
Add an entry to XDM.SERVERS in the following format:
server_name foreign
· server_name is the name of the X11R3 server you want to manage, in the standard X format (hostname:server number[.screen number]).
· "foreign" indicates that server_name does not use XDMCP.
The following sample XDM.SERVERS file contains entries for two X11R3 servers, BANZAI:0 and MIGUEL:0.
banzai.example.com:0 foreign
miguel.example.com:0 foreign
You can also specify classes of displays that share similar requirements.
Before the XDM server can produce a login dialog box on an X11R3 display, it must be granted access to the display via the X host access mechanism.
|
Note: The MultiNet XDM server does not support the MIT-MAGIC-COOKIE-1 mechanism.
|
The XDM server can only present the LOGINOUT dialog on X11R3 servers on which host access restrictions are entirely disabled, or enabled specifically for your MultiNet XDM server host.
For many X servers, you can disable access restrictions with the xhost client, or by modifying configuration files before starting the server. Refer to your X server administration documentation for information on granting access to remote hosts.
If an X11R3 display is already being managed by another XDM server, either remove the display from the other XDM server's configuration (usually the XSERVERS file) or change the X server's host access list so the other XDM server cannot access the display. Cancel the login dialog and verify that the other XDM server's login dialog does not return.
Reload the MULTINET:XDM.SERVERS file (or stop and restart the XDM server) after you have:
· Specified which X11R3 servers you want to manage in the MULTINET:XDM.SERVERS file
· Granted access to your XDM server
· Made sure that no other XDM server is managing the X servers
The XDM server reads the XDM.SERVERS configuration file when it starts (see the Starting the XDM Server section), restarts (see the Restarting the XDM Server section), and when you reload its configuration (see the Reloading the XDM Configuration section).