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

The PWIP driver makes possible communication between OpenVMS systems running both PATHWORKS server and TCP/IP Services software, and personal computers running PATHWORKS client software. It also enables the DECnet-over-TCP/IP feature which is 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 TCPIP$CONFIG or enter the following command:

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

To shut down the connection to the PWIP driver, enter:

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

1.3 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 product 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 maps a user account on one host to an account on another host. The information you provide with each entry, along with the privileges you set for the account, let you specifically grant or deny access to your system.

The configuration procedure TCPIP$CONFIG creates a proxy database file called TCPIP$PROXY. You add proxies to this database with the ADD PROXY command. The TCP/IP Services product allows two types of proxies:

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

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

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

  TCPIP> 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

  TCPIP> 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.4 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 this 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 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.

Compaq strongly recommends using the configuration procedure TCPIP$CONFIG to configure a TCP/IP cluster. If you cannot run TCPIP$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). Enter:

   TCPIP> SET INTERFACE QE0 /CLUSTER=ALLOFUS - _TCPIP> /C_NETWORK=255.255.0.0 /C_BROADCAST=128.44.55.0

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

   TCPIP> SET CONFIGURATION INTERFACE QE0 /CLUSTER=ALLOFUS - _TCPIP> /C_NETWORK=255.255.0.0 /C_BROADCAST=128.45.0.0

   
   The interface changes take effect the next time the product 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, enter:

   TCPIP> SET COMMUNICATION /CLUSTER_TIMER=30

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

   TCPIP> SET COMMUNICATION /CLUSTER_TIMER=0

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

The auxiliary server is the TCP/IP Services 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.5.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:

• TCP/IP Services proxy account
• Services database
• Remote client
• Local OpenVMS User Authorization File (UAF)
  In addition, users requesting services 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.

1.5.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.

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

The configuration file TCPIP$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 your requirements before setting privileges, quotas, and priorities to user accounts.
   The auxiliary server uses the proxy database (TCPIP$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, enter 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. Enter this string with the SET SERVICE command:

   TCPIP> 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. Enter:

   TCPIP> SET COMMUNICATION /SERVICES=n

   
   You can also enter:

   TCPIP> SET CONFIGURATION COMMUNICATION /SERVICES

   
   The changes take effect the next time the product starts up.

6. Check that the protections in the systemwide SYSLOGIN.COM file are set appropriately. If they are not, enter:

   $ 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.

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

TCPIP> ENABLE SERVICE TCPIP> SET CONFIGURATION ENABLE SERVICE

The first command immediately changes the running system. The second causes the services to be enabled the next time the product starts up. Before transferring data, a client and a server initialize several communication operations. Initialization is determined by the socket type and activation flags set in the services database. Table 1-2 describes the communication initialization process.

Table 1-2 Communication Initialization Variables

Variable	Option	Description
Socket type	STREAM	When initializing data communications for a STREAM socket, the server listens on a socket for a connection request. When a connection request is accepted, the new socket (which results from accepting the connection) is made available for network data transfer.
	DATAGRAM	This is a connectionless socket. No particular operation is required at initialization before data transfer. Therefore, an incoming datagram can be read directly, once the server socket exists and its characteristics are defined.
Activation flags	LISTEN	The flag is set with the /FLAGS qualifier of the SET SERVICE command. The auxiliary server starts the network process after data communication initialization. The server is able to start data communication directly on a socket that is passed at the logical name SYS$NET without any additional operations (other than $ASSIGN or a DEC C socket call). There is no need for communication initializations (connect, listen, or accept). This allows servers developed on UNIX to be ported with minimal effort. Also, multiple copies of a single-threaded server can run without any modification, allowing parallel processing of multiple requests.
	NOLISTEN	The auxiliary server creates a network process and starts the requested services after receiving a network request. The TCP/IP Services product does not initialize data communication. Therefore, the server for the requested service must initialize its own data communication. If a server is started with the NOLISTEN activation flag, it can listen for more service requests and process them as soon as they come. Use this function to terminate a server started with the NOLISTEN activation flag. Specify the idle time with the /INACTIVITY_TIMER qualifier of the SET SERVICE command. Note: This flag is reserved. Use it only under the guidance of your Compaq support representative.

The auxiliary server does not transfer data. Therefore, the auxiliary server can set socket options for a requested service either before or during data communications. Some available options are:

• KEEPALIVE and LINGER for TCP communications
• BROADCAST for UDP communications

You can also specify socket options for a requested service in the services database. These socket options are set before the new socket is passed to the requested server.

1.5.5 Setting Up Event Logging

Event logging can help you manage the software. By default, services do not log events, but you can enable event logging for all or selected configured services. You can configure the product to log events to the operator's console, a log file, or both. To set up event logging, enter the following commands:

• To specify event logging for one service, enter:
  SET SERVICE service /LOG_OPTIONS=(FILE=file,options)
  This configuration is overridden by the values set with the /FORCE_LOG_OPTIONS qualifier of the SET COMMUNICATION and SET CONFIGURATION COMMUNICATION commands.
• To interactively set event logging affecting all the services, enter:
  • SET COMMUNICATION /ALLOW_LOG_OPTIONS=options
    Provides an alternate way to capture logging that you did not set up with the SET SERVICE service /LOG command. Specifies options that, when set, apply to all the services.
  • SET COMMUNICATION /FORCE_LOG_OPTIONS=options
    /FORCE_LOG_OPTIONS overrides the settings of the SET SERVICE /LOG_OPTIONS command.
• To permanently set event logging affecting all the services, enter:
  • SET CONFIGURATION COMMUNICATION /ALLOW_LOG_OPTIONS=options
    Same options as SET COMMUNICATION /ALLOW_LOG_OPTIONS
  • SET CONFIGURATION COMMUNICATION /FORCE_LOG_OPTIONS=options
    Same options as SET COMMUNICATION /FORCE_LOG_OPTIONS

For a list of all the logging options, see the SET SERVICE command description in the DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual.

Some product components provide additional event logging capabilities. See individual component chapters for more information.