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.

Thu, Sep 25, 2025 - 4:15am by yorkshirepudding

Hi Kali

Since the last post, there have been some changes and the infrastructure lead has asked me to ask you to check again please.

Thu, Sep 25, 2025 - 2:01pm by kali

Hi,

The problem is still here.

If I don't by-pass DNS resolution, checking update fails.

The error message displayed in BackdropCMS logs interface  is : 

HTTP request to https://updates.backdropcms.org/release-history/globalredirect/1.x?site_key=ywiDUUcw7q5-JK1Vs-fYHLzmoWt3ze_e67wWSHBlJYc&version=1.x-1.6.0&list=globalredirect failed with error: Connection timed out.

The host is not even pingable on its IPv6 interface : 

$ ping updates.backdropcms.org
PING updates.backdropcms.org(backdropcms.org (2600:3c03::f03c:91ff:fec2:d257)) 56 data bytes 
^C 
--- updates.backdropcms.org ping statistics --- 
30 packets transmitted, 0 received, 100% packet loss, time 29680ms

If I by-pass DNS resolution, checking update works. I by-pass adding a declaration in my /etc/hosts that forces IPv4 : 

66.175.208.83 updates.backdropcms.org

And ping works since it pings the host on its IPv4 interface : 

$ ping updates.backdropcms.org
PING updates.backdropcms.org (66.175.208.83) 56(84) bytes of data. 
64 bytes from updates.backdropcms.org (66.175.208.83): icmp_seq=1 ttl=50 time=73.7 ms 
64 bytes from updates.backdropcms.org (66.175.208.83): icmp_seq=2 ttl=50 time=73.9 ms 
64 bytes from updates.backdropcms.org (66.175.208.83): icmp_seq=3 ttl=50 time=73.7 ms 
^C 
--- updates.backdropcms.org ping statistics --- 
3 packets transmitted, 3 received, 0% packet loss, time 2000ms 
rtt min/avg/max/mdev = 73.747/73.784/73.857/0.051 ms

As I wrote in a previous message, if the "infrastructure lead" removes the following  record from the public zone, it should solve the problem.  

updates.backdropcms.org. 1799   IN      AAAA    2600:3c03::f03c:91ff:fec2:d257

Before proceeding, the question is : " would it break something in the real world services ?" The "infrastructure lead" may be able to answer that question. And if the answer is "no",  to remove the record.

Feel free to send my whole message to the "infrastructure lead" ;)

Fri, Sep 26, 2025 - 12:26am by yorkshirepudding

Reply:

I am happy to remove the AAAA record for updates.backdropcms.org. There is a cname in place so it will still resolve. However, please use the command ping6 updates.backdropcms.org for your testing because it is the IPv6 version of the ping. Double check that you IPS has assigned an IPv6 address to your internet connection (router/gateway).

It looks like the release-history query you posted is working well for me on IPv4:

and IPv6 

$ ~ [2]> ping6 updates.backdropcms.org
PING updates.backdropcms.org(backdropcms.org (2600:3c03::f03c:91ff:fec2:d257)) 56 data bytes
64 bytes from backdropcms.org (2600:3c03::f03c:91ff:fec2:d257): icmp_seq=1 ttl=64 time=0.036 ms
64 bytes from backdropcms.org (2600:3c03::f03c:91ff:fec2:d257): icmp_seq=2 ttl=64 time=0.061 ms
64 bytes from backdropcms.org (2600:3c03::f03c:91ff:fec2:d257): icmp_seq=3 ttl=64 time=0.049 ms
64 bytes from backdropcms.org (2600:3c03::f03c:91ff:fec2:d257): icmp_seq=4 ttl=64 time=0.047 ms
64 bytes from backdropcms.org (2600:3c03::f03c:91ff:fec2:d257): icmp_seq=5 ttl=64 time=0.059 ms
64 bytes from backdropcms.org (2600:3c03::f03c:91ff:fec2:d257): icmp_seq=6 ttl=64 time=0.045 ms
64 bytes from backdropcms.org (2600:3c03::f03c:91ff:fec2:d257): icmp_seq=7 ttl=64 time=0.043 ms
64 bytes from backdropcms.org (2600:3c03::f03c:91ff:fec2:d257): icmp_seq=8 ttl=64 time=0.047 ms

^C--- updates.backdropcms.org ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7152ms
rtt min/avg/max/mdev = 0.036/0.048/0.061/0.007 ms

$ ~> curl "https://updates.backdropcms.org/release-history/globalredirect/1.x?site_key=ywiDUUcw7q5-JK1Vs-fYHLzmoWt3ze_e67wWSHBlJYc&version=1.x-1.6.0&list=globalredirect"
<?xml version="1.0" encoding="utf-8"?>
<project xmlns:dc="http://purl.org/dc/elements/1.1/">
  <title>Global Redirect</title>
  <short_name>globalredirect</short_name>
  <dc:creator>drop</dc:creator>
  <type>project_module</type>
  <api_version>1.x</api_version>
  <project_status>published</project_status>
  <recommended_major>1</recommended_major>
  <supported_majors>1</supported_majors>
  <default_major>1</default_major>
  <link>https://backdropcms.org/project/globalredirect</link>
  <releases>
    <release>
      <name>globalredirect 1.x-1.6.0</name>
      <version>1.x-1.6.0</version>
      <status>published</status>
      <date>1667443038</date>
      <filesize>23254</filesize>
      <security_update>false</security_update>
      <version_major>1</version_major>
      <version_minor>6</version_minor>
      <version_patch>0</version_patch>
      <release_link>https://github.com/backdrop-contrib/globalredirect/releases/tag/1.x-1.6.0</release_link>
      <download_link>https://github.com/backdrop-contrib/globalredirect/releases/download/1.x-1.6.0/globalredirect.zip</download_link>
    </release>
    <release>
      <name>globalredirect 1.x-1.5.0</name>
      <version>1.x-1.5.0</version>
      <status>published</status>
      <date>1429673649</date>
      <filesize>23255</filesize>
      <security_update>false</security_update>
      <version_major>1</version_major>
      <version_minor>5</version_minor>
      <version_patch>0</version_patch>
      <release_link>https://github.com/backdrop-contrib/globalredirect/releases/tag/1.x-1.5.0</release_link>
      <download_link>https://github.com/backdrop-contrib/globalredirect/releases/download/1.x-1.5.0/globalredirect.zip</download_link>
    </release>
  </releases>
</project>

Fri, Sep 26, 2025 - 4:23am by kali

Hi,

Now, checking updates works fine even if I don't force my host/system (server) to request the IPv4 address. Patch removed. Problem solved :)

Thank you !

Observations (hoping some can help)

  • ping6 is not "the" IPv6 version of ping even if it's the name of the command on your specific system.
  • the AAAA record declared for updates.backdropcms.org is still present in the public zone (authoritative DNS server). 
    • dig @dns2.registrar-servers.com updates.backdropcms.org AAAA
;; ANSWER SECTION: 
updates.backdropcms.org. 1799   IN      AAAA    2600:3c03::f03c:91ff:fec2:d257
;; SERVER: 2610:a1:1025::200#53(dns2.registrar-servers.com) (UDP) 
;; WHEN: Fri Sep 26 13:11:37 CEST 2025
  • there is no CNAME declared for updates.backdropcms.org nor backdropcms.org in the public zone (authoritative DNS server)
  • a zonemaster check on backdropcms.org reports an error
  • double-check that  tests are performed from outside the hosting infrastructure, on a system that relies entirely on DNS public zones (without local/user exception).