|
|
Just as there are many ways to configure Apache, there are many ways in which things can go wrong. Luckily, most errors fall into a few basic categories. Here are some of the common problems that Rackspace sees with some of our own customers' controlled Apache servers, along with simple solutions that will get you backup in no time:
Permission errors when viewing a user's site-Permissions are set incorrectly on the public web directory. You can either change the web directory's group to the apache group or define the directory so that it is world executable. If on a Red Hat, Fedora, or Debian system, you can use UPGs to allow the user apache into the site owner's web content. See the File Permissions section earlier in the chapter for more information.
Can't access www.example.com-If you can get web files at http://example.com but not at www.example.com, then you have the wrong or missing ServerAlias setting for that virtual host. The correct block of code should be as follows:
<VirtualHost 10.1.1.1>
DocumentRoot /home/bob/web/html/
ServerName example.com
ServerAlias www.example.com
</VirtualHost>
Apache won't start or generates run time errors-If httpd is not starting correctly, you may have mistakes in the httpd.conf file that prevent the Apache process from starting properly. Check /var/log/messages with the command grep httpd:/var/log/messages to see if the problem can be easily tracked down (these messages are also echoed to the console). If Apache starts but you continue to get run time errors such as broken graphic images or inoperative links, then the run time errors will be logged to /var/log/httpd/error_log. Use tail to watch this log file in real time as you use a web browser to generate the errors:
# tail -f /var/log/httpd/error_log
DNS problems-At least 50 percent of the time, new and migrating website problems are DNS related. Be sure you check DNS from the top of the DNS namespace to down. Use the whois command to discover who owns and does DNS for a given domain: whois example.com|grep -iA3 "server". After you know the authoritative DNS server(s), query it directly for the FQDN or URL you're interested in: dig www.example.com@the.nameserver.com. Make sure that there are valid CNAME records (aliases) or A records (IPs) for each of the URLs defined by a virtual host's ServerName and ServerAlias directives.
A new virtual site doesn't work-Jorge Arrieta, a Server Administrator and RHCE at Rackspace, has found that if you've configured a new virtual host but can't pull up the site in a browser, there are several possible causes. First, restart the server if you did not do so after adding the new host. Also, make sure that the httpd service is configured to have back up after reboots (via chkconfig). Next, make sure that the DNS record points to the appropriate IP address, remembering that any DNS changes may take some time to propagate. If DNS looks good, issue the command
# httpd -S
to parse httpd.conf and list the configured VirtualHost entries. If the new virtual host is not listed, then it is not configured correctly and you will have to correct the configuration or look through /var/log/messages for related errors.
|
|