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.
Unidata Support wrote: > > >From: McIDAS <address@hidden> > >Organization: McIDAS proyect > >Keywords: 199908201415.IAA18376 IDD feed requests > > Karli, > > Robb Kambic will be responding to this email as well. I just felt that > it was prudent to get some more information out to you as soon as possible. > Thank you for your promptness! > >As of last Tuesday we have not been getting any Satellite feeds from any > >of our feed servers. I wasn't aware of the problem until yesterday when > >I tried connecting to our secondary server, however the ldmd.log file > >keeps showing the "Aug 19 05:03:40 3Q:breeze aqua[728]: > >FEEDME(aqua.atmos.uah.edu): 7: Access denied by remote server" error > >with our old server and "Aug 20 00:00:14 3Q:breeze pluto[3895]: > >FEEDME(pluto.met.fsu.edu): 7: Access denied by remote server" from the > >backup server you guys recently set up. > > This sounds like something changed on your end. > > >To top it all off, today we've > >lost out NLDN feeds as well (latest feed dates 99231) and it too is > >plagued by the same problem: "Aug 20 00:00:46 3Q:breeze striker[3907]: > >FEEDME(striker.atmos.albany.edu): 7: Access denied by remote server" > > The fact that all of your feed sites have started to refuse connections > from you tells me that the problem is almost 100% sure to be on your > end. To test this out, I did a forward and reverse name lookup for > your ingest machine (breeze.upr.clu.edu): > > % nslookup breeze.upr.clu.edu > Server: laraine.unidata.ucar.edu > Address: 128.117.140.62 > > Name: BREEZE.UPR.CLU.EDU > Address: 136.145.165.17 > > % nslookup 136.145.165.17 > Server: laraine.unidata.ucar.edu > Address: 128.117.140.62 > > Name: breeze.uprm.edu > Address: 136.145.165.17 > > You can see from this pair of nlsookups that the machine names on the > forward and reverse lookup are different. The LDM does the forward and > reverse lookups to verify that a host is valid; its tests will fail > given the different names. > > The question back to you is whether or not you have any control over > this situation? Ok, from what I'd been told by Dr. Winter after I got here, our system had a similar problem with the domains. Unfortunately I have absolutely no control whatsoever over the naming systems here. The new domain was changed only recently and they've kept both domains active. I do know someone who might have some clout with the main systems. If you tell me what would need to be done with the Reverse DNS I ask him if it can be changed (if that's the problem). I gave you breeze.uprm.edu as our server name because that's what the reverse DNS gives us here. > > >we'd been havign serious connection problems with our T1, which > >constantly keeps falling off to the backup gateway. > > Could this be the cause of the differning names? > I doubt that these problems would serve as a direct cause, but I can't count them out. > >I thought that was > >the problem originally, but even when the connections are good, we still > >don't get anything. All radar images are OK, for the time being. > > The fact that your radar images are OK is strange IF there has been > disconnects > and reconnects over the same period of time to the WSI LDM. > The disconnects are campus wide, so we lose all outside communication during that period of time. Maybe the fact that these images are updated every six minutes might serve as a factor to explain this anomaly. However, these feeds have *always* stayed up whenever we've encountered this type of problem during the past couple of months. > >Thanks in advance. > > One of the first things that we need to get you to do is initiate dialogs > with your upstream sites when you have problems like this. It is likely > that an email by you to the site administrator at the feed sites could > resolve your problem a lot quicker than you sending email just to support. > > Here is the procedure: > > 1. Find the email addresses of the site administrators at your upstream sites: > > o start a web browser > o go to the Unidata WWW HomePage: > http://www.unidata.ucar.edu > o go to the Internet Data Delivery (IDD) link: > http://www.unidata.ucar.edu/projects/idd/index.html > o go to the Current Operational Status link: > http://www.unidata.ucar.edu/projects/idd/iddgeneral.html#status > o go to the IDD site contact list link: > http://www.unidata.ucar.edu/projects/idd/sitelist.html > o lookup the email addresses of the site administrators at your upstream > feed sites: > > University of Alabama-Huntsville > Scott Podgorny > address@hidden > 205-922-5819 > > Florida State University > Chris Vandersip > (ldm|cvander)@met.fsu.edu > 904-644-(1550|2522) > > State University of New York at Albany (SUNY-Albany) > David Knight > address@hidden > 518-442-4204 > > 2. Send the site administrators your email noting when your service stopped > and the errors you are seeing in your LDM log file. > > 3. Make sure to CC address@hidden. on your message so that we > will be aware of your situation. > > I am sending this email to the contacts at your upstream sites that appear > to be refusing your LDM's attempt to connect to try and get you going again. > Great, I have noted these instructions and will act accordingly the next time we have problems. > Scott, Chris, and David: > > The University of Puerto Rico has recurring problems with network connections > to their site. It is possible that the name that their name server > "assigns" them changes when their networking reverts to their backup gateway > causing a mismatch that causes your LDMs to refuse connections. Would it > be possible to generalize the ALLOW lines in your ldmd.conf files to > allow connections by IP address and by both of the names listed in the > nslookup listing below? This would help them out greatly IF it fixes > their problem. > > Thanks in advance, and please keep us informed about what is going on. > > Tom Yoksas > **************************************************************************** < > Unidata User Support UCAR Unidata Program < > (303)497-8644 P.O. Box 3000 < > address@hidden Boulder, CO 80307 < > ---------------------------------------------------------------------------- < > Unidata WWW Service http://www.unidata.ucar.edu/ < > **************************************************************************** < -- ==================================================================== Amos Winter address@hidden Director Puerto Rico Climatology Center P.O. Box 9013 Department of Marine Sciences phone: (787) 265-5416 University of Puerto Rico - Mayaguez fax: (787) 265-2195 Mayaguez, PR 00681-9013