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

[Staging #YHC-348380]: Perus LDM

Hi Marcial,

I put our exchange on configuring the Peru Meteorological Service
machine for LDM (and GEMPAK) use in our inquiry tracking system...

re:
> I have some problems with the ldm. It seems that some time has passed
> since I did this appropriately.
> 
> I keep getting these errors with the PIPEs in ldm, I have read many
> posts inside your email database and tried many others without finding
> the correct solution.
> 
> Can you give me a hand?

I used the login information you provided to access the machine in
Peru (IP address 190.102.140.16).  Here is a short list of the things
I did while logged on to that machine:

- removed some of the existing LDM installation in preparation for
  doing an install that follows the guidelines in:

Unidata HomePage
http://www.unidata.ucar.edu

  Software -> LDM -> Documentation & Training
  http:/www.unidata.ucar.edu/software/ldm/#documentation

    An installation guide provides instructions for installing and configuring 
the LDM
    
https://www.unidata.ucar.edu/software/ldm/ldm-current/basics/index.html#installation

      Installing from Source-Code
      
https://www.unidata.ucar.edu/software/ldm/ldm-current/basics/source-install-steps.html

- modified the LDM registry file, ~ldm/etc/registry.xml, to change the 
<datadir-path>
  entries for the <pqact> and <pqsurf> configuration entries

  Versions of the LDM newer than 6.8.x use ~ldm/etc/registry.xml to define
  a variety of things.  The entries I changed allow pattern-action file
  entries that write things into 'data/xxx' directories like v6.8.x and
  previous versions did.

- cleaned-up a number of soft links that appeared to be made to locate
  decode directories in the /data file system

  What is in place now is:

  ~ldm/data -> /data/ldm

  ~ldm/logs -> /data/ldm/logs

  The only thing left in the ~ldm/var directory hierarchy is the
  LDM queue which can be found in ~ldm/var/queues.

- changed the /etc/rsyslogd.conf entry for the LDM to write LDM
  log files in /data/ldm/logs

- changed the SELINUX setup in /etc/selinux/config from 'enforcing'
  to 'disabled'

  I rebooted the machine to make this change active.

  The change allows the LDM to use 'rsyslogd' to log.  LDM logging
  is now working.

- created the LDM startup script 'ldmd' in /etc/init.d

  Automatic startup of the LDM at boot time was tested when I
  rebooted the machine to active the SELINUX change above.

- split the single data REQUEST in ~ldm/ldmd.conf into
  thirds:

changed:
REQUEST       UNIDATA ".*"    idd.unidata.ucar.edu

to:
REQUEST IDS|DDPLUS      ".*"    idd.unidata.ucar.edu
REQUEST HRS     ".*"    idd.unidata.ucar.edu
REQUEST UNIWISC ".*"    idd.unidata.ucar.edu

  I did this to minimize the latencies for the datastreams being
  requested.  You can see the effect in the real-time statistics
  that the machine is reporting back to us:

Unidata HomePage
http://www.unidata.ucar.edu

  Projects -> Internet Data Distribution
  https://www.unidata.ucar.edu/projects/index.html#idd

    IDD Current Operational Status
    https://www.unidata.ucar.edu/software/idd/rtstats/

      Statistics by Host
      https://www.unidata.ucar.edu/cgi-bin/rtstats/siteindex

  Search for pe.gob.senamhi and then click on its link:

  data.senamhi.gob.pe [6.11.2]
  https://www.unidata.ucar.edu/cgi-bin/rtstats/siteindex?data.senamhi.gob.pe

- modified crontab entries to run 'bin/ldmadmin' instead of 'ldmadmin'

  This was needed as the actions were not running, and they were generating
  email to 'ldm' informing that they were not running.

- added an additional crontab entry that will rotate the GEMPAK log files
  in /data/ldm/gempak/logs

  Most users forget this step.

- cleaned up the list of programs that had been copied to the
  ~ldm/decoders directory

  Just the GEMPAK decoders should be copied there.

- copied the GEMPAK Cshell script that rotates GEMPAK log
  files from /home/gempak/NAWIPS/bin to the newly created
  ~ldm/util directory

  I then edited the script to source Gemenviron from
  ~gempak/NAWIPS.

- modified the PATH setting in ~ldm/.bash_profile

  When I first logged in, trying to run 'ps' to get a
  list of processes being run by 'ldm' would give an error
  since the 'ps' that was being executed was the GEMPAk
  routine that had been copied to the ~ldm/decoders directory.
  I moved the ~ldm/decoders and ~ldm/util directories to the
  end of the PATH definition in ~ldm/.bash_profile.

- changed ownership of some directories in /data to ldm:unidata

  Some of the directories were owned by 'root', and were not writable
  by 'ldm'.


I think that I highlighted all of the changes I made above.  There
is the possibility that I forgot about something that I changed
(but I don't think so).

As far as I can tell, the LDM setup on the Peru machine is now running
well: data is being ingested and decoded.

The last thing to note is that the setup in the GEMPAK account correctly
points to /data/ldm/gempak for the top level of the data hierarchy
to use (via the environment variable GEMDATA).  The proof of this
will be when someone runs GEMPAK on the machine and is successful :-)

Please let me know if you run into anything that you do not understand
or think is incorrect.

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: YHC-348380
Department: Support LDM
Priority: Normal
Status: Closed