| Previous | Contents | Index |
The XACCESS.TXT file, a required file, allows or restricts access to remote X servers. If the XACCESS.TXT file is not present, the system restricts all remote X server access. You use this file to control the way XDM responds to broadcast, direct, and indirect requests from X servers.
The default file specification for the XACCESS.TXT configuration file is:
SYS$SPECIFIC:[TCPIP$XDM]XACCESS.TXT |
If you choose to use another file name or directory location, you can override the default by adding a line in the XDM_CONFIG.CONF file similar to the following:
DisplayManager.accessFile: WORK1$:[XDM]XACCESS.TXT |
Example 21-2 shows a sample XACCESS.TXT configuration file.
| Example 21-2 XACCESS.TXT File |
|---|
# # File name: XACCESS.TXT # Product: HP TCP/IP Services for OpenVMS # Version: V5.4 # # © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P. # # # access control file for XDMCP connections # # # To control Direct and Broadcast access: # # pattern # # To control Indirect queries: # # pattern list of hostnames and/or macros ... # # To define macros: # # %name list of hosts ... # # The first form tells xdm which displays to respond to itself. # The second form tells xdm to forward indirect queries from hosts # matching the specified pattern to the indicated list of hosts. # # In all cases, xdm uses the first entry which matches the terminal; # for IndirectQuery messages only entries with right hand sides can # match, for Direct and Broadcast Query messages, only entries without # right hand sides can match. # * #any host can get a login window # # To hardwire a specific terminal to a specific host, you can # leave the terminal sending indirect queries to this host, and # use an entry of the form: # #terminal-a host-a |
Allowing Direct Access
To allow access, add a line to the XACCESS.TXT file with the host name, as shown in the following example:
condor.company.com |
Denying Access
To restrict access, add a line to the XACCESS.TXT file with the host name, preceded by an exclamation point, as shown in the following example:
!rufus.company.com |
You can use the question mark (?) and the asterisk (*) wildcard characters to specify host names that vary with one character or more than one character.
Allowing Indirect Access
To allow indirect access, add a line to the XACCESS.TXT file similar to the following line:
rufus.company.com richard.company.com henry.company.com william.company.com |
The XSERVERS.TXT file was originally used to specify all X servers to be managed by XDM. However, since the introduction of XDMCP, there is no need to specify X servers that are XDMCP compatible in this file.
This file now specifies the X servers that do not support XDMCP. Unlike other XDM implementations, this file is not used to specify XDM support for the local display server.
The default file specification for the XSERVERS.TXT file is:
SYS$SPECIFIC:[TCPIP$XDM]XSERVERS.TXT |
If you choose to use a different name and directory location, you can override the default by adding a line to the XDM_CONFIG.CONF file similar to the following line:
DisplayManager.servers: WORK1$:[XDM]XSERVERS.TXT |
Example 21-3 shows a sample XSERVERS.TXT configuration file.
| Example 21-3 XSERVERS.TXT File |
|---|
# # File name: XSERVERS.TXT # Product: HP TCP/IP Services for OpenVMS # Version: V5.4 # # © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P. # # # This file can be used to suppport X terminals which do not support XDMCP # # # For each terminal, add a line that consists of # DisplayName:0 foreign # # Where DisplayName is a IP name. # rufus.compaq.com:0 foreign |
In Example 21-3, the word "foreign" indicates that the X
server is running on another machine.
21.3.4 XDM_KEYS.TXT File
The XDM_KEYS.TXT file provides XDM-AUTHENTICATION-1 style XDMCP authentication. This optional file contains key ID and key value pairs for use with X terminals that support or require XDM authorization.
Each noncomment line in the XDM_KEYS.TXT file contains a display ID and a key value. The file is used when a request containing a display ID key is received from an X terminal. The corresponding key value is encrypted and returned to the X terminal. If the key value in the configuration file matches the key value specified by the X terminal's control information, the session is allowed.
The default file specification for the XDM_KEYS.TXT files is:
SYS$SPECIFIC:[TCPIP$XDM]XDM_KEYS.TXT |
If you choose to use a different name and directory location, you can override the default by adding a line to the XDM_CONFIG.CONF file similar to the following line:
DisplayManager.keyFile: WORK1$:[XDM]XDM_KEYS.TXT |
Example 21-4 shows a sample XDM_KEYS.TXT configuration file.
| Example 21-4 XDM_KEYS.TXT |
|---|
# # File name: XDM_KEYS.TXT # Product: HP TCP/IP Services for OpenVMS # Version: V5.4 # # © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P. # # # XDM security key file # # # Excursion Display ID: Excursion Cookie: # test123456 123457 # # Exceed Display ID: Exceed Key: # HCLpcXserver:629409365 1234568 |
XDM's default operation after login is controlled by the SYS$SYSTEM:TCPIP$XDM_XSESSION.COM file. This file first parses its p1 display parameter nodename[:server[.screen]] and creates the DECwindows display using the following command:
$ SET DISPLAY/CREATE/NODE=""NODENAME"'/TRANSPORT=TCPIP/SERVER='SERVER/SCREEN='SCREEN |
The default operation is to then create a Common Desktop Environment using the following command:
$ @CDE$PATH:XSESSION.COM |
At present, CDE is only available on Alpha systems in version 1.2-4 or later of DWMOTIF. It is not available on VAX systems. If the CDE command procedure XSESSION.COM is not found on the system, XDM looks for the DECwindows Desktop Session Manager startup command procedure DECW$STARTSM.COM to initiate the session by using the following command:
$ @SYS$MANAGER:DECW$STARTSM.COM |
Before executing either of these command procedures (but after performing the SET DISPLAY command), XDM looks for an XDM_XSESSION.COM file in the user's SYS$LOGIN directory. If found, XDM executes that file instead, passing it both the full display specifcation nodename[:server[.screen]] as p1 , and just the nodename as p2 . Users then have full control over exactly what type of session they prefer to start. For example, to simply start a DECterm, the following DCL commands would be placed into their XDM_XSESSION.COM file:
$ CREATE/TERMINAL/WAIT/WINDOW_ATTRIBUTES=(ICON=""p2"",TITLE=window_title) |
For a complete description of the CREATE command and its qualifiers,
use the DCL command HELP at the OpenVMS system prompt.
21.4 XDM Log Files
XDM maintains three log files to record XDM server and client activity:
Table 21-1 lists the XDM log files and their OpenVMS directory locations.
| Process | File Name | Location |
|---|---|---|
| XDM server | TCPIP$XDM_RUN.LOG | SYS$SPECIFIC:[TCPIP$XDM] |
| X terminal | xterm_name_domain.COM | SYS$SPECIFIC:[TCPIP$XDM.WORK] |
| xterm_name_domain.ERR | SYS$SPECIFIC:[TCPIP$XDM.WORK] | |
| xterm_name_domain.OUT | SYS$SPECIFIC:[TCPIP$XDM.WORK] | |
| User | xterm_name_domain.LOG | SYS$LOGIN |
The XDM server can be shut down and started independently from the rest of the TCP/IP Services software. This is useful when you change parameters or logical names that require the service to be restarted.
The following files are provided:
To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:
To configure your XDM server, you need to:
XDM requires DECwindows components that are not installed.
Attempts to activate XDM will fail.
Type C to continue with XDM configuration, or E to exit [ E ]:
|
To make sure that the XDM service is enabled and that the XDM process is running, enter the following TCPIP command:
$ TCPIP SHOW SERVICE XDM Service Port Proto Process Address State XDM 177 UDP TCPIP$XDM 0.0.0.0 Enabled |
If you have an X terminal that does not support the XDMCP protocol, you can manage this terminal by using an XSERVERS.TXT configuration file. See Section 21.3.3 for information about how to create the configuration file.
If you are running hp eXcursion, refer to the Compaq PATHWORKS 32 eXcursion User's Guide for configuration information. For all other X servers, refer to the third-party X Window System software documentation for information about how to configure their product.
Part 5 describes how to configure, use, and manage the components that enable transparent network file sharing: NFS server, PC-NFS, and NFS client. It includes the following chapters:
The Network File System (NFS) server software lets you set up file systems on your OpenVMS host for export to users on remote NFS client hosts. These files and directories appear to the remote user to be on the remote host even though they physically reside on the local system.
After the NFS server is installed on your computer, you must configure the server to allow network file access.
This chapter reviews key NFS concepts and describes:
See Chapter 23 for information on managing the NFS client.
If your network includes PC clients, you may want to configure PC-NFS.
Section 22.1.9 and Section 22.4 provide more information.
22.1 Key Concepts
NFS software was originally developed on and used for UNIX machines. For this reason, NFS implementations use UNIX style conventions and characteristics. The rules and conventions that apply to UNIX files, file types, file names, file ownership, and user identification also apply to NFS.
Because the TCP/IP Services product runs on OpenVMS, the NFS software must accommodate the differences between UNIX and OpenVMS file systems, for example, by converting file names and mapping file ownership information. You must understand these differences to configure NFS properly on your system, to select the correct file system for the application, and to ensure that your file systems are adequately protected while granting access to users on remote hosts.
The following sections serve as a review only. If you are not familiar
with NFS, see the Compaq TCP/IP Services for OpenVMS Concepts and Planning manual for more information.
22.1.1 Clients and Servers
NFS is a client/server environment that allows computers to share disk space and allows users to work with their files from multiple computers without copying them to their local system. The NFS server can make any of its file systems available to the network by exporting the files and directories. Users on authorized client hosts access the files by mounting the exported files and directories. The NFS client systems accessing your server may be running UNIX, OpenVMS, or other operating systems.
The NFS client identifies each file system by the name of its
mount point on the server. The mount point is the name
of the device or directory at the top of the file system hierarchy that
you create on the server. An NFS device is always named DNFSn.
The NFS client makes file operation requests by contacting your NFS
server. The server then performs the requested operation.
22.1.2 NFS File Systems on OpenVMS
The OpenVMS system includes a hierarchy of devices, directories and files stored on a Files--11 On-Disk Structure (ODS-2 or ODS-5) formatted disk. OpenVMS and ODS-2 or ODS-5 define a set of rules that govern files within the OpenVMS file system. These rules define the way that files are named and catalogued within directories.
If you are not familiar with OpenVMS file systems, refer to the HP OpenVMS System Manager's Manual: Essentials to learn how to set up and initialize a Files--11 disk.
You can set up and export two different kinds of file systems: a
traditional OpenVMS file system or
a UNIX-style file system built on top of an OpenVMS file system. This
UNIX-style file system is called a container file
system.
22.1.2.1 Selecting a File System
Each file system is a multilevel directory hierarchy: on OpenVMS systems, the top level of the directory structure is the master file directory (MFD). The MFD is always named [000000] and contains all the top-level directories and reserved system files. On UNIX systems or with a container file system, the top-level directory is called the root.
You can set up and export either an OpenVMS file system or a container file system. Which one you choose depends on your environment and the user needs on the NFS client host.
You might use an OpenVMS file system if:
Select the OpenVMS file system if you need to share files between users on OpenVMS and users on NFS clients.
You might use a container file system if:
The NFS software lets you create a logical UNIX style file system on your OpenVMS host that conforms to UNIX file system rules. This means that any UNIX application that accesses this file system continues to work as if it were accessing files on a UNIX host.
An OpenVMS server can support multiple container file systems. Creating a container file system is comparable to initializing a new disk with an OpenVMS volume structure, because it provides the structure that enables users to create files. The file system parameters, directory structure, UNIX style file names, and file attributes are catalogued in a data file called a container file.
The number of UNIX containers you should create depends on how you want to manage your system.
In a container file system, each conventional UNIX file is stored as a separate data file. The container file also stores a representation of the UNIX style directory hierarchy and, for each file name, a pointer to the data file. In addition to its UNIX style name, each file in the container file system has a system-assigned valid Files--11 file name.
An OpenVMS directory exists for each UNIX directory stored in the container. All files catalogued in a UNIX directory are also catalogued in the corresponding OpenVMS directory; however, the UNIX directory hierarchy is not duplicated in the OpenVMS directory hierarchy.
Because each UNIX style file is represented as an OpenVMS data file, OpenVMS utilities such as BACKUP can use standard access methods to access these files.
Except for backing up and restoring files, you should not use DCL commands to manipulate files in a container file system. Instead, use the commands described in Section 22.10. |
For more information about backing up and restoring files, see Section 22.7 and Section 22.10.7.
For information about setting up container file systems, see
Section 22.9.
22.1.2.3 NFS Support for Extended File Specifications
The NFS server and the NFS client support OpenVMS extended file specifications (EFS) on ODS-5 disk volumes.
You can use NFS server to export files on OpenVMS ODS-5 volumes. The traditional ODS-2 volumes continue to be supported. The NFS client can emulate an ODS-5 volume.
Note that the NFS server and NFS client support the ISO Latin-1 character set only.
If an ODS-5 volume is mapped and exported, the NFS server automatically supports EFS features and ignores the NAME_CONVERSION option of the EXPORT command, if it is specified in the export record.
On ODS-2 volumes (with or without the NAME_CONVERSION option), files with all uppercase names are displayed on non-OpenVMS clients with all lowercase letters. On ODS-5 volumes, the file names are displayed by clients in the same case as they are displayed locally on the server host.
If an ODS-2 volume contains file names that were created using the NAME_CONVERSION option of the NFS EXPORT command and include lowercase or special characters that are invalid for ODS-2 file names, those file names displayed locally on the server host contain character sequences (escape codes), as described in Appendix C. If the DCL SET VOLUME /STRUCTURE_LEVEL=5 command is performed on this volume, the names are displayed by clients with the character sequences exactly as they are displayed locally on the server host.
| Previous | Next | Contents | Index |