20001002: help is needed setting up McIDAS-X on RedHat 6.2 Linux

>From: "Jennie L. Moody" <address@hidden>
>Organization: UVa
>Keywords: 200010030228.WAA19313 McIDAS-X 7.613 RedHat Linux Dell

Jennie,

>Well, I thought I might be able to get things working.  
>I fixed the libraries, but I am not actually sure that
>by re-running the make (done end of last week) that I
>really replaced everything.  I reran agetserv by hand
>(make agetserv), but I still get the same error when I
>try to test out the build of mcidas (agetserv error when
>doing the first IMGDISP TOPO/CONF).  So, I am stuck.

I logged on and took a quick look in /home/mcidas/mcidas7.6/makelog.
This showed that the modules kb1aaa.o, kb2aaa.o, and kb3aaa.o were
for some reason not being added to libmcidas.a.  To check things out,
I did:

cd mcidas7.6/src
rm kb1aaa.f kb1aaa.o kb2aaa.f kb2aaa.o kb3aaa.f kb3aaa.o
make agetserv

The object modules kbnaaa.o were recreated OK, but they were still
not added to libmcidas.a.  So, I decided to do this by hand:

ar r libmcidas.a kb1aaa.o kb2aaa.o kb3aaa.o

and then remake agetserv:

make agetserv

This time, agetserv was created with no errors.  I then relinked everything
with:

make mcx

This led to an error that /home/mcidas/mcidas and /home/mcidas/mcidas/data
were not to be found.  These should have been created at the very beginning
of the build process.  Plowing ahead, I made the directories:

mkdir /home/mcidas/mcidas
mkdir /home/mcidas/mcidas/data

I could then run 'make mcx' to completion and do the install:

make mcx
make install.mcxall

The good news is that the machine is fast enough that the above only
took a couple of minutes.  The DSL network connection is nice and
usable also.  I can't wait until I get mine!

>I thought the mcadde account might be messed up, it
>had been added without a home directory, so I deleted
>it and remade it tonight, but it still seems to me that
>ahh, never mind, I am still confused (or reconfused, there
>was a time when I thought I got it) about the role
>of mcadde...

'mcadde' is the user the remote server runs under.  It allows remote
machines to access datasets.  It has the same HOME directory as
'mcidas' to keep down the number of accounts.  Its default SHELL is
/bin/false so nobody can login as 'mcadde'.

>is it even important when we are just
>trying to run as a client from local-data. 

No, not really EXCEPT for the following.  Let's assume that you have a
bunch of datasets on the local machine.  Each account that wants to run
McIDAS-X and access those datasets will have to have information setup
so that the sessions will know where to find the data files that make
up the datasets.  If you go through the remote server, on the other
hand, you only have to setup the location information in one place; in
the 'mcidas' account.  Then all that the other accounts have to do is
"point" (DATALOC) to the remote server for the dataset(s) that they
want to access.  Make sense?

>Maybe you can take a look around on the machine tonight.

The HOME directory of the user 'mcadde' should be the same as the HOME
directory of 'mcidas'.  The shell for 'mcadde' should be set to
/bin/false so that it is not a login account.  I made these changes as
'root' and removed /home/mcadde.  While at it, I:

<as 'root'>
chmod 775 /home/mcidas
mkdir /data
chown mcidas /data
chgrp mcidas /data

<as 'mcidas'>
mkdir /data/mcidas
mkdir /data/ldm
mkdir /data/ldm/surface
mkdir /data/ldm/surface/front
cd /home/mcidas/data
cp EXAMPLE.NAM LOCAL.NAM
<edited LOCAL.NAM and changed file locations to /data/mcidas>
cp DSSERVE.BAT LSSERVE.BAT
cp DATALOC.BAT LOCDATA.BAT
<edited LOCDATA.BAT and changed all dataset locations to 'localhost' except
for TOPO which I set to be LOCAL-DATA and RTGINI which set to be adde.ucar.edu>
<get the global topography image mainly to see how fast your DSL connection
is :-)>
ftp ftp.unidata.ucar.edu
  <user>  (passworded McIDAS FTP)
  <pass>
  cd data/topography
  binary
  get AREA9000
  quit

<setup dataset definitions>
cd /home/mcidas/workdata
te.k XCDDATA /data/mcidas
batch.k LSSERVE.BAT

<setup dataset locations>
batch.k LOCDATA.BAT

<updated to current bugfix (RedHat 6.2 Linux procedure is different from
online documentation due to a change in RH 6.2 'tar')>

cd /home/mcidas/mcidas7.6
ftp ftp.unidata.ucar.edu
  <user>
  <pass>
  cd unix/760/bugfix
  bin
  get mcupdateLinux.tar.Z
  quit

zcat mcupdateLinux.tar.Z | tar xvf -
cd src
make mcx
make install.mcxall

>Maybe this is more of a mess than I think....sigh.
>Why does everything have to be such a hassle?

It was not immediately obvious why kb1aaa.o, kb2aaa.o, and kb3aaa.o were
not being added to libmcidas.a.  I checked the makefile, but
there was nothing wrong there.  I finally figured out  that the problem
had to do with the clock time.  For instance, compare the times in
the following listings:

barb: /home/mcidas/mcidas7.6/src $ ls -alt kb*aaa.*
-rw-rw-r--    1 mcidas   mcidas      10412 Oct  3 01:14 kb3aaa.o
-rw-rw-r--    1 mcidas   mcidas      10412 Oct  3 01:14 kb1aaa.o
-rw-rw-r--    1 mcidas   mcidas      10412 Oct  3 01:14 kb2aaa.o
-rw-rw-r--    1 mcidas   mcidas      49005 Oct  3 01:14 kb1aaa.f
-rw-rw-r--    1 mcidas   mcidas      49005 Oct  3 01:14 kb2aaa.f
-rw-rw-r--    1 mcidas   mcidas      49005 Oct  3 01:14 kb3aaa.f
-rw-r--r--    1 mcidas   mcidas      15823 May 25  1999 kbxaaa.dlm
barb: /home/mcidas/mcidas7.6/src $ ls -alt libmcidas.a
-rw-r--r--    2 mcidas   mcidas    4792102 Oct  3 02:03 libmcidas.a

I think that the time on the library was newer than the time on the
kbxaaa object files.  This would account for them never being added
to the library, and that, in turn, would account for programs needing
them for linking never being linked.

I think I have to logoff your machine now. I just got a low battery
notification:

Broadcast message from root Tue Oct  3 02:21:46 2000...

Battery Low Notification from APM BIOS (10% 0:20)

>Thanks much.  

No problem.  Let me know if you run into anything that doesn't seem to
work.  I exercised things like file location (dmap.k), image listing
(imglist.k), image display (imgdisp.k), etc., and everything seemed to
work correctly.

Tom