[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[McIDAS #ECE-924432]: Creating and populating a local ADDE server

Hi Kevin,

re:
> Things are looking good, with a couple additions/exceptions:
> 
> 1) As you may have seen, LDM syslogging was not working properly.  I saw on a 
> support
> message that the LDM user account should *not* be in /home/ldm, so I switched 
> the ldm
> user account to /usr/local/ldm.

The location of the 'ldm' account should have nothing to do with LDM logging
using 'syslogd'.  Some likely reasons for logging not working are:

- SELINUX has not been configured as 'disabled'

  If it was, the change might not have taken effect if the machine was not 
rebooted
  after the change (/etc/selinux/config).

- there might be read/write permission problems with the LDM log file

- there could be problems with the configurations in the /etc/rsyslog.conf
  configuration file

As for not installing the LDM in /home: some in Unidata (Steve and Mike Schmidt 
for
two) believe that packages that provide system-wide services should not be
installed in /home/.  As a general concept, I find this to be useful guidance,
but not compelling.  A more compelling argument is that sites quite frequently
mount /home from a server machine using NFS (we do this, for example).  The
problem in this kind of setup is that frequently the way the file system
is mounted precludes setuid root programs from actually running as 'root'.
/usr/local should be on the local disk, so it should not have the potential
for the setuid root bit from not being honored.

re:
> 2) There were duplicate instances of pqact in ldmd.conf loading the 
> pqact.conf_mcidasA.
> I removed one of them.

Oops, I didn't notice this; sorry.  Removing it was, of course, the correct 
thing to
do.

re:
> 3) For some reason, the 'pipe' to util/ldmfile.sh always fails when pqact 
> pipes a
> product received from the UNIWISC feed (see verbose logs in 
> $LDMHOME/logs/ldmd.log).

I noticed this, but I did not have time to investigate it yesterday.  I will 
take
a second look today.

re:
> I
> tried putting in the full path to this script, but as I expected, that did 
> not help.

The ~ldm/util directory is in 'ldm's PATH, AND I changed the 
~ldm/etc/registry.xml
file so that the working directory for LDM processes would be ~ldm.  I did this
because the pattern-action file actions that are generated by GEMPAK and McIDAS
scripts tacitly assume that they will be run from ~ldm.  This is seen by all
of the 'decoders/dcxxxx' and 'util/yyyyy' entries for GEMPAK and McIDAS 
generated
pattern-action files.

re:
> Why not just directly FILE these products?

I wrote 'ldmfile.sh' originally because there was no way to log the arrival
and processing of products filed with the FILE action (and I wanted the
logging).  I kept the approach since I do not like that the '-log' flag
for FILE in newer LDM installations logs to the LDM log file; I wanted
the logging to go to a separate log file like ~ldm/logs/ldm-mcidas.log.

re:
> 4) I installed the ldm-mcidas 64-bit Linux 2.6 decoders.

OK.  As far as the installation that had been done, this was not necessary.
If you start processing wind profiler or lightning data (either NLDN or
USPLN), you will need the ldm-mcidas decoders 'proftomd' and 'lgt2md',
respectively.

I intended to look into the 'ldmfile.sh' issue this morning, but I note that
you modified the ~ldm/etc/pqact.conf_mcidasB pattern-action file to contain
both filing and "decoding" actions for UNIWISC products.  The question
for you now is which do you want to stay with, filing or decoding; you
should _not_ have both!


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: ECE-924432
Department: Support McIDAS
Priority: Normal
Status: Closed