Upgraded to 3.32-2 & now have problem with mod_suexec

On my Debian sarge server I have
apt-get update
apt-get install webmin-virtual-server

to install the latest upgrade but now have the following error checking configuration:

" Suexec is enabled in the default template, but the Apache module mod_suexec is not installed or not enabled.

… your system is not ready for use by Virtualmin. "

I don’t think I should be disable suexec in the default template.

How does one enable module mod_suexec?

I’m seeing the same problem. I don’t know if this is Debian-related - I’m using Ubuntu Edgy Eft 6.10 with Apache 2.0.55.

Linux 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linux

Virtualmin reports:

"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 …

  BIND DNS server is installed.

  Mail server Postfix is installed and configured.

  Suexec is enabled in the default template, but the Apache module mod_suexec is not installed or not enabled.

… your system is not ready for use by Virtualmin."

I’ve patched /usr/lib/apache2/suexec2 (rather than recompile it) so it reports:

-D AP_DOC_ROOT="/home"
-D AP_HTTPD_USER="www-data"
-D AP_LOG_EXEC="/var/log/apache2/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_USERDIR_SUFFIX="public_html"

Apache reports:

Server version: Apache/2.0.55
Server built: Sep 27 2006 16:52:14
Server’s Module Magic Number: 20020903:11
Architecture: 32-bit
Server compiled with…
-D APACHE_MPM_DIR=“server/mpm/prefork”
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D SUEXEC_BIN="/usr/lib/apache2/suexec2"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD=“logs/apache_runtime_status”
-D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock"
-D DEFAULT_ERRORLOG=“logs/error_log”
-D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types"
-D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf"

phpinfo() reports the loaded modules:
core mod_access mod_auth mod_log_config mod_logio mod_env mod_setenvif prefork http_core mod_mime mod_status mod_autoindex mod_negotiation mod_dir mod_alias mod_so mod_cgi mod_jk mod_perl mod_php5 mod_suexec mod_userdir

I should add I’m testing 3.32-gpl. The apache /server-info module reports:

Module Name: mod_suexec.c
Content handlers: none
Configuration Phase Participation: Create Directory Config, Create Server Config
Request Phase Participation: none
Module Directives:
SuexecUserGroup - User and group for spawned processes
Current Configuration:

So is this simply a case of no SuexecUserGroup directive in the server configuration yet? I did some extensive searching but didn’t find any articles that explicitly talk of adding the directive prior to starting Virtualmin.

I’ve checked and it appears “mod_actions” isn’t loaded, so the issue may be something to do with Webmin’s internal settings.

Webmin verson is 1.310

Apache Server Information

Server Settings, mod_userdir.c, mod_suexec.c, mod_php5.c, mod_perl.c, mod_jk.c, mod_info.c, mod_cgi.c, mod_so.c, mod_alias.c, mod_dir.c, mod_negotiation.c, mod_autoindex.c, mod_status.c, mod_mime.c, http_core.c, prefork.c, mod_setenvif.c, mod_env.c, mod_logio.c, mod_log_config.c, mod_auth.c, mod_access.c, core.c

I now pass configuration check:

In Re-Configure Known Modules (Webmin) I see that mod_suexec is unchecked. I checked its checkbox and hit configure.

Now configuration check passes ok, however when viewing the Re-Configure Known Modules panel again mod_suexec remains unchecked.

I’m happy to be functional again even if I am not much wiser.

I found there are two directories: installed_modules, available_modules, under the /etc/apache2 directory that after coping the mod_suexec from the available_mods directory to the installed_mods directory it includes those modules in the server.

This was on an ubuntu(6.10).

The issue might be in virtual-server-lib-funcs.pl, around line 8674:

if ($config{‘web’}) {

Where if it gets 3 boolean true values it reports the issue:

if ($tmpl->{‘web_suexec’} && $apache::httpd_modules{‘core’}]= 2.0 && !$apache::httpd_modules{‘mod_suexec’}) {
return &text(‘check_ewebsuexec’);

I added some reporting to find out what values are being seen:

	return &text('check_ewebsuexec') .

" web_suexec=" . $tmpl->{‘web_suexec’} .
" apache=" . $apache::httpd_modules{‘core’} .
" !mod_suexec=" . !$apache::httpd_modules{‘mod_suexec’};

And the web page shows:

Suexec is enabled in the default template, but the Apache module mod_suexec is not installed or not enabled.

web_suexec=1 apache=2.055 !mod_suexec=1

After tracing execution of the code I narrowed the cause down to the apparent non-setting of httpd_modules{‘mod_suexec’} but couldn’t pin down why.

Incidental to this tracing, in Webmin, I accessed

Servers] Apache Web Server] Re-Configure Known Modules

(to ensure mod_suexec was seen as enabled).

On leaving the page, to be sure the options were set, I pressed the “Configure” button although I hadn’t altered any settings.

I tried the Virtualmin configuration check again but this time it complained that “mod_actions” wasn’t enabled!

I returned to

Servers] Apache Web Server] Re-Configure Known Modules

and ticked "mod_actions" and the pressed the "Configure" button.

Returning to Virtualmin I again tried to do a check and this time to my surprise it passed the Apache check but complained about Webalizer not being configured or installed.

I pressed the Virtualmin "Module Config" link at the top-left of the page and then disabled Webalizer:

Webalizer report generation enabled? "No"

On returning to Virtualmin it succeeded in doing a check and now presents the Virtualmin Virtual Servers, master admin mode, page.

Checking the enabled modules once again at

Servers] Apache Web Server] Re-Configure Known Modules

it still shows "mod_action" un-ticked but Virtualmin appears to be working!

As I didn’t restart apache2 after ticking “mod_actions” I’m wondering if Webmin reloaded/restarted apache in the background (it didn’t say it had) or just changed a Webmin option setting, that Virtualmin subsequently found pleasing.

The upshot is that - somehow - Virtualmin has sprung to life!