Cumulus Support

@Griffo42,

When I type in: https:// komokaweather.com/cumulusmx4/index.htm, it goes to the Bing search results page.

Yes, good eye, that is not a clickable link with the space between https:// and Komokaweather.com/cumulusmx4/index.htm done on purpose as the forum Signature settings only allows 5 URL's and that one would be the 6th (there are 2 in the banner url). I left it that way in hopes users would see the error and remove the space
In any case the https now shows on all my other URLs

Now back to fixing the .ca sites...

Enjoy,
Paul

Hi Ken,

so, the root cause seems to be your webserver can't connect to the EC site.. that's a job for the hoster's tech support to solve.

BTW.. it's also good that you corrected the Settings.php and updated the ec-forecast.php to the current release. Also, the cache file for your default forecast (https://www.komokaweather.com/komokawea ... 326-en.txt) has contents that haven't been updated since Saturday February 03, 2024 at 10:03 EST -- maybe your website IP is on the EC's 'naughty list' and has a firewall block...

I have not yet contacted GoDaddy as have been doing a nearly new install from the latest Canada and CU zips from your template site. The result is about the same but comfortable I have the correct files uploaded. Is there an easy way that I can temporary rem the ec-forecast part so that the rest of the site displays?

Enjoy,
Paul

Do contact your hoster's tech support to get the root-cause (connectivity to weather.gc.ca) fixed.

I've tried multiple methods to 'quietly' disable ec-forecast.php, and all of them result in other Notice errata appearing.

Your base forecast uses data from https://dd.weather.gc.ca/citypage_weath ... 0326_e.xml and stores the file
in ./cache/ec-forecast-0-on-137-s0000326-en.txt

Try saving that file(attached) in your ./cache/ directory, then change ec-forecast.php to so the cache won't expire and your website should complete loading.

Wow, that brought both of them back to life
https://www.komokaweather.com/komokawea ... recast.php
https://www.komokaweather.com/komokawea ... recast.php

I know very little about cache, and am I correct to assume the longer period 600 to 999999 means the script is not trying to go the EC site where it would fail?

Getting ready for my call to GoDaddy, and their initial comment, "check your script"!

Enjoy,
Paul

Yes, changing the time to 999999 just causes the script to NOT try and fetch new data from the EC site (which is failing due to the connectivity issue).

Its typical for 1st level support to blame the script.. it's the webserver's connection to dd.weather.gc.ca (at IP 205.189.10.47 ) from your webserver at IP 198.12.220.99 that is failing. It may be a firewall block by the EC for abuse.. the tech support has to work that out.

Hi Ken,
I've had a long discussion with GoDaddy support and in the end they say it is a script or EC issue and they can't do anything further. I did mention that it is not an issue with other users of the script. I have sent a request to EC.

Since I have another similar template in construction I was able to show GoDaddy that it fails with the normal cache setting of 600 but not if refetch is disabled (set at 999999). I have tried both sites with both settings:
https://www.komokaweather.com/komokaweather-ca current setting $refetchSeconds = 999999; and displays, but fails if settings = 600
https://www.komokaweather.com/komokaweather-ca2 current setting $refetchSeconds = 600; and fails, but displays if settings = 999999

GoDaddy support say they have elevated the issue and have checked the connection to IP 205.189.10.47 and there is no issue that they can see - not being blocked nor failing. They had increased the PHP limit to the maximum in case that may have been an issue but that made no difference.

I'll wait for an EC response.

Enjoy,
Paul

Hi Paul,

I see you are working with Ken to successfully repair parts of your installation of the site.
So far I did not get feedback of my Malwarebytes support, but I think the now you have https working, you might ask a new IP address (either a new DHCP lease or another shared server) to change your IP address. I think that should solve the issue with malware alarms (either my or another guard).

Thanks Hans,
Not much success with GoDaddy support but I have contacted abuse@godaddy.com that my 198.12.220.99 hosting shows Grade A no malware found, and to do whatever is necessary to have it removed from the naughty list

I have an acknowledgement, within just a few minutes... I didn't realize until this reply that I had submitted in on GoDaddy's EU Digital Services reporting form but that is what my original email reply came from. I'll wait for what comes next.

Enjoy,
Paul

@paul: a EU Digital Services reporting form... Reporting for different parts of the world?

Somehow we must be able to have the complexity disappear don't we?

I suggest trying a different tactic.. contact the EC about dd.weather.gc.ca site (based on https://www.weather.gc.ca/mainmenu/contact_us_e.html ) contact, you should use the form at https://www.weather.gc.ca/mainmenu/contact_us_e.html and use the Data request.

Let them know you are trying to access the XML forecast at https://dd.weather.gc.ca/citypage_weath ... 0326_e.xml
and am receiving a timeout to connect to dd.weather.gc.ca from IP address 198.12.220.99.
Ask them to check their firewall configuration and see if that address is blocked, and if it is, to please remove the block.

Thanks Ken,
As I noted in an earlier post yesterday, I had contacted EC about the apparent blocking and waiting for their reply. It was the same form I used as your link. It is the weekend so I will be patient for their response. I hadn't mentioned specifically about "trying to access the XML forecast" so will do that in any reply from them. In addition to that, I followed up with GoDaddy as in my cPanel it shows A OK and no malware, but in the phone support they indicated it was malware. A lookup for the shared hosting IP address showed those issues that Hans had mentioned so I wanted to follow up from that perspective as well.

At the moment I have left one of the sites with the $refetchSeconds = 600; and the other $refetchSeconds = 999999; so that they can see the different behaviour.

Enjoy,
Paul

Hi Paul
I have Bitdefender installed and when using these CMX forms if you had an input into any I would get a Suspicious web site notice. I am pleased to say that these notices no longer happen since yesterday and today .
Dave

Good news from Environment Canada on data access:

Hi Paul,
Your request has been forwarded to me, thanks for your interest in our data and services.
I sent your email to our data dissemination team in charge of data dissemination.
"As announced earlier", some IP addresses have been blocked by a new security process beyond our control.. Our analyst will investigate and fix it as soon as possible.

Thanks a lot for your patience and our apologies for the inconvenience.

Best regards.
Sandrine

And the link in the "As announced earlier" has:

Announcement list for the MSC-Datamart.
Monday, 27 November 2023 9:47 p.m.

Dear MSC open data users,
Some users have reported problems accessing our data services (blocked IP addresses). If
this is your case, please contact me at
dps-client@ec.gc.ca<mailto:dps-client@ec.gc.ca> in order to restore the service.

We are aware of the inconvenience this situation, beyond our control, may have caused your
applications, and we will do everything in our power to prevent this from happening again
in the future.

Thank you for your cooperation and patience.

All the best.
Sandrine
--------
Sandrine Edouard

I will update the setting "$refetchSeconds = " when EC confirms the blocks has been corrected.

Again thank you Ken for your help in looking for the issue and suggestion for getting it fixed. Most greatly appreciated

Enjoy,
Paul

I may have the root cause of your issue.

According to https://www.abuseipdb.com/check/198.12.220.99 your webserver's IP address is on a major naughty list. That list is used by some companies to automatically block requests (using fail2ban).
Since it wasn't your specific website on the shared webserver at that IP address causing the abuse reports, but one or more of the other websites hosted there, you will likely be unsuccessful in getting the EC block removed.

Your best fixes may be:
1) get your hoster (GoDaddy) to port your service to another server that uses a different ip address, or failing that,
2) switch to a new hoster (and get a small VPS you can manage so there are no miscreant 'neighbors').

Hope this helps...

Thanks Ken. That is my expected outcome. I have not yet heard from EC but followed up with an email this morning. There has also been no further response from EU Digital services either. I have been following Mapantz' thread that appears to be somewhat similar.

Switching hosts has often been suggested but I seem to be so locked in with GoDaddy with email accounts and the other non-profit sites that I have on my hosting account, and it scares me

Enjoy,
Paul