I have mentioned before this server runs on old hardware and Fedora Core 14. That’s a 9-year-old OS which in terms of software, it’s like 3 times its life expectancy at this point. Fedora is almost on version 31 now. Keeping old OS around can be real hassle, but then again so is updating and upgrading to newer versions and making sure everything still works as before.
Nowadays updating the OS is a relatively simple task. The kernel gets updated with the new version almost as easily as updating a component and a reboot finishes the job. But at this point the Fedora 14 running on this server is so old that there no upgrade paths. The only way is to make a fresh install and then migrate the files, testing everything along the way. And so, I have decided to leave the OS alone and that’s how this server is nearing a decade on the same OS.
I have previously covered the fact that I have patched and upgraded components of the OS over time, from the Apache Web Server to PHP and Python to TLS to adding IPv6 stack to this server. As the OS has been out of support for many years, in just about all cases, the update job has been done by building and installing from the source. With bits of pieces of built components all over the place, the server is now a patchwork hell, but it has been a surprisingly stable one so far.
The latest effort has been to update PHP to version 7.3. This is actually the second time I was making a PHP update attempt on this server. Last year I upgraded PHP to version 5.6 to head off some security bugs that had been discovered in prior versions, and to make use of some new language features. This time WordPress provided the impetus to make the update. The latest WordPress versions have started to display this alert on the dashboard when running on older PHP versions:
Updating to the latest versions of PHP is pretty straight forward on a newer OS. It’s just the matter of making sure the correct repository is configured and then making the install. For example, in the RedHat/CentOS/Fedora world that entails adding the “Remi” repository followed by “yum install”.
In my case however, the standard “yum” option (now “dnf”) is out of the question. I needed to download the PHP 7.3 source and build it myself. Right from the start “./configure” unleashed a torrent of errors. Some were complaints about older version of products/libraries in my Fedora 14 OS while others were about missing libraries. Fixing those errors is like falling into a rabbit hole of iterative updates. One library relies on another which relies on another library with a newer version. That meant I had to download the sources and build the downstream libraries before I could come a level back up. In other cases, I had not placed the previously built libraries in standard locations, so I had to actually edit the “configure” file and provide a bit of location guidance in a few areas. I also decided to forego a few unused extensions such as “Mapi” that I could do without.
When “./configure” finally ran successfully emitting the “Makefile” file I had miraculously passed the first hurdle. The “make” command was up next. This command, following the “Makefile” instructions, builds the executables and libraries of PHP. I was sure there would be errors and I wasn’t surprised when I saw them. As I was hunting and correcting the errors one persistent error kept emanating from a few lines in “php_zip.c”. After some consideration, I decided that I could comment out those lines without harming the overall product as it is used on this server* and the second hurdle was finally overcome. I had my “php” and “php-cgi” holy grail executables.
The right next step after “make” is “make test”. On this step a number of tests and checks are run against the newly built PHP to make sure it is functioning properly. I knew there was no passing all those tests, given the old Fedora 14 OS. Instead I wanted to test the new PHP against the existing web pages on the server. This is of course not a proper test as even if it passes, that’s no guarantee future pages or scripts will function as expected. But this is my server and my pleasure so I headed straight to executing the cli “php -v”. It was encouraging to see the new version but a few errors also printed on the screen. At least I finally had PHP 7.3 running on the server.
Turns out those errors were due to missing extensions that PHP couldn’t load. A few of those extensions such “mysql” and “mcrypt” have been deprecated and are no longer part of the PHP 7.3 core. Other errors, such as “zip” load error were caused by old library versions, requiring me to build newer versions of those libraries, such as “libssl”, and install them.
The final piece was the “mcrypt” extension which has been deprecated and its use discouraged. Instead the “Sodium” or “OpenSSL” extensions are suggested as a safer alternatives. My site does make use of “mcrypt” and I need time to update those references so leaving that extension out was out of the question.
Getting the “mcrypt” extension involved downloading its source from PECL, placing the source files under the “/ext/” directory, then “cd” into “/ext/mcrypt/”, run “phpize” then “./configure” followed by “make”. Of course, even in this case I ended up with errors at the “./configure” step. Turns out I had an older version of “Autoconf” and, surprise, I had to download the new “Autoconf”, build and install it before I could build the “mcrypt” library.
There’s no doubt that I need to migrate this server to a newer OS version like yesterday. Even though I’m happy that this site is now running on the latest version of PHP and WordPress has stopped complaining, I realize that this patchwork hell can be pushed only so far before it comes apart. It’s amazing that it has gone as far as it has and I’m under no illusion that these newly built components may not necessarily be fully stable nor secure when deployed in this fashion. Guess what I’m trying to say here is, don’t try this at home.
Note: No sooner I had deployed PHP 7.3 on this server than the word of several PHP code execution flaws hit the street. While for most people the fix was to simply install the latest released version of PHP, for me it was back to the source download, code alterations, build and deploy. At least I had a recent roadmap this time to get there faster.
* Altering source code before building the executable could have adverse consequences in terms of security and stability. It is risky.
Give a few Sats