Apache Maintenance Basics Page 3

By Martin Brown (Send Email)
Posted May 13, 2004


Log Management

Contents
Monitoring Apache
Log Monitoring
Log Management
Configuration Management
Security and Passwords
Keeping Apache Up to Date
Other Systems and Extensions
Scheduling Maintenance

For obvious reasons, it's a good idea to keep logs for a while to track and trace problems. You'll also probably want to keep access logs for a long time to perform the necessary analysis. Error logs can be disposed of every three months — once you've gone through the steps above to check out any errors or potential problems.

The most effective way of doing this in the standard Apache release (without any clever configuration tricks) is to:

  1. Shut down Apache
  2. Rename the error and access logs
  3. Restart Apache

This obviously shuts down Apache for a period, which you may not want to do if the server is busy. To get around this, use the piped log system, which outputs log information through an external command that can automatically rotate and archive the information. Apache, in fact, provides the rotatelogs application as part of the standard kit to do this. Rotatelogs accepts the name of the log, and the interval for rotation (in seconds).

To enable rotatelogs, change the configuration file to use the pipe system for each log file:

CustomLog "|/usr/local/apache/bin/rotatelogs  /var/log/access_log  
86400" common 

The number 86400 is the number of seconds in a day. On a busy site, it is preferable to decrease that value so the rotation is performed every six hours, or even every hour. On less busy sites setting it for every week or month would work.

We recommend writing all logs into a custom MySQL database. This makes it easier to get out information from both error and access logs. The fields in the SQL table match those in the output, and an extra field records the name of the Web site.

Configuration Management

Many Web servers rarely have their configuration files modified and updated; others regularly add new configurations, virtual hosts, and other elements. Two ways to ensure the configuration is up to date and working are 1) checking the configuration and 2) tracking configuration changes.

Checking the configuration periodically highlights any problems (including any disparity between the currently running Apache and the current configuration file). Sometimes, it will even highlight changes made to the Apache configuration of which you may not have been aware.

Checking the configuration can be handled with the apachectl command with the configtest argument:

$ apachectl configtest
Processing config directory: /etc/httpd/sites/*.conf
  Processing config file:  
/etc/httpd/sites/0000_192.168.1.24_80_atuin.mcslp.pri.conf
  Processing config file:
/etc/httpd/sites/ 
0001_192.168.1.24_80_cheffy.devel.atuin.mcslp.pri_copy.conf
  Processing config file:  
/etc/httpd/sites/0001_any_80_cheffy.devel.atuin.mcslp.pri.conf
  Processing config file:  
/etc/httpd/sites/0002_any_80_webmail.mcslp.pri.conf
  Processing config file: /etc/httpd/sites/virtual_host_global.conf
[Wed May 12 11:07:11 2004] [warn] module mod_WebObjects.c is already  
added,
skipping
Syntax OK

The 'Syntax OK' line at the end is the key piece.

Configuration management is about keeping a history of the changes you've made to your configuration file. The easiest way to do this is to use RCS or CVS to check in any configuration changes made. They not only track the changes and differences between versions, but also enable you to record a log of the changes made and recover previous versions.

If you're worried you will forget to log the changes, you can run a script each night to automatically check the latest version of the script, along with a suitable description to identify the automatic changes:

cd /export/http/apache2/conf
cvs commit -m "Nightly auto-commit"



Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.