WARNING The “disable mod_php” feature in this release has a bug, where it doesn’t remove php_ directives from the Apache configuration. Please don’t click that button, yet. I’m working on getting the new version out. (You would only see this if you’d installed mod_php, as mod_php is not part of the default Virtualmin install and its use has been discouraged for several years.)
I’ve rolled out version 7.0-4 (7.0-5 for RHEL/CentOS) of the Virtualmin virtual-server module for all repos.
NOTE This is not the Virtualmin 7 installer. Don’t expect this to mean installation on any new distros is supported. The Virtualmin 6 installer is still the current version and the OS support list on the website is still the correct list of supported OSes. The new installer will arrive shortly, once I’ve finished getting the new repos working and tested.
Changes since 6.17:
On systems without SuExec, fcgiwrap will be used to execute CGI scripts instead for new virtual servers.
Removed the mostly useless configuration check for 127.0.0.1 in /etc/resolv.conf.
Added the reset-feature API command and a tab on the Validate Virtual Servers page to reset the settings for selected features of a virtual server back to their defaults.
Added a configuration option and flag to create-domain to allow SSL linkage across domain owners.
If using a supported Apache version or Nginx, HTTP2 can be enabled for individual websites or on the server templates page.
Added support for outgoing SMTP providers like Amazon SES, so that systems with dynamic IPs can reliably send email.
Reseller access to rename domains, manage extra admins, configure proxies, create, delete and edit virtual servers can now be restricted.
When backing up, you can now choose to download the resulting file in the browser via a link so that the progress of the backup is properly displayed.
The location of SSL certificate and key files can now be configured at the template level, and a safer default location can be set in the post-install wizard.
ZIP format backups now use ZIP for archive files inside the backup as well.
Apache mod_php is no longer recommended for running PHP, and can be entirely disabled using a button on the System Information page.
As always, let us know about any issues in a new topic or a github ticket.
Tested on a Debian 10 server, all went fine, tomorrow will mass update. Glad too see the Debian 11 support wait is coming to an end, will keep an eye on the 7 version of the install script. Thanks for the release guys!
Upgrading a Virtualmin 6 system to Debian 11 has been reported to work fine. I wouldn’t expect any issues.
It’s just installation on Debian 11 that isn’t yet supported (and will require a new install script).
But, then again, I haven’t tested it myself. Maybe the person who reported success does not use FTP (seems likely even, as it’s become pretty rarely used) and so didn’t notice that problem.
If you clicked the “disable mod_php” button after upgrading to 7.0, you’ll likely have now-unrecognized Apache directives, and Apache will refuse to start. To fix that, edit your Apache configuration (/etc/httpd/conf/httpd.conf on CentOS/RHEL or /etc/apache2/sites-available/*.conf on Ubuntu/Debian) and remove all php_* directives from the configuration. php_* directives for for mod_php and disabling mod_php makes them no longer exist in the running Apache. Removing them will allow Apache to start.
Sorry, I don’t understand. Are you saying that I have to remove the following for each site in /etc/apache2/sites-available/*.conf that has php_ in the line? For example:
Thanks, much appreciated. I now have all services running. However, I cannot access any site with a database, specifically Joomla, e107, and Piwigo. Joomla and e107 are throwing 500 errors whereas the Piwigo site highlights are below.
The error I get from my Piwigo site is:
**Fatal error** : Uncaught Error: Class 'mysqli' not found in /home/xxxx/public_html/include/dblayer/functions_mysqli.inc.php:52 Stack trace: #0 /home/xxxx/public_html/include/common.inc.php(109): pwg_db_connect('localhost', 'xxxx', 'pwd', 'xxx_piwigo') #1 /home/xxx/public_html/identification.php(11): include_once('/home/xxxx/...') #2 {main} thrown in **/home/xxxx/public_html/include/dblayer/functions_mysqli.inc.php** on line **52**
What have you done: did you only upgrade Virtualmin or did you update the OS as well? I had a lot of problems after upgrading from Debian 10 to Debian 11 because the upgrade process did not bring in all packages needed, among them the database handler Maria DB, and many other important packages.
Try to install php-mysqli with sudo apt install php-mysqli or if it is already installed you try an reinstall with sudo apt reinstall php-mysqli (sudo if you are not logged in as admin, othervise you skip sudo) or if you have multiple PHP versions you go for apt install php7.4-mysqli and so on.
If it works just keep on and solve the errors whereafter they turn up. A good help is Virtualmin → System Settings → Re-check Configuration.
Thanks for your response. I have done nothing out of the ordinary. Whatever the dashboard has asked me to do, I have done, like disable an unused package, update packages, or reboot.
I have rechecked configuration and everything’s fine. All PHP packages are installed. All services are running normally. Just getting 500 errors in all my database sites and cannot find anything relevant in the logs. At a loss what else to say.