We are having a bit of a contretemps with one our of Linode blog hosts. This host is running Ubuntu Linux 12X LTS and WordPress, and seems to be having fits of high CPU utilization. One way to see into the web hosting process is to examine the Apache mod_status page.
Mod_status is an Apache module which prints statistics about the Apache application. By default the page will be accessible using the the suffix of /server-status on your root web site URL. http://mysite.com/server-status. However, by default this is restricted to a request from a browser at the 127.0.0.1 address.
If you log into the console, you can attempt to see the status by running the following:
or if you aren’t logged in as root,
sudo apachectl status
This returns the status page.
If you are attempting to access this from a browser on another workstation via http://mysite.com/server-status, you get a 403 message:
The first thing is to find where this restriction is located. It is going to be in one of the Apache configuration files. These are located within /etc/apache2. If the status module is enabled, there will be a status.conf file that can be edited.
sudo nano /etc/apache2/mods-enabled/status.conf
Edit the lines after the <Location /server-status> line, per the instructions. After editing mine looked like:
Require ip 192.168.xxx.0/24
where “xxx” is your local subnet. In the above example, I’m accessing the server from inside the firewall from a workstation located on the same subnet as the Apache server. (In reality, I’m actually accessing a server running within a VirtualBox virtual machine, located on my Windows machine. )
Once these changes are made you have to restart Apache.
service apache2 restart
If this is successful, you get a page similar to the character-based page, but nicely formatted in html. Since the data is similar, however, if there is any issue trying to get at the statistics, probably the character-based method at the console is the first thing to try.
Ah…but what if you get a page, but it isn’t a status page? This is the problem we have with our WordPress site, and it has to do with which page is served as the default. http://myblog.com/server-status returns the default page from the blog rather than the server-status page. Stay tuned for that fix.