20041003: Installing LDM for local workstation (Vietnam) (cont.)

>From: Mai Nguyen <address@hidden>
>Organization: National Center for Hydro-Meteorological Forecasting of Vietnam
>Keywords: 200410040255.i942tZUE011833 LDM installation and configuration

Hi Mai,

>Thanks for your prompted advice.
>
>At the moment, our met_research3 just has been crashed
>down (because of an unknown reason). So we have to
>reinstall both LDM and GEMPAK. (I am truggling with
>them now). Could you please resend the script ldmd
>(for ldm to start when the computer starts up).

re: changing upstream feed host

>Sure. Please do. Do you mean you need "root" access? I
>will inform you just after the computer and LDM is up.

'root' access is not needed to change the host(s) an LDM requests data
from.  All I needed to do (I have logged on and made the changes) was
to be able to get on as the user running the LDM (user 'ldm') and make
adjustments to the file ~ldm/etc/ldmd.conf.

>Date: Mon, 4 Oct 2004 02:12:08 -0700 (PDT)
>From: Mai Nguyen <address@hidden>

>Our machine is up now, and LDM has been managed to run
>somehow. However, when I start ldm, there is an error
>messages:
>
>hupsyslog: couldn't open /var/run/syslogd.pid
>
>but it still runs. Is that serious?

The hupsyslog error message is typically caused by either syslogd not
running or the LDM application 'hupsyslog' not having setuid root
permission set.

>I guess there still must be some errors somewhere.
>There is only nwx data coming to us. Maybe there're
>some error in decoding? Do we need to create
>directories for other kinds of data? (I guess ldm
>created directories for nwx data. Would it do the same
>for others too?)

The problem turned out to be that the permissions on the HOME directory
for the user 'gempak' was not readable by any user except 'gempak'.
The ~ldm/etc/pqact.conf entries all include a reference to a GEMPAK
table that must be read, so the entries were failing when the process
couldn't read the information it needed.  This caused a lot of error
messages in the ~ldm/logs/ldmd.log file.  The only thing I did to
correct this situation was to add group and world read and execute
permissions to the HOME directory for GEMPAK.

In looking through the LDM-6.1.0 installation, I noticed that the
standard installation had not been made.  Someone had created the
~ldm/bin, ~ldm/man, ~ldm/lib, and ~ldm/include directories instead of
creating a runtime link to the current LDM installation and then links
to its subdirectories.  The other thing I noticed was that someone had
edited the ldmadmin startup script and set internal variables that are
used to "point" (locate) the LDM product queue.  While editing ldmadmin
is done routinely (to change the queue size) it is rare to need to
change the internal variables to locate the queue, etc.  The best way
of doing this is to make the ~ldm/data directory a link to the location
where one wants data decoded and the LDM queue to reside.  Given this,
I removed the ~ldm/data and ~ldm/logs directories and made them links
to /data/nadata and /data/nadata/logs, respectively.  So, when you do a
long list in the ~ldm directory now you will see various links:

% ls -lt
 ...
lrwxrwxrwx    1 ldm      ldm        17 Oct  6 00:49 logs -> /home/nadata/logs
lrwxrwxrwx    1 ldm      ldm        12 Oct  6 00:48 data -> /home/nadata
lrwxrwxrwx    1 ldm      ldm        11 Oct  6 00:41 src -> runtime/src
lrwxrwxrwx    1 ldm      ldm        15 Oct  6 00:41 include -> runtime/include
lrwxrwxrwx    1 ldm      ldm        11 Oct  6 00:41 lib -> runtime/lib
lrwxrwxrwx    1 ldm      ldm        11 Oct  6 00:41 man -> runtime/man
lrwxrwxrwx    1 ldm      ldm        11 Oct  6 00:41 bin -> runtime/bin
lrwxrwxrwx    1 ldm      ldm         9 Oct  6 00:35 runtime -> ldm-6.1.0
 ...

This now looks like a "standard" LDM installation.

The last thing to mention is that I had noticed that the LDM would not
start up like it should on met_research3.  What I mean is that it would
take several minutes for the LDM to start running the processes that
would ingest and then decode data.  We traced this back to the LDM not
being able to contact the portmapper on met_research3.  We found that
this was caused by the firewall running on the machine.  I explicitly
added an iptables entry that allows all contact to the machine from the
machine:

-A INPUT -s 203.162.14.98/32 -j ACCEPT

(accept everything from met_research3)

Now, the LDM starts up immediately after running 'ldmadmin start'.

So, as I finish this note, I can say that the LDM on met_research3
appears to be running with no problems and data is getting decoded as
it should where it should.  The installation on met_research3 can now
be used as a model for an LDM installation on other machines you may
want setup.

>Thanks for your helps and I am looking forward to your replies.

No worries.

>Best regards, Mai

Cheers,

Tom
--
**************************************************************************** <
Unidata User Support                                    UCAR Unidata Program <
(303)497-8643                                                  P.O. Box 3000 <
address@hidden                                   Boulder, CO 80307 <
---------------------------------------------------------------------------- <
Unidata WWW Service              http://my.unidata.ucar.edu/content/support  <
---------------------------------------------------------------------------- <
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.