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

[IDDBrasil #OHK-470427]: change allow for idd.cptec feed.

Hi Waldenio,

It is good to hear from you, but I wish it had been for more social
matters and not work-related problems :-)

re:
> Here are CPTEC/INPE we are unable to receive LDM data from idd.unidata
> for some days.
> We know that idd.unidata server experienced problems in the last days,
> but seems that all was fixed everywhere, but not for idd.cptec server.

I talked to our system administrator about this yesterday when I returned
from travel to Ghana, and he told me that idd.unidata.ucar.edu did _not_
stop relaying data to downstreams because of any problems with the cluster:
data continued to flow to all downstreams whose machines had full (forward
AND reverse) DNS.

re:
> I think that this is caused by another problem, related to the CPTEC´s
> DNS server.

Yes, we believe that the problem receiving problems experienced at CPTEC
was entirely caused by DNS problems at CPTEC.  Again, data never stopped
flowing from the IDD toplevel relay cluster, idd.unidata.ucar.edu.

re:
> This may be solved allowing the IP addresses directly.

Yes, but this "solution" is more brittle/inflexible than doing ALLOWs by
hostname.  We prefer that sites maintain valid DNS for their LDM/IDD
machines so that we can more easily do "blanket" ldmd.conf ALLOWs for
all machines for a particular domain/subdomain.  This makes the ALLOW
configurations for sites downstream of us much easier to maintain as
we take down nodes in our relay cluster for maintenance and updating.

Questions:

- how was the DNS problem at CPTEC resolved?

- can the DNS setup/configuration for CPTEC machines be made more
  robust?

re:
> Please, could you add these allow lines for CPTEC´s machine in idd.unidata ?
> 
> 150.163.141.227 (tumbyra.cptec.inpe.br, now working as idd.cptec.inpe.br)
> 150.163.141.149 (ubiru.cptec.inpe.br, now working as tigge-ldm.cptec.inpe.br)

OK, I just did this by hardwiring DNS definitions for these two machines in
the /etc/hosts file on each node of the idd.unidata.ucar.edu cluster.  This
should work _until_ the IP address of these machine changes.  We prefer to
do the configuration this way instead of converting ldmd.conf ALLOWs to IP
addresses since this requires that the LDM be restarted on each node the
change would be made on while the modification to /etc/hosts does not.  Given
that there are now over 700 downstream connections being maintained by
idd.unidata.ucar.edu, and given that the load on each node is impacted when
another node goes down for any reason, we prefer to not stop/restart the
LDM for any but the most critical reasons.

re:
> Thank you very much,

No worries.

By the way, it would be better in the future to CC address@hidden
on email exchanges like the ones you had with Art Person of Penn State instead
of CCing me personally.  Since I was on travel in a location where my ability
to access and respond to email was not as robust as I would have liked, the
emails CCed to me went unattended for much longer than was necessary in a 
situtation
like the one you were experiencing. The same emails CCed to address@hidden
would have resulted in other Unidata staff members seeing the issues and then 
knowing
that something was amiss and needed attending.

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: OHK-470427
Department: Support IDD Brasil
Priority: Normal
Status: Closed