HP OpenVMS Systems Documentation

The SMTP receiver process is made persistent so that it does not die after receiving each mail. Prior to Version 5.7, for each new mail, a new SMTP receiver process was created and it died after receiving the mail. Starting with Version 5.7, each receiver process services multiple incoming mails as configured.

1.2.6.1 Configurable parameters

Following are the configurable parameters used in SMTP persistent receiver:

• Persistent-Server: Enables the persistence of the SMTP receiver if set to ON. The default value is OFF.
• Loop-max: Specifies the maximum number of times the SMTP receiver must retry a connection. The default is no maximum (the same as setting this option to 0). This behavior requires the Persistent-Server option to be specified.
• Idle-Timeout: Specifies the time that the SMTP receiver waits for an incoming SMTP connection, in OpenVMS delta time format. The default is 5 minutes. This behavior requires the Persistent-Server option be specified.

HP TCP/IP Services for OpenVMS, Version 5.7 supports all the POP configurable fields through the TCPIP$POP.CONF file, except the POP tracing logical names.

The existing configuration based on logical names is obsolete. The POP rollover tool, TCPIP$POP_V57_ROLLOVER.EXE, can be used to upgrade the TCP/IP software to Version 5.7. Up on upgrade, the POP startup procedure will automatically change over to new ASCII file-based configuration method. It will create TCPIP$POP.CONF file in SYS$SYSDEVICE:[TCPIP$POP] directory. Up on successful rollover,
SYS$MANAGER:TCPIP$POP_V57_ROLLOVER.FLG will be created.

Include the appropriate POP configuration parameters in this file. The configuration template file, TCPIP$POP.CONF_TEMPLATE, contains the description of all the POP configurable parameters and its usage.

1.2.8 POP server support for external authentication

POP Server support for external authentication adds the capability to POP clients to authenticate an user on an OpenVMS system. The POP server uses the SYS$ACM system service that provides this capability.

OpenVMS Authentication and Credentials Management Extensions (ACME) subsystem provides the authentication services.

The new configuration parameter, No-SYSACM-User-Pass, is added to support the Username and Password authentication on the ACME agents. The ACME agents can be VMS native authentication extensions or any other Agents such as LDAP, which can authenticate the VMS user externally. When you configure the POP to make use of POP external authentication, you must ensure that the ACME agents are up and running.

No-SYSACM-User-Pass can be assigned with 0 or 1 as follows:

No-SYSACM-User-Pass: <Boolean Value>

Where: <Boolean Value> is either:

• 0 / FALSE: POP Server uses SYS$ACM system service for username and password authentication.
  OR
• 1 / TRUE : POP Server does not use SYS$ACM system service for username and password authentication.

By default, the No-SYSACM-User-Pass is set to TRUE, that is, the POP server is configured to use the native VMS authentication using SYS$GETUAI.

This chapter includes notes and changes made to the installation and configuration of TCP/IP Services, as well as startup and shutdown procedures. Use this chapter in conjunction with the HP TCP/IP Services for OpenVMS Installation and Configuration manual.

2.1 Installing Over V5.3 Early Adopter's Kits (EAKs)

If you have installed one or more of the following V5.3 EAKs, you must use the PCSI REMOVE command to remove the EAKs before you install TCP/IP Services V5.7:

• SSH for OpenVMS EAK
• failSAFE IP EAK

Upgrading from versions prior to V5.0 has not been qualified for this release.

2.3 Adding a system to an OpenVMS Cluster

The TCPIP$CONFIG.COM configuration procedure for TCP/IP Services Version 5.6 creates OpenVMS accounts using larger system parameter values than in previous versions. Only new accounts get these larger values. These values are useful on OpenVMS Alpha systems but essential on OpenVMS I64 systems.

To have your OpenVMS I64 system join an OpenVMS Cluster as a TCP/IP host, HP recommends adding the system to the cluster before you configure TCP/IP Services. The guidelines in Section 2.3.1 assume you have followed this recommendation.

If you configure TCP/IP Services before you add the system to a cluster, see Section 2.3.2.

2.3.1 Running a newly configured host on the Cluster

The following recommendations assume you are configuring TCP/IP Services on the system after having added the system to the OpenVMS Cluster.

If TCP/IP Services has previously been installed on the cluster and you encounter problems running a TCP/IP component on the system, modify the cluster System Authorization File (SYSUAF) to raise the parameter values for the account used by the affected component. The minimum recommended values are listed in Table 2-1.

The IMAP, DHCP, and XDM components can exhibit account parameter problems if the value assigned to PGFLQUOTA or to any of the other listed parameters is too low. Use the OpenVMS AUTHORIZE utility to modify SYSUAF parameters. For more information, see HP OpenVMS System Management Utilities Reference Manual: A-L.

2.3.2 Configuring TCP/IP Services before adding the system to the Cluster

If you configure TCP/IP Services before you add the system to a cluster, when you add the system to the cluster the owning UIC for each of the TCP/IP service SYS$LOGIN directories (TCPIP$service-name, where service-name is the name of the service) may be incorrect. Use the OpenVMS AUTHORIZE utility to correct these UICs.

2.3.3 Disabling or enabling SSH server

When you use the TCPIP$CONFIG.COM configuration procedure to disable or enable the SSH server, the following prompt is displayed:

* Create a new default Server host key? [YES]: 

Unless you have a specific reason for creating a new default server host key, you should enter "N" at this prompt. If you accept the default, clients with the old key will need to obtain the new key. For more information, see Section 3.15.6.

2.4 SSH configuration files must be updated

Note that this section refers to upgrades from a version prior to V5.4 ECO.

The SSH client and server on this version of TCP/IP Services cannot use configuration files from previous versions of SSH.

If the SSH client and server detect systemwide configuration files from an older version of SSH, the client and server will fail to start. The client will display the following warning message, and the server will write the following warning message to the SSH_RUN.LOG file:

You may have an old style configuration file. Please follow the 
instructions in the release notes to use the new configuration 
files. 

If the SSH client detects a user-specific configuration file from an older version of SSH, the SSH client will display the warning and will allow the user to proceed.

To preserve the modifications made to the SSH server configuration file and the SSH client configuration file, you must edit the templates provided with the new version of SSH, as follows:

1. Extract the template files using the following commands:

   $ LIBRARY/EXTRACT=SSH2_CONFIG SYS$LIBRARY:TCPIP$TEMPLATES.TLB - _$ /OUT=TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]SSH2_CONFIG. $ LIBRARY/EXTRACT=SSHD2_CONFIG SYS$LIBRARY:TCPIP$TEMPLATES.TLB - _$ /OUT=TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG.

   
   These commands copy the new template files into the SSH2 configuration directory with a new version number.
2. Copy the modifications made in the old versions of the configuration files to the new versions.
3. Start SSH using the following command:

   $ @SYS$STARTUP:SSH_STARTUP.COM $ @SYS$STARTUP:SSH_CLIENT_STARTUP.COM

If SMTP or LPD shutdown generates errors indicating that the queue manager is not running, check your site-specific shutdown command procedure (VMS_SYSHUTDOWN.COM). If this procedure contains the command to stop the queue manager (STOP/QUEUE/MANAGER), make sure this command is after the command that runs the TCPIP$SHUTDOWN.COM command procedure.

This chapter provides information about problems and restrictions in the current version of TCP/IP Services, and also includes other information specific to a particular command or service, such as changes in command syntax or messages.

3.1 IP Security

The IP Security (IPSec) feature that is included with this kit is not currently supported. HP recommends that you must not use IPSec in a production environment.

3.2 Dnssec_signzone utility may hang

The dnssec_signzone utility may hang when invoked from a foreign symbol. The utility will neither exhibit this behavior when it is executed from the command line using a foreign symbol or MCR, nor when the -r option is used to specify a source of entropy.

3.3 COPY /FTP restriction

COPY /FTP does not properly support ODS-5 filesystem files.

3.4 OpenVMS Mails

OpenVMS mails sent to a distribution list, to an invalid remote addresses does not get bounced. However, the mail to an invalid local address gets bounced.

3.5 Netstat utility

An IP address added to a tunnel interface cannot be seen with ifconfig. The new address cannot be seen unless you execute netstat -rn .

3.6 SMTP configured for cluster awareness

If SMTP is configured for cluster awareness, the disk on which the SMTP configuration files are saved must be mounted before the TCP/IP software is started. The system will hang up on TCP/IP startup, if the disk is not mounted.

3.7 Manually configuring an interface as DHCP leads to startup problems

Manually configuring an interface to be managed via DHCP may lead to an error, TCPIP-E-DEFINTE, when starting TCP/IP. This causes TCP/IP to not start properly. To work around this problem, shutdown TCP/IP, then on the interface that was manually configured as DHCP, issue the following command: $ tcpip set config inter ifname/PRIMARY Now restart TCP/IP.

3.8 SLIP restrictions

The serial line IP protocol (SLIP) is not supported in this release.

3.9 Advanced Programming Environment restrictions and guidelines

The header files provided in TCPIP$EXAMPLES are provided as part of the advanced TCP/IP programming environment. The following list describes restrictions and guidelines for using them:

• Use of the functions and data structures described in TCPIP$EXAMPLES:RESOLV.H is limited to 32-bit pointers. The underlying implementation will only handle 32-bit pointers. Previously, 64-bit pointers were wrongly accepted, resulting in undefined behavior for the underlying implementation.
• The IP.H and IP6.H header files are incomplete in the OpenVMS environment. They contain include directives for header files that are not provided in this version of TCP/IP Services. Refer to the HP TCP/IP Services for OpenVMS Sockets API and System Services Programming for more information.

BIND Version 9 has the following restrictions:

• Certain DNS server implementations do not support AAAA (IPv6 address) records. When queried for an AAAA (IPv6) record type by the BIND resolver, these name servers will return an NXDOMAIN status, even if an A (IPv4) record exists for the same domain name. These name servers should be returning NOERROR as the status for such a query. This problem can result in delays during host name resolution.
  BIND Version 9.3.1, which is supported with this release of TCP/IP Services, and prior versions of BIND do not exhibit this problem.
• Serving secure zones
  When acting as an authoritative name server, BIND Version 9 includes KEY, SIG, and NXT records in responses as specified in RFC 2535 when the request has the DO flag set in the query.
• Secure resolution
  Basic support for validation of DNSSEC signatures in responses has been implemented but should be considered experimental.
  When acting as a caching name server, BIND Version 9 is capable of performing basic DNSSEC validation of positive as well as nonexistence responses. You can enable this functionality by including a trusted-keys clause containing the top-level zone key of the DNSSEC tree in the configuration file.
  Validation of wildcard responses is not currently supported. In particular, a " name does not exist " response will validate successfully even if the server does not contain the NXT records to prove the nonexistence of a matching wildcard.
  Proof of insecure status for insecure zones delegated from secure zones works when the zones are completely insecure. Privately secured zones delegated from secure zones will not work in all cases, such as when the privately secured zone is served by the same server as an ancestor (but not parent) zone.
  Handling of the CD bit in queries is now fully implemented. Validation is not attempted for recursive queries if CD is set.
• Secure dynamic update
  Dynamic updating of secure zones has been partially implemented. Affected NXT and SIG records are updated by the server when an update occurs. Use the update-policy statement in the zone definition for advanced access control.
• Secure zone transfers
  BIND Version 9 does not implement the zone transfer security mechanisms of RFC 2535 because they are considered inferior to the use of TSIG or SIG(0) to ensure the integrity of zone transfers.
• SSL$LIBCRYPTO_SHR32.EXE requirement
  In this version of TCP/IP Services, the BIND Server and related utilities have been updated to use the OpenSSL shareable image SSL$LIBCRYPTO_SHR32.EXE. There is now a requirement that this shareable image from OpenSSL V1.2 or higher be installed on the system before starting the BIND Server. It must also be installed before using the following BIND utilities:

  BIND_CHECKCONF BIND_CHECKZONE DIG DNSSEC_KEYGEN DNSSEC_SIGNZONE HOST NSUPDATE RNDC_CONFGEN

The following sections describe restrictions in the use of IPv6.

3.11.1 Mobile IPv6 restrictions

Mobile IPv6 is not supported in this release.

3.11.2 IPv6 requires the BIND Resolver

If you are using IPv6, you must enable the BIND resolver. To enable the BIND resolver, use the TCPIP$CONFIG.COM command procedure. From the Core environment menu, select BIND Resolver.

You must specify the BIND server to enable the BIND resolver. If you do not have access to a BIND server, specify the node address 127.0.0.1 as your BIND server.

3.12 NFS restrictions

The following restrictions apply to the NFS server:

• When performing a mount operation or starting the NFS server with OPCOM enabled, the TCP/IP Services MOUNT server can erroneously display the following message:

  %TCPIP-E-NFS_BFSCAL, operation MOUNT_POINT failed on file /dev/dir

  
  This message appears even when the MOUNT or NFS startup has successfully completed. In the case of a mount operation, if it has actually succeeded, the following message will also be displayed:

  %TCPIP-S-NFS_MNTSUC, mounted file system /dev/dir

• If the NFS server and the NFS client are in different domains and unqualified host names are used in requests, the lock server (LOCKD) fails to honor the request and leaves the file unlocked.
  When the server attempts to look up a host using its unqualified host name (for example, johnws ) instead of the fully qualified host name (for example, johnws.abc com ), and the host is not in the same domain as the server, the request fails.
  To solve this type of problem, you can do one of the following:
  • When you configure the NFS client, specify the fully qualified host name, including the domain name. This ensures that translation will succeed.
  • Add an entry to the NFS server's hosts database for the client's unqualified host name. Only that NFS server will be able to translate this host name. This solution will not work if the client obtains its address dynamically from DHCP.

• If the OpenVMS NFS client is executing the MOUNT commands from the script in a non-sequential manner, a wrong unit number is returned causing the NFS exported directory to mount on a wrong device number because of the timing issue.
  For example, the following mount command makes NFS to be mounted on DNFS8 instead of the requested device DNFS4.

  $ TCPIP MOUNT DNFS4:[<directory>]/HOST=<host-name> /PATH=<path-name>/SUPER/PROCESSOR=UNIQUE

  Workaround
  
  Execute the mount commands such that the device numbers are sequential.
  For example, instead of the following set of commands:

  $ TCPIP MOUNT DNFS3:[<directory>]/HOST=<host-name> /PATH=<path-name>/SUPER/PROCESSOR=UNIQUE $ TCPIP MOUNT DNFS2:[<directory>]/HOST=<host-name> /PATH=<path-name>/SUPER/PROCESSOR=UNIQUE $ TCPIP MOUNT DNFS1:[<directory>]/HOST=<host-name> /PATH=<path-name>/SUPER/PROCESSOR=UNIQUE

  
  Change the sequence as follows:

  $ TCPIP MOUNT DNFS1:[<directory>]/HOST=<host-name> /PATH=<path-name>/SUPER/PROCESSOR=UNIQUE $ TCPIP MOUNT DNFS2:[<directory>]/HOST=<host-name> /PATH=<path-name>/SUPER/PROCESSOR=UNIQUE $ TCPIP MOUNT DNFS3:[<directory>]/HOST=<host-name> /PATH=<path-name>/SUPER/PROCESSOR=UNIQUE

• SYMLINKs fail to work for NFS client disks.
• To get proper timestamps, when the system time is changed for daylight savings time (DST), dismount all DNFS devices. (The TCP/IP management command SHOW MOUNT should show zero mounted devices.) Then remount the devices.
• The NFS client does not properly handle file names with the semicolon character on ODS-5 disk volumes. (For example, a^;b.dat;5 is a valid file name.) Such file names are truncated at the semicolon.
• The NFS client included with TCP/IP Services uses the NFS Version 2 protocol only.
• With the NFS Version 2 protocol, the value of the file size is limited to 32 bits.
• The ISO Latin-1 character set is supported. The UCS-2 characters are not supported.
• File names, including file extensions, can be no more than 236 characters long.
• Files containing characters not accepted by ODS-5 on the active OpenVMS version or whose name and extension exceeds 236 characters are truncated to zero length. This makes them invisible to OpenVMS and is consistent with prior OpenVMS NFS client behavior.

The NTP server has a stratum limit of 15. The server does not synchronize to any time server that reports a stratum of 15 or greater. This may cause problems if you try to synchronize to a server running the UCX NTP server, if that server has been designated as "free running" (with the local-master command). For proper operation, the local-master designation must be specified with a stratum no greater than 14.