Topic: Local METAR reports Not loading

[gateway2capecod]

Hello....


well I am presently using the work around that Jasiu created for my Metar data and seems to be working and Loading Real Good. Thanks for the work around Jasiu.

as for Godaddy.......UUUGGGHHHHHH!........Lol


Thanks....Chris

[rlee171]

I had an interesting thing happen in reference to this issue. I received an email from GoDaddy asking me for feedback from my recent "experience" with their tech support. The ratings were from 1 to 10 with 10 being the best. I gave every single category a one and fortunately there was also a "comment" section. I lit it up!! Letting them know how unprofessional, rude and useless their tech support is. Now comes the interesting part. The following morning I received an unsolicited text message wanting to discus my review. This is what it said: "Hello this is Ivette with GoDaddy. I wanted to let you know I'm reviewing your recent customer support survey feedback. My team is available to help if you have unresolved issues or would like to discuss further. If you aren't into texting, no hard feelings! Just reply stop"There are 30 messages in the conversation. I even referenced this thread during the conversation for them to read. I am waiting for Ken to return from his well need and deserved vacation and I am going to send him the entire conversation. I seem to have been able to have "escalated" this issue to a level where it can be discussed with folks outside the phone techs. I am glad it was done by SMS so I have a record of the conversation. I am very interested to hear Ken's thoughts.
updated 4:53pm..  btw, even after detailing Ken's response, word for word, they still refuse to acknowledge that they have a problem. They insist it is our "custom" scripts. I can promise you this, it is far from over. I'm 65 and have mellowed with age and don't let the "small" things bother me. Well, I am HOT!!

[Jasiu]

I just tried https://www.hsnpar.com/testdns.php and got a good result. Seems the issue is coming and going. Often incoming requests on high-volume server farms are load-balanced between multiple physical servers in order to improve response time (worked on a product that did just that a couple decades ago). Just a total guess but maybe that is what goes on here and it depends on which actual piece of hardware processes the request.

[rlee171]

Could that have anything to do with your fix that I applied?

update: I ran it this morning Sat. 9/21 and received:

bool(false)

Host address is tgftp.nws.noaa.gov

[Jasiu]

The fix/kludge that is in only affects the curl call in that file. Any other resolution requests still go through the normal process.

[CamarilloWX]

Thanks to Jasiu for the bypass fix shown above.  The root cause of the issue for GoDaddy folks is a DNS lookup failure by the GoDaddy caching DNS servers for tgftp.nws.noaa.gov. You have to ask their tech support to
1) login to the Webserver using SSH
2) try using

Code: [Select]

nslookup tgftp.nws.noaa.gov and see/fix the error messages shown.

They can use the contents of /etc/resolv.conf to figure out which nameserver(s) are having the issues.  It is THEIR problem to fix, and Jasiu’s bypass is a good temporary workaround.

I am currently on a cruise ship between Bergen, Norway and Torshavn, Faroe Islands on our way to Montreal, Canada on the 30th.  So.. responses to issues are going to be quite limited by me as I’m away from my normal debugging tools (writing this on an iPad using ship’s internet).

BTW.. in Bergen, Norway we’ve experienced the remnants of Dorian causing heavy rain/wind and high seas.  What goes up the east coast of the USA ends up in Europe, thanks to following the Gulf Stream.

I was able to login using SSH, this is what I saw.

[/]$ nslookup tgftp.nws.noaa.gov
;; Got SERVFAIL reply from 72.167.234.214, trying next server
;; connection timed out; trying next origin
;; Got SERVFAIL reply from 72.167.234.214, trying next server
;; connection timed out; no servers could be reached


[/]$ more /etc/resolv.conf
# Generated via Puppet
nameserver 72.167.234.213
nameserver 72.167.234.214
options rotate

As noted, the problem seems to be intermittent.  I'll keep an eye out and see if I can run the commands again when DNS lookup is working.  Then I'll contact GoDaddy with the results and see if I can get them to take a look.

[mkutche]

I don't have / use that code. If you want to DM me the source (you'll need to rename it a txt file to do that) I can have a look.

Hey Jasiu here is my cloudbaseCU.php as txt. Sorry it took so long been busy. Hope you or someone can help me with the METAR on this one.

Mike

[Jasiu]

Mike - unfortunately that code uses the simple PHP file() function rather than the curl system used by Ken's METAR code to fetch the METAR data from NOAA. I don't think you can override the local DNS decision with the file() call (at least I don't know how to do it).

In order to use the same workaround, someone would have to modify your code to use curl rather than file(). Or you'll just have to wait until the GoDaddy problem gets fixed.

Camarillo - great getting someone to SSH into a GoDaddy server. Will be watching your results.

[mkutche]

Mike - unfortunately that code uses the simple PHP file() function rather than the curl system used by Ken's METAR code to fetch the METAR data from NOAA. I don't think you can override the local DNS decision with the file() call (at least I don't know how to do it).

In order to use the same workaround, someone would have to modify your code to use curl rather than file(). Or you'll just have to wait until the GoDaddy problem gets fixed.

Camarillo - great getting someone to SSH into a GoDaddy server. Will be watching your results.

Well that sucks wish godaddy wasn’t stupid and could fix the issue without workarounds lol thanks for looking at it.

[mkutche]

is there away to make the get-metar-conditions to use Cumulus (Zambretti Forecast) data ONLY? I set my cloudbasecu.php getmetar to false and it is showing correctly that it is mostly cloudy near my location instead of clear.

edit i just had to delete the metar cache for the metar station near me it now show correctly i just hope this doesnt have to happen all the time to get it to work.. i'll keep an eye on it.

[DW7240]

Hey,

Don't want to speak too soon, but something has happened at GoDaddy it looks like, my site now loads as normal, with normal Metar etc.  I now wondering if I should go back to the previous scripts before this issue, I'll give it 24 hours, then go back to see if things work, interesting that my Sager forecast is back working at the same time.

 Awesome...…..Huge thanks to everyone here who contributed information and those with the knowledge to get those scripts working in our favour.

Thank You !!!!!!!!

Nick. dw7240.com

[the beteljuice]

interesting that my Sager forecast is back working at the same time.

BTJ Sager forecaster uses METAR look-up for cloud conditions.

[CamarilloWX]

I was able to login using SSH, this is what I saw.

[/]$ nslookup tgftp.nws.noaa.gov
;; Got SERVFAIL reply from 72.167.234.214, trying next server
;; connection timed out; trying next origin
;; Got SERVFAIL reply from 72.167.234.214, trying next server
;; connection timed out; no servers could be reached


[/]$ more /etc/resolv.conf
# Generated via Puppet
nameserver 72.167.234.213
nameserver 72.167.234.214
options rotate

As noted, the problem seems to be intermittent.  I'll keep an eye out and see if I can run the commands again when DNS lookup is working.  Then I'll contact GoDaddy with the results and see if I can get them to take a look.

As noted by Nick, things appear to be working again for now.  I logged in again with SSH and reran the commands as suggested by Ken.  This is what I saw:

[/]$ nslookup tgftp.nws.noaa.gov
Server:         72.167.234.213
Address:        72.167.234.213#53

Non-authoritative answer:
tgftp.nws.noaa.gov      canonical name = tgftp.op.ncep.noaa.gov.
tgftp.op.ncep.noaa.gov  canonical name = tgftp.cp.ncep.noaa.gov.
Name:   tgftp.cp.ncep.noaa.gov
Address: 140.90.101.79

[/]$ more /etc/resolv.conf
# Generated via Puppet
nameserver 72.167.234.213
nameserver 72.167.234.214
options rotate

I am pushing the envelope here with my troubleshooting skills so bear with me,  It looks to me like maybe when it wasn't working it tried using 72.167.234.214 but it was failed; it then tried 72.167.234.213 but it did not respond.  When it was working 72.167.234.213 was the server that responded and it worked.  Anyone out there with more knowledge then me that can confirm that or tell what's really going on?

Eric   

[Jasiu]

Note that you can specify the server after the host name in the nslookup command. E.g.,

  nslookup tgftp.nws.noaa.gov 72.167.234.214

[CamarilloWX]

Note that you can specify the server after the host name in the nslookup command. E.g.,

  nslookup tgftp.nws.noaa.gov 72.167.234.214

I did not know that, thanks.  Here are the results:

[/]$ nslookup tgftp.nws.noaa.gov 72.167.234.213
Server:         72.167.234.213
Address:        72.167.234.213#53

Non-authoritative answer:
tgftp.nws.noaa.gov      canonical name = tgftp.op.ncep.noaa.gov.
tgftp.op.ncep.noaa.gov  canonical name = tgftp.cp.ncep.noaa.gov.
Name:   tgftp.cp.ncep.noaa.gov
Address: 140.90.101.79

 [/]$ nslookup tgftp.nws.noaa.gov 72.167.234.214
Server:         72.167.234.214
Address:        72.167.234.214#53

Non-authoritative answer:
tgftp.nws.noaa.gov      canonical name = tgftp.op.ncep.noaa.gov.
tgftp.op.ncep.noaa.gov  canonical name = tgftp.cp.ncep.noaa.gov.
Name:   tgftp.cp.ncep.noaa.gov
Address: 140.90.101.79

Looks like both servers are working at the moment.  I'll try it again if the problem returns.

Eric

[Jasiu]

It looks like to GoDaddy resolution problem is back. I've seen it on two sites now.

[tshattuck]

Folks:
WOW! 
I didn't realize when I posted the question on Sept 13th regarding the METAR web page that there was such a huge underlying problem. I agree Customer Service at GoDaddy leaves something to be desired. I've had problems in the past with their Servers which is a pain to get addressed and usually takes multiple phone calls to fix.

I decided to simplify my web site by using NWS Product: RWR. Please see attached link.
It loads very fast and the coding is simpler. The down sides are; the new web page is all text and not all NWS local offices create product RWR. 

http://yourlocalweather-clay-ny.com/wxforecast-regional-weather-roundup.php

Thanks to all for your time and efforts

[DW7240]

Well...…..,as feared...…..I Spoke too soon, I come home from work and yes a slow site load again, also no metar reports, just as before, this problem seems to be a tricky one to point to a clear culprit, I'm beginning to think that GoDaddy are not the issue, that the main problem seems to stem from certain NOAA servers.

If your asking why I think this, it's because I had an issue with the NOAA radio broadcasts also, I retransmit the Toronto (XMJ225. 162.4 MHz) Weather Radio Broadcast, and funny enough this issue started around the same time, during the broadcast it would come across with no Forecasts being available from the list of forecasts available from the region, which was weird to listen to, and never gave it much thought as to whether this issue could be linked.  Not knowing how NOAA gathers it's forecasts I'm sure that all the forecast information crosses over with each form of broadast, whether it be metar forecasts for the airports etc, or whether it's on their weather radio broadcast, and that data comes to an end point, namely a server which carries that information to feed the end points as mentioned.  I could be barking up the wrong tree, but the radio broadcasts after a couple of weeks seem to be normal as before the issues.

Anybody with thoughts on this I'd be happy to read about, I'm not a stupid person but would welcome the extra knowledge to help in the future.

THanks.

Nick. dw7240.com

[Jasiu]

Here's why it can't be the actual NOAA servers...

Because no requests actually go to the NOAA servers.  It's in the "how to I get to NOAA" part of the process that it breaks.

A loose analogy... DNS on the Internet is somewhat like the contacts we have on our phones. Most of us are old enough to remember when you had to memorize phone numbers or at least have the ones you used most written down somewhere because you had to manually enter the number. Now, if I need to call Jane Smith, I just tap on "Jane Smith" and magic happens. I don't need to actually interact with the number.

Similarly, DNS maps domain and sub-domain names to IP addresses, and it is a global system so that anyone can reach any valid domain. But to get to any particular domain, when you get to what's transmitted on the wire/fiber/radio, you need its IP address. Without it, it would be like your phone trying to call Jane Smith when the phone number is blank.

That is what is happening in this case. The METAR code is saying to the local server "I want to connect to  tgftp.nws.noaa.gov" and the GoDaddy server says back, "Huh. Never heard of the guy. Sorry".  So there is never a single data request to NOAA because there is no way to contact their server.

If this were a problem outside of GoDaddy, others would see the issue also. I've seen no reports with other providers.

[DW7240]

Hey,

Awesome response, thank you for the explanation, that gives me a better insight as to what is going on, also backs up those who said they have no issues with other providers, but I've also heard that even some GoDaddy users are having no issues, so that tells me its one particular server, if so then there shouldn't be an issue finding that server by GoDaddy Techs.  Like I've said before, we weather enthusiasts are a small bunch in comparison to other users globally.  Bigger voice normally amounts to required action, but now a days with everything coming down to money, I'm surprised GoDaddy aren't listening, there's a lot of competition out there from other server providers, some cheaper, maybe less reliable, but they exist for people like us.  Sometimes money doesn't always do the talking, it's about customer satisfaction, I guess that means nothing now, and look at the result !

Again thanks for the explanation, can only hope GoDaddy can do the right thing, but I think we're all in for a long ride.

Nick. dw7240.com.

[wcrowder]

Thanks Jasiu!

[CamarilloWX]

I just spent 2 -1/2 hours on chat with GoDaddy tech support and I got absolutely nowhere.  I am conceding defeat.  Anyone have a recommendation for another host provider that isn't experiencing this issue?

[wcrowder]

And the temp fix has stopped working, seems odd. About to do that myself, did you ask them to ssh into you service and ping the address?

The server I'm on doesn't seem to recognize CURLOPT_RESOLVE as valid, that would make it a very old version of PHP.

[CamarilloWX]

And the temp fix has stopped working, seems odd. About to do that myself, did you ask them to ssh into you service and ping the address?

Odd that the fix stopped working for you, still looks good here.  I asked two different techs to run nslookup and observe the failure.  I sent them screen shots of me doing the same with the resulting failure.  I ran nslookup from my PC and it worked.  I ran nslookup from an online nslookup site and it worked.  I explained the issue every which way I could. I got nowhere.

You can set your version of PHP in the control panel.  I am at 7.0.33, any further than that and I start to get errors on some of the pages.

[wcrowder]

I get this with the "fix" now.

Warning: curl_setopt() expects parameter 2 to be long, string given in /home/content/80/7511980/html/crowderfarm/get-metar-conditions-inc.php on line 316

using

    curl_setopt($ch, CURLOPT_RESOLVE, array("tgftp.nws.noaa.gov:443:140.90.101.79"));
    curl_setopt($ch, CURLOPT_TIMEOUT, $numberOfSeconds); //  data timeout
    $data = curl_exec($ch); // execute session
    if (curl_error($ch) <> '') { // IF there is an error
      $Debug.= "<!-- curl Error: " . curl_error($ch) . " -->\n"; //  display error notice
    }

I've changed the update time to 84600 seconds until I can get this figured out. Probably need to call during normal business hours to get someone that knows anything.