Server updates- A Good Thing™

So I heard there were some updates for my web server OS, so I updated the updates so I could update. Yikes what a pleasure- but this would probably be easier if I did it more than once a year or so. Or not.

I decided to document a bit about what I needed to do to go from Fedora 25 to Fedora 34, with a few side trips into Apache (HTTP) issues around Fedora 33.

Where it began: WordPress wants a new PHP

What tweaked me onto the idea that maybe it would be a good time to upgrade was that WordPress started complaining about the PHP it was running on. This is part of a new ‘site health’ feature in WP that shows up on the site admin dashboard as of one of the more recent versions of my blog management software

Your site is running an insecure version of PHP (7.1.23), which should be updated.

So this sounds like something I should fix soonish. And from past experience I’ve come to realize that it is best to upgrade the whole OS, not to upgrade single packages.

Upgrading Fedora with DNF

I quickly realized that my operating system, an open source distribution of Linux called ‘Fedora’ from Red Hat, was woefully out of date. I was running Fedora release 25, and the current release was Fedora 34. This is sadly a fairly normal state of affairs for me- my blog gets neglected.

But thankfully Fedora 25 is at least ‘advanced’ enough to support the DNF (‘Dandified YUM’) package manager which was released as part of Fedora 22. This allows ‘easier’ OS updates i.e.: DNF can be used even when the kernel needs to be upgraded. I found this Fedora project quick doc that gives some clear instructions for how to proceed. This is an awesome guide, and I strongly recommend referring to it.

A key part of the above instructions that I chose to pay particular attention to:

System upgrade is only officially supported and tested over 2 releases at most (e.g. from 32 to 34). If you need to upgrade over more releases, it is recommended to do it in several smaller steps (read more).

That means I needed to perform five upgrades to go from Fedora 25 to 34. And again referring to the above Fedora doc, the rough set of steps looks like this:

1. dnf upgrade —refresh 
2. shutdown -r now
3. dnf system-upgrade download --allowerasing —releasever=<nextRelease> # generally about 2 GB of downloads per release
4. (solve any errors)
5. dnf system-upgrade reboot # note that this takes about 20 minutes in my experience
6. check that everything is working and ‘expected’ release is installed; then repeat

This got me through the process pretty painlessly right up until I hit Fedora 33

What happened at Release 33

Step #6 above is to ‘check that everything is working’. This was, for my purposes, a quick sanity check. That is: after the server restart, I checked all the basic services (including httpd) were up, and tried to navigate to my website.

Unfortunately, as of the upgrade to Release 33, Apache services (httpd) did not start up. Figuring this out took me the better part of three hours, and what was failing was not at all what I expected. I’ll cut to the solution for my woes:

Apache V2.4.33 (approximately) changed how the SSL configuration properties need to be structured.

• the only errors produced by the httpd startup looked something like this:

 httpd.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor pre>
    Drop-In: /usr/lib/systemd/system/httpd.service.d
             ??php-fpm.conf
     Active: failed (Result: exit-code) since Sun 2021-05-02 12:05:23 PDT; 1min>
       Docs: man:httpd.service(8)
    Process: 102224 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exite>
   Main PID: 102224 (code=exited, status=1/FAILURE)
     Status: "Reading configuration..."

• Initially, I thought something was wrong with the php-fpm configuration; this was enforced by the fact that mod_php was removed in Fedora 33- but as I ultimately determined, I had already migrated to php-fpm and wasn’t using mod_php at all, so that wasn’t a problem
• instead, the ‘clue’ in the above was the ‘FAILURE- Status: Reading configuration…’
  • the reference to php-fpm.conf was a complete red herring
• Disabling (removing/renaming) the /etc/httpd/conf.d/ssl.conf file was how I worked around this issue.

I found that ssl.conf was the issue somewhat by chance after eliminating almost every other possibility i.e.: going through /etc/httpd/conf.d and disabling one configuration file at a time. Then I was able to find a Stack Overflow conversation that discussed the issue and how other people resolved it.

Back up and running…

My blog site (this thing you are reading) is back and running after spending the better part of a day on the upgrade effort. WordPress is no longer complaining about PHP being out of date.

Google PageSpeed Insights is happier with the performance of my site as well: up from a mobile rank of about 35 to around 60. And the desktop rank is over 70.

• 

• 

I’m still pretty frustrated that the Apache errors were so un-helpful. And even the apachectl configuration check option didn’t find any problems. I’m also concerned as I believe this effectively disables SSL; not an issue right this instant, but I intend to enable https (which requires SSL) soon. I guess that will be a problem to figure out some other day.

I’m also considering enabling DNF ‘automatic updates’. I’m still pondering and reading about that: this article on the Fedora Project site gives some guidance including pros and cons.