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