Virtualmin virtual-server module 7.0-4 released


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 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.



Thank you @joe.

I’m running Debian 10. Webmin is notifying about those updates:

webmin web-based administration interface for Unix systems **New version 1.991
webmin-virtual-server Webmin module Virtualmin Virtual Servers **New version 7.0.gpl-4
webmin-virtualmin-awstats Webmin module AWstats Reporting **New version 6.0
webmin-virtualmin-htpasswd Webmin module Virtualmin Protected Directories **New version 3.1
webmin-virtualmin-nginx-ssl Webmin module Nginx Webserver SSL **New version 1.17

Can I safely update the following packages or it is advisable to wait to the Webmin server 7 update script to be launched?


It is fairly safe to upgrade!

1 Like

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!


For everyone installing/upgrading on RHEL/CentOS/Alma/Rocky - hold back. There is a bug currently in Virtualmin package.


This issue has been resolved with the latest package. Please upgrade.

1 Like

Ok, I didn’t read what Joe have written, I just upgraded to 7 and an then to Debian 11 and Apache 2 and the FTP server does not work!

I love snapshots!

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.


FTP is still used and needs to be available in every hosting platform, in my opinion.

By the way just upgraded on Ubuntu Linux 20.04.4 - all went OK.

1 Like

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.

1 Like

Ubuntu server here and slightly desperate.

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:

php_value memory_limit 32M
php_value post_max_size 10M
php_value upload_max_filesize 10M
php_value memory_limit 24M
php_value max_execution_time 60
php_value suhosin.session.encrypt Off

php_admin_value engine Off

or, from another site:

php_admin_value engine Off

php_value memory_limit 32M
php_value suhosin.session.encrypt Off
php_value magic_quotes_gpc On
php_value max_execution_time 300
php_value file_uploads On
php_value upload_max_filesize 25M
php_value post_max_size 25M
php_value session.auto_start Off
php_value mbstring.func_overload Off

Yes. That is used for mode_php only and mode_php is no longer supported. You have to take them away from .htaccess as well.

If you want to use that kind of commands you can to add them to .user.ini placed in the / next to .htaccess but then they look like this

max_execution_time = 240
max_input_time = 300
max_input_vars = 3000
post_max_size = 100M
upload_max_filesize = 100M
file_uploads = On
max_allowed_packet = 500M

More commands here PHP: List of php.ini directives - Manual

But most of the above settings can be done from within Virtualmin when ou use php-fpm instead of mode_php

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/ Stack trace: #0 /home/xxxx/public_html/include/ 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/** 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.

1 Like

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.

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