# DIGITAL TCP/IP Services for OpenVMS
Management

Previous | Contents

# 9.6 Log Files

Output redirected from SYS$OUTPUT for the agent process is logged to the following files:

- UCX$ESNMP.LOG
- UCX$OS_MIBS.LOG
- UCX$HR_MIB.LOG

Output redirected from SYS$ERROR is logged to the following files:

- UCX$ESNMP.ERR
- UCX$OS_MIBS.ERR
- UCX$HR_MIB.ERR

All log files are located in SYS$SYSDEVICE:[UCX$SNMP].

# 9.7 Writing Your Own Subagent

UCX provides the following header and object library files (located in UCX$SNMP) you can use to create your own subagents:

- ESNMP.H
- UCX$ESNMP.OLB
- UCX$SNMP.OLB
- UCX$SNMPUSER.OLB

See the subdirectory [.SNMP] in UCX$EXAMPLES for files with which to build a sample subagent.

# Part 3
Configuring Network Applications

Part 3 describes how to set up popular networking end-user applications.

Chapter 10 describes how to set your host as a TELNET and FTP server, allowing users on remote hosts to establish login sessions and transfer files.

Chapter 11 describes how to set up the server implementations of the popular Berkeley Remote (R) commands that enable remote file copying (RCP), remote logins (RLOGIN), remote command execution (RSH and REXEC), and remote management of magnetic tape and CD-ROM (RMT/RCD) drives.

Chapter 12 and Chapter 13 describe how to configure and manage the components that allow users to send and receive internet electronic mail.

# Chapter 10
Configuring and Managing TELNET and FTP

The DIGITAL TCP/IP Services for OpenVMS (UCX) product includes implementations of the end-user applications TELNET and FTP.

This chapter describes how to set up your host as a TELNET and FTP server.

For information on using TELNET and FTP, see the DIGITAL TCP/IP Services for OpenVMS User's Guide. For information on using the TELNET print symbiont, see Chapter 17.

# 10.1 Managing TELNET

Managing TELNET includes

- Setting up user accounts (Section 11.2)
- Monitoring and modifying the maximum number of TELNET sessions per user (Section 10.1.2)
- Creating and deleting sessions (Section 10.1.3)
- Displaying login messages (Section 10.1.4)
- Modifying TELNET welcome messages (Section 10.1.5)

## 10.1.1 Setting Up User Accounts

Hosts typically run both TELNET server and TELNET client software. Users on client hosts need valid accounts on server hosts before using TELNET to establish a remote session.

If your local host is to be a TELNET server, create OpenVMS accounts for remote users. You can create several individual accounts or one account that many remote users will use.

## 10.1.2 Maximum Number of User Sessions

The default maximum number of TELNET sessions that a user can simultaneously establish is 10. To change this number, define the logical name UCX$TELNET_MAX_SES n. Issue:

    $ DEFINE /SYSTEM UCX$TELNET_MAX_SES n

Ensure that at least one data buffer is available for each established session. The maximum number of internet device sockets is automatically:

- Increased by this number when you start the TELNET server.
- Decreased by this number when you stop the TELNET server.

## 10.1.3 Creating and Deleting Sessions

You can create and delete TELNET sessions from within a command procedure. Issue the DCL TELNET command with the /CREATE_SESSION and /DELETE_SESSION qualifiers. They have the same function as:

    TELNET> CREATE_SESSION

and

    TELNET> DELETE_SESSION

Example:

    $ TELNET /CREATE_SESSION TS405 2002 902

## 10.1.4 Displaying Login Messages

To display login and logout messages at the operator's console and log file, issue:

    UCX> SET SERVICE TELNET /LOG=(LOGIN,LOGOUT)

## 10.1.5 Creating a Welcome Message

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

    $ DEFINE /SYSTEM UCX$TELNET_MESSAGE "OpenVMS TELNET Server"

## 10.1.6 TELNET Client: TN3270

IBM 3270 Information Display System (IDS) terminal emulation (TN3270) lets UCX users make connections to hosts that use IBM 3270 model terminals.

TN3270 has default IBM 3270 IDS function assignments for DIGITAL keyboards. In addition, users can make their own assignments and might ask you for help. UCX provides EBCDIC-to-DMCS and DMCS-to-EBCDIC translation tables you can customize. Appendix E describes how to customize and rebuild these translation tables.

# 10.2 Managing FTP

The File Transfer Protocol (FTP) software is for file transfers between "nontrusted" hosts. Nontrusted hosts require user name and password information for remote logins. Managing FTP consists of the the following tasks:

- Enabling and disabling FTP (Section 10.2.1)
- Setting up Anonymous FTP (Section 10.2.2)
- Defining FTP logical names (Section 10.2.2.3)
- Monitoring FTP with FTP log files (Section 10.2.2.4)

## 10.2.1 Enabling and Disabling FTP

After FTP is configured by the post-installation configuration procedure, it is started automatically.

To stop any new connections, disable the FTP server interactively or permanently, every time UCX starts.

See the DIGITAL TCP/IP Services for OpenVMS Management Command Reference for descriptions of the SET SERVICE and SET CONFIGURATION SERVICE commands.

## 10.2.2 Configuring Anonymous FTP

Anonymous FTP is an FTP session in which a user logs into the remote server using the user name anonymous and, by convention, the user's real user name as the password.

On the local FTP Server, local users can access files without password authentication. Remote users do not require an account. File access is controlled by regular OpenVMS access restrictions.

By default, UCX$CONFIG creates an Anonymous account on the root directory SYS$SYSDEVICE:[ANONYMOUS]. Usual OpenVMS file protection limits inbound anonymous FTP sessions to this directory, its subdirectories, and files with the UIC [ANONYMOUS,ANONYMOUS].

In this case, a remote FTP client can

- View these directories
- Copy files to and from the directories owned by the [ANONYMOUS,ANONYMOUS] account.

How you set up Anonymous FTP determines the availability of end-user features. Your configuration can offer or limit the following features:

- View directories.
- View the guest and public directories.
  If you set up a public directory, users can look at bulletin-board information and files of interest. The public area is read-only. Its name is GUEST$PUBLIC¹.
- Copy files to and from GUEST$PUBLIC.
- From the ANONYMOUS$USER¹ directory:
  - Delete files
  - Create directories
  - Delete directories
  - Rename files
  - Rename directories

Example:
UNIX user ubird connects to the ANONYMOUS account on OpenVMS host TRAGOPAN. TRAGOPAN asks for ubird's password, which is CARIBBEAN.

    % ftp tragopan
    Connected to tragopan.asian,pheasant.edu.
    220 tragopan.asian.pheasant.edu FTP Server (Version 4.0) Ready.

    Name (tragopan:wings): ANONYMOUS
    331 Guest login ok, send ident as password.
    Password: CARIBBEAN
    230  Guest login ok, access restrictions apply.

            Welcome to DIGITAL TCP/IP Services for OpenVMS (UCX)
               on internet host TRAGOPAN    Date 24-NOV-1997
    FTP>

### 10.2.2.1 Concealed File Systems

The FTP Server processes each command individually as it receives the command and echoes a reply based on the command parameters. A reply can include a file specification that displays part of the server file system.

For security, Anonymous FTP masks file system devices and directories in FTP replies. The following messages show the difference between an unmasked file structure, shown in the first reply, and the less specific, masked structure in the second.

    220 opening data connection for USER$8:[HIDEME.PROJECT.TASK]PLAN.PS

    220 opening data connection for SYS$LOGIN:[PROJECT.TASK]PLAN.PS

### 10.2.2.2 Setting Up Anonymous FTP

The following shows how to set up Anonymous FTP access on your system:

1. Create an account ANONYMOUS with the password GUEST.
2. Set account access restrictions NOLOCAL, NOBATCH, NOREMOTE, and NODIALUP
3. Create a welcome banner. When an anonymous user logs in, FTP informs the user of the account's restrictions. This information consists of a banner in the format of a HELP screen. Define the text you want to display by defining the UCX$FTP_ANONYMOUS_WELCOME logical name.
4. Specify a location for the log files generated by FTP sessions.
   Use the UCX$FTP_ANONYMOUS_LOG logical name. If you do not define UCX$FTP_ANONYMOUS_LOG, FTP puts the files in SYS$SYSDEVICE:[UCX$FTP]UCX$FTP_ANONYMOUS.LOG.
5. Specify a user name for the Anonymous FTP account. Define the logical name UCX$FTP_ANONYMOUS_ALIAS.

### 10.2.2.3 Managing FTP with Logical Names

DIGITAL TCP/IP Services for OpenVMS provides the logical names described in Table 10-1 that you can use to manage the FTP server.

Table 10-1 FTP Logical Names
Logical Name | Description
--- | ---
UCX$FTP_ANONYMOUS_ALIAS | Defines an equivalence list (up to 10 entries) of the login names of users with access to the Anonymous account. These users share the same access rights and restrictions. If you do not define this logical name, the default is "anonymous" as the only login name. The following command shows how to create an equivalence list with the names THOMAS, JONES, and SMITH. These users can log in to the FTP Anonymous account without a password.
    $ DEFINE UCX$FTP_ANONYMOUS_ALIAS THOMAS,JONES,SMITH
UCX$FTP_SERVER_ANNOUNCE | Defines location and file name for the announcement text displayed to users at connect time, before the login sequence. The following example shows a prelogin announcement.
    "DIGITAL TCP/IP Services for OpenVMS (UCX) FTP Server Ready."
UCX$FTP_ANONYMOUS_WELCOME | Defines location and file name for the welcome text displayed to anonymous users at connect time, after the login sequence.
UCX$FTP_CONVERT_FILE | Define this logical name as TRUE or FALSE. When defined as TRUE, the FTP server converts files to variable with fixed-length control (VFC) formatted files before transfer. With the VFC file, users retain the Record Management Services (RMS) formatting information of their files. If you define UCX$FTP_CONVERT_FILE as FALSE, there is no conversion, and RMS formatting information is lost after the file transfer.
UCX$FTP_ANONYMOUS_DIRECTORY | Lists public directories accessible by Anonymous FTP.
UCX$FTP_EXTLOG | Enables detailed logging of errors in the UCX$FTPD.LOG file. Before you start FTP, define this logical name in the system logical name table.
    $ DEFINE UCX$FTP_EXTLOG /SYSTEM
UCX$FTP_FILE_ALQ | Specifies the number of blocks to be preallocated by Record Management Services (RMS) to a disk when a file is created. For information about how to change the default, see Section A.7.1.
UCX$FTP_FILE_DEQ | Specifies the number of blocks to be added when RMS automatically extends the file. For information about how to change the default, see Section A.7.1.
UCX$FTP_ANONYMOUS_LOG | Defines the location of the ANONYMOUS log file. The default is SYS$SYSDEVICE:[UCX$FTP].
UCX$FTPD_IDLETIMEOUT | Defines the maximum time interval that FTP processes can remain idle before FTP closes them. UCX terminates the FTP process if no control or data connection activity exists for the specified time. The default idle time is 15 minutes. This feature can help to improve system performance. Specify a value as hh:mm:ss.
UCX$FTP_KEEPALIVE | Detects idle and broken FTP connections. Define it on the client host as TRUE or FALSE.
UCX$FTPD_KEEPALIVE | Detects idle and broken FTP connections. Define it on the server host by issuing:
    UCX> SET SERVICE FTP /SOCKET_OPTIONS=KEEPALIVE
UCX$FTP_NO_VERSION | If you define UCX$FTP_NO_VERSION, FTP does not send file version numbers when you issue the mget and the ls commands to a non-OpenVMS host. Define this logical name in the system logical name table.
     $ DEFINE /SYSTEM UCX$FTP_NO_VERSION 1
UCX$FTP_RAW_BINARY | With this logical name turned on, FTP transfers files in block I/O mode if the server and client are in image mode. To activate this feature, define the logical name as TRUE. An FTP end-user can override your FALSE definition with the FTP PUT /RAW command.
UCX$FTP_STREAMLF | If you define this logical name as TRUE, the FTP server and client create files as STREAM_LF files. The default is variable length files.
UCX$FTP_WNDSIZ | This logical name sets the window size of the TCP send and receive buffers. Specify a decimal number for the number of bytes.

### 10.2.2.4 FTP Log Files

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:[UCX$FTP]UCX$FTPD_STARTUP.LOG
- SYS$SYSDEVICE:[UCX$FTP]UCX$FTPD.LOG
  This log 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 is closed by the user.
- SYS$SYSDEVICE[UCX$FTP]UCX$FTP_ANONYMOUS.LOG
  This log 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 issued
  - A time notation for the command
  - The source and destination file names
- UCX$FTP.LOG
  This log is created in the user's default login directory.

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

    $ SET FILE file /VERSION=n

### Note

#### ¹ The logical names GUEST$PUBLIC and ANONYMOUS$USER are simply examples of directories you can set up to provide an anonymous FTP service.

# Chapter 11
Remote (R) Commands

DIGITAL TCP/IP Services for OpenVMS (UCX) 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 capabilities described below.

RCP | Remote copy allows files to be copied to or from remote hosts. Its syntax is similar to the UNIX cp command, except that the path name can include the name of a remote host.
RLOGIN | Remote login provides interactive access to remote hosts. Its function is similar to TELNET.
RSH | Remote shell passes a command to a remote host for execution. Standard output from the remote execution is returned to the local host.
REXEC | Similar to the UNIX rsh command, remote execute authenticates and executes RCP and other commands. The authentication is based on password information stored in the OpenVMS system's user authorization file (UAF). REXEC is useful if the remote host does not have, or might not have, the authentication information that the RSH protocol require.
RMT/RCD | Remote access to magnetic tape and CD-ROM drives

This chapter reviews key concepts and explains how to configure the R command applications on your local host. For information on using these applications, see the DIGITAL TCP/IP Services for OpenVMS User's Guide.

# 11.1 Reviewing 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 on 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 are:

- /etc/hosts.equiv --- Defines the trusted hosts and users for the entire system
- .rhosts --- Defines the trusted hosts and users for an individual user account

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

# 11.2 Security Considerations

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 limit access by adding an entry to the proxy database (UCX$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, issue:

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

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

The proxy database is case-sensitive for remote user names. The case you use for communications entries will affect the way users access your host so use case consistently. 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 will match 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.

## 11.2.1 Registering Remote Users

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

Databse File | Type of Information
--- | ---
/etc/hosts.equiv | Host name and user name
.rhosts (in the user's home directory) | Host name and user name

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

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

    UCX> 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:

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

## 11.2.2 Case-Sensitivity Flag

When users issue RSH and RLOGIN commands without the /LOWERCASE qualifier, the commands default to ON. Ensure that RSH is enabled because no RCP service exists. Rather, RCP uses the RSH server process. (RCP uses RSH or REXEC to do its work. RSH must be configured properly for RCP to work.)

# 11.3 Creating a Welcome Message

To modify the welcome message displayed by the RLOGIN server, define the UCX$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 UCX$RLOGIN_MESSAGE "OpenVMS RLOGIN Server Version 4.2"

# 11.4 Remote Magnetic Tape and Remote CD-ROM (RMT/RCD)

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.

## 11.4.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 issuing 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 priviledges.
   - Create a communication proxy that associates the remote RMT client user with the OpenVMS account ROOT on the RMT server host. For example:

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

     (See Section 11.2 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 as follows:

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

   ## 11.4.2 Client Utilities Supported

   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 the user restore files selectively using rrestore.

   When the remote user enters these remote dump and restore commands, he or she must specify either the OpenVMS device name or a file name. If the user specifies a device name, it must be a valid OpenVMS type of magnetic tape device name.

   See the sections on dump, rdump, restore, and rrestore in your particular client system's documentation for details. The user should be careful about the order in which he or she specifies 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.

   The RMT/RCD server lets you specify the qualifiers with magnetic tape device names indicated in Table 11-1.

   Table 11-1 RMT Magtape Qualifiers
   Qualifier | Defines
   --- | ---
   /[NO]ASSIST | Whether to use operator assistance to mount the volume. /NOASSIST is the default.
   /BLOCKSIZE= n | Default block size for magnetic tape volumes. The default is 65534 bytes.
   /COMMENT= "string" | Additional information included with the operator request when the mount operation requires operator assistance (/ASSIST). The comment appears in the OPCOM message for the operator.
   /DENSITY= n | Density (in bits per inch) at which to write a foreign or unlabeled magnetic tape. The default is the current density.
   /[NO]MOUNT | Whether to use the OpenVMS MOUNT service to mount the tape. /NOMOUNT gains access to the tape directly without mounting it. Use this for UNIX utilities that expect the tape drive to hold its position (not rewind) if the utility closes it. The default is /MOUNT.
   /[NO]REWIND | Whether to rewind the drive when it is closed. The default is /REWIND.
   /[NO]STREAM | Whether to read the tape in record /NOSTREAM or byte-stream /STREAM mode. The default is /STREAM.
   /[NO]UNLOAD | Whether to unload the drive when it is closed. The default is /UNLOAD.
   /[NO]WRITE | Whether you can write to the volume. The default is /WRITE.

   Table 11-2 indicates the supported option for remote access to the local CD-ROM drive.

   Table 11-2 RMT CD-ROM Qualifiers
   Qualifier | Defines
   --- | ---
   /CD | Indicates that the remote device is a CD-ROM device.

   ## 11.4.3 Client Examples

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

   1. Put the directories on the tape by issuing two rdump commands. Specify the /nomount/norewind/nounload qualifiers to keep OpenVMS from rewinding the tape. Although rdump on the UNIX system can report that OpenVMS rewound the tape, it did not actually do so. Here are the commands:

          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 non-interactive command syntax.

   Previous | Next | Contents