iraf.net

Jeannette and I spent the day on the mountain yesterday with Jim Davis,
checking out and fixing up the various IRAF systems. IRAF was recently
propagated to each of five workstations rather than being served from a
central server. Before beginning, we were briefed by Bruce Bohannan on
some things he wanted fixed. Not all policy decisions have been made yet,
particularly with regard to coordination of visitor and staff accounts
on the mountain vs. downtown now that the T1 line is in (boy, that's great!).
We discussed the current necessity for .irafhosts files in visitor accounts
on the mountain and pointed out that this mechanism will be disappearing in
a future iraf release. iraf workstations:
khaki 4meter Sun3/260 + fpa
lapis 2meter Sun3/260 + fpa
taupe 36inch Sun3/260 + fpa
scarlet 50inch Sun3/260 + fpa
elsol mcmath Sun3/260 + fpa other systems of interest, no iraf at present:
bordeaux jdavis Sun4/65 (currently the mail server)
burgundy Sun3/50, diskless
claret coude Sun SLC [pending]
crystal ? terminal serverHere are some of the things we did: dev$hosts
Replaced "bin" with "bin.ffpa" on all systems in the irafks.e path.
These systems are of course configured generic, and iraf networking
apparently never worked in the past.

dev$devices
Added unix magtape aliases on a couple of machines.

node!local$notes.<node>
Started little local notes files for/on each node. hlib$extern.pkg
/u3/local/iraf/kpnolocal/local.cl
Cleaned up the external package definitions on each node. Many
had been commented out because of runtime problems with help and
the like due to things not being where they were said to be.
In local.cl, commented out the interpretation of local$lib/extern.pkg,
since none of the subpackages added was available on the mountain
anyway. Originally all the extern.pkg entries pointed to /local/...
The symbolic links were at least this complicated; I might be
forgetting something in between. /local -> /tmp2/local
/tmp2 -> /u3 (==> /local/iraf -> /u3/local/iraf) Jim is going to settle on a plan for all the mountain workstations
and clean up the disk partitions and symbolic links.

/u3/4meter/.irafhosts [khaki]
/u3/2meter/.irafhosts [lapis]
/u3/50inch/.irafhosts [scarlet]
/u3/36inch/.irafhosts [taupe]
/usr/local/lib/acct/setup_acct.4meter [khaki]
/usr/local/lib/acct/setup_acct.2meter [lapis]
/usr/local/lib/acct/setup_acct.50inch [scarlet]
/usr/local/lib/acct/setup_acct.36inch [taupe]
Fixed an incorrect syntax which effectively disabled all iraf
networking. When a new visitor arrives, that setup_acct shar
script is run (by a tech assistant?) via a /usr/local/bin/setup_acct
script to reinitialize the visitor account files, including
.irafhosts, login.cl etc. He will need to fix some things, e.g.
right now the visitor sees the message 'setting terminal to vt640'
(from system wide mkiraf; default should be set to gterm), while the
shar script creates a loginuser.cl that stty's to gterm but doesn't
notify the user. Jim is going to replace the shar script with a more conventional shell
script (he prefers the bourne shell) and template files, similar to what
we do with mkiraf.csh. This will be a lot easier to understand and
modify. He will coordinate with us on the contents of the template
files (loginuser.cl, .login, .cshrc, .irafhosts, .sunview-startup files,
etc.) before finalizing this scheme.We made sure all the hardcopy functions worked from each visitor account
at the 4 kpno nodes lapis, khaki, scarlet, and taupe, and made sure that iraf
networking including magtape access worked from those 4 nodes and elsol,
the mcmath workstation. Jim is going to fix up the UNIX printer device
names and aliases on all machines rather than edit and separately maintain
dev$graphcap & termcap files. The default printer on each node is and will
remain the printer in the same room (lw), but one could request a printout
on any other printer on the mountain if desired (if the local printer goes
down for instance). He intends to provide aliases like khaki for khaki's
printer; lw1 will then point to a single printer, not lw=lw1 separately for
each node.Someone is going to have to decide which/whether downtown nodes should be
available by iraf networking; for the time being we made tucana and ursa
available under "temporary" in dev$hosts.We didn't do much on elsol other than make sure that iraf networking and
the devices file were up to date, as this machine is more the purview of
nso. Elsol has no external packages at present, and it is not clear
whether any are desired.Currently bordeaux has 1Gb of disk but no iraf. Jim is planning to put
the master iraf system on bordeaux, and use rdist to propagate it to the
other nodes. He knows rdist, and decided to use something like our currently
pending scheme to wrap mkpkg files around rdist to manage it more easily.The external packages that are present are slightly different on the
different nodes, based upon need. Some are less up to date than their
downtown counterparts, and Jim will be coordinating with us on how best
to manage them.At the 2meter (or was it the 36inch?) Jim Deveny was present, and Jeannette
suggested we use iraf networking to display a bias frame just taken on the
instrument, into the imtool window currently running in the downtown ouv
workstation (after coordinating with them of course). This worked without
a hitch.