This chapter describes how to:
• Manage and troubleshoot the Berkeley R Commands Services, and set up host equivalence files on the server.
• Manage the R Shell (RSH) server, which handles Remote Copy Program (RCP) requests.
• Manage the Remote Magnetic Tape (RMT) Server.
Configure the Berkeley R Services as part of TCPware configuration (CNFNET). The following are the specific steps in the process:
1 Specify whether you want to enable the login, shell, and exec services. Specify YES or NO in each case.
2 For login service, also specify whether you want NORMAL or SECURE login authorization (the default is SECURE), as described in Table 16-2.
3 If desired, create a service access list.
4 Set up a host equivalence file.
You may want to set up a service access list to control which hosts, group of hosts, or network can access the service.
Use the ADD ACCESS_LIST command in TCPware's Network Control Utility (NETCU) that lets you specify a list number and PERMIT or DENY condition for a specific network internet address (and optional network mask). Here is the command format:
$ NETCU ADD ACCESS_LIST list condition ia mask
For details on the ADD ACCESS_LIST command, see the NETCU Command Reference.
Host equivalence files are security access files on the server host used to authorize access to services by other hosts or users. The files list hostnames (and, optionally, usernames) and indicate which remote hosts and users have equivalent access as local users.
(Host equivalence files authorize access to login and shell services only, since the exec service relies on direct username and password authorization.)
Two types of equivalence files are available: HOSTS.EQUIV and .RHOSTS. These files serve slightly different needs and are in different locations on the OpenVMS host, although they use the same data format:
• The HOSTS.EQUIV file defines which remote hosts or users can have equivalent access to the server host, and is analogous to the /etc/hosts.equiv file in UNIX. Place the HOSTS.EQUIV file in either the TCPWARE_COMMON:[TCPWARE] or TCPWARE_SPECIFIC:[TCPWARE] directory, depending on your configuration.
• The .RHOSTS file lets remote users access local accounts beyond what the HOSTS.EQUIV file specifies, and is analogous to the UNIX ~/.rhosts file. Place the .RHOSTS file in the local accounts login directory. Here are some things to keep in mind:
– A remote user specified in a .RHOSTS file can access the local account only if the account owns the file.
– Access to the SYSTEM (root) account, or one that has a system UIC group, requires a .RHOSTS file, and does not work in the HOSTS.EQUIV file.
– To disable user-specified SYS$LOGIN:.RHOSTS files (and use the HOSTS.EQUIV file only), set the TCPWARE_RCMD_FLAGS system logical to 1 (it is 0 by default).
Both the HOSTS.EQUIV and .RHOSTS files contain line entries for hostnames and optional usernames, in the following format, where host is the name of the remote host allowed access and the optional username is the name of a specific user on that host:
host [username]
Here are some sample lines in a host equivalence file, with the following considerations:
ALPHA
BETA smith
GAMMA Jones
DELTA +
+ JackSprat
• If you specify only host on a line (omitting username), users having accounts with the same names on both hosts can access the local system.
• If you specify both host and username on a line, the specified user on that host can access the local system or account. The username must match case exactly with the incoming username (JackSprat does not match with jacksprat).
• You can use the plus symbol (+) as a wildcard for host and username, but do not use an asterisk (*) since UNIX does not recognize it as a wildcard. A wildcarded host entry grants access to any host, provided username checks pass. A wilcarded username entry grants access to any user, provided the hostname passes.
• The HOSTS.EQUIV and .RHOSTS files may handle some entries differently, as described in Table 16-1.
|
Table 16-1 Usernames and Wildcards in HOSTS.EQUIV and .RHOSTS Files |
||
|
Sample entry... |
In the HOSTS.EQUIV file... |
In the .RHOSTS file (with account owner Betty)... |
|
ALPHA |
Accepts anyone from ALPHA for access to a local account with the same name as the remote username |
Accepts only username Betty from ALPHA |
|
ALPHA Betty |
Accepts only username Betty from ALPHA for any account other than SYSTEM |
Accepts only username Betty from ALPHA |
|
ALPHA David |
Accepts only username David from ALPHA for any account other than SYSTEM |
Accepts only username David from ALPHA who requests
username Betty (such as with rlogin |
|
ALPHA + |
Accepts anyone from ALPHA for any requested account |
Accepts anyone from ALPHA who requests username Betty |
|
+ Betty |
Accepts only username Betty from any host for any account other than SYSTEM |
Accepts only username Betty from any host |
|
+ David |
Accepts only username David from any host for any account other than SYSTEM |
Accepts only username David from any host who requests username Betty |
|
+ + |
Accepts anyone from any host for any requested account other than SYSTEM |
Accepts anyone from any host who requests username Betty |
CAUTION! Use username values or wildcards in the HOSTS.EQUIV file with security in mind. Because HOSTS.EQUIV files apply system-wide, any remote user (or group of users) can masquerade as a local user. Especially avoid using double pluses (+ +) in either file.
Host equivalence files grant access authorization differently depending on how you configure each R Service during the regular TCPware configuration:
• For login service, CNFNET offers NORMAL and SECURE options for login authorization (see Table 16-2).
|
Table 16-2 login Service Access Matrix |
||
|
When... |
With NORMAL login... |
With SECURE login... |
|
Hostname and username appear in the .RHOSTS or HOSTS.EQUIV file |
User is logged in |
User is prompted for password |
|
Hostname or username does not appear in the .RHOSTS or HOSTS.EQUIV file |
User is prompted for username and password (standard login sequence) |
Access is denied |
• The shell service checks the host equivalence files for command execution. If the check fails, shell denies access.
• The exec service performs a standard username and password check before allowing command execution on the host.
The exec service also tracks break-in attempts using the OpenVMS Intrusion database. If a remote user enters an invalid login, TCPware creates an intrusion record based on the remote source's IP address. If TCPware reaches the threshold number of invalid login attempts, no one at the remote IP address can use the exec service. The Intrusion database shows who the offending addresses are; you can re-enable login attempts by deleting the intrusion records.
See the SHOW INTRUSION and DELETE/INTRUSION_RECORD commands in HP's VMS DCL
Dictionary for details.
Incoming shell and exec services invoke the TCPWARE:TCPWARE_RSERVICE.COM procedure to perform the requested operation. You can customize this command procedure to map an incoming command to an OpenVMS command. (Just make sure that you do not destroy mapping for TCPware operations such as RCP and RMT.)
The REXEC and the RSHELL servers have the functionality to set up a DECwindows display to the client’s IP address if the TCP/IP transport is loaded. To enable this functionality, define the logical as:
$ DEFINE/SYSTEM/EXEC TCPWARE_RCMD_ENABLE_DISPLAY “TRUE“
You can set up a log file for incoming R Services such as RCP and RSH by defining the TCPWARE_RCMD_OUTPUT logical to log messages in the RCMD.LOG file, as follows:
$ DEFINE/SYSTEM/EXEC TCPWARE_RCMD_OUTPUT RCMD.LOG
Access error messages help by entering HELP TCPWARE MESSAGES [identifier].
Use the SHOW SERVICES command in NETCU to make sure that the R shell daemon (rshd) is operating before client users can use the RCP command. On TCPware hosts, the service should show up as shell under the "Port" column. If it does not, use CNFNET to enable the R Services.
You also need to use the rexec server if client users need to specify the RCP command's /USER, /PASSWORD, and /TRUNCATE qualifiers. On TCPware hosts, the service shows up as exec under the "Port" column.
CAUTION! The /PASSWORD qualifier requires entry of a plain text password, which could cause a security problem. You can avoid having users specify the /USER or /PASSWORD qualifier by checking that remote hosts include your hostname entry in their host equivalence files (such as the /etc/hosts.equiv file in UNIX systems, or the TCPWARE:HOSTS.EQUIV or SYS$LOGIN:.RHOSTS file locally).
Make sure that your users' login files (as well as the ~/.login files on UNIX system clients) do not contain commands that generate output.
You can log RCP activity by defining the TCPWARE_RCMD_OUTPUT logical. (See R Services Log File
.)
Here are some steps to follow to ensure that the RCP command given from a UNIX system works correctly with TCPware's R Services. First make sure that the R Services were configured by running @TCPWARE:CNFNET RCMD to make sure that RCP is at the very least enabled and the image installed. Then follow these steps:
On the TCPware system:
1 Set the default to the login directory of the user account to which you will be copying files.
2 Edit the SYS$LOGIN:.RHOSTS file and add the UNIX hostname and username.
3 Edit the TCPWARE:HOSTS. file and add the IP address and hostname of the UNIX system from which you will be copying files.
4 Check the user account's UAF record (using SET DEFAULT SYS$SYSTEM followed by MCR AUTHORIZE).
5 Check that the owner of the login directory and .RHOSTS file is the same as the UAF record's IDENTIFIER/UIC (using DIRECTORY/OWNER). If different, you must set the ownership of the login directory and .RHOSTS file to match the IDENTIFIER/UIC.
On the UNIX system:
1 Issue the rcp command. If you get a Login information not recognized at remote node message, run NETCU DEBUG /TCP /DATA=1500 /DIA=unix-host-ip-address, preferably with the additional /OUTPUT=RCPDEBUG.LOG.
2 If there is a debug trace, look for the unix.username.vax-username.rcp filename.ext. If you notice that the case of the username is different from how it appears in the .RHOSTS file, change the case in the .RHOSTS file to match.
A permission denied message usually indicates a protection error on the UNIX side.
Here are some preliminary tasks to make sure the remote client can access the tape or CD-ROM drive:
1 Make
sure the shell and exec services and the
RMTSETUP image are installed during TCPware configuration at the Do you want to activate ...
service: and
Do you want to INSTALL the
... image: prompts, or make sure that at least RCMD_SERVICES == ":SHELL:EXEC" and RCMD_CLIENTS ==
":RMTSETUP" appear in your TCPWARE:TCPWARE_CONFIGURE.COM file.
2 Make sure the magnetic tape or CD-ROM, recognizable to the system, is loaded in the device. With a tape device, the client essentially 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 command.
3 Make sure the rsh command works from the UNIX system user's root directory to the OpenVMS user SYSTEM's directory.
4 For SYSTEM accounts, RMT ignores the TCPWARE:HOSTS.EQUIV file and uses an explicit entry in the SYS$LOGIN:.RHOSTS file to grant access.
5 Make sure nothing is output from SYS$SYLOGIN procedure or from SYS$LOGIN:LOGIN.COM when issuing the rsh command to SYSTEM.
6 Make sure you suppress output by including the following commands in the SYS$SYLOGIN and LOGIN.COM procedures:
$ RMT_VERIFY
= 'F$VERIFY(0)
$ IF (F$MODE() .NES. "OTHER") THEN RMT_VERIFY = F$VERIFY(RMT_VERIFY)
On the remote host, a user can employ the rdump utility to dump files to OpenVMS tapes, or the rrestore utility 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 TCPware's RMT service. For example, not all UNIX systems let the user restore files selectively using rrestore.
When remote users use these remote dump and restore commands, they must specify either the OpenVMS device name or a filename. If they specify a device name, it must be a valid OpenVMS type of magnetic tape device name.
See the SunOS Reference Manual, the Maintenance chapter, the sections on dump,rdump, restore, and rrestore, or your particular client system's documentation for details. Users should be careful about the order in which they specify options on the command line.
Here is an example of an rdump command:
>/etc/rdump 0f
lilac:mua0:/nomount /usr
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.
TCPware's RMT Server lets you specify the qualifiers with magnetic tape device names indicated in Table 16-3. The qualifiers are available with the RMTSETUP command.
|
Qualifier... |
Defines... |
|
/ASSIST /NOASSIST |
Whether to use operator assistance to mount the volume. /ASSIST 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. |
|
/MOUNT /NOMOUNT |
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. With /NOMOUNT, the qualifiers /ASSIST,
/BLOCKSIZE, /COMMENT, and /DENSITY are not allowed. With
/NOMOUNT, the defaults are /NOUNLOAD, /NOREWIND, /STREAM, and |
|
/REWIND /NOREWIND |
Whether to rewind the drive when it is closed. The default is /REWIND. |
|
/STREAM /NOSTREAM |
Whether to read the tape in record (/NOSTREAM) or byte-stream (/STREAM) mode. The default is /STREAM. |
|
/UNLOAD /NOUNLOAD |
Whether to unload the drive when it is closed. The default is /UNLOAD. |
|
/WRITE /NOWRITE |
Whether you can write to the volume. The default is /WRITE. |
RMT CD-ROM Qualifiers indicates the supported option for remote access to the 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 Sun UNIX client system. They dump two Sun directories to the tape by issuing separate rdump commands. They then restore files selectively from the tape to the Sun client system:
1 Put the directories on the tape by issuing two rdump commands:
SUN>/etc/rdump 0f homer:mkb600/nomount /
SUN> /etc/rdump 0f homer:mkb600/nomount/rewind /usr
Include the /nomount qualifier with the first rdump to keep OpenVMS from rewinding the tape (even
though rdump on the
Sun reports to the contrary). The additional
/rewind qualifier for
the second rdump
actually rewinds the tape.
2 Restore the files selectively from the tape using rrestore. In this example, rrestore extracts .rlogin from the second (2) dump file on the tape:
SUN>/etc/rrestore fsx homer:mkb600/nomount/rewind 2 .rlogin
In this example, rrestore invokes the interactive utility to let the user specify particular files that were put on the tape in the first (1) dump file. The add command then adds the files to the extraction list and the extract command restores them:
SUN>/etc/rrestore fis
homer:mkb600/unload 1
restore>add /users
restore>extract
The rrestore command may display messages such as You have not read any volumes yet and ask you to specify the next volume. Although the messages may appear, rrestore should work properly.