Web Server Configuration
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
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 (ie, "/home/example/logs"). The
error_log is usually the most useful when troubleshooting, but the
access_log can contain clues.
The Wrong Site Shows Up
If you browse to one of the domain names on your server and see the wrong site content, there is likely an IP address mismatch on your system.
That is, Apache may be listening for requests for your domain on a particular IP address, but the request came in on a different address than expected.
To resolve that, first determine what IP addresses are on your server. You can do that by running:
# ip addr sh
Then, determine what IP address(es) Apache is expected requests to come in on by reviewing the VirtualHost section of your Apache config.
A quick way to do that is using the following command:
grep -i 'virtualhost' /etc/httpd/conf/httpd.conf
grep -i 'virtualhost' /etc/apache2/sites-enabled/*.conf
That output will produce a series of lines that look something like this:
Where "x.y.z.q" is the IP address. You would want to make sure that IP addresses listed there are all IP addresses that were shown in your
ip addr sh output above.
You would also want to verify that each VirtualHost block lists an IP address, and not an asterisk (*) character.
If you make any changes, you would need to restart Apache. You can restart Apache with the command "service httpd restart" on CentOS, and "service apache2 restart" on Ubuntu/Debian.
Once you've corrected the Apache config, you may also want to review some options in Virtualmin to make sure new records are being created correctly. Those options are in System Settings -> Virtualmin Config -> Network Settings:
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. You would typically want this to be the primary IP address of your server -- in most cases that is "eth0".
Default virtual server IP address - We recommend leaving this as it's default of "From Network Interface".
Default IP address for DNS records - If your server is behind a NAT router, this option should be set to "Automatically detect external address". Otherwise, you should leave it at the default of "Same as virtual server IP".
And, in System Settings -> Virtualmin Configuraion -> Defaults for new domains:
Address format for Apache virtual hosts - If you're on a dynamic IP, you may need to choose
Always use * and make sure all existing VirtualHost sections do the same. Otherwise, you probably want to
Always use IP.
500 Internal Server Error
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.
Permissions (too much not too little)
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
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).
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