ServerBuddies Support Blog

Ensuring that all Logs are Rotated

Edit the file /etc/logrotate.d/syslog.

Edit this line so that it contains a one-space-separated listing of each log file referenced in /etc/syslog.conf.

All logs in use on a system must be rotated regularly, or the log files will consume disk space over time, eventually interfering with system operation. The file /etc/logrotate.d/syslog is the configuration file used by the logrotate program to maintain all log files written by syslog.

By default, it rotates logs weekly and stores four archival copies of each log. These settings can be modified by editing /etc/logrotate.conf, but the defaults are sufficient for purposes of this guide.

Note that logrotate is run nightly by the cron job /etc/cron.daily/logrotate. If particularly active logs need to be rotated more often than once a day, some other mechanism must be used.

Sending Logs to a Remote Loghost

Edit /etc/syslog.conf. Add or correct the line:

Where loghost.example.com is the name of your central log server.

It is particularly important that logs be stored on the local host in addition to being sent to the loghost, because syslogd uses the UDP protocol to send messages over a network. UDP does not guarantee reliable delivery, and moderately busy sites will lose log messages occasionally, especially in periods of high traffic which may be the result of an attack. In addition, remote syslogd messages are not authenticated, so it is easy for an attacker to introduce spurious messages to the central log server. Also, some problems cause loss of network connectivity, which will prevent the sending of messages to the central server. For all of these reasons, it is better to store log messages both centrally and on each host, so that they can be correlated if necessary.

Customizing apache web logs

Custom formats for apache web logs, to record more information or to make them easier to read.

LogFormat

Apache’s “LogFormat” directive is what lets you define your own access log setup. Let’s look at how that directive would be used to define the combined log format (CLF):

That first argument, in quotes, is the string that describes the log format. The last argument, “combined”, gives a nickname to the format that can be used by CustomLog later on.

That format string contains a bunch of placeholders that describe the data to be included in the log. That first one, for example, is “%h” and represents the IP address of the visitor (the identifier for their host). A bit further on, “%t” represents the time of the request.

Deleting Stats logs daily in cPanel

Deleting Stats logs is something that is enabled on most servers but one does encounter servers with a full domlogs directory. To delete those logs you can follow these steps.

First step is to check how large are the apache domain logs, you can check those on a cPanel server by running “du -hs /usr/local/apache/domlogs”. If the size of those logs is large, then you may want as much free space as possible. Login to WHM and click Tweak Settings. Within that menu click “Delete each domain’s access logs after stats run” which will enable this and click ‘Save’. Now at the end of the stats run every night it will wipe out the directory so you should not have the logs grow very large, unless of course your server is very busy.

Auditing cPanle/WHM Apache logs

All exceptions caught by httpd, along with standard error output from CGI applications are logged here. The first place you should look when httpd crashes, or you incur errors when accessing a website.

This log file contains auditing information reported by suexec each time a CGI application is executed. If you receive an internal server error, with no relevant information being reported to the Apache error_log, check here for potential suexec policy violations.

How to check domain access logs

The general access log for each domain configured with cPanel.