NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Carissa, re: > Sorry I thought we were on the same page. We thought you would start > pulling this in your test feed, and we could start tracking the > products. Since this server is brand new it is possible that anything > could have been missed. And we want to make sure you can connect, > especially in the event something catastrophic happens to Boulder and we > have to flip. We had assumed as soon this was deemed good that you would > begin pulling from both. As was done with Boulder and Silver Spring. OK. The fact that I was not on the same page is undoubtedly my fault, and I apologize for dropping the ball! re: > And since you are saying that we should be able to connect to rtstats I > will go back to my folks and make sure they did add everything to port 388. You should be able to connect to rtstats.unidata.ucar.edu as there are no restrictions (firewall or LDM ACCEPT) on the out of band connections (ala ldmsend) that rtstats uses. HOWEVER, I just got into the office and logged onto one of our test machines and see that it too was having problems connecting to rtstats.unidata.ucar.edu until about 9:43 MDT today. I am interpreting the cessation of error messages in our machine's LDM log file as an indication that the problem has cleared. Please let me know if this is not the case. Back to test feeding CONDUIT from your new server(s): Looking back through previous exchanges in this ticket, I found the following comment from you: > And unless we hear negative feedback from you, the system is actually > going to be load balanced between 3 virtual systems. So you will only > request from 1 IP. > > 140.90.101.42 I am interpreting this to mean that we should setup our test feed to this machine. Some quick checking shows: - that there is forward and reverse DNS for this machine/cluster director: 140.90.101.42 <-> conduit.ncep.noaa.gov Excellent! - we _can_ contact the LDM using the fully qualified host name: <as 'ldm' on lead4.unidata.ucar.edu> % ldmping conduit.ncep.noaa.gov Oct 25 19:19:13 INFO: State Elapsed Port Remote_Host rpc_stat Oct 25 19:19:13 INFO: Resolving conduit.ncep.noaa.gov to 140.90.101.42 took 0.002515 seconds Oct 25 19:19:13 INFO: RESPONDING 0.090870 388 conduit.ncep.noaa.gov Excellent! - we can feed CONDUIT from this machine/cluster % notifyme -vl- -f CONDUIT -h conduit.ncep.noaa.gov Oct 25 19:20:36 notifyme[11618] NOTE: Starting Up: conduit.ncep.noaa.gov: 20131025192036.522 TS_ENDT {{CONDUIT, ".*"}} Oct 25 19:20:36 notifyme[11618] NOTE: LDM-5 desired product-class: 20131025192036.522 TS_ENDT {{CONDUIT, ".*"}} Oct 25 19:20:36 notifyme[11618] INFO: Resolving conduit.ncep.noaa.gov to 140.90.101.42 took 0.002477 seconds Oct 25 19:20:36 notifyme[11618] NOTE: NOTIFYME(conduit.ncep.noaa.gov): OK Excellent**3 :-) Based on these successes, I have reconfigured lead4.unidata.ucar.edu to feed CONDUIT from conduit.ncep.noaa.gov. I see data flowing in now, so things are working. We will have to wait for awhile to verify that the volume being received in this connection is the same as from the existing connections. I apologize again for dropping the ball on this test! 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: OAE-251505 Department: Support CONDUIT Priority: Normal Status: Closed