« Previous 1 2 3 Next »
Lean on Logwatch
Critical Support
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.
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.
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.
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.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
Support Our Work
ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.