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

[LDM #CPH-753570]: RADAR data error

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [LDM #CPH-753570]: RADAR data error
  • Date: Wed, 27 Apr 2016 15:38:04 -0600
Hi Russ,

re:
> I was told by my applications staff that the access was working a last
> month.

OK.  Was this from the same machine that you indicated in a previous
email:

geoprod4-cip.espc.nesdis.noaa.gov 140.90.203.194

I would guess no, since both forward and reverse DNS do not exist for
this name-IP pair:

% nslookup geoprod4-cip.espc.nesdis.noaa.gov
Server:         192.168.72.2
Address:        192.168.72.2#53

** server can't find geoprod4-cip.espc.nesdis.noaa.gov: NXDOMAIN

% nslookup 140.90.203.194
Server:         192.168.72.2
Address:        192.168.72.2#53

** server can't find 194.203.90.140.in-addr.arpa.: NXDOMAIN

And we do not have a special LDM ALLOW for your machine's IP address,
nor do we have an /etc/hosts mapping of your machines IP to a name
that will match an existing ALLOW on our cluster's real server
backend machines.

re:
> I sit just a matter of getting the geoprod4-cip server added to the
> RADAR ACL?

'RADAR ACL"?  If you are asking if all that is needed is an LDM ALLOW
for your machine, then the answer is that we do not like to create
special ALLOWs, especially ones for specific IP addresses, as that requires
that we modify the LDM configuration files on each real-server backend of
our top level IDD relay cluster. This, in turn, means that each of those
LDMs would have to be stopped and restarted, and that is not as easily done
as said on machines that are servicing so many downstream connections.  We
greatly prefer that machines REQUESTing feeds from our clusters have both
forward and reverse DNS so that blanket ALLOWs that we have in place on all
real server backend machines work.

So, the question to you is:

- did you recently change the machine that is REQUESTing the FNEXRAD
  datastream from idd.unidata.ucar.edu?

If the answer is no, it should mean that whatever DNS that was in
place and working is now not in place/working.  Assuming that this is the
problem, getting DNS (mainly reverse DNS) setup should be sufficient
for data to once again flow.

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: CPH-753570
Department: Support IDD
Priority: Normal
Status: Closed