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

[Staging #ZCW-362646]: Data from a IDD source at UNIDATA



Hi Rodrigo,

re:
> Sorry for the long time away and for not have answered your questions. I would
> like to try to receive data from another source besides CPTEC in Brazil.
> 
> You said:
> " The comments about getting redundancy in feeds is very interesting
>   mainly because having a separate feed from idd.unidata.ucar.edu does
>   not really give you redundancy since it is also feeding CPTEC.
>   What would give you more redundancy is a feed from some other
>   toplevel IDD relay like the Texas A&M cluster, idd.tamu.edu."
> 
> I say: I know this, but my idea was receive data when CPTEC is off. But
> receive data from other toplevel IDD is better. How can I get data from other
> toplevel IDD relay?

I can work with Texas A&M to add appropriate ALLOW(s) so that you can
setup your LDM(s) to REQUEST from them.

re:
> You asked:
> "Do you mean that this is the range of IP addresses at your site?"
> 
> I answer: Yes. There isn't a unique external IP related to machine where I
> want receive data from IDD. There is a range of IP.

Hmm... The typical setup is for a site to dedicate one machine to REQUEST
data from one or more upstream relays, and then relay the data received
to as many machines in their own domain as they want/need.

re:
> You said:
> "None of these machines have forward or reverse DNS."
> 
> I answer:
> Now, these machines have forward and reverse DNS.

Please provide me with the name(s) of the machine(s) that you
want to be ALLOWed to REQUEST data from Texas A&M.  I will test
to make sure that forward and reverse DNS is available for the
machine(s), and then work with the Texas A&M LDM/IDD site
administrator to make sure that the ALLOW(s) exist and are
active.

re:
> You asked:
> "What is the fully qualified machine name AND IP address for
>  the machine that you want to be ALLOWed to REQUEST data from
>  Unidata or other toplevel IDD relays?"
> 
> I answer:
> machine: ldm.smm.mil.br
> (http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/siteindex?ldm.smm.mil.br)
> External IP: 177.43.161.32/27

ldm.smm.mil.br does not have forward (name -> IP) name lookup:

% nslookup ldm.smm.mil.br
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find ldm.smm.mil.br: NXDOMAIN


There is reverse DNS for some of the machines in this IP range:

177.43.161.33  ->  teste.smm.mil.br
177.43.161.35  ->  ng.smm.mil.br
177.43.161.36  ->  ar.smm.mil.br
177.43.161.37  ->  ftp.smm.mil.br
177.43.161.38  ->  dpas03.smm.mil.br
177.43.161.39  ->  dpas04.smm.mil.br
177.43.161.40  ->  dpas05.smm.mil.br
177.43.161.41  ->  videoconf.smm.mil.br

Without reverse DNS, LDM/IDD sites relaying data have to do one
of two things:

- add an ALLOW by IP address

  The problem with adding an ALLOW by IP address is that the ALLOW entry
  has to be changed every time there is machine change at the REQUESTing
  site.

- edit the /etc/hosts file on the LDM/IDD relay machine and define an
  IP <-> fully_qualified_hostname mapping

  This is more brittle than adding an ALLOW by IP.

re:
> Thanks a lot!

Is there a problem in your organization with using a single machine to
REQUEST data AND to configure forward and reverse DNS for this machine?

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


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.