UNIX/IRAF Site Manager's Guide

UNIX/IRAF Site Manager's Guide

2.2. Configuring the Device and Environment Tables

Teaching IRAF about the devices, network nodes, external programs, and other special resources available at a site is largely a matter of editing a standard set of device descriptor and environment setup files, all of which are simple text files. The versions of these files provided with the distribution are simply those in use on the NOAO system from which the distribution files were made, at the time the distributions were generated. Hence while these files may be useful as examples of properly configured descriptor files, the defaults, and many specific device entries, will in many cases be meaningless for a different site. This is harmless but it may be confusing to the user if, for example, the default printer doesn't exist at your site.

The device and environment files also contain much material which any site will need, so care must be taken when editing the files. Important changes may be made to the global portions of these files as part of any IRAF release. To facilitate future updates, it is wise where possible to isolate any local changes or additions so that they may simply be extracted and copied into the new (distributed) version of the file in a future update.

2.2.1. Environment definitions

Since IRAF is a machine and operating system independent, distributed system it has its own environment facility apart from that of the host system. Host system environment variables may be accessed as if they are part of the IRAF environment (which is sometimes useful but which can also be dangerous), but if the same variable is defined in the IRAF environment it is the IRAF variable which will be used. The IRAF environment definitions, as defined at CL startup time, are defined in a number of files in the unix/hlib directory. Chief among these is the zzsetenv.def file which defines the default hardcopy devices, image frame buffer, buffer sizes, etc. Additional user modifiable definitions may be given in the template login.cl file (see §2.2.2).

The zzsetenv.def file contains a number of environment definitions. Many of these define IRAF logical directories and should be left alone. Only those definitions in the header area of the file should need to be edited to customize the file for a site. It is the default editor, default device, etc. definitions in this file which are most likely to require modification for a site.

If the name of a default device is modified, the named device must also have an entry in the termcap file (terminals and printers used for text hardcopy) or the graphcap file (graphics terminals and image displays and graphics hardcopy printers) in iraf/dev. There must also be an editor.ed file in dev for the default editor; edt, emacs, and vi are examples of currently supported editors.

Sample values of those variables most likely to require modification for a site are shown below.

set editor      = "vi"
set printer     = "lpr"
set stdplot     = "lpr"
set stdimage    = "imt512"
For example, you may wish to change the default editor to "emacs", the default printer to "lw5", or the default image display to "imt800". Note that the values of terminal and stdgraph, which also appear in the zzsetenv.def file, have little meaning except for debugging processes run standalone, as the values of the environment variables are reset automatically by stty at login time. The issues of interfacing new graphics and image display devices are discussed further in §5.

2.2.2. The template LOGIN.CL

The template login.cl file hlib$login.cl, is the file used by mkiraf to produce the user login.cl file. The user login.cl file, after having possibly been edited by the user, is read by the CL every time a new CL is started, with the CL processing all environment and task definitions, package loads, etc., in the login file. Hence this file plays an important role in establishing the IRAF environment seen by the user.

Examples of things one might want to change in the template login.cl are the commented out environment definitions, the commented out CL parameter assignments, the foreign task definitions making up the default user package, and the list of packages to be loaded at startup time. For example, if there are host tasks or local packages which should be part of the default IRAF operating environment at your site, the template login.cl is the place to make the necessary changes.

2.2.3. The TAPECAP file

Since V2.10 IRAF magtape devices are described by the "tapecap" file, dev$tapecap. This replaces the "devices" file used in earlier versions of IRAF. The tapecap file describes each local magtape device and controls all i/o to the device, as well as device allocation.

In V2.10 IRAF there was one tapecap file per IRAF installation and all client nodes sharing the same central version installation required device entries in the global tapecap file. In V2.11 this scheme has been generalized to allow each host to have its own private tapecap file, with a fallback to the generic tapecap file if no host-specific file is found. The system will look first for a configuration file called tapecap.node where node is the hostname of the server the tapecap file describes. If that is not found the default tapecap file will be used. In this way a separate tapecap file can be created for each node allowing a name such as 'mta' to always refer to the first tape on that machine regardless of whether it varies in type from node to node. Alternatively, sites may wish to maintain only a single tapecap file with generic device names describing the different types of tape drives available on the local network. In either case the devices.hlp file described in the next section should be edited to document for the user the tape devices available at your site.

The tapecap files included in the distributed system include some generic device entries such as "mtxb1" (Exabyte unit 1, Sun ST driver), "mthp2" (HP7880 9 track drive, unit 2), and so on which you may be able to use as-is to access your local magtape devices. The exact list of available device types depend on the platform in question. Most likely you will want to add some device aliases, and you may need to prepare custom device entries for local devices. There must be an entry in the tapecap file for a magtape device in order to be able to access the device from within IRAF. All magtape device names must begin with the two-letter prefix "mt".

2.2.4. Configuring new TAPECAP entries

The tapecap file is text data base file (similar to the termcap and graphcap files) describing the capabilities and device names associated with a particular tape device on the system. For information on the format of the file see the termcap(5) man page. A listing of all recognized fields is given in the program comments for the tape driver in iraf$unix/os/zfiomt.c (more on this later). In general, creating a new tapecap entry for a device is a matter of finding a similar entry in the distributed file, and either using that directly if the device names are correct, or simply modifying it slightly to change device names so it will be appropriate for a drive on a different SCSI unit or using a different host driver. On occasion, other tapecap parameters will need to be added to correct for specific behavior that affects appending new data and tape positioning.

A tapecap entry for a device is usually divided into three different sections: a high-level entry giving the name of the drive as known to IRAF, a mid-level section defining the host device names associated with the drive, and a low-level generic section describing capabilities associated with all instances of a particular type of drive (DAT, Exabyte, 9-track, etc.). The starting point for the tapecap entry is whatever iraf name was used to access the drive. This is usually something like 'mta', 'mtb', etc but can be any valid name beginning with an 'mt' prefix and which defines all the needed parameters. When searching for a particular tapecap parameter the first occurrence of that parameter in the entry is used by the system, and a complete tapecap description is composed of all the entries which are linked by the :tc continuation fields.

As an example consider a typical entry for a DAT drive on unit 0 known to a Solaris/IRAF system as 'mta', the high-level entry would look like:

mta|Generic DAT entry, unit 0|         :tc=mtst0.solaris.dat:
Here we define the iraf name (which must begin with an 'mt' prefix) along with any aliases delimited by the '|'. The :tc field continues the tapecap at the next entry named "mtst0.solaris.dat":
mtsd0|mtst0.solaris.dat|DAT drive on Solaris:\\
      :al=0 0bn 0cb 0cn 0hb 0hn 0lb 0ln 0mb 0mn 0u 0ubn \\
      0b 0c 0cbn 0h 0hbn 0l 0lbn 0m 0mbn 0n 0ub 0un:\\
      :dv=0bn:lk=0:tc=solaris-dat:
This entry is primarily used to specify the host device names associated with the drive. The :al (aliases) field is a list of all device aliases in the UNIX /dev or /dev/rmt directories associated with this device. This is needed so the tape allocation task can properly change the permissions and ownership on each device name which accesses that tape drive. The :dv (device) field is the no-rewind device name and is the device file actually opened for tape I/O; this must be a no-rewind device since IRAF will maintain the tape position automatically. The actual device name typically depends on the density of the tape, whether compression is used etc. The :lk is used to build the name of a "lok file" that is created in the /tmp directory of the machine hosting the drive that will be used to maintain the tape status and position information; this value should be unique for each drive on the machine to avoid conflicts. When configuring a new tapecap entry, all one usually needs change is the iraf device name in the first section and the host device names in the :dv, :al and :lk fields of this entry. Finally this section continues the entry with a :tc field saying to branch to the "solaris-dat" generic entry:
solaris-dat|sdat-60m|Sun/Solaris DAT drive:\\
      :dt=Archive Python 4mm Helical Scan tape drive:tt=DG-60M:\\
      :ts#1274378:bs#0:mr#0:or#65536:fb#10:fs#127000:mf:fe#2000:
The low-level entry here is where parameters relating to all drives of a particular type using a particular host tape driver are maintained, e.g. the record sized used for tape I/O, positioning capabilities, filemark sizes, etc. These will rarely need to be changed from the distributed entries unless you are using a new tape driver or a different model tape drive, or a type of tape cartridge with a capacity different than that given ("tz"). See the section below for a full list of the tapecap parameters and their meanings.

For a more complicated example let's consider how to add an entry for an Exabyte 8505 drive given an existing entry for an Exabyte 8200 device. We can ignore for now the low-level entry found in the distributed tapecap and concentrate on what fields actually need changing in this case. We begin with the high-level entry defining the iraf names, we will need one name for the drive in each of three modes (8200 mode, 8500 mode, and 8500 mode w/ compression):

mta|Exabyte 8200, Unit 0|            :tc=mtst0.solaris.exb8200:
mtb|mtblo|Exabyte 8505, Unit 0|      :tc=mtst0.exb8505-lo:
mtbhi|Exabyte 8505, Unit 0|          :tc=mtst0.exb8505-hi:
mtbc|Exabyte 8505, Unit 0|           :tc=mtst0.exb8505-c:
The new iraf names are therefore mtb (8200 mode), mtbhi (8500 mode), and mtbc (8500 + compression). These all link to the second level entry where we make use of the existing EXB8200 entry:
mtsee0|mtst0.solaris.exb8200|Exabyte 8200 drive on Solaris:\\
        :al=0 0bn 0cb 0cn 0hb 0hn 0lb 0ln 0mb 0mn 0u 0ubn \\
        0b 0c 0cbn 0h 0hbn 0l 0lbn 0m 0mbn 0n 0ub 0un:\\
        :dv=0bn:lk=0:tc=solaris-exb8200:
mtsee0lo|mtst0.exb8505-lo|:dv=0lbn:tc=mtsee0:
mtsee0hi|mtst0.exb8505-hi|:dv=0mbn:fs#48000:ts#5000000:tc=mtsee0:
mtsee0hic|mtst0.exb8505-c|:dv=0cbn:fs#48000:ts#5000000:tc=mtsee0:
Note that the names we just created link to the one-line entries below the standard EXB 8200 entry 'mtst0.solaris.exb8200' (the mtb entry could just as legally have linked to this entry right away). Since all we need to change is the :dv field (because we're opening the same drive, but by using a different name the host system accesses it in the appropriate mode) we can simply make a new entry point, change the :dv field and then link to the existing entry where all the rest of the parameters will be the same. In this case we've also reset the :fs and :ts fields to override the values in the low-level Exabyte description since these have also changed for the new model drive. If we wished to modify this entry for a drive on e.g. unit 2 all we would need to do is modify the various :dv, :al, and :lk fields so the device names are correct, and change the name of the tapecap entry points so we avoid any confusion later on.

When configuring a new tapecap and encounter problems it is useful to turn on status output so you get a better idea of where the tape is positioned and what's going on, to do this use the :so field as follows:

cl> set tapecap = ":so=/dev/tty"
Alternatively, the :so can be specified on the command line, e.g.
cl> rewind "mta[:so=/dev/tty]"
Any other tapecap parameters can be specified in the same way. The quotes around the tape name are required if any special characters such as '=' are included in the device name string. Status output like this can also be directed to an Xtapemon server running either locally or remotely, see the xtapemon man page for details. Help with configuring new tapecap entries is available from IRAF site support.

2.2.4.1. More on TAPECAP parameters

As we see from the previous section, in most cases the only tapecap parameters that need to be changed are :dv, :al, and maybe :lk. There are however a number of other tapecap parameters that sometimes must be modified to describe how the tape device operates or to optimize I/O to the device. A full listing of the available tapecap parameters can be found in the program comments for the iraf tape driver iraf$unix/os/zfiomt.c; we will only briefly discuss a few here. Any changes you make with the parameters mentioned here can usually go in the low-level tapecap entry so they will "fix" all drives of the same type, however you may also wish to modify just the high-level entry to change only one drive. For example:

mta|Generic DAT entry, unit 0|      :se:ow:tc=mtst0.solaris.dat:
would add the ":se:ow" fields (discussed below) to only the mta device.

Boolean tapecap parameters may be negated if you are linking to an existing entry which already defines a particular field. For example, in

mta|Generic DAT entry, unit 0|      :se@:tc=mtst0.solaris.dat:
the '@' character would negate the :se field regardless of whether it is defined elsewhere in the entry.

One of the most common problems encountered is that only odd-numbered images on a tape are readable by the drive. The solution to this is usually to add a se to the tapecap to tell the driver that the tape will position past the EOT in a read. Another common problem is with appending new data to an existing tape, this sometimes requires the addition of a ow field to tell the driver to backspace and overwrite the EOT when appending. A re is sometimes needed if there is a problem sensing the EOT when reading all images from a tape, this tell the driver that a read at EOT returns an ERR.

The parameter fb may be specified for a device to define the "optimum" FITS blocking factor for the device. Unless the user explicitly specifies the blocking factor, this is the value that the V2.11 wfits task will use when writing FITS files to a tape. Note that for cartridge devices a FITS blocking factor of 22 is used for some devices; at first this may seem non-standard FITS, but it is perfectly legal, since for a fixed block size device the FITS blocking factor serves only to determine how the program buffers the data (for a fixed block device you get exactly the same tape regardless of the logical blocking factor). For non-FITS device access the magtape system defines an optimum record size which is used to do things like buffer data for cartridge tape devices to allow streaming.

Some devices, e.g. most Exabyte drives, are slow to switch between read and skip mode, and for files smaller than a certain size, when skipping forward to the next file, it will be faster to read the remainder of the file than to close the file and do a file skip forward. The fe parameter is provided for such devices, to define the "file equivalent" in kilobytes of file data, which can be read in the time that it takes to complete a short file positioning operation and resume reading. Use of this device parameter in a tape scanning application such as rfits can make a factor of 5-10 difference in the time required to execute a tape scan of a tape containing many small files.

On a device such as most cartridge tape devices where backspacing is not permitted or does not work reliably it may be necessary to set the nf parameter to tell the driver to rewind and space forward when backspacing to a file.

Lastly, when configuring a new low-level generic entry for the device it is sometimes necessary to change the various size parameters for the drive. These include:

bs           device block size (0 if variable)
fb           default FITS blocking factor (recsize=fb*2880)
fe           time to FSF equivalent in file Kb
mr           maximum record size
or           optimum record size
fs           approximate filemark size (bytes)
ts           tape capacity (Mb)
dn           density
All but the last three fields are used either by the driver or a task when reading or writing a tape, the :fs, ts and :dn fields are used by tape monitoring tasks such as xtapemon to compute the approximate amount of tape used and do not affect tape operation. For devices which are capable of variable block size I/O (i.e. almost anything but a cartridge tape) it is best to leave the bs field at zero. The maximum and optimum record sizes, the mr and or fields, are usually determined by the host tape driver used. Values for these can either be found in the host driver man page or it's system include file.

2.2.5. The DEVICES.HLP file

All physical devices that the user might need to access by name should be documented in the file dev$devices.hlp. Typing

cl> help devices
or just
cl> devices
in the CL will format and output the contents of this file. It is the IRAF name of the device, as given in files such as termcap, graphcap, and tapecap, which should appear in this help file followed by a brief description of the device, see the distributed file as an example. Starting with V2.10 this file in no longer used to configure tape devices, it is informational only.

2.2.6. The TERMCAP file

There must be entries in this file for all local terminal and printer devices you wish to access from IRAF (there is currently no "printcap" file in IRAF). The entry for a printer contains one special device-specific entry, called DD. This consists of three fields: the device name, e.g. "node!device", the template for the temporary spoolfile, and the UNIX command to be used to dispose of the file to the printer. On most UNIX systems it is not necessary to make use of the node name and IRAF networking to access a remote device since UNIX lpr already provides this capability, however it might still be useful if the desired device does not have a local lpr entry for some reason. Printer devices named in this file may be used for text hardcopy output such as you get from the LPRINT task, graphics hardcopy devices are configured by editing the graphcap file discussed in the next section.

As an example, assume we have a printer known to the sun as 'lw5', the termcap entry would look something like:

lw5|lp5|                                :tc=sapple5:
sapple5|sapple|Apple laser writer NT on Orion:\\
    :co#80:li#66:os:pt:ta^I:\\
    :DD=lpnode!apple,/tmp/asfXXXXXX,!{ lpr -Plw5 $F; rm $F; }:
To then create an entry for a new device named 'lw16' simply copy this entry and change the '5' to '16' in the device and termcap entry names, and especially in the lpr command of the DD string. The $F denotes the name of the file to be printed, specifically the temp file created so it should be removed to avoid filling up the disk. Note that the DD string can contain any valid unix command to print a file to a specific device, we use various local print commands, Enscript, etc.

If you have a local terminal which has no entry in the IRAF termcap file, you probably already have an entry in the UNIX termcap file. Simply copy it into the IRAF file; both systems use the same termcap database format and terminal device capabilities. However, if the terminal in question is a graphics terminal with a device entry in the graphcap file, you should add a `:gd' capability to the termcap entry. If the graphcap entry has a different name from the termcap entry, make it `:gd=gname'.

2.2.7. The GRAPHCAP file

There must be an entry in the graphcap file for all graphics terminals, batch plotters, and image displays accessed by IRAF programs. We will discuss each briefly since the setup is slightly different in each case. Help preparing new graphcap device entries is available from iraf site support if needed, but with the exception of new graphics terminals creating an entry for a new device is usually just a matter of editing an existing entry. We ask that new graphcap entries be sent back to us so that we may include them in the master graphcap file for all to benefit.

2.2.7.1. Graphics hardcopy devices

Graphics hardcopy devices nowadays are typically Postscript printers, but support is included in the system for various pen and raster plotters, and non-PostScript printers such as HP LaserJet, Imagen, QMS, etc. We will concentrate here on PostScript devices since they are the most common. The typical graphcap entry will look something like

lp5|lw5|                :tc=uapl5:
uapl5|UNIX generic interface to 300dpi printer on Orion:\\
    :xs#0.269:ys#0.210:ar#0.781:\\
    :DD=apl,tmp$sgk,!{ sgidispatch sgi2uapl $F -l$(XO) -w$(XW) \\
    -b$(YO) -h$(YW) -p$(PW) | lpr -Plw5; rm $F; }&:tc=sgi_apl:
where the device is known to the system as lw5 or lp5. The entry is very similar in form to the termcap entry discussed above, and changing it for a new device is primarily a matter of changing the device names. The exception however is in the DD string: here instead of a simple print command we invoke an SGI translator via the sgidispatch command (in this case the sgi2uapl translator) which is used to the convert the graphics kernel metacode to PostScript for the final printing. The arguments to the sgi2uapl translator are the device resolution and offset parameters obtained from the sgi_apl entry linked by the :tc field at the end of the graphcap entry. The output from the translator is piped to a printer and the temp file is removed.

If we wish to convert this entry for a different type of printer, aside from the changing the name in the graphcap entries and the print command, the DD string may have to be changed to call a new SGI translator with the appropriate arguments, and the final :tc field would have to link to a new entry appropriate for that device. In V2.11 the following SGI translators are available:

sgi2uapl.c  - PostScript for LaserWriters and PS plotters
sgi2ueps.c  - Encapsulated PostScript, PS-Adobe-3.0, EPSF-3.0
sgi2uhpgl.c - HP Graphics Language for HP 7550A and others
sgi2uimp.c  - Impress language for Imagen printers
sgi2uqms.c  - QMS Vector Graphics (Talaris Lasergrafix)
sgi2uhplj.c - HP Printer Command Language (LaserJet Series)
sgi2uptx.c  - Printronix plotter
In addition, Versatec plotters are supported (no SGI translator needed).

2.2.7.2. Image display frame buffers

Graphcap entries are required to configure the available stdimage devices for the system. These are basically just frame buffer configurations describing the size of the image display being used (whether it's an actual frame buffer such as an IIS mode 70 or a display server such as XImtool or SAOimage). A typical entry for a 512x512 frame buffer looks like:

imt1|imt512|imtool|Imtool display server:\\
    :cn#1:LC:BS@:z0#1:zr#200:DD=node!imtool,,512,512:tc=iism70:
Here the :cn field is the configuration number and the frame buffer size is given in the DD field. For display servers such as XImtool the configuration number is passed to the server which then uses that as an index to the imtoolrc file (normally installed by the system as a link to dev$imtoolrc) it uses to determine the frame buffer size to be used. When adding a new frame buffer you need to be sure the :cn field is unique and the size in the graphcap file agrees with the size in the imtoolrc file for that config, both files must be edited for the new size to be recognized correctly. Note that SAOimage has a limit of 64 possible frame buffers that will be recognized, XImtool and SAOtng recognize up to 128 possible configurations.

2.2.7.3. Graphics Terminals

New graphics terminals will need a new entry in the graphcap file if one does not already exist. The IRAF file gio$doc/gio.hlp contains documentation describing how to prepare graphcap device entries. A printed copy of this document is available from the iraf/docs directory in the IRAF network archive. However, once IRAF is up you may find it easier to generate your own copy using help, as follows:

cl> help gio$doc/gio.hlp fi+ | lprint
This will print the document on the default IRAF printer device which will be the default printer for your machine or the one named by your UNIX PRINTER environment variable (use the "device=" hidden parameter to specify a different device). Alternatively, to view the file on the terminal,
cl> phelp gio$doc/gio.hlp fi+
The help pages for the IRAF tasks showcap and stty should also be reviewed as these utilities are useful for generating new graphcap entries. The i/o logging feature of stty is useful for determining exactly what characters your graphcap device entry is generating. The gdevices task is useful for printing summary information about the available graphics devices.

2.2.8. Configuring IRAF networking

The dev directory contains several files (hosts, irafhosts, and uhosts) used by the IRAF network interface. IRAF networking is used to access remote image displays, printers, magtape devices, files, images, etc. via the network. Nodes do not necessarily have to have the same architecture, or even run the same operating system, so long as they can run IRAF.

To enable IRAF networking for a UNIX/IRAF system, all that is necessary is to edit the "hosts" file. Make an entry for each logical node, in the format

nodename [ aliases ] ":" irafks.e-pathname
following the examples given in the hosts file supplied with the distribution (which is the NOAO/Tucson hosts file). Note that there may be multiple logical entries for a single physical node.

The "uhosts" file is not used by UNIX/IRAF systems hence does not need to be modified (it used by VMS/IRAF). The "irafhosts" file is the template file used to create user .irafhosts files. It does not have to be modified, although you can do so if you wish to change the default parameter values given in the file.

To enable IRAF networking on a particular IRAF host, the host OS hostname (i.e. the output of the unix hostname command) must appear as a primary name or alias somewhere in the IRAF hosts table. On systems where this is the fully qualified host name (FQHN) the node name may exceed a limit 16-character limit on a node name so at least one alias should include a truncated version of the FQHN, the entire FQHN should appear on the right side of the ':' in the irafks.e pathname. During process startup, the IRAF VOS looks for the system name for the current host and automatically disables networking if this name is not found. Hence IRAF networking is automatically disabled when the distributed system is first installed - unless you are unlucky enough to have installed the system on a host with the same name as one of the nodes in the NOAO host table. Note that it may be best to simply delete the NOAO host table entries since any duplicate with a local host entry will will cause the IRAF "cd" command to fail and may have other consequences.

Once IRAF networking is configured, the following command may be typed in the CL to verify that all is well:

cl> netstatus
This will print the host table and state the name of the local host. Read the output carefully to see if any problems are reported.

Alternatively users can set up a private hosts table by copying the system version and making any additions. To then make use of this define a CL environment variable irafhnt which is the path to the private hosts file. For example,

cl> copy dev$hosts home$myhosts      # make private copy
cl> edit home$myhosts                # edit any changes
cl> reset irafhnt = home$myhosts     # reset hosts table to be used
cl> flpr 0                           # reinitialize system to use it
You can also define a UNIX irafhnt variable in the same way prior to logging into the CL to accomplish the same thing.

For IRAF networking to be of any use, it is necessary that IRAF be installed on at least two systems. In that case either system can serve as the server for an IRAF client (IRAF program) running on the other node. It is not necessary to have a separate copy of IRAF on each node, i.e., a single copy of IRAF may be NFS mounted on all nodes (you will need to run the IRAF install script on each client node). If it is not possible to install IRAF on a node for some reason (either directly or using NFS) it is possible to manage by installing only enough of IRAF to run the IRAF kernel server. Contact IRAF site support if you need to configure things in this manner.

UNIX IRAF systems currently support only TCP/IP based networking. Networking between any heterogeneous collection of systems is possible provided they support TCP/IP based networking (virtually all UNIX-based systems do). The situation with networking between UNIX and VMS systems is more complex. Contact the IRAF project for further information on networking between UNIX and VMS systems.

Once IRAF networking is enabled, objects resident on the server node may be accessed from within IRAF merely by specifying the node name in the object name, with a "node!" prefix. For example, if foo is a network node,

cl> page foo!hlib$motd
cl> allocate foo!mta
cl> devstatus foo!mta
In a network of "trusted hosts" the network connection will be made automatically, without a password prompt using the rsh protocol. A password prompt will be generated if the user does not have permission to access the remote node with UNIX commands such as rsh. Hosts are made "trusted" in a network by listing them in the system /etc/hosts.equiv file, most often when rsh fails it's because this file hasn't been configured, usually for security reasons. User's can configure a .rhosts file in their UNIX login directories (see the rhosts(5) man page) to make the hosts trusted for their account and bypass the passwd prompt. Each user also has a .irafhosts file in their UNIX login directory which can be used to exercise more control over how the system connect to remote hosts. See the discussion of IRAF networking in the IRAF Version 2.10 Revisions Summary (in iraf$doc/v210revs.ms), or in the V2.10 system notes file, for a more in-depth discussion of how IRAF networking works.

To keep track of where files are in a distributed file system, IRAF uses network pathnames. A network pathname is a name such as "foo!/tmp3/images/m51.pix", i.e., a host or IRAF filename with the node name prepended. The network pathname allows an IRAF process running on any node to access an object regardless of where it is located on the network.

Inefficiencies can result when image pixel files are stored on disks which are cross-mounted using NFS. The typical problem arises when imdir (the pixel file storage directory) is set to a path such as "/data/iraf/user/", where /data is a NFS mounted directory. Since NFS is transparent to applications like IRAF, IRAF thinks that /data is a local disk and the network pathname for a pixel file will be something like "foo!/data/iraf" where "foo" is the hostname of the machine on which the file is written. If the image is then accessed from a different network node the image data will be accessed via an IRAF networking connection to node "foo", followed by an NFS connection to the node on which the disk is physically mounted, causing the data to traverse the network twice, slowing access and unnecessarily loading the network.

A simple way to avoid this sort of problem is to include the server name in the imdir, e.g.,
cl> set imdir = "server!/data/iraf/user/"
This also has the advantage of avoiding NFS for pixel file access - NFS is fine for small files but can load the server excessively when used to access bulk image data.

Alternatively, one can set imdir to a value such as "HDR$pixels/", or disable IRAF networking for disk file access. In both cases NFS will be used for image file access.

2.2.9. Configuring the IRAF account

The IRAF account, i.e., what one gets when one logs into UNIX as "iraf", is the account used by the IRAF site manager to work on the IRAF system. Anyone who uses this account is in effect a site manager, since they have permission to modify, delete, or rebuild any part of IRAF. For these and other reasons (e.g., concurrency problems) it is recommended that all routine use of IRAF be performed from other accounts (user accounts).

If the system has been installed according to the instructions given in the installation guide the login directory for the IRAF account will be iraf/local. This directory contains both a .login file defining the environment for the IRAF account, and a number of other "dot" files used to setup the IRAF system manager's working environment.

Most site managers will probably want to customize these files according to their personal preferences. In doing this please use caution to avoid losing environment definitions, etc., which are essential to the correct operation of IRAF, including IRAF software development and maintainence.

The default login.cl file supplied in the IRAF login directory uses machine independent pathnames and should work as-is (no need to do a mkiraf - in fact mkiraf has safeguards against inadvertent use within the IRAF directories and may not work in iraf/local). It may be necessary to edit the .login file to modify the way the environment variable IRAFARCH is defined. This variable, required for software development but optional for merely using IRAF, must be set to the name of the desired machine architecture, e.g., sparc, vax, rs6000, ddec, etc. If it is set to the name of an architecture for which there are no binaries, e.g., generic, the CL may not run, so be careful. The alias setarch, defined in the iraf account .login, is convenient for setting the desired architecture for IRAF execution and software development.

2.2.10. Configuring user accounts for IRAF

User accounts should be loosely modeled after the IRAF account. All that is required for a user to run IRAF is that they run mkiraf in their desired IRAF login directory before starting up the CL. Defining IRAFARCH in the user environment is not required unless the user will be doing any IRAF based software development (including IMFORT). Programmers doing IRAF software development may wish to source hlib$irafuser.csh in their .login file as well.