April 1, 2000

Where do I get IRAF?

Google IRAF or noao iraf, and get an up to date copy (and install instruction) from the official noao iraf website.

These notes are for the 2.11.3 release which runs on Red Hat Linux 6.1. If you are reading them today, I really can't imagine why.

You will find 4 scripts here, along with the stuff from noao. You will want to look at them and probably change some variables near the top to conform to your own setup.
"check_files" is a perl script to validate checksums and lump together a collective .tgz file from the pieces that noao distributes.
"unpack_iraf" is a shell script to unpack the big tar files and set up the directory structure (it automates the bulk of the install process).
"unpack_x11" is a shell script I use to unpack the parts of the x11iraf distribution and put them into /usr/local/bin and /usr/local/lib.
"install" is the script from /iraf/iraf/unix/hlib that is shipped with a syntax typo/bug. (Don't ask me why they don't rebuild their distribution and fix this.)

I also have the 2.11 release which runs on Red Hat Linux 5.x. and I also have the special patch release for Red Hat 6.0. These can probably still be found on: kofa.

If you want to run IRAF on Linux prior to Red Hat 4.x you are on your own, but there are some notes about how to get the 2.11 release to do this. (Red Hat 5.x began using a glibc based libc which is the issue here.)

How do I install IRAF on my RH 5.x system?

Well, if you are installing iraf on a RH5.x system look at my old notes. If you have already installed iraf on a 5.2 system, have upgraded to RH6.x and get something like this when you try to run it:
(/u1/fred) wally $ cl
/iraf/iraf/bin.redhat/cl.e: error in loading shared libraries:
/iraf/iraf/bin.redhat/cl.e: undefined symbol: __setfpucw
Then you need to reinstall iraf as per the following. (see the detailed info on the noao site).

How do I install IRAF on my RH 6.x system?

If you are installing on a RH6.x system, keep reading.

Getting ready

You can cat /proc/version to see what kernel you are running. If it reports something other than 2.2.5 you may be running something older than Red Hat 6.0. If it reports 2.2.12 or later you are probably running 6.1. It seems that RH6.0 and beyond are glibc based (just as RH5.x was), but we will find out when we get around to installing ximtool and other stuff in x11iraf.

Now decide where to put iraf. In my case I have a big /u1 partition and I put it there, so I do this (yes it seems like there are too many levels of iraf, but trust me here:

You will have to do the first part of this as root (up until where you tranform into the "iraf" user).

	mkdir /u1/iraf
	mkdir /u1/iraf/iraf
	ln -s /u1/iraf /iraf

Make and "iraf" group and user. I use uid and gid 502 for iraf, but you may have other ideas or needs. First edit /etc/group and put in the group:

Make an user "iraf" by entering the command: (you used to just edit the password file, but with the new md5 and shadow passwords that you are surely using, you need to use useradd).
useradd -c "Iraf Psuedo User" -u 502 -g 502 -d /iraf/iraf/local -s /bin/csh iraf
chown -R iraf:iraf /u1/iraf
Now find some place with enough room to hold the install files and get them there. This could be an nfs mounted partition or whatever suits your fancy. In my case I dumped them into /u2/iraf.

Also note that I keep one big tarball on my ftp site, but some folks without a "reget" on their ftp client may want the tarball split into a bazillion pieces, those will have to go to the noao site.

    /pub/iraf/rhux-6.0/as.pcix.gen.tgz --> /u2/iraf/
    /pub/iraf/rhux-6.0/ib.rhux.x86.tgz --> /u2/iraf/
    /pub/iraf/rhux-6.0/nb.rhux.x86.tgz --> /u2/iraf/

Unpacking the files

At this point the noao notes say to login as iraf, what I do (since I don't intend to set a password for iraf) is to just su to the user iraf (see below). Also since I have setup the iraf home directory, I don't get the warning they mention. Also notice that /iraf/iraf is already made.
	su - iraf
	whoami	(verify that I am iraf)
	setenv iraf /iraf/iraf/

	cd $iraf
	tar -xzvpf /u2/iraf/as.pcix.gen.tgz

	cd /iraf
	mkdir irafbin
	mkdir irafbin/bin.redhat
	mkdir irafbin/noao.bin.redhat

	cd $iraf/bin.redhat
	tar -xzvpf /u2/iraf/ib.rhux.x86.tgz

	cd $iraf/noao/bin.redhat
	tar -xzvpf /u2/iraf/nb.rhux.x86.tgz

Doing the install

First do the following little step that hardly seems to do anything.
	cd $iraf/unix/hlib
	source irafuser.csh
Now we are ready for the big install step. (This messes with stuff in /usr/local/bin, perhaps other places as well). If you are nervous, or curious, or both, run it first with the -n switch and it will ask questions, announce things, but hopefully do nothing. Then do it for real (as root).

Before you do this, watch out for the buggy install script shipped with the 2.11.3 iraf for Red Hat 6.1, the fixed script is available as mentioned above and goes into /iraf/iraf/unix/hlib.

Ignore the business about /usr/tmp and /d0/iraf, since we take care of this below.

	./install -n
Now we are ready to test this out by trying to start the CL. (We did the exit above to resume our identity as user iraf. It may want you to run mkiraf, so be cooperative if so.
	source .login
The following change is recommended by Skip Schaller here at Steward Observatory.

For each user that will use iraf, edit the login.cl as follows: replace:

	imdir = "/usr/tmp/xxxxxx"
	imdir = "HDR$pixels"
This means that each user will create image files and the pixels will be in a directory below the directory with the header (named pixels), rather than in some master image area (like /usr/tmp or /d0/iraf).

Cleaning up

Since you probably don't want the original tar files hogging space on your disk (to the tune of about 50M or so), just get rid of them!
	rm -rf /u2/iraf

Where the heck is imtool now?

So, you can't find imtool (and xgterm is nowhere to be found either). If you really want these (and I'll bet you do), you need to get the x11iraf package. Here is what I did:
	su iraf
	mkdir $iraf/x11iraf
	cd $iraf/x11iraf
	tar -xzpvf /u2/iraf/x11iraf-v1.1-linux-glibc-bin.tar.gz 
Then I distributed the pieces as follows:
	cp bin/* /usr/local/bin

Why does ximtool give me this weird message?

Does your message look something like this?
(/u2/iraf) wally $ ximtool
Warning: Cannot convert string "center " to type Justify
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  72 (X_PutImage)
  Serial number of failed request:  3674
  Current serial number in output stream:  3679
Congratulations, you have found the absolute nadir of all error messages ever produced by any piece of computer software at any place and at any time. You could study this message for as long as it would take monkeys typing on typewriters to produce the works of Shakespeare and still not have a clue as to what is wrong, so here is the straight scoop.

Type xwininfo on any window that seems willing to accept a command from you at a shell prompt and then click the mouse on, say, the background and you will see a long message like so:

(~/admin) kofa $ xwininfo

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x26 (the root window) (has no name)

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1152
  Height: 864
  Depth: 16
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x23 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -0+0  -0-0  +0-0
  -geometry 1152x864+0+0
The key thing in all of this is the PixelDepth. If it is anything other than 8, (here it is 16, which will not work), you are out of luck running imtool for the time being. There are a variety of tricks (dirty and otherwise) to get you going. The simplest thing is to restart your X server with an 8-bit pixel depth via a command that resembles:
	startx -- -bpp 8
The trouble with this is that with only 256 colors, you run out of them in a hurry (and things like images in Netscape look pretty shabby).

If your X server is cooperative, xnest can provide a solution, but I have no experience with this. The best option is probably to run X in a separate session at the requisite depth and use the Linux virtual consoles to switch back and forth. The essence of this is to use Control - Alt - Function key to select which virtual console you are running on. (Your usual session is in F7, try F1 or F2 for the 8 bit depth). For this to work you must have an 8 bit depth entry in your XF86Config file. (It also seems that virtual consoles confuse the daylights out of xdm.)

Details are available at: tdc-www.harvard.edu which I reproduce here.

Have any comments? Questions? Drop me a line!