TCPware's X Display Manager (XDM) server manages remote X displays (X terminals). When starting up, remote X displays communicate with XDM through the UDP-based X Display Manager Control Protocol (XDMCP). The XDM server creates a DECwindows login process that prompts remote X display users to log in and create a DECwindows session.
TCPware's XDM server supports broadcast, direct, and indirect requests. It also supports display authentication. A direct request is to a particular display or displays, and a broadcast request polls any number of displays for a response. An indirect request forwards the request to another XDM server to determine the X display. Display authentication requires that the XDM server and the X display share a private key.
The server is supported on all versions of the Alpha platform, all versions of the I64 platform and on VAX/VMS 6.1 or higher. VAX/VMS 5.5-2 is supported if DEC C or the DEC C Run-Time Library (RTL) is installed.
The XDM server is based on the X11R6.1 release from X Consortium.
This chapter describes the XDM server, its configuration, and how to impose access restrictions from other servers.
Enable the XDM server through CNFNET configuration by responding with YES at the following prompts (both default to NO):
· Do you want to use the TCPware for OpenVMS XDM server:
· Do you want to restart XDM:
When enabled and started, the XDM server runs as a detached process, TCPware_XDM. A log file, TCPWARE:XDMSERVER.LOG, is created that captures log information enabled through the DisplayManager.debugLevel X Resource (see the next section).
Configure the XDM server using an X Resource style configuration file, TCPWARE:XDM_CONFIG.DAT. You must create this file. (A template is provided as TCPWARE:XDM_CONFIG.TEMPLATE, which you can rename TCPWARE:XDM_CONFIG.DAT.)
The below example shows a sample configuration file.
# TCPWARE:XDM_CONFIG.DAT
#
DisplayManager.debugLevel: 1
DisplayManager.accessFile: TCPWARE:XDM_ACCESS.DAT
DisplayManager.removeDomainname: false
DisplayManager.keyFile: TCPWARE:XDM_KEYS.DAT
#
Any characters after the pound sign (#) are ignored. The XDM server supports the following X Resources:
· DisplayManager.debugLevel
· DisplayManager.opcomLevel
If these resource values are set to non-zero, this enables logging. The default is 0 (no logging). If set to non-zero, the XDM server logs debugging information to the TCPWARE:XDMSERVER.LOG file or sends a message to OPCOM. The debug levels are as follows:
|
0 |
None |
2 |
Critical |
4 |
Warning |
6 |
Informational |
|
1 |
Alert |
3 |
Error |
5 |
Notice |
7 |
Debug |
The defaults are:
• DisplayManager.debugLevel:4
• DisplayManager.opcomLevel:5
· DisplayManager.accessFile
Specifies the access control file that defines access limitations of servers to the XDM server. By default no file is specified, which allows any X display to connect to the XDM server. If this resource is specified with a non-existent or empty file, no X display can connect to the XDM server. The usual file is TCPWARE:XDM_ACCESS.DAT. See Server Access Control.
· DisplayManager.removeDomainname
When computing the display name for XDMCP clients, the name resolver typically creates a fully qualified hostname for the terminal. As this may be confusing, you can use this resource to remove the domain name portion of the hostname, if it is the same as the domain name of the local host when this variable is set. The value is true by default.
· DisplayManager.keyFile
XDM-AUTHENTICATION-1 style XDMCP authentication requires that a private key be shared between XDM and the terminal. This resource specifies the file containing those values. Each entry in the file consists of a display name and the shared key.
The display name is either a unique name associated with the display hardware (such as -Ethernet-8:0:2b:a:f:d2 in the form manufacturer-model-serial) or any unique identifier. The shared key is a 56-bit integer represented by a 14-digit hexadecimal integer prefixed with 0x.
The below example shows a sample key file. (A template file, XDM_KEYS.TEMPLATE, is provided so that you can rename XDM_KEYS.DAT and use as the default.)
#
TCPWARE:XDM_KEYS.DAT
#
# display name shared key (14 digit hex)
# ----------------------- -------------------------
-Ethernet-8:0:2b:a:f:d2 0x4f098af322dd98
#
You can control access to the XDM server in the TCPWARE:XDM_ACCESS.DAT file by enabling the DisplayManager.accessFile resource in the XDM_CONFIG.DAT file (see Server Configuration). (A template file, XDM_ACCESS.TEMPLATE, is provided that you can rename XDM_ACCESS.DAT and use as the default.)
Note that if you specify the DisplayManager.accessFileresource without a filename value, any X display can connect to the XDM server. If the file specified is empty or nonexistent, no X display can connect to the XDM server.
The XDM_ACCESS.DAT file contains entries that control the response to direct and broadcast queries and contains separate entries for indirect queries. Each entry is a hostname, pattern, or macro.
· For a hostname, all comparisons involve network addresses, so that you can use any name that converts to the correct network address. An exclamation point (!) preceding a hostname excludes that host.
· A pattern involves wildcards, where only canonical hostnames are compared – do not attempt to match aliases. An exclamation point (!) preceding a pattern excludes hosts that match the pattern. A pattern includes one or more of the following wildcard meta-characters:
|
* |
Matches any sequence of characters compared against the hostname |
|
? |
Matches any single character compared against the hostname |
· A macro definition contains a macro name preceded by % and a list of hostnames or other macros, which can be nested.
An indirect entry also contains a hostname or pattern but follows it with a list of hostnames (such as defined by a macro) to which indirect queries should be sent. When checking access for a particular display host, each entry is scanned in turn and the first matching entry determines the response. Direct and broadcast entries are ignored when scanning for an indirect entry, and indirect entries are ignored when scanning for direct or broadcast entries. Other access control file formats are as follows:
|
Blank lines are ignored |
|
|
# |
Comment delimiter, causing the rest of that line to be ignored |
|
\ |
Line continuation character, allowing indirect host lists to span multiple lines |
The below example shows a sample XDM_ACCESS.DAT file. Note that the positioning of entries is important. For example, if the !bogus.example.com and *.example.com lines had been transposed, direct or broadcast access from bogus would have been allowed, which is not desired. In the entry !bogus.example.com dummy, the dummy is a dummy host.
# TCPWARE:XDM_ACCESS.DAT
#
# Direct/broadcast query entries
#
bambi.example.edu # allow access from bambi at Example U
!bogus.example.com # disallow direct/broadcast service from bogus
*.example.com # allow access from any display in example (x bogus)
#
# Indirect query entries
#
%HOSTS expo.example.com xenon.example.com excess.example.com
kanga.example.com
extract.example.com xenon.example.com # force extract to contact xenon
!bogus.example.com dummy # disallow indirect access to bogus
*.example.com %HOSTS # all others get to choose from
# hosts in the %HOSTS macro list
#