Support

Akeeba Backup for Joomla!

#20671 Update Checker broken on Brazilian EC2 instances

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Thursday, 07 August 2014 07:24 CDT

Ludwig von Mises
Description of my issue:

Nikolas, I never bother you with support but this time you're the target for something that is affecting core Joomla, Akeeba Backup & Admin Tools as well as SourceCoast! Hope you can give me some insight.

I have used Joomla & Akeeba for years in multiple hosting environments (shared, cloud, VPS, dedicated) and have never had the hanging update problem before. Now I do. And it is only happening on EC2 instances in Sao Paulo, Brazil. I have already tested these two sites on other VPS services as well as EC2 in Virginia, so I can definitely rule out my setup. In a nutshell, EC2 Virginia = checking updates works; EC2 Brazil = checking updates kills server with 504.

I use EC2 + ServerPilot with a LEMP stack (100% Nginx), however I have also tested with Apache and the updates are still broken.

Here is an Nginx error:
2014/07/31 12:17:45 [error] 7049#0: *37344 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 190.49.12.42, server: app-mydomain, request: "GET /administrator/index.php?option=com_akeeba&view=cpanel&task=updateinfo&tmpl=component HTTP/1.1", upstream: "fastcgi://127.0.0.1:abcde", host: "mydomain.com", referrer: "https://mydomain.com/administrator/index.php?option=com_akeeba"

And here is an example Apache error:
[Mon Aug 04 19:07:22.618820 2014] [proxy_fcgi:error] [pid 27449:tid 140724745996032] [client 190.49.34.212:56776] AH01067: Failed to read FastCGI header, referer: https://mydomain.com/administrator/index.php

Remember, I have tested these two sites hosted in Brazil on other servers in the US (EC2 Virginia, DigitalOcean NY2, a2 Hosting dedicated) and the updates work fine. I also manage a dozen or so sites in various hosting environments and updates are fine. Also, in Brazil, NoNumber updates and the jReviews news feed work fine. Front-end is 100% perfect as well as back-end, barring Akeeba Backup, Admin Tools, Joomla update, Extension Manager update and JFBConnect update.

I have tried every Nginx directive in the book with no luck. ServerPilot support suggests setting up a proxy server (which I would like to avoid) or asking you guys if you have me blocked (which is what I am asking now).

So, are you, Joomla and Sourcecoast BLOCKING the requests from EC2 Sao Paulo? Is hosting outside the US causing the problem? The server's IP is 54.94.155.118.

Thanks!

nicholas
Akeeba Staff
Manager
Updates are handled by Joomla! itself, not Akeeba Backup. We are merely asking Joomla! to tell us if an update is available. Our update XML file is hosted on Amazon CloudFront. I don't think that Amazon blocks its own CDN from its own servers, so no, we are not blocking your EC2 instances.

You can always update the component manually.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Ludwig von Mises
Thanks for confirming that. I set all updates to enabled=0 in the update_sites table. Just logging in to admin killed the whole site when the update check failed! So I will do everything manually, take the issue up with Amazon and see what they say. If I ever get to the bottom of this I will report back.

Thanks!

nicholas
Akeeba Staff
Manager
Just logging in to admin killed the whole site when the update check failed!


That's very strange. Once the Joomla! control panel page loads it sends an AJAX request to the site to report available updates. Joomla! will check the last update timestamp of each enabled update site. If it's older than the current time minus the update frequency (set in the Options of Manage Extensions, default 6 hours) it will attempt to download the XML update stream specified in the update file and populate the updates table. If it can't download the XML file it will instead disable the update site. Finally, the code counts the update sites with non-zero update records and returns that through the AJAX request. The Javascript code in Joomla! reads the returned value and updates the page.

If the AJAX request fails there is no problem in Joomla!'s control panel. It simply won't report any updates. You can continue using the CMS just fine. This method (AJAX request) was selected back in the Joomla! 1.7 era exactly because it doesn't bring down the site if the Joomla! update fetch fails.

If the update check brings down your site you should check your server setup. Maybe you have an intrusion detection system or a firewall with an itchy trigger finger?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!