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

20040402: access to UNIWSIC imagery (cont.)

>From: "Luis A. Lopez" <address@hidden>
>Organization: UPRM
>Keywords: 200404011627.i31GRGCT021091 IDD DNS name lookup

Hi Luis,

>I already verified  with nslookup our server, now it respond both ways,
>by hostname and by ip address, but it seems that this ip address was
>registered long time ago in one of our other campus with the name
>heat.upr.clu.edu, I'll contact the dns administrator of the other
>campus, so they can remove the ip from their tables.

OK, sounds good.

>LDM daemon is also running with the modification to the ldmd.conf file
>that you suggested.

I see that atm.geo.nsf.gov is feeding data to heat.UPR.CLU.EDU.

Apr 02 17:56:37 atm.geo.nsf.gov heat(feed)[29940]: topo:  heat.UPR.CLU.EDU 
Apr 02 17:57:59 atm.geo.nsf.gov heat(feed)[2719]: topo:  heat.UPR.CLU.EDU 

The indication of the name of the machine that is being fed should
change when the DNS entry is updated.

What I do not see, however, is real time statistics from 'heat'.  The
reporting of realtime statistics is done through the program 'rtstats'
which is run out of an 'exec' action in the LDM machine's
~ldm/etc/ldmd.conf file.  Here is what this entry should look like on
your machine:

exec    "rtstats -h rtstats.unidata.ucar.edu"

If you have this entry in your ldmd.conf file (and it is not commented
out), then it should be sending us real time statistics. Since we are
not getting those stats, I have to assume that your ldmd.conf file:

- doesn't have the rtstats line

- the line is commented out

- there is a DNS problem that is preventing the IP address of
  rtstats.unidata.ucar.edu from being evaluated

>The ldm dameon should be running as root or with ldm user??.

The LDM should always be run out of the 'ldm' account.  It should never
be run as 'root'.  If you are running LDM as 'root', you will need to
stop it, and then go into the ~ldm directory and recursively change
ownership of files so that they are owned by 'ldm'.  This is true for
_all_ files except ~ldm/bin/rpc.ldmd and ~ldm/bin/hupsyslog.

Two routines in the LDM package have setuid root permission: rpc.ldmd
and hupsyslog.  rpc.ldmd needs setuid root to be able to use a port
less than 1024 (the LDM uses port 388).  The effective user of
rpc.ldmd, however, is set to the user that initially runs it after the
port access is established.  hupsyslog has setuid root permission so
that it can send a HUP signal to the syslogd daemon (that is all that
it does).  The HUPping of syslogd is needed so that the LDM log file
(~ldm/logs/ldmd.log) can be rotated (renamed to ldmd.log.1 and a new
one created that syslogd writes into).

>Do you have any example of how to tell mcidas  to read this images (mcidas
>and ldm)?,

I need to know where you are in the process of getting things setup.
First, have you installed the ldm-mcidas decoders needed to process the
imagery you are ingesting using the LDM?  If no, here is a quick ABC
for what to do:

Even though building the ldm-mcidas decoders from source is possible,
the easiest thing for you to do is use a binary distribution of the
ldm-mcidas decoders. You can get the binary distribution of ldm-mcidas
decoders for Sun Solaris SPARC using anonymous FTP from our FTP server,

<login as 'ldm'>
cd ~ldm
mkdir ldm-mcidas
mkdir decoders
<add ~ldm/decoders to the PATH of the user 'ldm' (e.g., in .cshrc, etc.)>
cd ldm-mcidas

ftp ftp.unidata.ucar.edu
  <user> anonymous
  <pass> address@hidden
  cd pub/binary/sunos_5.8-sparc
  get ldm-mcidas-2003.tar.Z

zcat ldm-mcidas-2003.tar.Z | tar xvf -

Then do the following:

- copy the decoders you need/want from the ~ldm/ldm-mcidas/ldm-mcidas-2003/bin
  directory to ~ldm/decoders

- copy the files SATANNOT and SATBAND from the
  ~ldm/ldm-mcidas/ldm-mcidas-2003/etc directory to ~ldm/etc

- integrate the decoding actions you need from those contained in:


into your ~ldm/etc/pqact.conf file.

You will be looking for the MCIDAS stream actions and the NIMAGE stream
actions.  At some point, you will also want to ingest the radar data
for San Juan, so you should go ahead and add the FNEXRAD actions, and
later some actions for the NNEXRAD feed.  Let's deal with that

I pointed you to the online example copy of ldm-mcidas decoders (the
URL above) since the ones in the binary ldm-mcidas distribution are not
as uptodate as they should be.

By the way, the complete set of instructions for getting a binary
ldm-mcidas distribution; installing it; and configuring it can be found
in our LDM-MCIDAS web pages:


Please let me know if you would like guidance in setting your
pqact.conf entries.

The next step after getting ingestion and decoding working is setting
up data scouring.  The LDM can bring over a lot of data in a hurry, so
your disk can easily get filled unless you are have setup data
scouring.  If you are only going to be looking at satellite imagery in
McIDAS, then the scouring method you choose will depend on the method
you use to store the data after it is decoded.  We should talk about
your options so you understand the possibilities.

The next step after decoding the data is configuring McIDAS to be able
to access it.  Let's tackle this step after the ingest and decoding are

>excuse me by this dummy question, but I'm new installing this
>software, and I'm not the end user for both of them, me neither know
>anything about climatology science :-).

No worries.  If you want, I could logon to your machine and do a lot of
the setup in a few minutes.  I would need the login info for the users
'ldm' and 'mcidas' to be effective.

>Again thanks a lot for your time.  have a nice weekend.


NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.

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.