I’m a big fan of Slackware Linux – no wizards, no extra fluff, just the core system that can be repurposed to serve almost any computing need. While perhaps lacking in the user-friendliness model it certainly makes a compelling case for installing only the software you want installed, without any extra bulk.

While this does present some logistical , maintenance-related challenges (I can’t just point an upgrade script at all installed packages and say “go forth and prosper!”), it also makes me feel really good when I am able to solve issues and resolve problems, usually after a great deal of internet sleuthing. To me, using Slackware is about learning and using Linux, instead of some specific flavor or distribution (such as Ubuntu or Debian), and that means learning how core systems operate and interact.

As measures to secure my various websites I have included several directives that limit which external domains they can contact, which shell commands PHP can execute, which IP ranges can access which sites, and the like. When a web service needs to be updated, I lift a particular restriction for the update then replace it. All of this has been working fine for me for a healthy amount of time, until lately I wasn’t able to update WordPress any more.

Even after I removed all of the blocks I had put into my [wp-config] file, I was getting a strange cURL error, specifically reporting that it wasn’t able to resolve remote domains, such as the ones it tries to pull updates from. Identifying that as a DNS problem, I started looking at how cURL interacts with the rest of the system.

cURL error 6: Could not resolve host

I ran a simple command-line cURL get, which succeeded. I then tried the same from within PHP, which failed. “Ah,” thought I, “something’s going on with PHP-cURL.” I reinstalled both cURL and PHP, just in case there had been a blocking issue in a recent order of upgrades, but to no avail. Doing further research, signs pointed to the error being related to IPv6 versus IPv4. After testing, it did appear that PHP cURL commands could successfully communicate through IPv4 but not IPv6 – without additional arguments default behavior was to try v6 first and then fall back to v4 if necessary.

Adding a few extra options into WordPress to force it into using IPv4, I was dismayed to see that the issue persisted – I wasn’t able to obtain updates to either the core WordPress installation or plugins. Knowing how often WordPress receives security updates, I wanted to make sure I was as current as possible; my other security precautions would be for naught if the underlying system were vulnerable.

Dozens of blog articles, forum searches, and third party plugin bug trackers later, I finally found a single comment that lead me to my solution. Apparently there was a specific bug in the [glibc] library that caused cURL to fail many get requests, particularly when called from PHP.

[glibc] is one of those package sets that I have to be very careful updating, since so many programs and scripts end up being statically linked to a specific version – change the version, break the program. I made sure to update [glibc-solibs] first, which can serve as a framework for other packages, and then the rest of [glibc].

After a clean restart of apache (my webserver), cURL was again working just fine. A huge, huge thank you to this thread and “bobbybouwmann” in particular for pointing me in the right direction with his post earlier this year.