Problems with the web server are usually relatively easy to troubleshoot, but some common problems are tricky, because they aren't usually errors of configuration and so might not show up as reasonable errors in the error_log.

The first place to look for clues in any webserver problem is in the logs. Every virtual server or sub-server in Virtualmin has its own webserver log files. You can find them in the logs directory in the virtual servers home directory. The error_log is usually the most useful when troubleshooting, but the access_log can contain clues

If you browse to one of your virtual server domain names and see the wrong site content, there is a mismatch between the NameVirtualHost and VirtualHost sections of your Apache configuration. This can happen if you've modified the Apache configuration file manually or using other tools, or used Webmin to make changes. Other sources of trouble are misconfiguring Virtualmin to use * for the IP address (this can never work, as it will also break the DNS records, among other things).

Correcting this problem is a simple as making the IP address in the NameVirtualHost directives match the right VirtualHost directives.

There are several possible causes of this problem, and once corrected in the Apache configuration, you should also find the source of the incorrect configuration. It is likely to be found in the Virtualmin Module Configuration under the Other Server Settings category. Specifically, the following options could lead to incorrect IP addresses, or * being used in the VirtualHost sections of your Apache configuration. Incorrect settings here could also lead to invalid or incorrect DNS records being generated.

The options to check are:

Network interface for virtual addresses - This is automatically detected by Virtualmin during the configuration check, but could be detected incorrectly, if you have multiple physical interfaces, or your system is some virtualized system like a vserver or Zone or OpenVZ instance.

Default virtual server IP address - If you've manually configured this to *, for ease of moving a virtual server later, you'll need to instead set it to one of the IP addresses on your system. Moving Virtualmin virtual servers from one IP to another is easy, but getting virtual servers configured correctly with * in place of an IP can be challenging (also note that if you use *, the behavior of other virtual hosts that have explicit IPs set may become unpredictable, if extreme caution isn't used). We strongly recommend you never use * in a virtual hosting environment. But, if you do, you must configure the next option.

Default IP address for DNS records - This option is generally only needed in two circumstances: Your server is behind a NAT router or firewall, and you need the address in DNS records to be a public IP, while the Apache configuration needs to get the private IP; or, you really want to use * based VirtualHost sections in Apache. * is not a valid address for a DNS record, and so you must set an address here. As mentioned above, using * in a virtual hosting environment is not recommended.

This error is the bane of every Apache administrator's existence, as it rarely results in a useful error message in the error_log. And, to compound matters, permission problems show up in the suexec_log, which users don't have access to.

A common problem in an environment using suexec is that permissions on the executable files are too loose. There is a lot of bad advice on the web about setting permissions to 777 for testing, and then figuring out the tighter security later. If group or other users can write your scripts in a suexec environment, they will not execute. Correct permissions for scripts in a suexec equipped system are 750 or less. The script will be executed as the owner of the domain, so as long as the owner has appropriate permissions the script will be executable by the Apache suexec process.

Scripts may have errors in syntax, or be incompatible with the default version of PHP. You may be able to check the syntax from the command line by explicitly calling PHP and the script, like so:

php -l scriptname.php
 

If you think it might be a version mismatch you could see if the script runs with each of the available versions (Virtualmin provides both PHP4 and PHP5 on most supported platforms).

php4 scriptname.php
 

And:

php5 scriptname.php
 

Scripts may also not have the correct permissions for the files it needs to access. A common problem is unzipping or untarring a script archive as root for use by a domain account user. This will result in files that may not be readable or writable by the domain owner, and thus unreadable or unwritable by the suexec process. Check to be sure the files are all owned by the owner of the domain using ls -l. If they aren't, you can use:

chown -R domainname:domainname scriptdirectory
 

The Webmin Wiki contains the following article that may be also be useful:

Apache Web Server