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)
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.
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.
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
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.
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:
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!
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.
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 …
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.
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
