[daip] AIPS install
Tim Robishaw
robishaw at physics.usyd.edu.au
Fri Jan 9 00:09:52 EST 2009
Hi there Eric,
Thanks a ton for the pointers! Everything is up and running and
working smoothly. I've attached the detailed notes that I took for
getting this up and running here, just in case they're of any use. A
few questions came about from these, but nothing that's preventing us
from using aips... these are just questions that I wasn't able to find
the answer to in the cookbook or install pages.
* What is the difference between the DA00 and DATA directories? I
wasn't able to parse why the DATA directory needs to exist. I have
placed symbolic links to multiple drives in the DATA directory because
that seems to be what the installation guides suggest, but I don't
fully understand why I couldn't just keep links to all DATA areas in
DA00. This has been really mysterious to me throughout the process.
* The SPACE file was the root of all my problems; I did see that I
completely missed this important note on the Manager's FAQ. Thanks
for sorting this out. So, after running SYSETUP and creating SPACE,
aips will now start but it complains about not finding the file
"MSD001000.001;" so it has to be copied manually (from the disk space
of the HOST on which I installed aips). Don't know what this file is,
but should/can it be included in the TEMPLATE directory? And a blank
SPACE file for that matter?
* I've set 8 0's in NETSP for each user data area, so a user with any
user number can access these drives. Now that I've done this, a user
can type any old user number when they enter aips and all will work
since the drives aren't restricted. However, should we be using
unique assigned aips user numbers among us, and, should each user be
using the same aips user number each time? Empirically, I'd imagine
I'd find out pretty readily if varying the user number causes
problems, but it would be good to know what to do before I goof
anything up.
Thanks again for the help! Best -Tim.
On Wed, 7 Jan 2009, Eric Greisen wrote:
> You have become pretty expert. Note that we strongly recommend that the
> actual disk data areas and the ones $AIPS_ROOT/DA00/<hostname> actually be on
> the intended host. This is because file locking over NFS occasionally fails
> and leaves files locked by no-longer existent processes. That said - the
> data areas require a 0-byte files names SPACE that has read/write privilege
> for anyone using it. That is probably what is missing.
>
> The security issue could be addressed by inventing a new group, assigning all
> files and data areas to that group, and putting the would be users in that
> group (as one of the secondary groups). Your sysadmin could do that part for
> you.
>
> Another note - the Linux load modules that we build with the Intel compiler
> run very much faster on Pentium IVs than gnu-build load modules. A binary
> install is easy and should perform better
>
> perl install.pl -n
------------------------------------------------------------------------
Tim Robishaw EMAIL: robishaw at physics.usyd.edu.au
School of Physics A29 PHONE: +61 2 9351 5577
The University of Sydney FAX: +61 2 9351 7726
NSW 2006 Australia WWW: http://www.physics.usyd.edu.au/~robishaw
-------------- next part --------------
* /usr/physics/AIPS
* lisa was put in charge of maintaining, but doesn't know how
* 2004 distribution, way out of date
* installing and maintaining new aips on /import/fenway2/robishaw/AIPS
* grab the perl installer install.pl from the aips site
* http://www.aips.nrao.edu/install.shtml
* go through all the setup and follow along; really well-documented.
* refer to pages:
* http://www.aips.nrao.edu/install.shtml
* http://www.aips.nrao.edu/aipsmgr/index.html
* http://www.aips.nrao.edu/install.ps
* before install, make sure to remove any ~/.AIPSRC file that might be left
over from a previous install.
* fenway is a 64-bit machine (e.g., type "arch" and see x86_64); we'd like
everybody to be able to use the aips that we're building, so we need to
build this with a 32-bit library so that the executable binaries are
32-bit.
* Ended up going with the binary install method. Eric tells us:
The Linux load modules that we build with the Intel compiler run very
much faster on Pentium IVs than gnu-build load modules. A binary
install is easy and should perform better
> ./install.pl -n
* just use "astrop" group
* site name = USYD
* we added hosts: ARSENAL MARVIN ANILA
* just put the suggested value here and fix stuff later by hand; found
that using the symbolic link syntax here didn't quite work.
* we set up the printers:
astroplw2 [PS] and colourlw5 [COLOR]
* ${NET0} = ${AIPS_ROOT}/DA00 (where DA = Data Area)
* the directories in ${AIPS_ROOT}/DA00 are the host names, i.e.,
${AIPS_ROOT}/DA00/FENWAY
* From the wicked old PostScript installation guide:
An environment variable $DATA_ROOT will usually be set to $AIPS_ROOT/DATA/,
and this area can either contain the actual user data directories
themselves or symbolic links to the real data areas.
* if you want to add other non-hostname data areas, do it using the da=
option when starting aips
* We're taking the suggested approach of having the directories in $NET0
and $DATA_ROOT be symbolic links to directories that are actually
stored on the disks that are local to each host.
* To add new hosts, put them in ${AIPS_ROOT}/HOSTS.LIST
* To add new data areas, put them in:
* ${AIPS_ROOT}/DA00/DADEVS.LIST
# PRIMARY HOST DATA AREAS...
- /import/fenway2/robishaw/AIPS/DA00/FENWAY
- /import/fenway2/robishaw/AIPS/DA00/ARSENAL
- /import/fenway2/robishaw/AIPS/DA00/MARVIN
- /import/fenway2/robishaw/AIPS/DA00/ANILA
#
#
# OTHER HOST DATA AREAS...
- /import/fenway1/robishaw/AIPS/DATA/FENWAY_1
- /import/fenway2/robishaw/AIPS/DATA/FENWAY_2
- /import/fenway2/robishaw/AIPS/DATA/ARSENAL_1
- /import/fenway2/robishaw/AIPS/DATA/ARSENAL_2
* ${AIPS_ROOT}/DA00/NETSP
# PRIMARY HOST DATA AREAS...
/import/fenway2/robishaw/AIPS/DA00/FENWAY 365.0 0 0 0 0 0 0 0 0
/import/fenway2/robishaw/AIPS/DA00/ARSENAL 365.0 0 0 0 0 0 0 0 0
/import/fenway2/robishaw/AIPS/DA00/MARVIN 365.0 0 0 0 0 0 0 0 0
/import/fenway2/robishaw/AIPS/DA00/ANILA 365.0 0 0 0 0 0 0 0 0
#
#
# OTHER HOST DATA AREAS...
/import/fenway2/robishaw/AIPS/DATA/FENWAY_1 365.0 0 0 0 0 0 0 0 0
/import/fenway2/robishaw/AIPS/DATA/FENWAY_2 365.0 0 0 0 0 0 0 0 0
/import/fenway2/robishaw/AIPS/DATA/ARSENAL_1 365.0 0 0 0 0 0 0 0 0
/import/fenway2/robishaw/AIPS/DATA/ARSENAL_2 365.0 0 0 0 0 0 0 0 0
* We took the approach of using the symbolic link names (i.e., the
locations in $NET0 and $DATA_ROOT, rather than the actual locations on
the drives of the host machines [the targets of the symbolic links])
* To prevent overworking disk heads, it's best to have 2 or more disk
areas when cleaning, one of them being a temporary scratch drive (set
up via the BADDISK adverb). These should be named in the $DATA_ROOT
directory as HOST_1, HOST_2, ... HOST_N
* there is a template directory located at:
${AIPS_ROOT}/31DEC04/LINUX/TEMPLATE/
all the files in this directory will have been copied to the
${NET0}/${HOST} directory for the HOST on which aips was built, but not
for the other hosts listed in ${NET0}. you need to run SYSETUP to
propagate these template files to the other hosts listed in HOSTS.LIST.
* each user needs to add the following to their .login or .cshrc or .bashrc
or .profile or whatever the hell they want to add it to so that their
shell knows about these variables (and obviously change the syntax from
cshell to bash or bourne or whichever is appropriate):
setenv AIPS_MSG_EMULATOR xterm
setenv AIPS_TEK_EMULATOR xterm
setenv AIPSREMOTE "ssh -n"
setenv AIPS_ROOT /import/fenway2/robishaw/AIPS
* each user needs to do SYSETUP themselves because, since I'm not
superuser, I can't propagate files to their local aips
directories. (I think this is true, but might be a lie... when I set up
the symbolic links, the SYSETUP script gave me errors when trying to copy
files to the local disks of other users... this is probably because the
directories local to each host were made without write permission set for
the group astrop; maybe this should be set!?) Anyway, for now, each user
should:
> source ${AIPS_ROOT}/LOGIN.CSH
and then run SYSETUP using whichever HOST aips was compiled on as the
master so that it can propagate the system files in the TEMPLATE
directory to the other HOSTS:
> SYSETUP ARSENAL
SYSETUP: Enter the AIPS manager account name [aipsmgr]: lhs
SYSETUP: Enter the AIPS user group name [aipsuser]: astrop
SYSETUP: Enter the "master" host name [arsenal.physics.usyd.edu.au]: fenway
SYSETUP: master = FENWAY
SYSETUP: Operating on 1 host: ARSENAL
SYSETUP: Is this acceptable? (yes/no) yes
SYSETUP: Processing ARSENAL...
* TOTALLY MISSED THIS NOTE FIRST TIME AROUND:
* The data area itself needs to have only one AIPS file before it may be
used. That file is called SPACE and can be a 0-byte file with write
privilege for anyone supposed to use that data area. It may be created
with the command "touch SPACE"
* But, it needs to have group write bit set! So...
> touch SPACE; chmod g+w SPACE
* HOWEVER, we've empirically discovered that the file MSD001000.001; is
not showing up either.
??? What is it and what can be done about it?
??? Should the above two files be copied to TEMPLATE? Then they
would be propagated by SYSETUP, right?
* users can futz with window properties by putting these in ~/.Xdefaults
and then typing xrdb -load ~/.Xdefaults
!!
!! aips
!!
AIPStv*geometry: 768x768+0+0
AIPSmsg*geometry: 90x77+0+0
AIPSmsg*background: azure
AIPSmsg*foreground: blue
AIPSmsg*iconStartup: False
AIPSmsg*saveLines: 10000
AIPSmsg*scrollBar: True
AIPSmsg*tekInhibit: True
AIPStek*geometry: +0-48
AIPStek*background: red
AIPStek*foreground: gold
AIPStek*iconStartup: False
AIPStek*scrollBar: False
AIPStek*tekInhibit: False
* set up a weekly update by running a cron job:
30 6 * * 0 /suphys/robishaw/bin/update_aips.fenway
* for a little while after aips is exited via kleenex, something happens to
prevent the XAS server from starting again, so it's prudent to wait a bit
before restarting aips. Here's the message:
MakeLink: bind error (INET): Address already in use
TVSERVER told to shut down by XAS
XAS: Quitting NOW.
* Lisa was getting this always on arsenal, so she had to start up using
> \aips tv=local
* This was highly correlated with the fact that she was running MIRIAD
with a display window open: when she closed miriad, typing plain old
"aips" without "tv=local" worked and the TV display opened with no
INET error.
* since the old useless aips still lives in /usr/physics/AIPS, users need
to either source ${AIPS_ROOT}/LOGIN.CSH before starting aips or put
${AIPS_ROOT} ahead of /usr/physics in their path.
* looks like the aips user number is set up in $AIPS_ROOT/DA00/NETSP
* the 8 0's means any user can join in...
* so typing any old user number seems to work for a USER ID NUMBER.
??? should we be careful to use the same number every time even though I
haven't restricted disk access in NETSP?
??? What is the strict difference between DA00 and DATA???
??? Should aips data directories local to each host have the group write
bit set? If we want multiple users to be able to access the data, yes!
More information about the Daip
mailing list