I am building a new Virtualmin server using Debian 11 in Azure. My question is what is the oldest version of PHP that I an install on that server without creating issues when using the latest version of Virtualmin.
I have an old Debian 8 server in AWS that I need to ditch, costing me too much for one website. That site however using PHP 5.6.40 and cannot be upgraded due to the software running on it.
So basically, can I have Debian 11, running Virtualmin 7 Pro with PHP 5.6.40 & Php 7.4.33, 8.1 & 8.2 ?
I do have a production server using Debian 10 and Virtualmin 6 Pro, can I install PHP 5.6.40 on that without breaking everything ?
packages provide both the NTS and ZTS (Thread Safe) versions
php56-php-, php70-php-, php71-php-, php72-php-, php73-php-, php74-php-, php80-php-, php81-php- and php82-php-* packages are Softwares Collections (multiple versions)
I have repeatedly said that if you must use PHP 5 (you should not), the only way to do it reasonably safely is to run it on CentOS 7, which reaches end of life next year (at which point it will really no longer be safe to run PHP 5).
If you run PHP 5 on any distro other than CentOS 7, you almost certainly are running a PHP package with known security bugs that are unpatched, because as far as I know, no one is maintaining PHP 5 packages for other distros in the sense that they have security patches regularly applied.
That’s the benefit of a long lifecycle distro.
Just because you can do something does not mean you should. Virtualmin doesn’t care, but you certainly should care whether you’re deploying something with known vulnerabilities.
Edit: To be clear, the only reason it is somewhat safe to run it on CentOS 7 (or RHEL 7), is because that’s the default version of PHP in that distro, and it will be maintained by Red Hat until the EOL for the distro. The existence of PHP 5 packages says nothing about whether they are maintained, and “newer” PHP 5 version numbers does not mean more secure than what is in CentOS/RHEL 7. Upstream, the PHP project stopped maintaining PHP 5 quite a while ago…so, any security maintenance that gets done must be done downstream. Nobody other than RHEL has those kind of resources, AFAIK.
To go further, you probably can’t do it yourself, either. I mean, if you go fetch the last PHP 5 tarball from php.net, if you can even find it, and build it yourself, you will be running unmaintained software, likely with known security vulnerabilities. You would have to cherry pick any patches applied by the Red Hat folks to their packages that happened after the EOL of PHP 5 upstream (or go through all the CVEs since then, and patch them yourself). The last version of PHP 5 from upstream was 5.6.40 on January 10th or 2019. That’s over four years of no maintenance on a codebase known for having a spotty security history (though it’s much better now, it was only on the way to being much better in PHP 5).
I want to be really clear that it’s not reasonable or safe to run PHP 5 on a production system at this point in history. The closest you can get is running it on CentOS/RHEL 7, but only for another few months.
We suggest using sury/php and ondrej/php repos in our Multiple PHP Versions page, and this (trusted by many) vendor has been known to backport security patches to older PHP versions.
However, it’s not clear exactly, if it’s still the case for PHP 5.6, because even PHP 7.4 is already EOL.
Surely for peace of mind wouldn’t it be better to get the client owner of the archaic website to upgrade their version of PHP and whatever old software is running on it. or ditch the client - how far back does one need to go?
If the client is important just charge them accordingly for you having to maintain old server in AWS. - How long is AWS going to continue to support it anyway?
A rusty old broken bike is only of use as a museum exhibit.
