PHP 8.1 not detected by Virtualmin despite correct installation (CentOS 7)

SYSTEM INFORMATION
OS type and version CentOS 7
Webmin version 1.973
Virtualmin version 6.08
Related packages Various

Note - I’m unable to upgrade Virtualmin any further on this box due to specific SSL deployment and configuration requirements which fundamentally changed with the following major release of Virtualmin.

It’s a CentOS 7 box using the remi-safe PHP repo for 7.4; I attempted to install 8.1 in a similar manner. I enabled the 8.1 repo to be doubly sure, then issued

yum install php81, installed when prompted, then ran yum install php81-php-{cli,fpm,pdo,gd,mbstring,mysqlnd,opcache,xml,zip}

All installs went OK and I can see the various PHP 8.1 files in /bin and /opt/remi/php81/.

However, virtualmin check-config only sees the 7.4 install:

(The following PHP versions are available : 7.4.33 (/bin/php74-cgi)
The following PHP-FPM versions are available on this system : 7.4.33 (php74-php-fpm)

Furthermore, Webmin > Tools > PHP Configuration only shows /etc/php.ini and isn’t detecting the 8.1 ini in the /opt/remi path.

How best should I manually make 8.1 available to this install? I’d rather not mess with alternative, start symlinking or overriding paths to binaries. This used to work fine with different versions of PHP 7, I switched between them incredibly easily as I upgraded.

as long as you followed docs for repo install it should install ok.
Else you have a bug
https://www.virtualmin.com/documentation/web/multiplephp/

Indeed, I used yum but otherwise the process was identical. Seems like it might be some bug…

only thing you said you used this command first. in docs it doesn’t say to do that first. That may come from a different repo, just a thought.

Sorry I thought I mentioned but I can appreciate now it wasn’t exactly clear; I enabled the remi-safe php81 repo first. :slight_smile: it’s definitely Remi’s version installed, as I have for 7.4 (and prior versions), I’ve used his repos on my CentOS boxes for some time.

Look like you picked up a bug somewhere. I did a clean install of centos 7 and works fine.
Do you see a PHP-FPM 8.1 server? there should be one for 7.4 as well.

I did a module load php81 to forcibly try that with a virtualmin check-config and php -v happily reports 8.1.19 (fpm-fcgi);

PHP 8.1.19 (fpm-fcgi) (built: May 10 2023 13:43:03)
Copyright (c) The PHP Group
Zend Engine v4.1.19, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.19, Copyright (c), by Zend Technologies

I also manually amended the PHP-FPM port for the 8.1 install (to 9081) in /etc/opt/remi/php81/php-fpm.d/www.conf, started and enabled the php81-php-fpm service via systemctl and checked it was loaded correctly.

However only 7.4 is detected by the virtualmin config checker. I have all recommended packages installed per the “Multiple PHP Versions” kb article…

yum list installed | grep php
gd3php.x86_64                        2.3.3-7.el7.remi               @remi-safe
oniguruma5php.x86_64                 6.9.8-1.el7.remi               @remi-safe
php74.x86_64                         7.4-3.el7.remi                 @remi-safe
php74-php-bcmath.x86_64              7.4.33-6.el7.remi              @remi-safe
php74-php-cli.x86_64                 7.4.33-6.el7.remi              @remi-safe
php74-php-common.x86_64              7.4.33-6.el7.remi              @remi-safe
php74-php-dba.x86_64                 7.4.33-6.el7.remi              @remi-safe
php74-php-dbg.x86_64                 7.4.33-6.el7.remi              @remi-safe
php74-php-devel.x86_64               7.4.33-6.el7.remi              @remi-safe
php74-php-embedded.x86_64            7.4.33-6.el7.remi              @remi-safe
php74-php-enchant.x86_64             7.4.33-6.el7.remi              @remi-safe
php74-php-fpm.x86_64                 7.4.33-6.el7.remi              @remi-safe
php74-php-gd.x86_64                  7.4.33-6.el7.remi              @remi-safe
php74-php-intl.x86_64                7.4.33-6.el7.remi              @remi-safe
php74-php-json.x86_64                7.4.33-6.el7.remi              @remi-safe
php74-php-mbstring.x86_64            7.4.33-6.el7.remi              @remi-safe
php74-php-mysqlnd.x86_64             7.4.33-6.el7.remi              @remi-safe
php74-php-pdo.x86_64                 7.4.33-6.el7.remi              @remi-safe
php74-php-pear.noarch                1:1.10.13-1.el7.remi           @remi-safe
php74-php-pecl-igbinary.x86_64       3.2.14-1.el7.remi              @remi-safe
php74-php-pecl-imagick.x86_64        3.4.4-17.el7.remi              @remi-safe
php74-php-pecl-ip2location.x86_64    8.1.2-1.el7.remi               @remi-safe
php74-php-pecl-mcrypt.x86_64         1.0.6-1.el7.remi               @remi-safe
php74-php-pecl-memcached.x86_64      3.2.0-1.el7.remi               @remi-safe
php74-php-pecl-msgpack.x86_64        2.1.2-1.el7.remi               @remi-safe
php74-php-pecl-mysql.x86_64          1.0.0-0.23.20190415.d7643af.el7.remi
php74-php-pecl-recode.x86_64         1.0.0~DEV.20190723-6.el7.remi  @remi-safe
php74-php-pecl-redis5.x86_64         5.3.7-1.el7.remi               @remi-safe
php74-php-pecl-zip.x86_64            1.21.1-1.el7.remi              @remi-safe
php74-php-process.x86_64             7.4.33-6.el7.remi              @remi-safe
php74-php-soap.x86_64                7.4.33-6.el7.remi              @remi-safe
php74-php-xml.x86_64                 7.4.33-6.el7.remi              @remi-safe
php74-runtime.x86_64                 7.4-3.el7.remi                 @remi-safe
php81.x86_64                         8.1-4.el7.remi                 @remi-safe
php81-php-cli.x86_64                 8.1.19-1.el7.remi              @remi-safe
php81-php-common.x86_64              8.1.19-1.el7.remi              @remi-safe
php81-php-fpm.x86_64                 8.1.19-1.el7.remi              @remi-safe
php81-php-gd.x86_64                  8.1.19-1.el7.remi              @remi-safe
php81-php-mbstring.x86_64            8.1.19-1.el7.remi              @remi-safe
php81-php-mysqlnd.x86_64             8.1.19-1.el7.remi              @remi-safe
php81-php-opcache.x86_64             8.1.19-1.el7.remi              @remi-safe
php81-php-pdo.x86_64                 8.1.19-1.el7.remi              @remi-safe
php81-php-pear.noarch                1:1.10.13-1.el7.remi           @remi-safe
php81-php-pecl-mysql.x86_64          1.0.0-0.25.20210423.ca514c4.el7.remi
php81-php-pecl-zip.x86_64            1.21.1-1.el7.remi              @remi-safe
php81-php-process.x86_64             8.1.19-1.el7.remi              @remi-safe
php81-php-xml.x86_64                 8.1.19-1.el7.remi              @remi-safe
php81-runtime.x86_64                 8.1-4.el7.remi                 @remi-safe
wbm-php-pear.noarch                  2:1.6-1                        @virtualmin-universal

Odd one this! Starting to wonder if this build of virtualmin isn’t aware or able to accommodate php versions >7.

Did you enable and start it in Webmin > System > Bootup and Shutdown?

Richard

After install, I did the equivalent at the prompt (systemctl start, systemctl enable) and the Bootup and Shutdown page indicates yes in both columns.

I am begging y’all to stop installing mod_php. It is in the php81 package (and php74 package in your case). The fact that it’s installed means you didn’t follow our docs, you did some improvising.

Hi Joe, I thought I’d followed the package install instructions precisely, must have subsequently also installed mod_php out of frustration. I intentionally added the Pear package tonight.

There’s fewer 8.1 packages currently on the box versus the older 7.4 install as I’m yet to confirm what is required for the sites, given I couldn’t get virtualmin to detect the presence of 8.1 at all.

There’s a bit of history with the older 7.4 installation, it initially used mod_php but then I adjusted the install to use fcgi except for a tuned FPM setup for two larger sites. No mod_php in use.

For investigation’s sake I first removed the php81 package and left everything else, then I removed completely and reinstalled Remi’s php81 packages according to the multiple versions document. It’s necessary to slightly modify for EL7 (so using Remi’s php81-php- packages, as I want to keep 7.4 for the moment). All installed ok, but virtualmin seems to be unable to see 8.1 FPM, fcgi, etc, despite them existing next to php74 in /bin, /opt/remi, /etc/opt/remi and so on.

I read online this evening that the obsolete mod_php method is now just aliased in modern releases, is that the case? I intend to run everything on FPM eventually because I know fcgi has also been deprecated.

:face_with_monocle:

Yeah I know :sweat_smile: for his reason - a while back you might recall the changes to SSL management and deployment precluded me from upgrading virtualmin on this box;

I’ve kept virtualmin updated on another development box I mostly use for experiments but it doesn’t seem like the features this server uses are available again. Or have I missed it?

Should PHP 8 support be available on this older version of virtualmin regardless, or did it need some hardcoded change to the multi PHP implementation?

There have been many changes to PHP support in Virtualmin since 6.08. PHP 8 did not exist when your version of Virtualmin was released. I can’t imagine how it could be expected to support software that didn’t even exist yet.

My general advice for people who need to use very new software (like PHP 8.x) is to use very new versions of your OS and very new versions of Virtualmin.

The reason those copy-to buttons went away is that everything in new OSes now supports SNI (and they were super confusing!), so you don’t really need to care about which domain certs are used for which service (and should not). The services will mostly use the cert for the domain you’re connecting on.

It’s probably possible to convince Virtualmin to do the old thing. Somehow. Jamie rarely actually removes capabilities even when the UI gets simplified. But, I wouldn’t know how to do it; it doesn’t make sense to me to have a different default name for every service, especially since most services use the name of the domain you connect on to choose the cert, at least on reasonably modern distros.

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.