VMS/IRAF Installation and Site Manager's Guide

$! IRAFKS.COM -- Fire up the iraf kernel server under DECNET.
$!
$  if f$mode() .nes. "NETWORK" then exit
$!
$! iraf                         ! uncomment if not in login.com
$  irafks :== "$irafbin:irafks" ! define irafks as a foreign task
$  irafks dn.irafks             ! start the iraf kernel server
$  logout

This works, but has the disadvantage that every user account must have an IRAFKS.COM file in the login directory, or IRAF DECNET-based networking will not work. A better approach is to define IRAFKS as a known network object which will execute the file IRAFKS.COM supplied in the IRAFHLIB directory with V2.10 VMS/IRAF. This eliminates the need for each user to have a private copy of the IRAFKS.COM file, and makes proxy logins possible, which can eliminate the need for password prompts.

$ run sys$system:ncp
ncp> define object irafks -
    number 0 file usr$3:[iraf.vms.hlib]irafks.com
ncp> set object irafks -
    number 0 file usr$3:[iraf.vms.hlib]irafks.com
ncp> exit

In normal operation the NCP configuration is automatically preserved when the system is rebooted. If the local system has a network configuration procedure to redefine the NCP settings in the event of damage to the network database, then an NCP DEFINE command similar to that shown should be added to this file.

To enable proxy logins for IRAF networking one must first define IRAFKS (the IRAF kernel server) as a known network object, as outlined in the previous section. The VMS authorize utility is then used to enable proxy logins.

For example, assume we have two nodes ROBUR and DRACO.

$ run sys$system:authorize                  ! run on node robur
authorize> add/proxy draco::* */default

$ run sys$system:authorize                  ! run on node draco
authorize> add/proxy robur::* */default

This would enable proxy logins between nodes draco and robur for all user accounts that have the same user login name on both systems. Alternatively one could do this for only a specified set of user accounts. The authorize utility automatically updates the affected disk files so that the change will be preserved the next time the system is booted.

To eliminate the password prompts during IRAF networking connections one must also edit the user .irafhosts file, or the system irafhosts file (in dev) to disable login authentication. For example, if the dev$irafhosts file contains

# dev$irafhosts

draco       :  <user> none
robur       :  <user> none
*           :  <user> ?

then authentication will be disabled for connections made between nodes draco and robur, but a password will be required to connect to any other node. The above irafhosts file would result in a DECNET login request such as

hostname"username"::"0=irafks"

which forces a login as "username" on the remote host. If the user name is omitted, the default proxy login on the remote node is used. The user's .irafhosts file, if present, will be used instead and should be configured similarly.

These changes make IRAF DECNET based networking transparent between cooperating nodes in a local network, without requiring users to place password information in .irafhosts files. This is especially desirable if a routing node is used to route IRAF networking connections between TCP/IP and DECNET networks.

On the UNIX side the dev$hosts entry for a directly-connected VMS node should be similar to the following example.

robur r                 : -rcb robur!irafks

This specifies that for logical node robur, alias r, the rexec-callback connect protocol (TCP/IP) should be used to connect to the network node robur. The command to be executed on the remote node is whatever is to the right of the "!", i.e., the command "irafks" in our example.

When the rexecd daemon executing on the remote VMS node responds, the first thing it will do is login using the username and password supplied with the rexec request, and execute the user's LOGIN.COM file. For an IRAF user this must contain the command iraf, which causes the IRAFUSER.COM file in [IRAF.VMS.HLIB] to be interpreted by DCL. This defines all the IRAF logical names and symbols. One of the sybols defined is the irafks command which is subsequently executed to complete the rexec network request. The irafks command is defined in IRAFUSER.COM as follows:

$  irafks       :== $irafbin:irafks     !  IRAF network kernel server

Hence, as might be expected, the result of the rexec connect is to run the IRAF kernel server irafbin:irafks.exe on the server node. In the case of the rexec-callback connect protocol, the actual command passed to DCL includes command line arguments to the IRAF kernel server telling it how to call the client back on a private network socket. What happens is that the client reserves a port and creates a socket on this port, then issues a rexec call to the VMS system to run the kernel server. The port and host name are passed on the rexec command line. The rexecd daemon on the server runs the irafks.exe process on the VMS node, and irafks calls the client back on the socket reserved by the client. The end result is a high bandwidth direct socket connection between the client and server processes.