HP OpenVMS Systems Documentation

By default, the FTP server creates several log files you can use to monitor the service and user transactions. These log files are:

• SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_RUN.LOG
  This log file contains an abbreviated dialog of each new connection process. It is created by each new invocation of the server and is accessible only after an ongoing connection times out or after being closed by the user.
• SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_ANONYMOUS.LOG
  This log file contains Anonymous FTP entries that show:
  • The user name and source host (FTP client) for the session
  • The time the session was initiated and terminated
  • The FTP command that was entered
  • A time notation for the command
  • The source and destination file names
• SYS$LOGIN:TCPIP$FTP_SERVER.LOG
  This log file is created in the user's default login directory. It records session information, requests, and responses. To initiate the creation of this log file, the user can define the TCPIP$FTP_LOG_CLIENT_ACTIVITY logical name. To ensure that all users' FTP activity is being logged, define this logical systemwide, as described in Section 16.1.4.

The number of log files (one per FTP session) might become large. To limit the number of versions, enter:

$ SET FILE file /VERSION=n

You can improve FTP performance for users who transfer large files from systems that are not running TCP/IP Services to a host running the TCP/IP Services software.

16.2.1 Performance

Large file transfers can affect file transfer performance. A file transfer consists of the following events:

1. FTP calls RMS to create the file.
2. RMS creates the file with the system's default for number of blocks to be allocated (FTP_FILE_ALQ value).
3. If the file being copied is larger than the space originally allocated, RMS extends the space by adding blocks of memory space.
4. The number of extension blocks is determined by the system's RMS default extension quantity (FTP_FILE_DEQ value). For more information about RMS, refer to the OpenVMS Record Management Services Reference Manual.

Performance is affected by the RMS overhead taken up by the file extension process. One way to improve performance is to reset the appropriate parameters. To do this, redefine the FTP logical names that:

• Reset buffer sizes
• Preallocate disk blocks
• Increase the inactivity timer

These logical names are described in the following sections.

16.2.1.1 Buffer Sizes

Changing the window size of the send and receive buffers can improve network performance. To set or modify the window size, define or redefine the logical name TCPIP$FTP_WNDSIZ.

• For a systemwide change, redefine this logical name in the system table.
  Edit the SYS$MANAGER:TCPIP$SERVICES_SETUP file to add this line:

  $ DEFINE /SYSTEM /EXEC TCPIP$FTP_WNDSIZ 4096

• For the change to apply to one user, define the logical name in the LOGIN.COM file in the default directory of that user.

For noisy lines, such as modems, you should set the value of the TCPIP$FTP_WNDSIZ parameter to a lower number.

16.2.1.2 File Allocation and Extension Sizes

FTP logical names preallocate disk blocks. FTP tells RMS to truncate unused blocks so that disk space is not wasted. This can affect RMS performance.

To reduce the RMS overhead, use the following logical names:

• TCPIP$FTP_FILE_ALQ --- Modifies the allocation quantity.
  Specifies the number of blocks to be allocated to a disk file when it is created. For example:

  $ DEFINE /SYSTEM/EXEC TCPIP$FTP_FILE_ALQ 50000

• TCPIP$FTP_FILE_DEQ --- Default extension quantity.
  Specifies the number of blocks to be added when RMS automatically extends the file. For example,

  $ DEFINE TCPIP$FTP_FILE_DEQ 100

Define these logicals in the TCPIP$SYSTARTUP.COM procedure, or in the SYS$MANAGER:STARTUP_VMS.COM file before the command that starts TCP/IP Services. Because disk quotas may control the system, these logical names are defined by default as zero (system RMS defaults) or are undefined. For file transfers between hosts that both use VMS Plus mode, these logical names have no effect.

16.2.1.3 Inactivity Timer

The larger the inactivity timer value, the longer FTP maintains sessions without timing out. Excessive inactive sessions might slow down performance, degrade security, or prevent other users from establishing sessions.

To increase the inactivity timer, change the value of the TCPIP$FTPD_IDLETIMEOUT logical name. The default is 15 minutes. For example:

$ DEFINE TCPIP$FTPD_IDLETIMEOUT 01:00:00

The TCP/IP Services software includes client and server implementations of the Berkeley Remote (R) command applications: RCP, RLOGIN, RSH, REXEC, and RMT/RCD. These applications provide end users with the following capabilities:

This chapter reviews key concepts and describes:

• How to manage the R command servers ( Section 17.2)
• Security considerations ( Section 17.3)
• How to create a welcome message ( Section 17.4)
• How the Remote Magnetic Tape/Remote CD-ROM (RMT/RCD) service operates ( Section 17.5)

For information about using these applications, see the HP TCP/IP Services for OpenVMS User's Guide.

17.1 Key Concepts

In addition to password authentication, the R commands use a system based on trusted hosts and users. Trusted users on trusted hosts are allowed to access the local system without providing a password. Trusted hosts are also called "equivalent hosts" because the software assumes that users given access to a remote host should be given equivalent access to the local host. The system assumes that user accounts with the same name on both hosts are "owned" by the same user. For example, the user logged in as molly on a trusted system is granted the same access as a user logged in as molly on the local system.

This authentication system requires databases that define the trusted hosts and the trusted users. On UNIX systems, these databases include:

• /etc/hosts.equiv
  This file defines the trusted hosts and users for the entire system.
• .rhosts
  This file defines the trusted hosts and users for an individual user account. This file is located in the user's home directory.

On OpenVMS hosts, the proxy database TCPIP$PROXY.DAT defines trusted hosts and users for the entire system.

17.2 Managing the R Command Servers

The following sections describe the command procedures and logical names used in managing the R command servers.

17.2.1 R Command Server Startup and Shutdown

Each R command server can be shut down and started independently. This is useful when you change parameters or logical names that require the service to be restarted.

The following files allow you to start up each R command server independently:

• SYS$STARTUP:TCPIP$REXEC_STARTUP.COM
• SYS$STARTUP:TCPIP$RMT_STARTUP.COM
• SYS$STARTUP:TCPIP$RSH_STARTUP.COM
• SYS$STARTUP:TCPIP$RLOGIN_STARTUP.COM

The following files allow you to shut down the each R command server independently:

• SYS$STARTUP:TCPIP$REXEC_SHUTDOWN.COM
• SYS$STARTUP:TCPIP$RMT_SHUTDOWN.COM
• SYS$STARTUP:TCPIP$RSH_SHUTDOWN.COM
• SYS$STARTUP:TCPIP$RLOGIN_SHUTDOWN.COM

To preserve site-specific parameter settings and commands to be executed when the R server starts up, create one of the following files, as appropriate. These files are not overwritten when you reinstall TCP/IP Services:

• SYS$STARTUP:TCPIP$REXEC_SYSTARTUP.COM
• SYS$STARTUP:TCPIP$RMT_SYSTARTUP.COM
• SYS$STARTUP:TCPIP$RSH_SYSTARTUP.COM
• SYS$STARTUP:TCPIP$RLOGIN_SYSTARTUP.COM

To preserve site-specific parameter settings and commands to be executed when the R server shuts down, create one of the following files, as appropriate. These files are not overwritten when you reinstall TCP/IP Services:

• SYS$STARTUP:TCPIP$REXEC_SYSHUTDOWN.COM
• SYS$STARTUP:TCPIP$RMT_SYSHUTDOWN.COM
• SYS$STARTUP:TCPIP$RSH_SYSHUTDOWN.COM
• SYS$STARTUP:TCPIP$RLOGIN_SYSHUTDOWN.COM

Table 17-1 lists the logical names you can use for managing the RLOGIN service.

Because R commands can bypass normal password verification, it is important to configure these applications carefully to avoid compromising system security. In a complex networking environment, improperly configured R commands can open access to your host to virtually anyone on the network.

A properly configured environment grants remote access to preauthorized clients. You can limit access by adding an entry to the proxy database (TCPIP$PROXY.DAT) for each user authorized to access your host. This entry, called a communication proxy, provides the user name and name of the remote host. To add a communication proxy, enter:

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

For each host, be sure to define the host name and any aliases.

Users with communication proxies cannot use virtual terminals. Therefore, if the logical name TCPIP$RLOGIN_VTA is set, users logging in by proxies will observe that the terminal device they are assigned is displayed as TNAnnn rather than VTAnnn. For more information, see Section 17.2.2.

17.3.1 Registering Remote Users

For users on UNIX hosts, the following information must be listed in at least one of the following databases:

For users on OpenVMS clients running TCP/IP Services, check that the appropriate proxy information is in the remote system's proxy database.

You can also restrict remote printing to specific users by entering:

TCPIP> SET SERVICE service /FLAGS=APPLICATION_PROXY

With this flag set, the R commands use the communication entries in the proxy database for authentication.

To reject access from a remote host, use the SET SERVICE service /REJECT command. For example:

TCPIP> SET SERVICE RLOGIN /REJECT=HOSTS=(loon,ibis,tern)

The proxy database is case sensitive for remote user names. The case you use for communications entries affects the way users access your host, so use case in a consistent fashion. In the proxy database, if the user name is in:

• Uppercase, the user must use the /NOLOWERCASE qualifier.
• Lowercase, RSH and RLOGIN default to /LOWERCASE.

If the flag CASE_INSENSITIVE is set, the server matches an incoming user name with an all-lowercase or an all-uppercase remote user name in the proxy database.

The case-sensitivity flag for RLOGIN, RSH, and RCP defaults to CASE_INSENSITIVE. With this setting, the server accepts both all-uppercase and all-lowercase user names.

Ensure that RSH is enabled, because no RCP service exists. Instead, RCP uses the RSH server process. (RCP uses RSH or REXEC to do its work. RSH must be configured properly for RCP to work.)

17.4 Creating a Welcome Message

To modify the welcome message displayed by the RLOGIN server, define the TCPIP$RLOGIN_MESSAGE logical name and specify the text. For example, the following command defines a welcome message for RLOGIN clients when they log in to the server:

$ DEFINE /SYSTEM TCPIP$RLOGIN_MESSAGE "OpenVMS RLOGIN Server Version 5.4"

The Remote Magnetic Tape/Remote CD-ROM (RMT/RCD) server provides remote system access to local OpenVMS magnetic tape and CD-ROM drives. The tape or CD-ROM drives appear to the RMT client users as if they were mounted locally. The RMT server fully implements the UNIX commands rdump and rrestore and the OpenVMS commands MOUNT, BACKUP, COPY, and EXCHANGE.

This section assumes that you are familiar with device mounting and server access conditions relevant to the R command services.

17.5.1 Preparing Drives for Remote Mounts

Perform the following tasks to make sure the remote client can access the tape or CD-ROM drive:

1. Enable the RSH, REXEC, and RMT services.
2. Load a magnetic tape or CD-ROM into the device.
   With a tape device, the client mounts and allocates the tape; you do not need to perform this task.
   With a CD-ROM device, you need to make the device accessible by entering a MOUNT /SYSTEM command.
3. Make sure the remote shell command (RSH) works from the UNIX root account.
   • Create the OpenVMS account named ROOT. This account must have PHYIO and VOLPRO privileges.
   • Create a communication proxy that associates the remote RMT client user with the OpenVMS account ROOT on the RMT server host. For example:

     TCPIP> add proxy root /HOST=host /REMOTE=user

     
     See Section 17.3 for more information about communication proxies.
4. Make sure the rsh command works from the user's account on the remote UNIX host.
5. For the OpenVMS account ROOT, suppress SYS$LOGIN and LOGIN.COM output by entering the following commands:

   $ RMT_VERIFY = 'F$VERIFY(0) ... $ IF (F$MODE() .NES. "OTHER") THEN $RMT_VERIFY = F$VERIFY(RMT_VERIFY)

On the remote host, a user can use rdump to dump files to OpenVMS tapes, or rrestore to restore files from OpenVMS tapes. The functionality of rdump and rrestore depends entirely on the type of UNIX system you use and not on the RMT service. For example, not all UNIX systems let you restore files selectively using rrestore .

When you enter these remote dump and restore commands, you must specify either a valid OpenVMS magnetic-tape device name, or a file name.

See the sections on dump, rdump, restore , and rrestore in your client system's documentation for details. Be careful about the order in which you specify options on the command line.

Here is an example of an rdump command:

> /etc/rdump 0f lilac:mua0:/nomount/density=1600 /usr

In the example, the remote user requests to remotely dump the /usr file system onto device mua0: on system lilac and specifies the /nomount qualifier and a tape density of 1600 bits per inch.

You can specify the qualifiers described in Table 17-2 with magnetic-tape device names.

The following steps perform rdump and rrestore functions from a UNIX client system. These commands dump two UNIX directories to the tape with separate rdump commands. These commands then restore files selectively from the tape to the UNIX client system:

1. Put the directories on the tape by entering two rdump commands. Specify the /nomount/norewind/nounload qualifiers to prevent OpenVMS from rewinding the tape. Although the UNIX system reports that the tape was rewound, it was not actually rewound. The commands are:

   UNIX> /etc/rdump 0f vax:device/nomount/norewind/nounload dir1 UNIX> /etc/rdump 0f vax:device/nomount/norewind/nounload dir2

2. Restore the files selectively from the tape using rrestore . Be sure the tape is loaded and rewound. Use either the interactive or noninteractive command syntax.

The rrestore command might display messages such as "You have not read any volumes yet" and then ask you to specify the next volume. Although these messages might appear, rrestore should work properly.

In the following example, rrestore extracts the file specified by file_name from dump file number 2 on the tape:

UNIX> /etc/rrestore fsx vax:device/nomount/nounload/norewind 2 file-name

In the following example, rrestore invokes the interactive utility to let the user specify particular files that were put on the tape in dump file 2. The add command then adds the files to the extraction list and the extract command restores them:

UNIX> /etc/rrestore fis vax:device/nomount/nounload/norewind 2
restore> add file_name
restore> extract