HP OpenVMS Systems Documentation

With profiling enabled, you can compare performance data of when PPE is enabled and disabled. Assuming that you have a test that sufficiently saturates the TCP/IP CPU, complete the following steps to produce data sets that can be easily compared:

1. Enable profiling
   Profiling must be enabled while gathering statistics only. To enable profiling, execute the following:

   $ SYSCONFIG -r INET PROFILING=1

2. Ensure that PPE is disabled by executing the following:

   $ SYSCONFIG -r INET PPE_ENABLE=0

3. Run the stress test and monitor the performance as follows:
   • Using the MONITOR utility
     If the MONITOR utility shows that the TCP/IP CPU is not approaching saturation, enabling PPE will not yield any advantage.

     $ MONITOR MODES/CPU=xx ! xx = TCP/IP CPU

   • Using the TCPMON utility
     Capture the fine-granularity statistics and write them to a comma-separated value (CSV) file as well as display them on to the terminal. The CSV file can later be graphically analyzed using external programs, such as TLViz (from TDC) or a spreadsheet program.

     $ TCPMON /CSV=PPE_COMPARISON.CSV /DISPLAY [/SHOW=INET]

   • Run the Performance Data Collector (TDC)
     TDC provides the complete data set, which provides a whole-system view of performance.
     For more information about TDC, see the Web site at:

     http://h71000.www7.hp.com/openvms/products/tdc/index.html

4. Dynamically enabling PPE
   After collecting sufficient data with PPE disabled, dynamically enable PPE. There is no need to interrupt the data collection methods described in step 3.

   $ SYSCONFIG -r INET PPE_ENABLE=1

5. Comparing the data
   After gathering sufficient data with PPE disabled and enabled, compare the performance characteristics for the given test load. Stop the data collection and examine the data set.
6. Disable profiling
   There is a small overhead associated with profiling. So, it is recommended to disable profiling when statistics is not gathered.

   $ SYSCONFIG -r INET PROFILING=0

FTP Anonymous Light can be used for restricting user access to a particular set of directories. A system administrator who wants to restrict an OpenVMS user's FTP access to a particular set of directories must set the TCPIP$FTP_ANONYMOUS_LIGHT parameter for that user.

Setting this parameter restricts the FTP operations for the user to a set of directories indicted by TCPIP$FTP_ANONYMOUS_DIRECTORIES. The TCPIP$FTP_ANONYMOUS_LIGHT can be defined in LOGIN.COM.

To restrict the FTP access for all users, the parameter must be defined using a system-wide logical. FTP Anonymous Light users must specify the correct password to log in. By default, when an anonymous user is prompted for the identity, any password is accepted. Optionally, the system administrator can also set TCPIP$FTP_ANONYMOUS_WELCOME to display a message upon successful login.

The following example illustrates how FTP Anonymous Light works:

 
"TCPIP$FTP_ANONYMOUS_DIRECTORY" = "TCPIP$ENETINFO1:[UCX]" 
= "TCPIP$ENETINFO1:[UCX_AXP]" 
= "TCPIP$ECO:" 
= "TCPIP$PATCH:" 
= "COMMON_SYSDISK:[FAL$SERVER]" 
= "TCPIP$INTERNAL:" 
"TCPIP$FTP_ANONYMOUS_LIGHT" = "1" 
"TCPIP$FTP_ANONYMOUS_LOG" = "SYS$LOGIN:TCPIP$FTP_ANONYMOUS.LOG" 
"TCPIP$FTP_ANONYMOUS_WELCOME" = "FTP Anonymous Light demo" 
 
 
ftp plane.tcpip.zko.hp.com 
220 plane.tcpip.zko.hp.com FTP Server (Version 5.6) Ready. 
Connected to plane.zko.hp.com. 
Name (plane.zko.hp.com:test): 
331 Username test requires a Password 
Password: 
230-FTP Anonymous Light demo 
230 Guest login OK, access restrictions apply. 
FTP> cd sys$system 
550 insufficient privilege or file protection violation  (1)
 
FTP> cd tcpip$eco 
250-CWD command successful. 
250 New default directory is TCPIP$ENETINFO1:[TCPIP$ENGINEERING_CHANGE_ORDERS](2)
 
 
FTP> cd sys$login 
250-CWD command successful. 
250 New default directory is WORK4$:[TEST] 
FTP> bye 
221 Goodbye. 

An output similar to the following is saved in the log file:

20-JUN-2008 05:21:45.64 Anonymous Light User:test from Host:16.116.92.100 
20-JUN-2008 05:22:39.61 Anonymous Light User:test status:00010001 
                        CWD dir:TCPIP$ENETINFO1:[TCPIP$ENGINEERING_CHANGE_ORDERS] 
20-JUN-2008 05:23:13.49 Anonymous Light User:test status:00010001 
                        CWD dir:WORK4$:[TEST] 
20-JUN-2008 05:23:19.15 Anonymous Light User:test status:00000000 
                        RETR file:WORK4$:[TEST]A.TXT;30 
20-JUN-2008 05:23:26.07 Anonymous Light User:test logged out 

Although the system administrator does not specify the directory, SYS$LOGIN is always added to TCPIP$FTP_ANONYMOUS_DIRECTORY. As a result, the Anonymous Light users will always have access to their SYS$LOGIN.

At some instances, the system administrator may not want the user to access their SYS$LOGIN. To prevent the user from accessing the SYS$LOGIN, the system administrator must define TCPIP$FTP_ANONYMOUS_NOSYSLOGIN for that particular user. This parameter is useful when a user has changed the directory in LOGIN.COM and when the system administrator does not want to grant access to SYS$LOGIN.

1.1.2.1 Access restrictions for FTP operations

The FTP Anonymous Light feature restricts user access to a particular set of directories. To increase the system administrator's flexibility, a new set of parameters can be defined to restrict user operations.

The FTP server checks for the existence of the following four parameters:

• TCPIP$FTPD_NOLIST - LIST and NLST commands
• TCPIP$FTPD_NOREAD - RETR commands
• TCPIP$FTPD_NOWRITE - STOR, STOU, APPE, RNFR, RNTO, DELE, MKD, and RMD commands
• TCPIP$FTPD_NODELETE - DELE and RMD commands

If the parameter is defined, the FTP server will reject all.

These new access restrictions are applicable in addition to any restrictions implied by the protections of the underlying files, directories, volumes, and devices.

If TCPIP$FTPD_NOLIST is defined, the usage of wildcards is not allowed in FTP operations. This is necessary to prevent FTP users from obtaining a list of the files in the directory by attempting to retrieve or delete all the files. Table 1-2 lists the FTP restriction logicals that are used to control their operation:

For example, if the System Administrator does not want a user to delete files through FTP, set TCPIP$FTPD_NODELETE for that user.

The following example illustrates how to set the TCPIP$FTPD_NODELETE and TCPIP$FTPD_NOLIST:

"TCPIP$FTPD_NODELETE" = "1" 
"TCPIP$FTPD_NOLIST" = "1" 
 
$ ftp plane.tcpip.zko.hp.com 
220 plane.tcpip.zko.hp.com FTP Server (Version 5.6) Ready. 
Connected to plane.zko.hp.com. 
Name (plane.zko.hp.com:test): test 
331 Username test requires a Password 
Password: 
230-FTP Anonymous Light demo 
230 Guest login OK, access restrictions apply. 
FTP> directory * 
200 PORT command successful. 
550 Cannot execute LIST command, Access denied. (1)
 
%TCPIP-E-FTP_NOSUCHFILE, no such file * 
FTP> delete a.txt 
550 Cannot execute DEL command, Access denied.(2)
 
FTP> bye 
221 Goodbye. 

FTP restriction logicals can be used in conjunction with FTP Anonymous Light to restrict user access through FTP, helping to mitigate a risk to the system that has been problematic for system administrators.

1.2 Enhancements

With support for IP as the cluster interconnect (IPCI), Interface Configuration Menu now supports the following:

• Management of interfaces and addresses on another cluster member that shares the same TCPIP$CONFIGURATION database.
• Addresses that can be configured for use with IPCI.

Assuming that the cluster members share the same TCPIP$CONFIGURATION database, each cluster member can be configured from the same console. This only affects the TCPIP$CONFIGURATON database; it is not possible to manage the active addresses on a remote cluster member.

An output similar to the following is displayed for the TCPIP$CONFIG Interface * Address Configuration menu from one of the node in a cluster:

              HP TCP/IP Services for OpenVMS Interface & Address Configuration Menu 
 
 Hostname Details: Configured=kirra-g0, Active=kirra-g0 
 
 Configuration options: 
 
   0  -  Set The Target Node (Current Node: KIRRA) 
   1  -  IE0 Menu (EIA0: TwistedPair 1000mbps) 
   2  -  19.176.56.100/23    kirra-g0              Configured,Active 
   3  -  19.176.56.101/23    kirra-g1              Configured,Active-Standby 
   4  -  19.176.57.100/23    hogwarts-nfs          Configured,Active-Standby 
   5  -  19.176.56.25/23     ns1                   Configured,Active-Standby 
   6  -  IE1 Menu (EIB0: TwistedPair 1000mbps) 
   7  -  19.176.56.101/23    kirra-g1              Configured,Active 
   8  -  19.176.56.100/23    kirra-g0              Configured,Active-Standby 
   9  -  19.176.57.100/23    hogwarts-nfs          Configured,Active-Standby 
  10  -  19.176.56.25/23     ns1                   Configured,Active-Standby 
   I  -  Information about your configuration 
  [E] -  Exit menu 
 
Enter configuration option: 0 (1)
Enter name of node to manage [KIRRA]: GRYFFI (2)
Enter system device for GRYFFI [$1$DGA62:]: (3)
Enter system root for GRYFFI [SYS0]: (4)
 
      HP TCP/IP Services for OpenVMS Interface & Address Configuration Menu 
 
 Hostname Details: Configured=gryffindor-e0 
 
 Configuration options: 
 
   0  -  Set The Target Node (Current Node: GRYFFI - $1$DGA62:[SYS0.]) 
   1  -  IE0 Menu (EIA0: TwistedPair 100mbps) 
   2  -  19.176.56.65/23     gryffindor-e0         Configured 
   3  -  19.176.56.81/23     gryffindor-e1         Configured 
   4  -  19.176.57.100/23    hogwarts-nfs          Configured 
   5  -  19.176.56.25/23     ns1                   Configured 
   6  -  IE1 Menu (EIB0: TwistedPair 100mbps) 
   7  -  19.176.56.81/23     gryffindor-e1         Configured 
   8  -  19.176.56.65/23     gryffindor-e0         Configured 
   9  -  19.176.57.100/23    hogwarts-nfs          Configured 
  10  -  19.176.56.25/23     ns1                   Configured 
   I  -  Information about your configuration 
  [E] -  Exit menu 
 
Enter configuration option:

LPR/LPD provided by TCP/IP services for OpenVMS 5.6 and prior versions connects directly to port 515 on a remote server and sends the data as specified in the RFC 1179. With TCP/IP services for OpenVMS 5.7, this remote port is made configurable. A system manager can choose any ephemeral port.

1.2.2.1 Configuring the remote port

In the printcap file, TCPIP$PRINTCAP.DAT, for each printer entry, a new field, rt is added, which can be used to configure remote port.

For example:

LOOP_BOGUS_P_1|loop_bogus_p_1:\
                      :lf=/TCPIP$LPD_ROOT/000000/LOOP_BOGUS_P_1.LOG:\
 :lp=LOOP_BOGUS_P_1:\
                :rm=qtvtcp.digitalindiasw.net:\
                :rp=bogus_p_1:\
                :rt#2333:\
               :sd=/TCPIP$LPD_ROOT/LOOP_BOGUS_P_1: 

Using the rt field in the printer entry in TCPIP$PRINTCAP.DAT, the LPD jobs is sent over an SSH encrypted tunnel. You can configure SSH port forwarding to establish a tunnel from port (rt) on a system to an LPD receiver port (default is 515 or any other port on which LPD service is configured manually) on another system where the LPD receiver is listening. For sample LPD/LPR configurations, see Appendix A.

1.2.3 FTP over SSL

The Transport Layer Security/Secure Socket Layer (TLS/SSL) feature enables the FTP software to use the security features provided by SSL. When this feature is enabled, FTP provides a secured FTP session and a secure file transfer. FTP over SSL is compliant with RFC 4217 and RFC 2228.

1.2.3.1 Configuring an FTP server for SSL

To configure an FTP server and to allow the FTP server to handle incoming client connections which are over SSL, the certificates and keys must be copied at the following location:

Certificate file : SSL$CERTS:SERVER.CRT 
Key file: SSL$KEYS:SERVER.KEY 

The key and certificate file of the server must be placed in this directory and must be named as SERVER.CRT and SERVER.KEY. During the FTP server startup, if it does not find either the key or the certificate file in the required location, the FTP server will not support SSL.

1.2.3.2 Using FTP client in an SSL environment

You can use FTP over SSL to connect to the server by invoking the client using the following commands:

 
$FTP /SSL <server> 
 

Or

 
$FTP 
FTP> CONNECT /SSL <server> 
 

If you connect to the server using the /SSL qualifier, both the control and data connection use SSL by default. By default, the PROT P command is sent by the client to the server indicating that the data connection will use SSL.

If you want the data connection communication to happen in clear text, you can issue the PROT C command on the FTP client CLI.

ftp> PROT C 

The OpenVMS FTP client and server also supports the Clear Command Channel (CCC) mode of operation. The CCC mode can be used in NAT environments that need a clear command channel to setup NAT for FTP/SSL. An FTP Client issues the CCC command to indicate to the server that the command channel must not be encrypted. Note that the data channel will remain encrypted. As a result, the file transfer will continue to be secured by SSL.

For example, if you want the control connection to not be encrypted, execute the CCC command at the FTP client CLI:

ftp> CCC 

If you want to use the copy operation in FTP, COPY/FTP , the syntax is as follows:

copy /ftp/ssl=(data,ccc) <src system>   <dst system>

If you do not want the data connection to be encrypted, specify NODATA in the preceding command instead of DATA.

If you want CCC (by default), specify CCC , else specify NOCCC .

1.2.3.3 Considerations during configuration

• If the server does not find the SEREVER.CRT and SERVER.KEY, the server will not accept the AUTH TLS command. However, the server will continue to accept regular FTP connections.
  An SSL enabled client will still be able to connect to non-SSL enabled server and displays the following message:

  AUTH command will fail, session will continue in plain text.

• A non-SSL enabled client will be able to login to SSL enabled server.

SMTP provided by TCP/IP Services for OpenVMS is cluster aware. It exploits the high availability and load balancing features of a cluster. The name of the generic queue is now TCPIP$SMTP, without the node name as the suffix. This is a common SMTP generic queue for all nodes in the cluster.

1.2.4.1 Configuration

The following configurable parameters can be found in the TCPIP$SMTP.CONF file:

• Number-Of-Queues-Per-Node: Specifies the number of execution SMTP queues created on each node of a cluster. The default value is 1. The execution queue will have the name format as follows:

  TCPIP$SMTP_<emphasis>(<nodename>_<n>)

• Queue-name: Specifies the name of generic SMTP queue. The default is TCPIP$SMTP.

TCPIP$SMTP.CONF can also be used to configure the trace and debug parameters, but the precedence will be changed.

The existing configuration based on logical names and TCPIP> SET CONFIGURATION SMTP is obsolete. The SMTP rollover tool, TCPIP$SMTP_V57_ROLLOVER.EXE, can be used to upgrade the TCP/IP software to Version 5.7. Up on upgrade, the SMTP startup procedure will automatically change over to new ASCII file based configuration method. It creates the TCPIP$SMTP.CONF file in the TCPIP$SMTP_COMMON directory. Up on successful rollover, SYS$MANAGER:TCPIP$SMTP_V57_ROLLOVER.FLG is created.

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