[daip] AIPS install

[Eric Greisen]

Tim Robishaw wrote:
> 
> Hi there Eric,
> 
> I'm trying to install aips at the University of Sydney and I'm running 
> into a bit of a problem regarding user data areas.  I've carefully read 
> through install.shtml, the Cookbook, the old install.ps file as well as 
> the AIPS manager FAQ, but I'm really stumped.  I'm co-advising a summer 
> student with the aim of reducing some VLBA data (for which we need the 
> latest version of aips) so I thought I'd drop a line to see if there's 
> any advice that you might be able to offer.
> 
> ----------------------------------------
> 
> Executive summary: I've set up aips on my local machine (fenway) because 
> the sysadmin won't manage aips (he covers the whole school of physics in 
> addition to the astronomy dept) and has asked that I do so from my own 
> user account (this scares me because it seems permissions could well be 
> a problem).  I've specified 3 hosts (FENWAY MARVIN ARSENAL) and no 
> matter which host I try to run aips from, I receive a message like so:
> 
> START_AIPS: User data area assignments:
>   (Using global default file 
> /import/fenway1/robishaw/AIPS/DA00/DADEVS.LIST for DADEVS.PL)
>                   /import/fenway1/robishaw/FENWAY is currently unavailable.
> 
> START_AIPS: Cannot start AIPS because there are no defined data areas!
> START_AIPS: (check DADEVS.LIST or .dadevs files, or AIPSASSN.\*)
> 
> ----------------------------------------
> 
> Details: The installation goes smoothly. I give group ownership to 
> "astrop", which is the common shared group for all astronomers here. I 
> add the 3 hosts to HOSTS.LIST and then change DADEVS.LIST to include the 
> data disks for each host:
> 
> -  /import/marvin2/shami/MARVIN
> -  /import/fenway1/robishaw/FENWAY
> -  /import/arsenal1/lhs/ARSENAL
> 
> I then add the following to NETSP:
> 
> /import/arsenal1/lhs/ARSENAL 365.0    0    0    0    0    0    0    0 0
> /import/fenway2/robishaw/FENWAY 365.0    0    0    0    0    0    0 0    0
> /import/marvin2/shami/MARVIN 365.0    0    0    0    0    0    0    0 0
> 
> I compiled on arsenal (because my home computer, fenway, is an AMD64 
> with x86_64 architecture but the other machines are i686... thought it 
> would be safer to make sure all binaries are 32-bit), so I then ran 
> SYSETUP to propagate the template files to each DA00/HOST directory... 
> SYSETUP: Enter the AIPS manager account name [aipsmgr]: robishaw 
> SYSETUP: Enter the AIPS user group name [aipsuser]: astrop SYSETUP: 
> Enter the "master" host name [arsenal.physics.usyd.edu.au]: arsenal
> 
> SYSETUP: Operating on 3 hosts: ARSENAL FENWAY MARVIN
> 
> SYSETUP: Is this acceptable? (yes/no) yes
> 
> SYSETUP: Processing FENWAY...
> 
> SYSETUP: Processing MARVIN...
> 
> Now when I run LOGIN.CSH and try to start aips, I get the [disk] 
> "currently unavailable" message.
> 
> I tried the suggestion in the manager's FAQ of making symbolic links to 
> the data directories from $DATA.  I then tried (a) leaving the ACTUAL 
> DISK LOCATIONS in DADEVS.LIST and NETSP, and then (b) using the symbolic 
> link locations I'd created in $DATA, but neither fixed the "currently 
> unavailable" message.
> 
> I'm guessing there is something happening regarding group or owner 
> permissions; it's probably not ideal for me to be maintaining a shared 
> aips distro from my own home drive... it should probably be on a 
> department disk and maintained by someone with root permissions, but 
> that probably isn't going to happen.
> 
> Hope this wasn't too much of a core dump.  Any advice at all would be 
> hugely appreciated.

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

Eric Greisen