20040804: problem with ldm installation on Linux (cont.)

>From: address@hidden
>Organization: GMU
>Keywords: 200408031626.i73GQHaW027481 LDM configure environment variables

Ying,

>Thanks Tom

No worries.

>I fixed the mistake in  /etc/syslog.conf and get the log as attached. Still
>confused why there is no data coming.

Now, I do see that atm.geo.nsf.gov is denying your request for data:

Aug 04 00:33:23 atm.geo.nsf.gov rpc.ldmd[13878]: gethostbyaddr: failed for 
129.174.124.79
Aug 04 00:33:23 atm.geo.nsf.gov rpc.ldmd[13878]: Denying connection from 
129.174.124.79
Aug 04 00:33:23 atm.geo.nsf.gov rpc.ldmd[13878]: gethostbyaddr: failed for 
129.174.124.79
Aug 04 00:33:23 atm.geo.nsf.gov rpc.ldmd[13878]: Denying connection from 
129.174.124.79

The reason you are being denied is that there that the machine name
for the IP address 129.174.124.79 fails (as can be seen in
gethostbyaddr: failed for 129.174.124.79)

So, the comment I sent in my last email still needs to be attended to:

2) work with your network folks on getting forward and reverse 
   name lookup setup for unidata.scs.gmu.edu

>What I have is only the ip address, it will take time to get the forward and
>reverse name lookup

OK.  You will be unable to feed from an upstream LDM until this is taken
care of, so this looks like it should be your top priority.

re: firewall

>There is no firewall specified on this machine. I'm not sure about the dept
>rules. It at least worked fine before this reinstallation.

OK.  Since I am seeing your machine contacting atm, I no longer think
a firewall is involved in any way.

re: make sure that to run the last step in the LDM install
sudo make install_setuids           <- this is the step I am talking about

>Yes, I did so.

Very good.

>Hope you can help getting some clues from the log file. Thank you so much!

The problem is the lace of forward AND reverse name lookup.  As soon as
this is solved by your network folks, your data request will be honored.

>BTW, I tried quite a lot of data types in pqact.conf, due to the requirement
>of an undergoing project. I did get data using the same pqact.conf
>previously (before reinstallation)

The entries in pqact.conf only pertain to the processing of data that
you receive.  They have nothing to do with the receipt of data.  Your
request for data in ~ldm/etc/ldmd.conf is formatted correctly:

request ANY ".*" atm.geo.nsf.gov

This request, however, is asking for all data in all datastreams.  This
is a LOT of data.  The total volume of data that will be sent to you
given this request can exceed 3.5 GB per hour, and will easily average
over 2.6 GB per hour.  Here are the volume numbers by datastream for
atm for a period spanning the past two days:

Data Volume Summary for atm.geo.nsf.gov

Maximum hourly volume   3515.338 M bytes/hour
Average hourly volume   2747.278 M bytes/hour

Average products per hour     137729 prods/hour

Feed                           Average             Maximum     Products
                     (M byte/hour)            (M byte/hour)   number/hour
CRAFT                  1069.247    [ 38.920%]     1483.407    59230.143
CONDUIT                1049.409    [ 38.198%]     1713.678    22867.673
NIMAGE                  195.076    [  7.101%]      387.328      186.673
HDS                     192.778    [  7.017%]      592.256    13834.163
NNEXRAD                 175.362    [  6.383%]      221.209    23702.204
FNEXRAD                  24.586    [  0.895%]       32.862       48.531
UNIWISC                  21.182    [  0.771%]       32.087       29.163
IDS|DDPLUS               12.338    [  0.449%]       15.140    17812.592
DIFAX                     5.084    [  0.185%]       20.727        6.571
FSL2                      2.218    [  0.081%]        2.323       11.551

Is this _really_ what you want?

Cheers,

Tom
--
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.

>From address@hidden  Thu Aug  5 09:03:23 2004

Tom
Thanks a lot! It's working after the network staff fixed a coorection
on 129.174.x.x reverse DNS queries.

Have a good day,
Ying