Virtualmin on Centos 8 not working - multiple PHP issues

Have installed Centos 8 bare bones, and used install.sh to install virtualmin and having a few major issues.

1st major issue is that PHP is very broken. FCGI does not work because the chroot is /var/www ?

SuExec cannot be used to run PHP scripts in CGI or FCGId modes : The Suexec command on your system is configured to only run scripts under /var/www, but the Virtualmin virtual server home directory is /home. CGI scripts run as domain owners will not be executed.

I figured i could use php-fpm , however it seems mod_proxy is not available/enabled, and even when i enabled every proxy module i can find its still not working

The following PHP-FPM versions cannot be used : 7.2.24 (Apache module mod_proxy is missing or not enabled)

[root@kowhai ~]# httpd -M
Loaded Modules:
core_module (static)
so_module (static)
http_module (static)
access_compat_module (shared)
actions_module (shared)
alias_module (shared)
allowmethods_module (shared)
auth_basic_module (shared)
auth_digest_module (shared)
authn_core_module (shared)
authn_file_module (shared)
authz_core_module (shared)
authz_groupfile_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
brotli_module (shared)
deflate_module (shared)
dir_module (shared)
env_module (shared)
expires_module (shared)
headers_module (shared)
include_module (shared)
info_module (shared)
log_config_module (shared)
logio_module (shared)
mime_module (shared)
negotiation_module (shared)
rewrite_module (shared)
setenvif_module (shared)
slotmem_plain_module (shared)
slotmem_shm_module (shared)
socache_shmcb_module (shared)
unixd_module (shared)
mpm_prefork_module (shared)
proxy_module (shared)
lbmethod_bybusyness_module (shared)
lbmethod_byrequests_module (shared)
lbmethod_bytraffic_module (shared)
lbmethod_heartbeat_module (shared)
proxy_ajp_module (shared)
proxy_balancer_module (shared)
proxy_connect_module (shared)
proxy_express_module (shared)
proxy_fcgi_module (shared)
proxy_fdpass_module (shared)
proxy_ftp_module (shared)
proxy_http_module (shared)
proxy_hcheck_module (shared)
proxy_scgi_module (shared)
proxy_uwsgi_module (shared)
proxy_wstunnel_module (shared)
xml2enc_module (shared)
proxy_html_module (shared)
ssl_module (shared)
systemd_module (shared)
cgi_module (shared)
fcgid_module (shared)
http2_module (shared)
proxy_http2_module (shared)
php7_module (shared)

Finally, less important, Dav is completely not working because its not installed. i did not look into this since it was pointless and php was dead.

Any hints/suggestions ?

See the release notes: https://forum.virtualmin.com/t/virtualmin-install-sh-support-for-centos-8

For PHP, FCGId is deprecated on CentOS 8 (because we no longer provide a custom Apache package, so there is no working suexec). The only currently supported way to run PHP is FPM. This is what’s recommended by the upstream PHP folks, so we’re just going along with that. It’s still plausible we’ll come back around to believing we need suexec, but I’m not convinced of that, so far. There are ways to use it even without a custom build, but I don’t really like any of them (bind mounting home over /var/www is one).

But, PHP-FPM not working out of the box is a serious issue, though I don’t know that we’ve had bug reports about it and it didn’t show up in our testing. I’ll have to try to replicate that.

I’m not sure about DAV. It’s been a long time since I looked at it, since the Apache implementation is kinda crap and doesn’t really work in the real world for most people. What specifically are you doing with DAV? If it worked in the past, we’d like it to continue to work, and I don’t know, off-hand, any reason it wouldn’t…so, it’s maybe something we can fix, even if we aren’t spending a lot of effort on DAV.

To be honest most people dont use dav, it just said it was not installed or detected on the check/refresh config, and i disabled it. I was more worried about the PHP issue since people use that

What module should it be looking for that was not in my list to have that found? how is that installed usually?

Are you sure there were no errors during the configuration stage? There shouldn’t have been any need to turn anything off or whatever to make config check pass. Though I’ve been planning to completely get rid of DAV support in the default installation just because it’s unnecessary complexity for new users for dubious benefit. But, I’m pretty sure it’s still enabled in a default install unless something went wrong.

For PHP, I don’t know. It’s supposed to Just Work. The php-fpm package mandatory, so unless something went wrong during installation it should be there. (https://github.com/virtualmin/virtualmin-yum-groups/blob/2dab7ce13b9c3fc07dfac98a6374d8198abca2aa/virtualmin-centos-8-comps.xml#L32)

Sounds like maybe the Apache config stage just failed for your installation. There should have been errors either in the console or in the virtualmin-install.log. We’d need to figure out what went wrong and then get a working fresh install for you, rather than trying to fix it after the fact.

I think i have found something that may be related

pin pid is: 3311
2020-09-20 21:14:09 URL:https://software.virtualmin.com/vm/6/gpl/centos/8/x86_64/virtualmin-release-latest.noarch.rpm [14112/14112] -> “virtualmin-release-latest.noarch.rpm” [1]
Downloading virtualmin-release-latest.noarch.rpm: Success.
Spin pid is: 6380
warning: virtualmin-release-latest.noarch.rpm: Header V4 RSA/SHA1 Signature, key ID 60d62a6b: NOKEY
error: can’t create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-webmin: key 1 import failed.
error: can’t create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin: key 1 import failed.
error: can’t create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin-6: key 1 import failed.
Installing virtualmin-release package: Success.

On a new install it does updates afterwards , i suspect this is the possible cause. Reinstalling now and gonna make sure those are done before the installer is run.

Okay fresh install, went with defaults all the way in the config, did not add a default domain, just did refresh

The status of your system is being checked to ensure that all enabled features are available, that the mail server is properly configured, and that quotas are active …

Your system has 1.94 GiB of memory, which is at or above the Virtualmin recommended minimum of 256 MiB.

BIND DNS server is installed, and the system is configured to use it.

Mail server Postfix is installed and configured.

Postfix is configured to support per-domain outgoing IP addresses.

PHP execution mode fcgid was selected in the default template, but is not supported on this system. Changing the default to mod_php.

SuExec cannot be used to run PHP scripts in CGI or FCGId modes : The Suexec command on your system is configured to only run scripts under /var/www, but the Virtualmin virtual server home directory is /home. CGI scripts run as domain owners will not be executed.

The following PHP versions are available : 7.2.24 (/bin/php-cgi), 7.2 (mod_php)

The following PHP execution modes are available : mod_php

The following PHP-FPM versions cannot be used : 7.2.24 (Apache module mod_proxy is missing or not enabled)

PHP versions have changed to 7.2, 7.2 since last check. Regenerating any missing php.ini files.

Webalizer is installed.

Apache is configured to host SSL websites.

MariaDB 10.3.17 is installed and running.

ProFTPD is installed.

Logrotate is installed.

SpamAssassin and Procmail are installed and configured for use.

ClamAV is installed and running.

Plugin AWstats reporting is installed OK.

The Apache mod_dav module must be installed before DAV can be used

… your system is not ready for use by Virtualmin.

Same error in the virtualmin installer log

Spin pid is: 13230
2020-09-21 02:17:19 URL:https://software.virtualmin.com/vm/6/gpl/centos/8/x86_64/virtualmin-release-latest.noarch.rpm [14112/14112] -> “virtualmin-release-latest.noarch.rpm” [1]
Downloading virtualmin-release-latest.noarch.rpm: Success.
Spin pid is: 13285
warning: virtualmin-release-latest.noarch.rpm: Header V4 RSA/SHA1 Signature, key ID 60d62a6b: NOKEY
error: can’t create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-webmin: key 1 import failed.
error: can’t create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin: key 1 import failed.
error: can’t create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin-6: key 1 import failed.
Installing virtualmin-release package: Success.
[2020-09-21 02:17:19 UTC] [DEBUG] Phase 2 of 3: Installation
Spin pid is: 13319
RHEL/CentOS 8 - x86_64 - Virtualmin 14 kB/s | 17 kB 00:01
Virtualmin Distribution Neutral Packages 258 kB/s | 689 kB 00:02

Well, that’s obviously wrong! mod_php shouldn’t even exist!

Is this a custom OS install that already has Apache and PHP packages installed (specifically the php package that includes mod_php)?

We should obviously handle that better, but if you don’t have mod_php installed (we don’t install it), Virtualmin won’t try to use it. There’s no scenario where mod_php is the right way to run PHP scripts in new deployments, so getting rid of it is reasonable. But, I’ll make sure there’s a ticket to make sure we don’t fall back to it before falling back to php-fpm.

The key errors are unimportant. Package installation obviously succeeded and those are the keys used to sign our packages, so it didn’t prevent installation.

And, I’m not sure why mod_proxy isn’t enabled, by default. it should be…I’ll look into it.

1 Like

Awesome. Let me know if you need any more information.

I gave it more fresh tests and PHP-FPM works out of the box for me on clean CentOS 8 install, on CentOS 8 minimal install.

Looks like mod_poroxy is also installed and enabled:

image

Are you sure you haven’t installed by accident a container or pre-built LEMP CentOS 8 version, instead of using a clean, minimal install? What is your hosting provider?

Yes. Its our standard setup at Rimuhosting, we have an image and errata scripts we use to setup a default system. Ill go through the scripts we have and see if i can see anything that may affect it tomorrow.

Assuming this post it looks that you have installed two versions of PHP 7.2, which shouldn’t be done.

Ill go through the scripts we have and see if i can see anything that may affect it tomorrow.

Can you deploy your scripts out after running Virtualmin install script and testing that initial Virtualmin installation works prior any further changes? Because for us, official image of clean, minimal install of CentOS 8 works just fine!

I dont think so.
[root@host ]# yum list installed | grep -i php
php.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-cli.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-common.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-fpm.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-gd.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-json.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-mbstring.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-mysqlnd.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-odbc.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-opcache.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-pdo.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-pear.noarch 1:1.10.5-9.module_el8.2.0+313+b04d0a66 @AppStream
php-pgsql.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-process.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-xml.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-xmlrpc.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
wbm-php-pear.noarch 2:1.6-1 @virtualmin-universal

Looked at the errata and im not seeing anything obvious. Or scripts mostly just do things like network setup, adding rimu keys, and logging things (for our own use), plus install whatever control panel they want (including virtualmin)

I will check tomorrow with co-workers to see if there is anything else that could cause issue

I’d recommend not having php installed (the specific php package, which contains mod_php). Virtualmin will offer it as an available execution mode, if it’s installed, but literally nobody is recommending running PHP with mod_php today.

That’s orthogonal to the issues you’re seeing and removing it probably won’t fix the failure to configure Apache that seems to be happening, but it’s worth point out. The php package is not needed and not recommended.

Virtualmin does prefer to be installed on a fresh base OS install, rather than one that’s already had a bunch of other packages installed, but it may be OK if it’s just standard OS packages and no extra configuration is being done before installation of Virtualmin.

Are you sure you have the current version of the Virtualmin install script? It might be worth posting the actual output you see when you run the script…look carefully for missed steps in the configuration stage, in particular.

Since we haven’t been able to reproduce it, we need to know where it’s breaking, specifically.

Have checked through our setup, and i think our base image has some dodgy apache module/configs things going on.

Seems to work well once i removed /purged those packages, so going to drill down and look into that more. This fixed both FPM/proxy and Dav issues.

Thanks for your help

2 Likes

Just an update to this.

Seems our default image had the modules installed but not enabled. I have changed our script to enable those modules , which has fixed the initial issue .
Ideally This should be something the installer checks, that modules are both installed and enabled.

great! now we can get it going and it works - except …

When you do the Setup Wizard - at the very end it offers to add a default domain. Because it has not done the ‘Re-check the configuration’ kept defaulting to using FCGI which does not work on Centos.

My installer script already automated the virtualmin install , then i had it run a
virtualmin modify-template --id 0 --setting web_php_suexec --value 3

This sets the PHP mode in the default template to be fpm .

I checked this, so default template is definitely using fpm before wizard is run, at the end of wizard it adds the domain - and it sets that to use fpm also, and then i try running the re-check configuration, and its somehow added in errors

Apache configuration errors were found :

AH00526: Syntax error on line 363 of /etc/httpd/conf/httpd.conf:
Invalid command ‘SuexecUserGroup’, perhaps misspelled or defined by a module not included in the server configuration

Those lines are the virtual config for that domain …

<VirtualHost *:80>
SuexecUserGroup “#1000” “#1000

Edit: nm i think this another module i need to find / enable in apache

Thanks for the updates. I’m thinking about spinning up a CentOS 8 server to familiarize myself with it, and I appreciate your sharing your observations, experiences, and fixes.

Richard

ok finally got all the bugs and bis worked out.

Seems my co-worker got overly enthusiastic about disabling modules by default on the Centos image. Just finding the required ones seemed to do it, then uncommenting it.

Also i really wish Centos has things like a2enmod and a2dismod to make that easier :smiley:

1 Like

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