Major changes to how PHP requests are handled in Fedora 33

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

I run the 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?” updated

Since about lat 2016, my website had problems with uptime:  It was mostly down.  In the spring of 2017, it was finally up and I did a bit of restoration work.  And then … it was down again for a few months.  (And, due to the circumstances of this downtime, my restoration work was lost.)

Finally, I transferred my website to an existing home server, and it is now living out of a computer which I believe may be as old as 2003, living under CentOS 7.x series, in my bedroom.  Having fixed a faulty telephone line (squirrels!) the line is now “not noisy” and the internet is back properly.

Main work has been:

How to put XFCE on CentOS 6

This post is following my having replaced the gnome desktop from my centos-6 home server with XFCE, due to:

– the machine is probably over 11 years old and only has 256megs of memory
– the machine is not really likely to be easily upgraded, nor replaced
– the change is worth it anyway given the light load I put on it
– because it was so slow, and even seemed to progressively grind to a halt in a short period of time (a week or less, it seemed)
– questions online about how to replace gnome to XFCE under centos were inconclusive regarding how to make XFCE the default desktop on CentOS.

No, I don’t know how to make them co-exist, I tried a bit and decided after a three or four commands that since I didn’t need Gnome anyway, that replacing it completely with XFCE was the best way to go in my case.


– an installed and working CentOS 6 setup on the “target machine”
– an internet connection
– an operating ssh server on the target machine — including, if you’re controlling things through the internet, appropriate settings to receive the connection through the internet (another topic)
– root priveleges on the target machine

Optional, but likely to be highly useful (as it was for me given the “cart-before the horse” approach I used):

– a second computer, “the head”, with an ssh client, able to connect to the target machine via ssh either locally on the same network, or through the internet.

This process can be dangerous, will probably require at least one reboot, and ideally should require having physical access to the machine in case of requiring a hard power-down and repowering of the machine. All critical processes should become less critical (ie. user announcement for downtime, transfer to another server, etc.) and a backup should be performed beforhand.

I am presuming that on the target machine, root login has been disabled and that you will be logging in via “mere mortal” accounts and then elevating to root. Should you be using sudo on the target machine, the account into which you will be logging should have appropriate sudo priveleges, and you should adjust the instructions accordingly (that much I won’t do for you, I don’t like sudo; “Don’t be afraid of root. Respect it, but don’t be afraid” as my brother says.) I am also presuming that you are controlling the target machine using the head.

– using the head, ssh into the target computer — make sure that you are logged into an account on the head which also exists on the target. If you are on the same network, on the target machine itself, determine the IP address using “ifconfig” at the command line, and look for the number with a “192.168.***.***” format in the second grouping after the “inet addr” tag.
– Elevate to root (“su” )
– Install the Fedora epel repository on the target computer.
– visit
– enter the following if you are running Red Hat Enterprise Linux 6 / CentOS 6 / Scientific Linux 6:
“rpm -Uvh”
– enter the following if you are running Red Hat Enterprise Linux 5 / CentOS 5 / Scientific Linux 5:
“rpm -Uvh”
– Uninstall the gnome desktop.
– “yum remove groupremove gnome-desktop”
– Install the xfce desktop.
– “yum –enablerepo=epel-testing groupinstall xfce-desktop”
– add a line about changing the desktop type
– “nano /etc/sysconfig/desktop”
– add the following lines:

– Reboot the target machine with “reboot now”. The head will lose its connection to the target machine. The machine should now reboot and the xfce desktop should appear on the target machine.


In my case, I had installed the XFCE desktop environment first, and some dependencies were removed when I uninstalled the gnome environment; I figured this out after a reboot and the screen came up blank after a reboot. I therefore ssh’ed using the head into the target and reinstalled the xfce desktop as above, which installed the necessary missing dependencies. I also installed the evince reader (“yum install evince”) which has nautilus as a dependency (and as such installs it, although so far the only real difference between it and Thunar is that the latter doesn’t support dual panes.) Both seem to work nicely with XFCE because it uses the same libraries as Gnome.

19 months, 16 *successful* installs

I just did a tally of all the installs I’ve done on my personal systems since the end of June, 2008, when I bought a new-to-me desktop and took advantage of the opportunity to upgrade from the CentOS 4.x series (to the CentOS 5.x series. 🙂 ). And I was a bit blown over; unfortunately, not surprised, but blown over nonetheless.

Over 5 systems, I’ve done 16 successful installs; then there were a few dud installs that had to be restarted right away, although a couple of said duds were counted because the installs were actually useful for a few weeks, including one not counted as a successful install during the most recent cycle despite the fact that it was a successful install; unfortunately, the boot sector on the drive died (it was to be expected, back last June or July, Palimptest identified the drive as having a fatal error on it, and the drive was declared as having about 6 months to live, and whaddya know!) so I had to get another “new” drive, which I happened to have handy, and do another install.

To be fair, there has been one factory sealed new system thrown in there (what fun to wipe the Windows install, which curiously, apparently irreparably froze up after all the updates were done, the whole thing to be able to say “yeah, but Windows worked on it!” — which it didn’t!), another system that just about hasn’t been used since and after a few months has now been removed from the upgrade cycle, another system that finally died or at least on whose ghost I have given up, and a finally a replacement system for said “death in the family”.

One of the reasons why I always say “I’d love to go back to CentOS if it weren’t so hopelessly obsolete” is that it’s stable and has a long life to it (something like typically 7 years) — Fedora *has* been good to me since I started using it from version 9, and hence with CentOS you don’t have to upgrade every six months like with Fedora — oops, that’s every 12 months or so — given the support cycle (wink wink). 🙂

Problem is that when you have several systems, you’re still doing installs every 6 months or so if the systems aren’t in sync with each other; further one of the consequences of using second hand or third hand computers, buying new computers, upgrading parts and hard drives, and even trying out another distro at least once is that your systems are hardly every likely to be in sync for the whole 13 months or so lifespan of a new-version-released-every-6-months distro like Fedora. And of course, that someone who would like to avoid having to do new installs every 6 months is going to upgrade a system that is out of sync to bring it in line with the others in the hopes that “this will be the cycle when I get to enjoy the whole lifespan and not have to upgrade 6 months from now”.

Hence the ideal of trying to avoid the “install every 6 month habit” by syncing the installs with each other when a single new install is done in order to hopefully avoid having to reinstall in 6 months is fallacious when you have at least two systems — in fact, you end up doing the opposite since you not only are installing (or re-installing) at least once every six months for one legitimate reason or another, but you end up doing multiple installs, many of which are unnecessary in and of themselves, every 6 months, just to keep everything in sync. And as such, the “install every 6 month habit”.

Of course, I have often been enjoying the process despite myself; in fact, I’ve managed to put together an ever-increasingly long list of steps to take from start to finish when installing a system (which I’ll be presenting to one of the local LUGs in a few weeks.) Fortunately, my computers are purely home desktops or hobby servers without any critical processes on them, and my brother at least humours my habit by doing those little bits that are still beyond my ever-increasing sysadmin skill set (which of course is growing with each install cycle). And in the process I’m gaining a practical appreciation for what I’ve known all along since I started using Linux in 2006 and started using CentOS: The likes of Fedora and Ubuntu may be great, but you have to re-install every 6 months! Who wants to do that?!?!” (Apparently, I do. 🙂 )

It must be interesting having multiple production servers with multiple versions of a given distro, let alone more than one distro (ie. a mix of CentOS, Debian, SuSE, and for some good fun, Slackware). Good thing that usually having “the latest and greatest” usually isn’t as particularly important on a server so that it can actually have a useful life. Must be hard for the likes of Red Hat, for instance, when it must add new drivers all the time, but in order to keep from breaking compatibility and adding “bad change” into the distro other things don’t happen (things like the HPLIP version that is one incremental subversion or whatever it 0.x increments are called behind the minimum requirements for my 2.5 year old printer, and which has since gone through several such incremental upgrades and at least a whole version upgrade since.)

Oooooops, I was wrong … (so what else is new?)

In a previous post, “I may just have that reason to get rid of Ubuntu” I stated that the thing that killed Ubuntu for me was the difference in how OO.o on Ubuntu 8.04 and Fedora 9 deal with the “notes” function in a document. The versions of OO.o in question were — according to — 2.4.0 for Ubuntu 8.04 and 2.4.0 for Fedora 9. As of today’s date my F9 notebook has updated itself to 2.4.2, so to be fair I imagine that in the past year Hardy Heron has had some updates as well.

Today I stumble across this little gem from the website:

Improved Notes Feature in Writer

“In the past; notes in were just displayed as small yellow rectangles within the text. This was not very intuitive and user friendly. With version 3.0, got an advanced notes features which displays notes on the side of the document. This makes notes a lot easier to read. In addition, notes from different users are displayed in different colours together with the editing date and time.”


I went off on a holy rant, wondering why the heck Ubuntu has changed a few things more that it arguably needed to, when in fact … well, it apparently hadn’t: The annoying yellow dot was a function of OO.o to begin with. At that time. If anyone was changing things, it was Fedora backporting this function some time last fall, assuming that it wasn’t OO.o doing it, or adding a preview into the version that Fedora grabbed and included in F9 — in keeping with Fedora’s usual policy of not using custom patches not necessary to Fedora integration or backporting updates, instead opting for rapid changes, new releases, and submitting bug and improvement patches upstream instead.

Which is perhaps not saying much since at release time, both distros were using 2.4.0; rather, it only raises the question of why things are different between two nominally identical pieces of software, and perhaps lifts blame away from Ubuntu.

Oh well, I still don’t like Ubuntu. 🙂

In the meantime … I wonder how this is explained given that both distros apparently had the same version of OO.o at release time. I wonder if the feature was backported in Fedora. Or if it was backported by OO.o and Fedora simply passed on the change. Or … ?

And in the meantime as well, I wonder about the notes function in previous versions of the 2.x series of OO.o acting in “the new way” at least back to 2006 — again in the same post, second to last paragraph:

“The appearance of the notes in the margin is not a recent occurrence in OO.o, at least in the 2.0 series: back in August 2006 under CentOS 4.4” OK, this is still the Red Hat family” I received a document with the notes visible in the margin (being a work contract I declined the document and asked that they resend the proper version, please.) I was using the standard OO.o 2.whatever downloaded and installed directly from (since the CentOS 4 series originally came wih OO.o 1.5.something series; I’d been using the OO.o 2.0 series for close to a year at that point under Windows before I’d made the switch to linux.)”

Hmmm … OO.o differences, Fedora, and Ubuntu

In my post I may just have that reason to get rid of Ubuntu I whined about minor differences between “stock” appearances and functions and those I used straight off the OO.o website as well as what ships with Fedora.

This blog (here’s my archive) explains a bit why: It says “Many Linux distributions ship ooo-build. … Fedora ships a modified, but Fedora does not use ooo-build.” Which means that in keeping with Fedora’s usual policy, it ships upstream versions of software with only reasonably required modifications to make it work under Fedora. When I was using CentOS, I was using the vanilla version directly from OO.o.

That explains a few things. It doesn’t necessarily justify my whining — nor all the changes Ubuntu or other distros (or even Fedora) make, but … Why mess with a good thing? 🙂

Vino-server appears to have struck again!

Back a couple of years ago, my CentOS-4.6 system was slowing down to near unuseability. Using the Top command at a command line, there seemed to be this service listed at the top called Vino taking up a good amount of resources. My brother looked at it, researched it, and set up an hourly cron job to kill the vino-server every hour, and the problem was solved.

Back last fall, I was getting this notion, while running Ubuntu 8.04 LTS, that the system had slowed down a bit much the same way that Windows 2000 is a little slower than Win98. When I switched back to Fedora 10, I noticed the same thing. However, I never noticed a return of the infamous vino-server.

Then last week I figure it’s time to get more memory and decided to pull out my 512meg memory stick and go with it, for comparative purposes to make sure I get the right thing, to the store to get a twin for it, or a 1gig stick, in the hopes that either a gig or a 1.5 gigs would improve performance. I’m cheap and was pleased to pick up what appeared to be a nearly-new, opened box of 1gig of SDR2 667mhz for $5.

Well, I guess those of you who actually know what to do around an open computer are chuckling by now and know that my new purchase doesn’t fit in my DDR slots, the little slot in the DDR2 stick being about a millimetre or two over from the same slot in DDR memory sticks.

In the meantime I of course put my original memory stick back and notice over the past week that my computer is becoming increasingly bogged down to unuseability. During the week I found a website that seemed to make my computer freeze, but others didn’t. Today I mention the general slowness that the computer has bogged down to to my brother who looks at things and he has a flash of memory. A quick hourly cron job is set up to kill vino-server, and my computer works fine again.

Uggghh … I need a bar of soap

I think I’m going to be sick. 🙁

I never cared for Debian and derivatives because Debian never seems organized enough to get a new release out. In all honesty I’ve never tried Debian. I hate Ubuntu, mostly because I’m very suspicious of anything with great marketing hype and hordes of fanboys to boot. (So much for my initial suspicion of the Stargate movie in 1994 and all of its over-hyping; I have long since wished I had overcome this and gone to see it in the theatres, and I do love SG1 in reruns. 🙂 )

Last week my brother and I were jumping hoops again and again to get my printer working under Centos 5.2. Last January we’d gone to a lot of trouble to get it to work under Centos 4.6 (I finally upgraded to the 5.0 series about a month ago.) No matter how many hoops we’d jump through and resolve there were still more, or another set would surface. Realize that this is a relatively new printer that must have come out at least last fall if not earlier, my brother received it as part of a “throw it in with the new laptop he bought” kind of deal. Red Hat therefore had gone through at least one update, if not two (at least 5.2 if not also 5.1) to add the appropriate drivers or move to the next HPLIP version that would support the printer. To give you an idea, Centos 5.2 comes with HPLIP 1.6.something, my printer needs at least 1.7.something, and the current version is 2.8.something.

Seems to me that commodity printers should be supported, it’s not as though a corporate situation doesn’t use printers. Though they would probably say that my line of printers is too commodity for an enterprise to be interested in, they probably want high-capacity, high-quality printers, not an inkjet meant for the consumer market.

I knew that the printer worked under ubuntu since I tried a live CD from them and it worked without saying boo. My brother was “willing” to continue trying to get it to work but was pushing hard to switch. “You can always switch back to Centos you know.”

The printer was a killer. So is getting wireless on my laptop, using a several years old (about 4 years old) pcmcia wireless card; under CentOS 4.6 I had a kernel under which it worked but any time there was a kernel upgrade I would have to switch back if I wanted to use the wireless. We hadn’t done anything yet about the wireless but had a plan.

I still haven’t gotten the wireless to work under Ubuntu but to be fair I haven’t tried yet at all.

My first reaction was that Ubuntu was the Playskool version of linux.

I also HATE the fact that the default user under Ubuntu is a defacto root user — first thing I did was get rid of the annoying sudo requirement by assigning a password to root, but it’s not of much value because so far I haven’t come across anything in Ubuntu that really requires root the way it would under ANY other linux distribution, other than the fact that it constantly asks for passwords to do anything. Also annoying is that I can’t log root into a gui to do things that way (including to REMOVE the default user from the admin ring.)

This may be the undoing of Ubuntu along the lines of the way that Windows is plagued with problems because most of the time the default user has admin rights and can install and run just about anything unless the Admin user shuts it down. The only upside is that it always asks for your password, but I expect that most windows converts would find this annoying and just mindlessly enter their password just to get on with things.

Once I got over the shock, the problem now is that the user experience, other than the administration to which I’m accustomed mostly doing under a command line instead of gui, is identical to Centos. (The main ubuntu distro desktop is gnome, as is the case for Centos.) Admittedly, the Synaptic gui package manager along with the extensive Ubuntu repo vs. the Centos repos is as good as they say, and worth the switch. And 8.04.1 is an LTS version, meaning that it’s supported for 3 years instead of having to go through the reformat treadmill every 6 months (OK, Fedora supports versions for a month after the release of the second release following, meaning about 12-13 months.)

I hope that RHEL (and hence Centos) shapes up and realizes that some people like using as a desktop, and that making it at least vaguely usable without pulling teeth and hair is as important as making it stable.

I have to go now and wash my mouth out with soap.

Trying to make a new server

So last December I find this old clunker in the garbage pile at work: base memory, CD rom, and power source. Oh, and it weighs a ton.

I decided that I wanted a server to act as my internet gateway and was too cheap to buy a router; I bought an 8 gig HD used for $10 and burned the appropriate disks. Realize that my wonderful PIII 555 is slowing down a bit, so in order to get the most out of it I decide that it should no longer have to deal with internet sniphing, attacks, pinging and so on.

The install takes just about all night. It succeeds, though, and I got to see what the “new” (now of course old) gnome desktop looks like, a glimpse of which I’d seen a couple of years before with FC5. (Shudder. Bad experience.)

And what happens?

My brother says that the HD I bought was a dud. Point final.