Posted by kali on Sun, Feb 23, 2025 - 3:08pm --- Updated: Feb 23 '25 - 4:22pm

Hello,

My Backdrop CMS web sites doesn't display update information anymore event on a simple site with no external modules. 

Versions

  • Debian 12
  • Apache  2.4.62
  • PHP  8.3.17 (including openssl)
  • Backdrop CMS 1.30.1

Description

As user 1, Reports > Available update > List available update displays :  "backdrop 1.30.1 … Failed to get available update data".

The message generated in the logs shows  :  

https://updates.backdropcms.org/release-history/backdrop/1.x?…………… failed with error: Connection timed out.

This same url (logged in the message) works when used with wget and curl, on the server, ran by the user running the web site. It downloads the same xml content I can get with a web browser on my workstation.

Tips and directions to investigate would be welcome. Thanks in advance.

Kali.

Accepted answer

The reason was too simple : misconfiguration of the updates server

My server uses IPv6 first and :

# dig updates.backdropcms.org AAAA

;; ANSWER SECTION:
updates.backdropcms.org. 856    IN      AAAA    2600:3c03::f03c:91ff:fec2:d257

# ping 2600:3c03::f03c:91ff:fec2:d257
PING 2600:3c03::f03c:91ff:fec2:d257(2600:3c03::f03c:91ff:fec2:d257) 56 data bytes
^C
--- 2600:3c03::f03c:91ff:fec2:d257 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5110ms

Workaround (temporary)

appended to /etc/hosts

66.175.208.83 updates.backdropcms.org

Then updates instantly  worked like a charm on all websites powered by Backdrop CMS on this server.

Of course, this workaround by-passes DNS resolution :(

Solution

The solution is on Backdrop CMS's side : consistent configuration of DNS and web servers of updates.backdropcms.org 

Please let us know so that I can roll-back /etc/hosts.

Comments

Fri, Mar 07, 2025 - 3:46pm by onyx

PHP Openssl is missing perhaps?
 I know you've stated that it's there, but if it's having issues loading for any reason, it will fail with updates.
Try doing a phpinfo(); call to check it is loaded.

Mon, Mar 10, 2025 - 1:35am by yorkshirepudding

You can easily check phpinfo() by going to the Status Report (admin/reports/status) and clicking the link against the PHP item:

Mon, Mar 10, 2025 - 3:40am by kali

Thanks for the suggestions !

site/admin/reports/status/php reports that the OpenSSL module is present :


PHP Version 8.3.17
...
OpenSSL support     enabled
OpenSSL Library Version     OpenSSL 3.0.15 3 Sep 2024
OpenSSL Header Version  OpenSSL 3.0.15 3 Sep 2024
Openssl default config  /usr/lib/ssl/openssl.cnf
...
Phar Native OpenSSL support     enabled

But the directives related to CA have no value set :

Directive Local Value Master Value
openssl.cafile no value no value
openssl.capath no value no value

Is it a problem to get Backdrop update information ?

Mon, Jun 16, 2025 - 11:10pm by kali

The reason was too simple : misconfiguration of the updates server

My server uses IPv6 first and :

# dig updates.backdropcms.org AAAA

;; ANSWER SECTION:
updates.backdropcms.org. 856    IN      AAAA    2600:3c03::f03c:91ff:fec2:d257

# ping 2600:3c03::f03c:91ff:fec2:d257
PING 2600:3c03::f03c:91ff:fec2:d257(2600:3c03::f03c:91ff:fec2:d257) 56 data bytes
^C
--- 2600:3c03::f03c:91ff:fec2:d257 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5110ms

Workaround (temporary)

appended to /etc/hosts

66.175.208.83 updates.backdropcms.org

Then updates instantly  worked like a charm on all websites powered by Backdrop CMS on this server.

Of course, this workaround by-passes DNS resolution :(

Solution

The solution is on Backdrop CMS's side : consistent configuration of DNS and web servers of updates.backdropcms.org 

Please let us know so that I can roll-back /etc/hosts.

Tue, Jun 17, 2025 - 3:50am by yorkshirepudding

Thanks for reporting back kali.  I have posted your feedback in our infrastructure chat channel and hopefully there will be a resolution in the near future.

Thu, Jun 19, 2025 - 2:56am by yorkshirepudding

Our infrastructure lead has advised that he has added 'the A and AAAA records for updates.backdropcms.org'

Please can you test again and report back

Thu, Jun 19, 2025 - 9:07am by kali

Hi,

Thank you yorkshirepudding for pushing up and reporting back !

It still doesn't work on ipv6. I don't know what the infrastructure lead did since both records already existed.

The problem is that https requests to 2600:3c03::f03c:91ff:fec2:d257 are not served. As long as the AAAA record exists in the public zone, https public request to the ip declared are supposed to be served. The solution to the problem depends on many factors. The key word is consistency.

For instance, removing the AAAA record from the public zone would do this job but it sounds more like a temporary patch than a good practice, and could break other services (deployment, backups…)

Thu, Jun 19, 2025 - 9:08am by yorkshirepudding

Thanks for your quick response.  I'll feed this back.