[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Staging #YHC-348380]: Perus LDM
- Subject: [Staging #YHC-348380]: Perus LDM
- Date: Wed, 19 Dec 2012 17:31:59 -0700
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