[LDM #FGZ-978731]: LDM installation and configuration at USNA

Hi Alex,

re:
> Thanks Bonnie!

Ditto!

re:
> Tom, I did the following as <root" user:

Hopefully, you performed the following as the 'ldm' user!

re:
> [ldm@edmapsserver ~]$ ldmadmin start
> The product-queue is OK.
> Checking pqact(1) configuration-file(s)...
> etc/TDS/pqact.satellite: syntactically correct
> Checking LDM configuration-file (/usr/local/ldm/etc/ldmd.conf)...
> Starting the LDM server...
> [ldm@edmapsserver ~]$ less ~/var/logs/ldmd.log

OK.  Just to be sure of where we stand, this was done while the
runtime link was pointing at the ldm-6.12.14 LDM installation, true?
If yes, then it says that there is something about the LDM-6.13.[34]
builds that is not quite right.  More on this at the end of this
reply.

re:
> I let the ldmd.log sit for about 10 minutes. Nothing popped up!

OK, but let's be sure that the ~ldm/etc/TDS/pqact.satellite
NIMAGE action is actually working.  I would do this in two
ways:

<as 'ldm'>
ls -alt /data/ldm/pub/native/satellite

If the satellite subdirectory now exists, it means that the action
in ~ldm/etc/TDS/pqact.satellite is working.  At the same time,
however, the script should be logging output to a log file
that is different than ~ldm/var/logs/ldmd.log.  BUT, I just looked
in the script ~ldm/etc/TDS/util/ldmfile.sh, and I see that it
needs to be updated/modified to log to the ~ldm/var/logs directory.
The change that needs to be made is:

change:

# Send all messages to the log file
if [ $# -eq 2 ]; then
   logfile=$2
else
   logfile=logs/ldm-mcidas.log
fi

to:

# Send all messages to the log file
if [ $# -eq 2 ]; then
   logfile=$2
else
   logfile=var/logs/ldm-mcidas.log
fi

The change is to preprend logs/ldm-mcidas.log with 'var'.

NB: nothing needs to be done with the LDM for this editing
change to take effect.  After the editing change, and after
at least one new NIMAGE product has been received, there
should be a new log file in ~ldm/var/logs:

cd ~ldm
ls -alt var/logs/ldm-mcidas.log

re:
> Can we plan on working Tuesday?  Would 1000 EDT work for you?

Certainly.  But, this may turn out to not be necessary IF the
test that I outlined in my response to Bonnie is followed and
works.  Here again is the test that I sent:

<as 'ldm'>

cd ~ldm
ldmadmin stop

-- edit the .bashrc or .bash_profile file and set LDMHOME as follows:

LDMHOME=/usr/local/ldm
export LDMHOME

- make the LDMHOME setting active in the login:

export LDMHOME=/usr/local/ldm

- rebuild LDM-6.13.4

cd ldm-6.13.4/src
make distclean
./configure --disable-root-actions > configure.log 2>&1
make install > install.log 2>&1

<as 'root'>
cd /usr/local/ldm/ldm-6.13.4/src
make root-actions
exit

<as 'ldm'>
cd ~ldm

rm runtime
ln -s ldm-6.13.4 runtime

ldmadmin start

This test should not take long; I estimate that it would take between
5 and 10 minutes.

re:
> Thanks everyone!

I think we are very close to having a fully functional and current version
of the LDM!

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: FGZ-978731
Department: Support IDD
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.