Remote Device Facilitytm
Previous Contents Index

Chapter 6
RMT Functionality with RDF

Remote Device Facility allows most UNIX systems with standard RDUMP and RRESTORE commands to access OpenVMS tape devices using the RMT protocol. The RMT protocol is available on most standard UNIX systems.

The UNIX system is required to have the standard RSH, RDUMP and RRESTORE installed, as well as a TCP/IP connection to the OpenVMS RDserver machine.

6.1 Requirements

In order to use RMT functionality with RDF, you must be the SUPERUSER on the UNIX system. Also, there must be a UCX proxy set up on the RDF server node for username ROOT. This proxy must be a UCX proxy, not a DECNET proxy. For security reasons, the ROOT account should be created as a non-privileged OpenVMS username.

The OpenVMS ROOT username only requires NETMBX and TMPMBX OpenVMS privileges.

Example of Setting Up and Verifying the UCX Proxy

The following example shows how to set up an OpenVMS account for username ROOT. 


 
    UAF> ADD ROOT/UIC=[376,501]/DEVICE=CODE2:/DIR=[ROOT]/PASS=AFGKDLFD 
 
    UAF> SHOW ROOT 
 
    Username: ROOT                             Owner:  RDF for Unix 
    Account:  SYSTEM                           UIC:    [376,501] ([UCX$AUX,ROOT]) 
    CLI:      DCL                              Tables: DCLTABLES 
    Default:  CODE2:[ROOT] 
    LGICMD: 
    Flags:  DisCtlY DefCLI DisMail 
    Primary days:   Mon Tue Wed Thu Fri 
    Secondary days:                     Sat Sun 
    No access restrictions 
    Expiration:            (none)    Pwdminimum:  6   Login Fails:     0 
    Pwdlifetime:         60 12:00    Pwdchange:      (pre-expired) 
    Last Login:            (none) (interactive), 29-JAN-2000 13:39 (non-interactive) 
    Maxjobs:         0  Fillm:       200  Bytlm:       175000 
    Maxacctjobs:     0  Shrfillm:      0  Pbytlm:         150 
    Maxdetach:       0  BIOlm:      1500  JTquota:      32768 
    Prclm:          20  DIOlm:       500  WSdef:         7168 
    Prio:            4  ASTlm:       300  WSquo:        10240 
    Queprio:         0  TQElm:       300  WSextent:     16384 
    CPU:        (none)  Enqlm:       500  Pgflquo:     200000 
    Authorized Privileges: 
      NETMBX    TMPMBX 
    Default Privileges: 
      NETMBX    TMPMBX 
 
    UAF>

The ROOT user takes on all privileges and rights of the DEFAULT account. This account must have a default directory owned by the account and disk quota must be granted if the disk being used has quotas enabled. The only data stored to this directory are remote shell log files.

Example of Setting Up an UCX Proxy

The following example shows how to set up an UCX proxy for the OpenVMS ROOT account.

Note that "root" is quoted and in lowercase. 


 
    UCX> ADD PROXY ROOT/REMOTE_USER="root"/HOST=* 
    UCX> SHOW PROXY ROOT 
 
    OpenVMS User_name     Type      User_ID    Group_ID   Host_name 
 
    ROOT                  CD      root                     * 
    UCX>

Example of How to Test the Proxy

The following example shows how to test the proxy by executing an OpenVMS command from a remote Unix node: 


    sun1044# rsh ssdhv2 show time 
 
      30-JAN-2000 08:27:42 
    sun1044#

When RDF is started, it modifies the UCX remote shell service proxy. This is a permanent change to the UCX database. If RDF is not properly shutdown, the UCX RSH service will not work when OpenVMS is rebooted unless RDF is restarted.

6.2 Starting the RMT Server

To enable RMT client connections to a RDserver, the RDRMT_STARTUP.COM file must be executed. For example: 


    $ @TTI_RDEV:RDRMT_STARTUP.COM

Once the RDRMT_STARTUP.COM file is run, all RMT connections to this node will be sent through the RDserver. All other RSH commands will be passed through UCX's default service.

The following example shows how to determine if the RDRMT_STARTUP.COM file has been executed. The "File:" line should show "TTI_RDF:RDF_UCX_RSHD_STARTUP.COM". 


 
    $ ucx 
    UCX> show service rsh/full 
 
    Service: RSH 
                               State:     Enabled 
    Port:              514     Protocol:  TCP             Address:  0.0.0.0 
    Inactivity:          5     User_name:                 Process:  UCX$RSHD 
    Limit:             100     Active:      0             Peak:       0 
 
    File:         TTI_RDF:RDF_UCX_RSHD_STARTUP.COM 
    Flags:        Listen Proxy Rexe 
 
    Socket Opts:  Rcheck Scheck 
     Receive:            0     Send:               0 
 
    Log Opts:     Acpt Actv Dactv Conn Error Exit Mdfy Rjct TimO Addr 
     File:        not defined 
 
    Separators: 
     Port:   0    User_name: 0    Password:  0    Command:  0 
 
    Security 
     Reject msg:  not defined 
     Accept host: 0.0.0.0 
     Accept netw: 0.0.0.0 
 
    UCX>

The value, TTI_RDF:RDF_UCX_RSHD_STARTUP.COM, is only valid when the TTI_RDF logical name is defined after starting RDF. Otherwise the RSH service is broken. The default value is: SYS$SYSDEVICE:[UCX$RSH]UCX$RSHD_STARTUP.COM

To define the TTI_RDF logical: 


    DEFINE TTI_RDF:RDF_UCX_RSHD_STARTUP.COM TTI_RDF

Note
The UCX_RSHD_STARTUP.LOG file in a RSH user's LOGIN directory, is called RDF_UCX_RSHD_STARTUP.LOG while RDF is running.

6.3 RDUMP and RRESTORE

These two UNIX commands are used to backup and restore file systems using the RMT protocol:

6.3.1 Remote Backup

With RDF, you can backup file systems on a UNIX client to a RDF OpenVMS server.

Example: 


    # rdump -9f fast:muc0 / 
      DUMP: Date of this level 9 dump: Mon Jan  9 10:30:08 2000 
      DUMP: Date of last level 0 dump: Thu Aug 26 07:26:02 1999 
      DUMP: Dumping /dev/rrz2a (/) to ntest on host fast 
      DUMP: Mapping (Pass I) [regular files] 
      DUMP: Mapping (Pass II) [directories] 
 
      DUMP: Estimated 8185856 bytes output to file named ntest 
 
      DUMP: Dumping (Pass III) [directories] 
      DUMP: Dumping (Pass IV) [regular files] 
 
      DUMP: 8182784 bytes were dumped to file ntest 
 
      DUMP: Dump is done 
    #

6.3.2 Remote Restore

With RDF, you can restore file systems on a UNIX client from a RDF OpenVMS server.

Example: 


    # rrestore -tf fast:muc0 
    Dump   date: Mon Jan  9 10:30:08 2000 
    Dumped from: Thu Aug 26 07:26:02 1999 
             2      . 
          3968      ./etc 
          4025      ./etc/passwd 
          4001      ./etc/disktab 
           :           : 
           :           : 
            51      ./.lwk_personal.linkbase 
            48      ./prince.du 
    #

When using Digital UNIX®
If no block size is specified when using the rdump command, you must specify a block size of 10 in the rrestore command. If you specify a block size in the rdump command, you must specify that same block size when using the rrestore command. An example of the rrestore command follows:

# rrestore -b 10 -tf fast:muc0

Note

® Digital UNIX (formerly called DEC OSF/1) is a registered trademark of Digital Equipment Corporation.

Chapter 7
Shutting Down RDF

Ultrix Clients
RDF/ULTRIX has no STARTUP or SHUTDOWN procedures.

7.1 Shutdown Instructions

The Remote Device Facility allows RDCLIENT and RDSERVER nodes to be independently shut down. In order to shut down an RDF node, you should log into the SYSTEM account and run the appropriate procedure.

7.2 RDCLIENT Shutdown

To perform an orderly shutdown of an RDF CLIENT, from the client node you should log into SYSTEM and then execute the RDF client shutdown procedure. 


  USERNAME: SYSTEM 
  PASSWORD: (the system password) 
 
  $ @tti_rdev:RDCLIENT_SHUTDOWN 
  RDEV - VMS Remote Device Facility (Version V4.n) - RDclient Shutdown Procedure 
  Copyright (c) 1990-2000 by Touch Technologies, Inc. 
      . 
      .  All RDF client operations are shutdown. 
      . 
  RDclient shutdown completed 
  $ LOGOUT

7.3 RDSERVER Shutdown

To perform an orderly shutdown of an RDF SERVER, from the server node you should log into SYSTEM and then execute the RDF server shutdown procedure. 


  USERNAME: SYSTEM 
  PASSWORD: (the system password) 
 
  $ @tti_rdev:RDSERVER_SHUTDOWN 
  RDEV - VMS Remote Device Facility (Version V4.n) - RDserver Shutdown Procedure 
  Copyright (c) 1990-2000 by Touch Technologies, Inc. 
      . 
      .  All RDF server operations are shutdown. 
      . 
  RDserver shutdown completed 
  $ LOGOUT

Chapter 8
Remote Device Security Access

The Remote Device Facility Security Access feature allows System Managers to control access of remote devices by RDCLIENT nodes.

8.1 Implementation

To implement the security access feature, you must edit the RDSERVER's configuration file. The text file is named tti_rdev:CONFIG_nodename.DAT where nodename is the name of the RDSERVER node. (See Appendix B, Configuration File Example.)

The RDSERVER configuration file contains a list of all servable devices on the RDSERVER node. This file is built the first time RDSERVER_STARTUP.COM is executed.

For security reasons, entries in the configuration file for disk devices are commented out. Disk devices can not be accessed by RDCLIENTs until the System Manager implements the security access feature. Disk devices are not automatically made available to RDCLIENT nodes, because the System Manager would not have any control over which RDCLIENT nodes could access the RDSERVER disk drives. Tape devices are automatically made available to RDCLIENT nodes because the System Manager can control what tape media is mounted on rdallocated tape drives. 


     $ type config_zeus.dat 
       . 
       . 
     device $1$MUA0:  MUA0, TK50 
     device MSA0:     TU80, 1600bpi 
       . 
       . 
     !device ZEUS$DKA200: DKA200 
     !device ZEUS$DKA300: DKA300

8.2 Allow Access to Remote Disk Devices

To allow RDCLIENT access to disk drives, the System Manager must:

8.3 Determining Which Users Can RDallocate Remote Disk Devices

The first step in security access is determining which users are permitted to RDallocate remote disks. The following options are available:

8.3.1 Access to Specific RDClient Nodes

To permit all users on a particular node access to all remote disk devices, add the CLIENT/ALLOW qualifier before the first device line in the RDSERVER's configuration file.

If security is added to any device in the RDSERVER's configuration file, the client added on the device line has to be added to the CLIENT/ALLOW line before the first device line. This is true for all clients including UNIX RMT clients.

Example: 


    $ edit tti_rdev:config_zeus.dat 
      CLIENT/ALLOW=(CURLY, MOE)
      device $1$MUA0:  MUA0 
      device ZEUS$DKA200:  DKA200 
      device ZEUS$DKA300:  DKA300 
       .                     . 
       .                     .

In the above example, RDCLIENT nodes CURLY and MOE are given access to remote disk devices DKA200 and DKA300.

Note
If there is more than one RDCLIENT node being allowed access, separate the node names by commas. This allows access to all devices listed in the configuration file by the RDCLIENT nodes listed in the allow statement.

8.3.2 Access to Specific Remote Disk Devices

To permit all users on a particular node read-only access to a specific remote disk, add the /READ qualifier on the desired device line in the RDSERVER's configuration file. To allow for read/write access, use the /WRITE qualifier.

Example: 


    $ edit tti_rdev:config_zeus.dat 
      device $1$MUA0:  MUA0 
      device ZEUS$DKA200:  DKA200  /READ=(CURLY::*)
      device ZEUS$DKA300:  DKA300

In the above example, all users on RDCLIENT node CURLY are given read-only access to device DKA200. All other nodes are denied access to device DKA200.

8.3.3 Access to Non-Privileged Users

In addition to TMPMBX and NETMBX, READALL privilege is required to RDallocate a disk device for read-only access. Specific users without READALL privilege can be allowed to RDallocate remote disks either by username or UIC group. Add the /READ qualifier on the desired device line in the RDSERVER's configuration file.

SYSPRV privilege is required to RDallocate a disk device for read/write access. Specific users without SYSPRV privilege can be allowed to RDallocate read/write either by username or UIC group. Add the /WRITE qualifier on the desired device line in the RDSERVER's configuration file.

Example: 


    $ edit tti_rdev:config_zeus.dat 
       . 
       . 
      device ZEUS$DKA200:  DKA200 /READ=(CURLY::OPER)
      device ZEUS$DKA300:  DKA300 /WRITE=(MOE::[1,*])
       . 
       .

In the above example, all privileged users on RDCLIENT node CURLY are given read-only access to remote device DKA200. Because OPER is a non-privileged account (without READALL), it must specifically be included in the /READ line to be given the same access.

All privileged users on RDCLIENT node MOE are given read/write access to remote device DKA300. All non-privileged users in the UIC group [1,*] are also included.

Note
UIC groups are enclosed in brackets and can be wildcarded. To specify multiple RDCLIENT nodes, usernames and UIC groups in the /READ line, separate nodes with commas, usernames and UIC groups with '+' and surround the entire string with parentheses.

Example: 


    $ edit tti_rdev:config_zeus.dat 
       . 
       . 
      device ZEUS$DKA200:  DKA200 /READ=(CURLY::[1,*]+SYSTEM,FRED::OPER+SYSTEM)
       . 
       .

In the above example, all members of UIC group [1,*] and username SYSTEM on node CURLY are given read-only acces to remote device DKA200. Usernames OPER and SYSTEM on node FRED are also given the same access.

8.3.4 Read/Write Access or Read-only Access

Once a remote disk is mounted, it can only be RDallocated by an RDCLIENT node for read-only access. Only those remote disk devices that are not already mounted can be RDallocated for read/write access.

The following is an example of an unsuccessful RDallocate for read/write access. Remote device DKA300 is already mounted prior to the RDallocate.

Example: 


    $ @tti_rdev:rdallocate zeus::zeus$dka300/write/exclusive
 
    RDEV - VMS Remote Device Facility (Version V4.n) - RDallocate Procedure 
    Copyright (c) 1990-2000 by Touch Technologies, Inc. 
 
    Device ZEUS$DKA300 on node ZEUS does not exist or is unavailable... 
    Available devices on node ZEUS:: 
    Name           Status   Usage     Characteristics/Comments 
    $1$mua0        -free-             mua0 tk50 
    jr$dka200      not avl            Server config doesn't allow access 
    zeus$dka300    in use   mnt/syst  dka300 jrsys 
    $

8.3.5 Accessible Files on a Remote Disk

Once the remote disk is mounted and allocated, file access is governed entirely by OpenVMS.

8.4 Allow Access to Remote Tape Devices

Unlike disk devices, to allow RDCLIENT access to tape drives, the System Manager need not modify the configuration file on the RDSERVER node. When the configuration file is setup, it automatically allows all users on all RDCLIENT nodes access to all tape devices.

8.4.1 Access to Specific RDClient Nodes

To permit all users on a particular node access to all remote tape devices, add the CLIENT/ALLOW qualifier before the first device line in the RDSERVER's configuration file (see Section 8.3.1).

If security is added to any device in the RDSERVER's configuration file, the client added on the device line has to be added to the CLIENT/ALLOW line before the first device line. This is true for all clients including UNIX RMT clients.

Example: 


        $ edit tti_rdev:config_zeus.dat 
        CLIENT/ALLOW=(MINI,BIG)
        DEVICE $1$MUA0:  MUAO, TK50 
        DEVICE MSA0:     TU80, 1600bpi

In the above example, MINI and BIG are the specific RDCLIENT nodes that are allowed access to all the remote devices (MUA0, TU80) on this RDSERVER (ZEUS) node.

Note
If there is more than one RDCLIENT node being allowed access, separate the node names by commas. This allows access to all devices listed in the configuration file by the RDCLIENT nodes listed in the allow statement.

8.4.2 Access to Specific Remote Tape Devices

To permit all users on a particular node access to a specific remote tape device, add the /ALLOW qualifier to the desired device line in the RDSERVER's configuration file.

Example: 


        $ edit tti_rdev:config_zeus.dat 
        DEVICE $1$MUA0:  MUA0, TK50/ALLOW=(MINI,BIG)
        DEVICE MSA0:     TU80, 1600bpi/ALLOW=(BIG)

In the above exmple, MINI and BIG are the specific RDCLIENT nodes that are allowed access to device MUA0 only. In this situation, MINI is not allowed to access device MSA0:.

If MINI attempts to RDALLOCATE device MSA0:, the following error message is displayed: 


        $ @tti_rdev:RDALLOCATE ZEUS::MSA0: 
          . 
          . 
        Device MSA0: on node ZEUS does not exist or is unavailable... 
          . 
          .

Previous Next Contents Index