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

20020626: LDM setup at Howard (cont.)

>From: Pavel Byles-Howard University Engineering <address@hidden>
>Organization: Howard University Engineering
>Keywords: 200206241943.g5OJhXa29444 LDM ldmd.conf

Pavel,

>No, we are on the T3 not the T1

OK.

>But this data should go to the ~ldm/data/gempak dir right?

Yes.

>ok I will give you a logon. I tried call you just now but it's Sherry 
>Corpus' number. I'd rather give you over the tele than e-mail.
>I just started the ldm and there is nothing being recieved. Which is odd.

OK, I got the info from you on the phone and logged onto your machine.
Here is what I found:

1) you identified your machine as zephyr.atmphys.howard.edu with
   IP address 128.238.124.124.  A reverse name lookup (IP -> name)
   shows that this machine is known as zephyr.124.238.138.in-addr.arpa:

nslookup 138.238.124.124
Server:  twister.nsf.gov
Address:  198.181.231.17

Name:    zephyr.124.238.138.in-addr.arpa
Address:  138.238.124.124

   A forward lookup (name -> IP) gives an error for the name:

 nslookup zephyr.124.238.138.in-addr.arpa
Server:  twister.nsf.gov
Address:  198.181.231.17

*** twister.nsf.gov can't find zephyr.124.238.138.in-addr.arpa: Non-existent 
host/domain

   These two things taken together show that the DNS for this machine is
   not correct.  The LDM relies on being able to do both forward and
   reverse name lookups as part of its security.  You need to find out
   why the DNS stuff is wrong and correct it.

2) your ~ldm/.cshrc file had the PATH information needed by the LDM
   as a first thing in the file.  You later reset 'path' with no
   information about paths needed by the LDM.  I moved your PATH
   setting to later in the file so that the LDM executables could be
   found.  I then sourced .cshrc to make the settings active.
   The effect of PATH being wrong would be that pqact should not
   have been run when starting the LDM with 'ldmadmin start'.

The big problem is the lack of forward and reverse name lookup.  This
is undoubtedly why the original feed site, snow.nrcc.cornell.edu would
not feed you.  You need to get this problem solved before you can
get other IDD sites to feed you data.

For reference, I setup things to work off of atm.geo.nsf.gov so
that you could get NEXRAD data to use in testing GEMPAK/GARP.
We will need to stop this feed to zephyr as soon as you get
your DNS problem sorted out.

You now have NEXRAD data in ~ldm/data/gempak/nexrad/NIDS/...

Tom