Execution

The file /etc/cron.daily/00logwatch (Figure 1) shows how to adjust the email recipient on Debian-based servers. However, the sendmail method explored earlier is more universally accepted. The cron implementation on other Unix-like flavors varies dramatically, and I've seen unwieldy logwatch scripts run straight from cron. Because logwatch is triggered as a cron job, however, that means you can also run it manually, and because it's a complex shell script, you can change much of its internal functionality.

Figure 1: The logwatch cron entry on a Debian server.

For now, however, assume the scripts are powerful enough and extensible enough that you don't need to make many changes; instead, you can alter its configuration. A user with sufficient privileges to read the logfile directory is allowed to execute the cron entry. (However, many Unix-like systems consider system logs to be privileged, so to process all of the logs with logwatch, you might need be root.)

The following command runs logwatch manually on Debian and sends a detailed report by email to recipients pulled from config files:

# /usr/sbin/logwatch --output mail

A large number of logfiles could take a few minutes to complete, but on servers whose performance is tuned correctly, it can be pretty much instant for at least two of the three date ranges (yesterday or today, with all being the slowest).

The logwatch report in Figure 2 shows information relating to how the report is configured, when it was run, and how logwatch deals with pluggable authentication modules (PAM) or user logins by default. This section is included at the top of the report because it is key to checking up on the security of your server and makes you aware of which users have managed to elevate their privileges to root with both su and sudo. If root became another user (e.g., for testing), you will also see that information here, if it was user initiated. Anything unexpected in this section will almost certainly warrant further investigation.

Figure 2: The header of a typical logwatch report.

The file that cron calls, which is found in /usr/share/ … scripts/logwatch.pl, holds a staggering 1,570 lines of code. If you scroll down a little, you can see where HTML can be added to both the header and the footer of the emailed reports. The logwatch script also mentions a debug option a few times and has a section for processing each logfile. A lot of attention is paid to cleaning up old logwatch temporary directories, and one section checks permissions:

print "File $ThisFile is not readable. Check permissions.";
if ($> != 0) {
  print " You are not running as superuser.";
}

Finally, a plethora of sensible, neat-and-tidy formatting options provide the clarity required.

When specifying which applications you want to include in your morning reports, you can specify a run-time --detail level that allows you to clarify how much noise you want passed down via the reports. The default level of detail is well considered, but if you are otherwise inclined, the options are a positive integer or high, med, low (i.e., 10, 5,  ).

Services

To specify which services should generate a report, you use an /etc/services-type format; logwatch looks through any config files present in /usr/share/ … scripts/services. Along with the default services (ntp, pam, tftp, etc.), you can ask that logwatch run through all the services found on the server (and any logfile-groups, which I'll look at shortly) that have filters:

Service = All

Sometimes saving reports to disk can be more useful than email, because if you have a struggling server exhibiting symptoms of an ailment over a few days, you might be able to diagnose it simply by turning up the debug level for a short period of time and running a command-line diff over the salient sections of the saved reports. To save your files to disk, just add --save filename as a parameter at launch. Incidentally, you might want to try that debug option mentioned in the logwatch.pl script by enabling a debug setting from   to 100 at run time with, for example, --debug 25.

The logwatch.conf file lets you select and ignore specific services. To ignore a service, prepend its name with a minus:

Service = "-ftp"
Service = "-bgpd"
Service = "-http"

The syntax of the Service variable takes a few different forms. For example, if you want only to receive information about FTP daemon messages in /var/log/messages and /var/log/xferlog, use the entries:

Service = "ftpd-messages"
Service = "ftpd-xferlog"

The comments in the logwatch.conf file suggest using the options

Service = pam_pwdb
Service = pam

if you only want PAM messages. Another option is to switch off DNS lookups with --numeric so that only IP addresses are displayed and not DNS names.

If you would like to see a number options implemented at the command line, you can enter something like the following command, as shown in the logwatch man pages:

logwatch --service pam_pwdb --range yesterday --detail high--print

This command faithfully checks any user login data that was logged for the previous day and then prints out a high level of detail.

In Figure 3 you can see an example of logwatch showing all upgrades and new packages installed. If you archive your email over a long period of time, you can always search for this information at a later date.

Figure 3: All packages I installed and upgraded on an Amazon Linux server running on AWS EC2.

Documentation

Before using logwatch and creating your own filters, you should explore the excellent documentation and a few examples. As touched upon earlier, the logwatch documentation provided in the /usr/share/doc/logwatch/HOWTO-Customize-LogWatch.gz file [2] demonstrates in detail how to customize configuration files and create new service filters. If for some reason your less viewer doesn't uncompress this file, you can try to read it using zless:

# zless /usr/share/doc/logwatch/HOWTO-Customize-LogWatch.gz

The HOWTO file explains that the bundled dist.conf directory contains very specific files relating to your distribution's build requirements. The default.conf directory, however, holds the majority of pertinent configuration files, and under the services directory therein is a specific noise setting for each application.

The ignore.conf file suppresses output matching any Perl-style regular expressions (regex) you add to the file, and it even has a standalone logfile feature that processes /var/log/messages in the event that you have only one logfile to check:

LogFile = messages

This command will run through any filters associated with that logfile, but setting Service = All will run through all your logs, which is probably more pragmatic in most scenarios.