In most respects the installation is the same, provided a single installation can be fed to client machines in the local network by using an NFS (auto)mounted disk. The installation proceeds normally on the server, however the install script must also be run on each of the client nodes (to create the /dev fifo pipes and local bin directory links). Since nodes in the network will be sharing an iraf directory tree, the iraf root must appear to be the same on all nodes. This can be done with a symbolic link and is necessary so the definition of the iraf root in the shared hlib$cl.csh file is valid for all nodes. Once the system is installed the dev$hosts file must be edited with the name of all machines in the local iraf network. Verify that the path name to the irafks.e kernel server is correct for each machine. The NETSTATUS task can later be used to see which machines are in the network. With this done any resource (tape, disk, or image display) can be accessed using the 'node!' syntax. Note that images are created with a pixel pathname embedded in the header that includes the node name on which it was created.
The IRAF install script creates several links in the system dir- ectories, in /dev for the fifo pipes needed for SAOimage image display, and /usr for the /usr/include/iraf.h file. Links are also made for commands like 'cl' in a "local bin directory", usually /usr/local/bin. If IRAF is not run on the client nodes, iraf networking will fail because of a missing <iraf.h> although IRAF itself may continue to work because of the NFS mounted disks.
A remote tape drive is accessed just as any other resource in iraf using the 'node!' syntax, for example
cl> alloce ursa!mta
to allocate a tape known as 'mta' on the node 'ursa'. In all commands that reference the drive the device name must have the node! syntax. This requires that IRAF networking has been configured between the two machines, by making appropriate modifications to the dev$hosts file. The node!device syntax differentiates the device from a device known by the same name on the local machine.
The individual tapecap fields are defined entirely in the program header comments for the IRAF tape driver, $iraf/unix/os/zfiomt.c. This information however does not explain fully how to set these values. A more detailed description of the tapecap file can be found in the platform Site Manager's Guide for each platform. An explanation of the various fields was given in the last issue of the Newsletter and is available as
If you still have questions about tapecaps or need an example entry from which to begin, contact site support.
This requires that IRAF be installed successfully on both the Unix and VMS hosts, and that the tape drive be configured correctly for local access. Once that is done the VMS system is added to the Unix system's dev$hosts file wo that the rexec-callback protocol be used to make the conn- ection. For example, if the unix host is 'tucana' and the VMS host is known as 'robur', then tucana's dev$hosts file would contain an entry of the form
robur : -rcb robur!irafks
This says that from tucana the rexec-callback protocol (the '-rcb') is to be used to connect to robur. On the VMS system the IRAF kernel server will access the tape and pass the output through the network back to the local host. On systems where the only reason to access a VMS system is for tape access users should contact the iraf group for a "kernel server kit" which can be used in place of a full-fledged IRAF installation.
With V2.10 IRAF and after, the default protocol used for IRAF networking between between two Unix hosts is rsh. In this situation, with a properly configured host network, the password prompts should not appear. If it does, then the 'rexec' protocol, not rsh, is being used to make the connection. This can happen for several reasons. The /etc/hosts.equiv file names the "trusted hosts" in the network, meaning that the 'rsh' command at the host level can be used between machines. System administrators sometimes worry about this being a security hole and won't set up the hosts.equiv file or else it's incomplete on all systems. One workaround for this is to put the name of the hosts in a personal '.rhosts' file in the user's login directory to accomplish the same thing. The rsh protocol can also fail if the user doesn't have an account or has a different password on the remote machine. To use the rexec protocol explicitly users can add the passwd in their .irafhosts file for a particular node along with a parameter override. For example
pisces : tapeuser tapetape protocol=rex * : <user> <user>
In this case any network connection to node 'pisces' will be done as a user named 'tapeuser' whose password is 'tapetape' using the rexec protocol. All other connections to other nodes (which match the '*') will be done in the normal way, if the rsh fails then once again the passwd prompt will appear. This is most often done to connect to a remote resource on a machine on which they don't have an account or the login/passwd is different. Note that the '*' entry must be the last line in the file, any nodes which follow it will be ignored.
When you install IRAF networking (by adding your host names to dev$hosts), IRAF networking is used for all remote access of peripherals (tapes) and disks, as well as remote imtool use. Wherever the CL encounters the node! syntax and the nodename appears in dev$hosts, IRAF networking will be used. IRAF networking must be used for remote tape access and remote use of IMTOOL. You can disable it for disk access (and so use NFS to access the disks) by some creative editing in the dev$hosts file. IRAF networking is used when the local and remote node appear on separate lines in dev$hosts; in this way they are defined as distinct nodes. If two node names appear on a single line, they are aliased and interpreted as being the same node. You can alias those nodes which you will not need IRAF networking. You may want to create a new node name to be used exclusively for tape access. Say you have three nodes (ast1, ast2, ast3) and ast1 has the tape drive. Edit dev$hosts to include the following, with appropriate pathname substitutions; note that only the KS pathname for the tape node will actually be used: ast1 ast2 ast3 : ast1!/iraf/iraf/bin.ssun/irafks.e astmt : ast1!/iraf/iraf/bin.ssun/irafks.e IRAF networking has been disabled for nodes ast and will not be used to access pixel files beginning with those nodenames. For tape access, the user has to reference the new node name, as in:
cl> rfits astmt!mta