Major changes to how PHP requests are handled in Fedora 33

(This post has an update 20210203 at the bottom.)

I run the www.malak.ca website and this blog on an old reclaimed computer using Fedora Linux. I used to use CentOS because of its long term stability, and in fact I still have a computer running CentOS running at full capacity as a computational node for the World Community Grid.

I have used Fedora on my desktops since 2008, and on my website server since at least 2018.

I have found CentOS very stable but, through my brother, somewhat limiting as each given version ages. My brother provides invaluable technical support and often does the heavy lifting on my servers and computers when it comes to, well, technical support and setup, for which I am very grateful. He has humoured me over the years in my use of CentOS, but has been frustrated with CentOS for years given its upstream source’s conservative development cycle and the difficulty in maintaining such systems over time.

In the meantime, over the years while using Fedora, I typically use a version for roughly its full lifecycle of 12 to 13 months, and I normally skip a version in the process. Previous to somewhat recent experiences, I would perform a full new install every year from a downloaded image; I was acting on advice from the Fedora website, increasingly old and out of date each time I performed a reinstall, to not use the dnf upgrade function on the grounds that it wasn’t ready yet. This further gave me reason for the occasional use of CentOS and its long term stability on some computers, which I might want to not want to bother reformatting yearly, let alone reinstall software. However, while I was performing another fresh install from Fedora 27 to Fedora 29 in the fall of 2018, I observed a command line upgrade of a Fedora system, and was intrigued. In the fall of 2019, when upgrading from Fedora 29 to Fedora 31, I used the command line upgrade path instead. (Here’s my archive.) This resolved, at least in my mind, my longtime concerns about the short lifespan of Fedora.

Unfortunately, this proved to be a matter of famous last words, since it was merely a convenience for upgrading, something that could be easily done on a weekday evening, instead of setting aside a Saturday afternoon and a (wholly pleasant) visit with my brother.

My most recent upgrade cycle of my server, from Fedora 31 to Fedora 33, was in and of itself as easy as it was on my laptop, desktop, and another box earlier this year. However, it proved to be effectively fatal for my website, since the web server was showing error 503 for PHP requests on the blog. Apparently, a PHP handling module, mod_php, used on my website, was deprecated in favour of php-fpm (here’s my archive). A mixed technical and somewhat editorialized discussion on this is on my brother’s blog. (Here’s my archive.)

For me, this isn’t so much an opportunity to complain; as I said, my brother did the real work in performing another iteration of setting up my website in April, 2020, only to do it once more in November, 2020, for which I’m grateful, under a fresh, baremetal install (which I performed.) Instead, the second comment to come to mind — initially, privately, and tongue-in-cheek! — after my gratitude that he would do the job yet again, was that my brother at least got to hone his skills on “the new method”.

After that, a few other things came to mind. As such, risking being a back-seat gratuitous commentator on the process:

  • It occurs to me that Fedora, while an excellent desktop operating system, arguably has risks associated with it as a medium-term and long-term server, given its mission to showcase and test new technologies as they are introduced while “old” technologies are deprecated;
    • And, since CentOS (and RHEL) grow old long enough before their 10 year EOL, but Fedora’s approximately 13 month lifespan is too short, how long is ideal?
  • The actual process itself of upgrading Fedora versions remains smooth, polished, and easy;
  • Could the upgrade process itself have included:
    • At least a warning that certain major changes were literally about to occur or were occurring?
    • An opt-out option for some changes?
    • Or involve as possible actually upgrading settings and/or other setups such that a neutral net effect on existing functions is effected, ie. change things properly, not just literally changing things without regard to any possible detriment to functions?
    • Or, make changes, but in separate, neutered files, and a notification that some potential conflicting changes have been made, requiring attention?
  • With regards to general version upgrading of my server, I should do some research into the new technologies to be installed before upgrading, so as to prepare for any major changes, just as any sysadmin should when upgrading versions to another of any long-term distribution such as CentOS, RHEL, Debian, Ubuntu LTS versions, or any other such system.

20210203 Update: It would seem that another victim of the change toward php-fpm was an inability to use the WordPress upgrade tool when it was time to change to v.5.6. It seems that using some file ownership settings on my machine, which facilitated my administration of the website on a larger scale than just WordPress, was at issue, and how php-fpm handles files and the required permissions, vs. the way mpm-itk and php-cgi would handle similar tasks.

And, at the same time, it seems to me that an additional question is raised, following my musing of “And, since CentOS (and RHEL) grow old long enough before their 10 year EOL, but Fedora’s approximately 13 month lifespan is too short, how long is ideal?”: The literal answer may well lie in “well that depends on individual packages and how they evolve over time, especially regarding the “real world” and other pressures which may shape the project’s evolution”, meaning that things may change more swiftly than Fedora’s 13 month lifespan, and others may outlive RHEL / CentOS’ (at least old) lifespan of ten years.

Which leads to my asking: “How to deal with change management?” and “How to choose a distro, and deal with change in a selected platform which has gone in a different direction from decisions leading to its original choice?”

Leave a Reply

Your email address will not be published.