Configurations can quietly drift away from working over time, illustrated
At this point, we've been running various versions of Ubuntu LTS
for over ten years. While we reinstall individual systems when we
move from LTS version to LTS version, we almost never rebuild our
local customizations from scratch unless we're forced to; instead
we carry forward the customizations from the last LTS version, only
changing what seems to need it. This is true both for the configuration
of our systems and also for the configuration of things we build
on top of Ubuntu, such as our user-run web servers. However, one of the hazards of carrying
forward configurations for long enough is that they can silently
drift away from actually working or making sense. For example, you
can set (or try to set) Linux
sysctls that don't exist any more
and often nothing will complain loudly enough for you to notice.
Today, I had an interesting illustration of how far this can go
without anything obvious breaking or anyone saying anything.
For our user-run web servers, we supply a set of configurations for Apache, PHP, and MySQL that works out of the box, so users with ordinary needs don't have to muck around with that stuff themselves. Although some people customize their setups (or run web servers other than Apache), most people just use the defaults. In order to make Ubuntu version to Ubuntu version upgrades relatively transparent, most of this configuration is central and maintained by us, instead of being copied to each user's Apache configuration area and so on. This has basically worked over all of the years and all of the Ubuntu LTS versions; generally the only version to version change people have had to do in their user-run web server is to run a magic MySQL database update process. Everything else is handled by us changing the our central configurations.
(I'm quite thankful that both Apache and MySQL have 'include' directives in their configuration file formats. You may also detect that we know very little about operating MySQL.)
One of the things that we customize for user-run web server is the
MySQL settings in PHP, because the stock settings are set up to try
to talk to the system MySQL and we don't run a system MySQL (especially
not one that people can interact with). We do this with a custom
php.ini, and that
php.ini is configured in the Apache configuration
in a little
.conf snippet. Here is the current one, faithfully
carried forward from no more recently than 2009 and currently running
on our Ubuntu 16.04 web server since the fall of 2016 or so:
<IfModule mod_php5.c> PHPIniDir conf/php.ini </IfModule>
Perhaps you can see the problem.
Ubuntu 16.04 doesn't ship with PHP 5 any more; it only ships with
PHP 7. That makes the
IfModule directive here false, which means
that PHP is using its standard system Apache
php.ini. For that
matter, I'm not certain this directive was actually working for
Ubuntu 14.04's PHP 5 either.
This means that for at least the past two years or so, people have been operating their user-run web servers without our PHP customizations that are supposed to let their PHP code automatically talk to their MySQL instances. I'm not sure that no one noticed anything but at the very least no one said anything to us about the situation, and I know that plenty of people have user-run web servers with database-driven stuff installed, such as WordPress. Apparently everyone who needed to was able to set various parameters so that they could talk to their MySQL anyway.
(This is probably not surprising, since 'configure your database settings' is likely a standard part of the install process for a lot of software. It does seem to be part of WordPress's setup, for example.)
On the one hand, that this slipped past us is a bit awkward (although understandable; it's not as if this makes PHP not load at all). On the other hand, it doesn't seem to have done any real harm and it means that we can apparently discard our entire php.ini customization scheme and make our lives simpler, since clearly it's not actually necessary in practice.
(I stumbled over this in the process of preparing our user-run webserver system for an upgrade to 18.04. How I noticed it actually involve another bit of quiet configuration drift, although that's story for another entry.)