# DIGITAL TCP/IP Services for OpenVMS

# Management

# October 1997

Revision Information: This is a revised manual.

Operating Systems: OpenVMS Alpha Version 6.2, 7.0, 7.1 OpenVMS VAX Version 6.2, 7.0, 7.1

Software Version: DIGITAL TCP/IP Services
for OpenVMS Version 4.2

Digital Equipment Corporation Maynard, Massachusetts

October 1997

Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description.

Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from DIGITAL or an authorized sublicensor.

DIGITAL conducts its business in a manner that conserves the environment and protects the safety and health of its employees, customers, and the community.

© DIGITAL Equipment Corporation 1997. All rights reserved. The following are trademarks of DIGITAL Equipment Corporation: ACMS, DECdtm, DDCMP, DEC, DECnet, DECNIS, DECserver, DECsystem, DECwindows, DIGITAL, DNA, InfoServer, LAT, OpenVMS, PATHWORKS, POLYCENTER, VAX, VAXstation, VMS, VMScluster, and the DIGITAL logo.

The following are third-party trademarks:

HP and Hewlett-Packard are registered trademarks of Hewlett Packard Company.

IBM and OS/2 are registered trademarks of International Business Machines Corporation.

MS-DOS is a registered trademark of Microsoft Corporation.

OSF/1 is a registered trademark of Open Software Foundation, Inc.

PostScript is a registered trademark of Adobe Systems, Inc.

Sun, NFS, and PC-NFS are registered trademarks of Sun Microsystems, Inc.

UNIX is a registered trademark of UNIX System Laboratories, Inc., a wholly-owned subsidiary of Novell, Inc.

All other trademarks and registered trademarks are the property of their respective holders.

ZK6526

This document is available on CD-ROM.

# Contents

# Preface

This manual provides system and network managers with information needed for the day-to-day management of the DIGITAL TCP/IP Services for OpenVMS (UCX) software product. This manual is best used in conjunction with the DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual.

See the DIGITAL TCP/IP Services for OpenVMS Installation and Configuration manual for information about installing, configuring, and starting this product.

# Intended Audience

This manual is for experienced OpenVMS and/or UNIX system managers and assumes a working knowledge of TCP/IP networking, TCP/IP terminology, and some familiarity with the DIGITAL TCP/IP Services for OpenVMS product.

If you are not familiar with the DIGITAL TCP/IP Services for OpenVMS product, please review the DIGITAL TCP/IP Services for OpenVMS Concepts and Planning Guide before using this manual to configure and manage UCX components.

If you are familiar with DIGITAL TCP/IP Services for OpenVMS software components, DIGITAL recommends spending a few minutes reading the "Reviewing Key Concepts" section of each chapter before modifying or working with individual software components.

# Document Structure

This manual contains six parts as follows:

Part 1 | Describes how to configure network interfaces, how to set up serial lines, and how to configure and manage routing.
Part 2 | Describes how to set up and manage the following network services: BIND name server and resolver BOOTP and TFTP Portmapper Network Time Protocol (NTP) SNMP
Part 3 | Describes how to configure network applications that let users send and receive electronic mail from the internet; establish login sessions with a remote host; and transfer files. Part 3 describes how to configure these applications on the local host to provide the following support to remote and local users: TELNET Remote (R) commands FTP SMTP and POP
Part 4 | Describes how to configure, use, and manage the components that enable transparent network file sharing: NFS server, PC-NFS, and NFS client.
Part 5 | Describes how to configure and manage network printing services: LPD/LPR and TELNETSYM.
Part 6 | Provides appendixes that: Explain how to identify and resolve problems with UCX software Describe error and informational messages you may receive when using UCX software Describe error messages you may receive when analyzing NFS UNIX-style and OpenVMS-style file systems Provide a template for creating a customized security driver Provide EBCDIC/DMCS translation tables Describe how NFS converts UNIX file names to OpenVMS files names

# Terminology

This manual uses the following terminology:

- The abbreviation for the product name is UCX.
- UCX and DIGITAL TCP/IP Services for OpenVMS is used to mean both:
  - DIGITAL TCP/IP Services for OpenVMS Alpha
  - DIGITAL TCP/IP Services for OpenVMS VAX
- Software components
  - Auxiliary server is the DIGITAL TCP/IP Services for OpenVMS implementation of the UNIX internet daemon (inetd.)
  - NFS is the DIGITAL TCP/IP Services for OpenVMS implementation of the NFS protocols, including the NFS server, the NFS client, and PC-NFS.
  - TN3270 means the TELNET software that emulates IBM 3270 model terminals.
- UNIX operating system
  UNIX refers to UNIX Version 4.3 of the Berkeley Software Distribution (BSD). The DIGITAL UNIX operating system is fully compatible with UNIX BSD Version 4.3.
- Networking terms
  - Host and node both mean a system connected to an internet.
  - The term Internet refers to the global interconnection of networks, as defined by RFC 1208, which consists of large networks using TCP/IP to provide universal connectivity, reaching the Defense Advanced Projects Research Internet, MILNET, NSFnet, CERN, and many worldwide universities, government research labs, military installations, and business enterprises.
    The term internet refers to private interconnected networks that use TCP/IP to connect together and function as one, virtual network.

# Acronyms

For a complete list of acronyms used throughout this and other manuals in the DIGITAL TCP/IP Services for OpenVMS documentation set, see the DIGITAL TCP/IP Concepts and Planning guide.

# Conventions

All IP addresses in this book represent fictitious addresses. The following conventions apply to this book.

Convention | Meaning
--- | ---
UPPERCASE TEXT | Indicates names of OpenVMS and UCX commands, options, utilities, files, directories, hosts, and users.
lowercase special type | Indicates UNIX system output or user input, commands, options, files, directories, utilities, hosts, and users.
italic type | Indicates a variable.
`[Return]` | Indicates that you press the Return key.
`[Ctrl/]` x | Indicates that you press the Control key while you press the key noted by x.
[ ] | In command format descriptions, indicates optional elements. The elements are separated by vertical bars (|). You can enter as many as you want.
{ } | In command format descriptions, indicates you must enter at least one listed element. The elements are separated by bars (|).

# Reader's Comments

DIGITAL welcomes your comments on this manual or any of the DIGITAL TCP/IP Services for OpenVMS documents. Send us your comments through any of the following channels:

Internet | openvmsdoc@zko.mts.dec.com
Fax | 603 884-0120, Attention: OSSG Documentation, ZKO3-4/U08
Mail | OSSG Documentation Group, ZKO3-4/U08 110 Spit Brook Rd. Nashua, NH 03062-2698

# How To Order Additional Documentation

Use the following table to order additional documentation or information. If you need help deciding which documentation best meets your needs, call 800-DIGITAL (800-344-4825).

Location | Call | Fax | Write
--- | --- | --- | ---
U.S.A. | DECdirect 800-DIGITAL 800-344-4825 | Fax: 800-234-2298 | Digital Equipment Corporation Mailstop: TAY2-2/11D 153 Taylor Street Littleton, MA 01460
Puerto Rico | 787-781-0505 | Fax: 787-749-8300 | Local DIGITAL subsidiary
Canada | DTN: 621-6005 800-DIGITAL | Fax: 613-592-1946 | Digital Equipment of Canada, Ltd. Box 13000 Kanata, Ontario, Canada K2K2A6 Attn: CICC
International | --- | --- | Local DIGITAL subsidiary or approved distributor
Internal Orders | DTN: 261-2010 603-791-2010 | Fax: 800-741-6970 | U.S. Software Supply Business Digital Equipment Corporation 8 Cotton Road Nashua, NH 03063-1260

# Part I
Connecting to the Network

Part 1 provides the information you need to get started after installing and configuring DIGITAL TCP/IP Services for OpenVMS software.

Chapter 1 provides the following topics:

- A review of the post-configuration environment
- Making changes to the initial configuration
- Configuring DIGITAL TCP/IP Services for OpenVMS software on an OpenVMS Cluster
- Using the auxiliary server to start services and log events

Chapter 2 describes how to set up network interfaces.

Chapter 3 describes how to set up serial lines.

Chapter 4 describes how to configure and manage network routing.

# Chapter 1
Managing DIGITAL TCP/IP Services for OpenVMS

This chapter provides a brief review of information you need to get started with the DIGITAL TCP/IP Services for OpenVMS (UCX) software. Topics include:

- A review of the pertinent UCX databases, logical names, and other files
- How to make changes to your inital configuration then stop and restart UCX
- Enabling PATHWORKS support
- Creating user accounts and proxy identities
- Configuring UCX on an OpenVMS Cluster
- Starting services with the auxiliary server
- Memory management and how to obtain network activity statistics

# 1.1 Getting Started

This manual assumes you installed and configured DIGITAL TCP/IP Services for OpenVMS software with the UCX configuration procedure called UCX$CONFIG. This menu-driven procedure configures the software components you select or all of the UCX software components. The "out-of-the-box" defaults are designed to get your system up and running as an internet host with minimal effort.

UCX$CONFIG creates several database files described in Table 1-1

Table 1-1 UCX Databases
Database | File Name
--- | ---
BOOTP Database | SYS$COMMON:[SYSEXE]UCX$BOOTP.DAT
Configuration Database | SYS$COMMON:[SYSEXE]UCX$CONFIGURATION.DAT
Export Database | SYS$COMMON:[SYSEXE]UCX$EXPORT.DAT
Hosts Database | SYS$COMMON:[SYSEXE]UCX$HOST.DAT
Networks Database | SYS$COMMON:[SYSEXE]UCX$NETWORK.DAT
Proxy Database | SYS$COMMON:[SYSEXE]UCX$PROXY.DAT
Routes Database | SYS$COMMON:[SYSEXE]UCX$ROUTE.DAT
Services Database | SYS$COMMON:[SYSEXE]UCX$SERVICE.DAT
Printcap Database (used by LPR/LPD) | SYS$SPECIFIC:[UCX_LPD]UCX$PRINTCAP.DAT

## 1.1.1 How UCX Uses Logical Names

UCX provides logical names to customize or modify component behavior. Logical names also point to directories, database files, and log files.

UCX$CONFIG (a logical name that represents the UCX configuration procedure) defines the following logical names for the UCX databases listed in Table 1-1.

- UCX$BOOTP
- UCX$CONFIG
- UCX$EXPORT
- UCX$HOST
- UCX$NETWORK
- UCX$PROXY
- UCX$ROUTE
- UCX$SERVICE
- UCX$LPD

See individual component chapters in this manual for information on how specific components use logical names.

## 1.1.2 Modifying Your Configuration

After the initial configuration, you may want to reconfigure existing components or configure new ones; disable and re-enable components; add hosts; reconfigure routing; and so forth.

When making any configuration modifications, DIGITAL strongly recommends that you rerun the configuration procedure UCX$CONFIG¹.

In some instances, however, (for example, when configuring a BIND name server) UCX$CONFIG only partially configures a component. You may need to run additional setup programs or issue UCX management commands to complete the configuration and fine-tune your environment.

Component-specific chapters in this manual describe additional configuration tasks and explain how to configure and manage specific components. These tasks may include:

- Manually adding information, such as database records, that the configuration procedure cannot handle
- Temporarily enabling or disabling a service
- Configuring customized applications
- Tuning performance
- Troubleshooting problems

Throughout this manual, all commands are assumed to be UCX management commands. The few mentioned DCL commands are identified as such.

For a full description of the UCX management commands and a discussion of how to use them, see the DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual.

## 1.1.3 Saving Changes

The configuration procedure UCX$CONFIG saves configuration and initialization information in the file UCX$CONFIGURATION.DAT. You can modify the configuration database dynamically, or permanently, as follows:

- SET commands modify the software dynamically, as it is running. Changes made in this manner are not saved permanently and are overwritten if they differ from settings in the permanent configuration database.
- SET CONFIGURATION commands modify the permanent database but do not take effect until the next time UCX starts up.

In order to make changes take effect immediately and modify permanent settings, issue both the interactive SET and permanent SET CONFIGURATION commands.

The following commands permanently modify the configuration database:

- SET CONFIGURATION BIND
- SET CONFIGURATION COMMUNICATION
- SET CONFIGURATION ENABLE SERVICE
- SET CONFIGURATION DISABLE SERVICE
- SET CONFIGURATION INTERFACE
- SET CONFIGURATION NAME_SERVICE
- SET CONFIGURATION PROTOCOL
- SET CONFIGURATION SMTP
- SET CONFIGURATION SNMP
- SET CONFIGURATION START ROUTING
- SET CONFIGURATION STOP ROUTING
- SET CONFIGURATION TIME

## 1.1.4 Manually Starting and Stopping UCX

DIGITAL strongly recommends you use UCX$CONFIG to start and stop UCX software. If you need to start and stop the software manually, use the following commands:

To start UCX:

    $ @UCX$STARTUP

The startup procedure enables the configured services and initializes the configured network interfaces

To stop UCX:

    $ UCX$SHUTDOWN

The shutdown procedure:

1. Stops network communication
2. Disables active services
3. Deletes the network interface definitions
4. De-assigns defined logical names
5. Deletes installed images

## 1.1.5 Enabling PATHWORKS Support

DIGITAL TCP/IP Services for OpenVMS software includes the PATHWORKS Internet Protocol (PWIP) driver and the PATHWORKS network ancillary control process (ACP).

The PWIP driver makes possible communication between OpenVMS systems, running both PATHWORKS server and UCX software, and personal computers running PATHWORKS client software. It also enables the DECnet-over-TCP/IP feature included with the DECnet-Plus for OpenVMS Version 6.0 and later software. For more information, see the DECnet-Plus for OpenVMS documentation.

To start the PWIP driver, rerun UCX$CONFIG or issue the following command:

    $ @SYS$COMMON:[SYSMGR]UCX$PWIP_STARTUP.COM

To shut down the connection to PATHWORKS, type:

    $ @SYS$COMMON:[SYSMGR]UCX$PWIP_SHUTDOWN.COM

### Note

#### ¹ You cannot use UCX$CONFIG to set up SLIP or PPP lines. See Chapter 3 for more information.

# 1.2 Setting Up User Accounts and Proxy Identities

You will need to set up accounts for local users, coordinate the establishment of corresponding accounts on remote systems, and create accounts for remote users who will be accessing server components on the local host.

When creating accounts for remote users, you can create one account for all remote users, an account for groups of remote users, or accounts for individual users. The strategy you use depends on your organization, system resources, and security needs.

Certain UCX components (for example, LPD/LPR, RMT/RCD, and NFS) act as servers for remote clients. You control access to your system and to these services by giving remote users proxy identities. A proxy identity simply maps a user account on one host to an account on another host. The entries you make and the information you provide with each let you specifically grant or deny access to your system.

The configuration procedure UCX$CONFIG creates a proxy database file called UCX$PROXY. You add proxies to this database with the ADD PROXY command. UCX allows two types of proxies as follows:

- Communication proxy
  A communication proxy provides an identity for remote users of of RSH, RLOGIN, REXEC, RMT/RCD, and LPD/LPR. For each host, be sure to define the host name and any aliases. UCX treats proxy entries as case sensitive. Take care to use the appropriate case when adding entries for remote users. Use the ADD PROXY command as follows:

      UCX> ADD PROXY user /HOST=host /REMOTE_USER=user

  You may use wildcards when adding proxy entries for users on remote systems. For example, the command

      UCX> ADD PROXY STAFF  /HOST=STAR /REMOTE_USER=*

  provides the identity STAFF to any user on the remote host STAR.
- NFS proxy
  An NFS proxy provides an identity for users of NFS client, NFS server, and PC-NFS. In addition to host and user information, an NFS proxy provides a UNIX-style identity with a UID/GID pair. NFS proxies can also specify access to the NFS client, the NFS server, or both.
  For example, the command

      UCX> ADD PROXY CHESTER /NFS=OUTGOING /UID=23 /GID=34 /HOST="orbit"

  provides the OpenVMS identity CHESTER for a local NFS client user with the UID/GID pair 23/34. This user can access remote files from the NFS server orbit.

See the DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual for a complete description of the ADD PROXY command. For a more complete discussion about UNIX-style identities and how the NFS server and client use the proxy database, see Part 4 in this manual.

# 1.3 Configuring a TCP/IP Cluster

If your host is part of an OpenVMS Cluster, you can use a cluster alias to represent the entire cluster or selected host members. In such a case, the network sees the cluster as a single system with one name.

Incoming requests are switched among the cluster hosts at the end of each cluster time interval (specified with the SET COMMUNICATION command). The cluster name is not switched away from a host if there are any active TCP/IP connections to the cluster interface on that host.

A remote host can use the cluster alias to address the cluster as a single host or the host name of the cluster member to address a cluster member individually.

If more than one host in the cluster is running the NFS server, the cluster can appear to an NFS client as a single host. This configuration provides automatic failover.

## 1.3.1 Setting Up a TCP/IP Cluster

DIGITAL strongly recommends using the configuration procedure UCX$CONFIG to configure a TCP/IP cluster. If you cannot run UCX$CONFIG, configure a TCP/IP cluster by completing the following steps.

1. Create the interfaces for all cluster members.
2. Interactively specify a cluster alias (for example, ALLOFUS). Issue:

       UCX> SET INTERFACE QE0 /CLUSTER=ALLOFUS -
       _UCX> /C_NETWORK=255.255.0.0 /C_BROADCAST=128.44.55.0

3. Make these settings permanent in the configuration database. Issue:

       UCX> SET CONFIGURATION INTERFACE QE0 /CLUSTER=ALLOFUS -
       _UCX> /C_NETWORK=255.255.0.0 /C_BROADCAST=128.45.0.0

   The interface changes take effect the next time UCX starts up.
4. Add the cluster host name or the cluster IP address to the database of the host. Enter the same information you use with the SET INTERFACE command.
5. Change the interface parameters (specified with the SET INTERFACE command) only after deleting and re-creating an interface.
6. Set the cluster timer with the SET COMMUNICATION or SET CONFIGURATION COMMUNICATION command. For example:

       UCX> SET COMMUNICATION /CLUSTER_TIMER=30

7. Optionally, direct traffic to a specific host, by issuing:

       UCX> SET COMMUNICATION /CLUSTER_TIMER=0

   The host owns the cluster alias until you either bring down the system or delete the network interface.

# 1.4 Using the Auxiliary Server

The auxiliary server is the UCX implementation of the UNIX internet daemon (inetd). In addition to standard inetd functions, the auxiliary server provides access control and event logging.

The auxiliary server listens continuously for incoming requests and acts as a master server for programs specified in its configuration file. The auxiliary server reduces the load on the system by invoking services only as they are needed.

In addition to listening for and responding to requests, the auxiliary server provides access control and event logging.

## 1.4.1 How the Auxiliary Server Works

The auxiliary server listens for connections on the internet addresses of the services that its configuration file specifies. When a connection is found, it invokes the server daemon for the service requested. Once a server is finished, the auxiliary server continues to listen on the socket.

When it receives a request, the auxiliary server dynamically creates a network process, obtaining user account information from one or all of the following sources:

- UCX proxy account
- Services database
- Remote client
- Local OpenVMS User Authorization File (UAF)
  In addition, requesting users at the client can include their user account information as part of the command line.

Once a process is created, the auxiliary server starts the requested service. All services except RLOGIN and TELNET must have access to their default device and directories and to the command procedures within them.

You can provide additional access control by using your own customized security driver (see Appendix D).

## 1.4.2 Rejecting Client Requests

The auxiliary server rejects client requests for the following reasons:

- The maximum number of simultaneous processes for the requested service has been reached.
- The maximum number of simultaneous server processes for all the auxiliary server-controlled services systemwide has been reached.
- The request is from a host that is marked for rejection.

## 1.4.3 Configuring the Auxiliary Server

The post-installation configuration procedure, UCX$CONFIG, creates an entry in the services database for each service you configure. If you need to modify your initial configuration, simply rerun UCX$CONFIG or use individual UCX commands.

The configuration file UCX$SERVICE includes information about the service name, the socket and protocol type associated with the service, the user name under which the service should run, and any arguments to be passed to the service program.

Before you manually activate a service, configure the auxiliary server as follows:

1. Use $AUTHORIZE to create a user account, preferably a restricted account, for the process. Use the following qualifiers when creating the account.
   - /NOINTERACTIVE
   - /NOBATCH
   - /NOREMOTE
   - /FLAGS=(RESTRICTED,NODISUSER,NOCAPTIVE)
   For more information about creating restricted accounts, see the OpenVMS system security documentation.
2. Provide user account information that can be used when the network process is created. Carefully plan for your requirements before setting privileges, quotas, and priorities to user accounts.
   The auxiliary server uses the proxy database (UCX$PROXY.DAT) to obtain user account information. By default, the information in the proxy database is case-sensitive. To override this default, set the CASE_INSENSITIVE flag. You can set this flag for individual services or for all services.
3. Optionally, issue the SET SERVICE command to:
   - Define the syntax of the message that contains the user account information.
   - Specify your own protocols for a client and server to follow for transmitting user account information.
4. Provide the network process name.
   The auxiliary server builds the network process name from the character string in the services database. Specify this string with:

       UCX> SET SERVICE service /PROCESS_NAME=process

   > Note

   > For TELNET and RLOGIN, the process name is set by either the system or users.

5. Set the maximum number of server processes that can run simultaneously. (This step is part of managing system resources.)
   This number should not exceed the maximum number of sockets allowed on the system. Issue:

       UCX> SET COMMUNICATION /SERVICES=n

   You can also issue:

       UCX> SET CONFIGURATION COMMUNICATION /SERVICES

   The changes take effect the next time UCX starts up.
6. Check that the protections in the systemwide SYSLOGIN.COM file are set appropriately. If they are not, issue:

       $ SET PROTECTION=(W:RE) SYS$MANAGER:SYSLOGIN.COM

7. Enter the SHOW SERVICE command to ensure that the services database has an entry for each service you want to offer.

   ## 1.4.4 Enabling Services

   The services you configure are started during the UCX startup procedure. Afterwards, to initialize (enable) a service, issue:

       UCX> ENABLE SERVICE

       UCX> SET CONFIGURATION ENABLE SERVICE

   Next | Contents