Output redirected from SYS$OUTPUT for the agent process is logged to the following files:
Output redirected from SYS$ERROR is logged to the following files:
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:
See the subdirectory [.SNMP] in UCX$EXAMPLES for files with which to build a sample subagent.
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.
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
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:
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
To display login and logout messages at the operator's console and log file, issue:
UCX> SET SERVICE TELNET /LOG=(LOGIN,LOGOUT)
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"
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:
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
How you set up Anonymous FTP determines the availability of end-user features. Your configuration can offer or limit the following features:
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>
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
The following shows how to set up Anonymous FTP access on your system:
DIGITAL TCP/IP Services for OpenVMS provides the logical names described in Table 10-1 that you can use to manage the FTP server.
| 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. |
By default, the FTP server creates several log files you can use to monitor the service and user transactions. These log files are:
The number of log files (one per FTP transaction) might become large. To limit the number of versions, issue:
$ SET FILE file /VERSION=n
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:
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:
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)
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"
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:
UCX> add proxy root /HOST=host /REMOTE=user
$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 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.
| 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.
| Qualifier | Defines |
|---|---|
| /CD | Indicates that the remote device is a CD-ROM device. |
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:
UNIX> /etc/rdump 0f vax:device/nomount/norewind/nounload dir1 UNIX>/etc/rdump 0f vax:device/nomount/norewind/nounload dir2