| SYSTEM INFORMATION | |
|---|---|
| OS type and version | AlmaLinux 9 |
| Virtualmin version | 7.30.8 |
I noticed that PHP 8.0 is the version that is installed with Virtualmin. Should I uninstall this version and replace it with PHP 8.4 and PHP 8.3 or should the base PHP 8.0 be left alone?
I may be wrong here but Virtualmin doesnāt make that decision it is your OS (Iām not a great user of PHP (just no call for it - and only have one client using it) and on Debian 12.
No donāt remove, just use the docs to install extra versions then if needed you can have different versions on different virtual servers.
That is your OS supported version. VM doesnāt make this choice.
This is pretty much your choice. While all PHP8.x should be backwards compatible, there is always some risk, even if very small, that something could break. If you are reselling domains you might want to talk to the individuals using PHP8 to see if they would have a problem with it.
There is a difference between managing a server for your self and one you manage for the benefit of others.
Which is weird. I keep seeing throughout posts āthat is your OS supported versionāā¦ and my question is, what makes that the decision and can I force it to be 8.4?
Yesterday, I tried to run a PHP script (OSTicket) and when I called for it to run via āpipe to a programā, I kept getting an error complaining that the PHP version was 8.0 and not 8.4.
I followed another guide to install additional PHP versions and had made the server choose āthe most recent PHPā but for some reason, when PEAR runs it picks up the 8.0 version instead. Iām contemplating asking about this maybe in another question, because I have no idea how to rationalize āwell it is what it isā in this case. (I also fear I might be asking TOO many questions, because Iām obviously missing something.)
Iām fortunate that Iām running the server for myself and managing the domains. I would always prefer the most recent edition, but for some reason, most scripts always want to use older versions of PHP. (For example, one such installation requires the use of 8.3 and caps at that edition to the point that it wonāt run in 8.4 unless I specifically go in and mess with the code that checks the edition.)
Your OS vets a version of a program and that will remain the version for the life of the OS. That is the āsupported versionā. It ensures operability with everything else. Any security fixes will be applied to that version. For the most part, server owners HATE CHANGE because of the headaches that result when something breaks.
This differs from desktop machines. As an example, if you install Kicad on Debian 12 (the current release) you get Kicad 6 instead of the latest version, Kicad 9 because V6 was the stable version when Debian 12 launched. Debian isnāt going to risk āautomaticallyā breaking or changing your version of Kicad. They offer backports if you want to do it yourself. On a desktop, this can be good. On a server, this can be bad.
This may well indeed be a different question. I āthinkā the cli version of PHP always picks up the default OS version.
#Should show PHP 8.0
php -v
#Backup the current PHP 8.0 binary
sudo mv /usr/bin/php /usr/bin/php80-backup
#Create a symlink to PHP 8.4
sudo ln -s /usr/bin/php84 /usr/bin/php
#Should now show PHP 8.4
php -v
Rather than thisā¦ is there a way to call up a specific version of PHP to execute the script?
For example, Iām running a pipe to program email aliasā¦ if I wanted to run a specific to the domain version of PHP, is there a way I can that version instead?
Cāest la vie - or the joys of running your own server - but donāt forget it is yours you have control of just about everything (with the exception of what the supplier did to the bare metal) - if you chose to install PHP v5 (ok - but you are going to be responsible to maintain it - if you stick to whatever is supplied by the OS then the OS maintainers will do that for you.
Running a server can be a full time job
Run php8.4 for 8.4 etc
We are out of my area here. But, you can modify the script with the php version you want? I think the default would be the OS installed from the context above .
root@main:~# locate bin/php
/usr/bin/php
Iām thinking one of these would work in place of /usr/bin/php?
/usr/bin/php8.2
/usr/bin/php8.3
/usr/bin/php8.4
full output
root@main:~# locate bin/php
/usr/bin/php
/usr/bin/php-cgi
/usr/bin/php-cgi.default
/usr/bin/php-cgi8.2
/usr/bin/php-cgi8.3
/usr/bin/php-cgi8.4
/usr/bin/php.default
/usr/bin/php8.2
/usr/bin/php8.3
/usr/bin/php8.4
/usr/bin/phpdbg
/usr/bin/phpdbg8.3
/usr/bin/phpdbg8.4
/usr/lib/cgi-bin/php
/usr/lib/cgi-bin/php.default
/usr/lib/cgi-bin/php8.2
/usr/lib/cgi-bin/php8.3
/usr/lib/cgi-bin/php8.4
/usr/sbin/php-fpm8.2
/usr/sbin/php-fpm8.3
/usr/sbin/php-fpm8.4
/usr/sbin/phpdismod
/usr/sbin/phpenmod
/usr/sbin/phpquery
Again, outside my area, but can a specific user set an environmental variable for the desired php version?
I was LITERALLY about to report back after I tried this. (I had to reinstall the OS as a whole, which I really have to stop doingā¦)
I just realized there was a shebang line that reads
#!/usr/bin/php
and I have a feeling that if I change that line to one of the ones you listed, that it would force the script to run at that version.
Iāll report back and flag this as solved if it works out.
I always leave the system default PHP version installed, even if I wonāt be using it. Itās harmless, and means the system is closer to default. When it comes time to restore after a disaster, having a system very similar to a stock OS install is a good thing.
You should understand how paths in third-party packages work (i.e. if you want to run something with PHP 8.3, you need to use php8.3 or php83 to run it, and you may want to add something to your PATHā¦on EL for comfort, thatād be a path in /opt/remi/...), but otherwise it doesnāt make any difference.
I would discourage having a bunch of third-party PHP versions, though, as thatās just more things you need to keep up with.
Youāre showing paths found on Ubuntu or Debian. It will be different on any EL with packages installed via Remi repos.
On EL with packages installed from Remi, it will be php84, not php8.4.
But, also, we have documentation for this. Just follow the docs, and your system will work the way everyone elseās does and when you have questions, weāll be able to answer without a lot of back and forth and confusion over why your system looks so different from everyone else. The more things about your system that meet expectations, the more likely things are to work first time, without a lot of hassle, and when things do go wrong, we can spot the problem much more quickly.
Going off-road is a thing you do for fun as a hobby. For production servers, follow the paved path.
recent EL systems have something called AppStreams, where RedHat gives you a choice of your base PHP ā¦ see what is shown to you with:
yum module list php
and perhaps I am guessing too much here ā is your OSTicket issue from it, or you, running a script at the cmd line? As others have pointed out above, there are several solutions, as well as the MODULE option I mention that adjusts the base/default php version. Note the MODULE method adjusts the default php for the entire server, not just one website or one user.
good luck.
Doing it the way the OS vendor provides is preferable to third-party options, if you must replace the default one (rather than using the scripts provided by e.g. Remi), however, you should be aware AppStreams are not supported through the life of the OS, like the packages provided with the OS are. An AppStreams package will reach EOL whenever upstream (the one at php.net) does.
AppStreams is not a pass for treating non-default PHP versions as part of the OS, in terms of support lifecycle. The one that comes with your OS is still preferable and recommended unless you must use a different version.
Can confirm it was the shebang line (and one additional problem found, nested chmod problems) that caused me to have this headache filled nightmare. New topic being made.
to clarify a bit on RedHat AppStreams ā RedHat says in part at Red Hat Enterprise Linux Application Streams Life Cycle | Red Hat Customer Portal for RHEL 10
RHEL 10 Full Life Application Streams Release Life Cycle
php 8.3 Release Date: May 2025
but since you are running Alma 9, sadly the v9 table later on that page does say php 8.0 is the only Full Life (supported) version. My point is, some versions in the AppStream family do have full support over the life of the O/S from the vendor themselves.
in the case of php 8.3 on v9, another table says that will be supported thru May 2029 ā note RHEL 9 itself (according to google) is supported thru May 2032.