Lock down your logfiles with logrotate

Wait a Minute, Mr. Postman

A truly exceptional feature, which I had scripted myself independently a few times before discovering logrotate, is mailing logs when they rotate. Clearly, it's impractical much of the time when logfiles are unwieldy and cumbersome in size, but if you're not already aware, I will let you in on a little secret.

Simply put, logs absolutely love being compressed. By that I mean that the majority of logfiles have so many repetitive patterns that you might be inclined to spill your coffee after looking at a massive logfile's compressed file size. It can be staggering! For this reason, logs (maybe with a little encryption here and there) are quite suitable for email. I've had occasion to keep login transaction logs to evidence certain users' activities in the past, and a 100KB file does nothing to my mail server load, but it does mean that salient logging is saved in my ever-growing email repository should it be needed in the future.

To don your postmaster hat, use the following config line:

mail chris@binnie.tld

Another useful addition to consider is whether you want to mail the newly rotated log as opposed to one that's about to be deleted (which will occur by default). To achieve this, set:

mailfirst

One final email config option is the obvious maillast parameter. Contrary to the mailfirst choice, you simply email the logfile that is about to be expunged, not the freshly rotated logfile.

Another option that suits this parameter well is size. Instead of waiting for a specific time period to rotate your logs, you can trigger logrotate when a certain file size limit has been reached. Whether you omit the daily, weekly, or monthly options or not, the size option can be coupled with mail so as not to send your mail servers into a downward-spinning spiral with a sudden, massive amount of unexpected logging activity related to an attack, a serious error, or a misconfiguration of the system.

The very handy minsize option gives you the choice not to rotate, even considering the timestamp from the daily, weekly, or monthly options and the size parameters. This means that your server potentially is doing less work and only putting effort into gzipping when it's absolutely necessary. I think there's no reason not to use this on smaller logs, other than that every now and again you might briefly wonder why some logfiles only have three rotated logs and others have more.

Declaring file sizes is straightforward:

  • A lowercase k sets the file size in kilobytes.
  • An uppercase M sets the file size in megabytes.
  • An uppercase G sets the file size in gigabytes.

In most situations, setting a file size saves worrying about multiplying bits by 8 and bytes by 1024 to reach a sensible number at which to rotate.

This and That

The plethora of options available just keep on coming with logrotate. For example, think about what happens if you're logging sensitive data, such as partial credit card details, to an error log when it suffers a specific problem. Your Service Level Agreement with customers allows you to keep a number of logs for a period of time, as long as they are destroyed in a proper fashion after that period has been reached. Step forward the system shred option:

shred -u

I really like the man page's explanation of what shred tries to achieve: It wraps up the functionality very concisely, with a loosely implied disclaimer to boot. By utilizing the clever shred utility, after deleting a logfile, it's possible "to make it harder for even very expensive hardware probing to recover the data" [2]. In layman's terms, this means that logs should no longer be readable post-deletion. It's a nice security feature that might serve in a number of scenarios.

Another problem I had once was that inside a script, file names weren't being picked up because they were rotated with a zero at the end. Like the decision to begin a calendar week on a Sunday or a Monday, sometimes you need the first iteration of your rotated logs to end in  , and sometimes you need it to end in 1. The start parameter comes into play nicely here and can be manipulated with a trailing number:

start 101

This statement means that no logs will possess the file extension from   to 100; instead, the first rotated log will be <daemon>.log.101.

On that note, you can also find yourself in situations in which you have to purge logs once they reach a certain age (e.g., to maintain a decent working capacity on your disks). One config option, the maxage parameter, allows you to sever all ties with files of a certain age:

maxage 90

The number 90 is the age in days a file must be before it is purged. I tend to use this as a last resort to clean up old logs, in case I haven't been checking on whether they are behaving and rotating in a timely manner. In this way, I can make sure I'm not filling disks to the breaking point. Clearly, you need to be sure you're deleting logfiles using this config option when they're no longer useful and not before.

One final option I'll look at is tabooext, which I find useful when my logs live in the same directory as other functioning files. With this config switch, I can ban logrotate from going anywhere near these files (usually hard-won scripts), which would break if anything tampered with them.

The tabooext feature lets me supplement an already default system list that includes

.rpmorig, .rpmsave, ,v, .swp, .rpmnew, ~, .cfsaved, .rhn-cfg-tmp-*,\
  .dpkg-dist, .dpkg-old, .dpkg-new,.disabled

by simply adding a line to my logrotate config like:

tabooext + .chris .ignore .save .chrisbinnie

It's worth noting that if you make sure a plus sign follows the tabooext declaration, this list will append to the default system list. whereas without the magical plus symbol, the existing list is overwritten with this new custom list of taboo file extensions.

It Must Stop Here

Logging, in itself, is a simple activity, but managing logs can be far from simple. The ever-faithful logrotate simply has too many options – to be applied in a number of scenarios – to cover in full here. Boasting extensible functionality, the formidable logrotate tool puts some other software packages to shame. In this article, my intention was to give newcomers to logrotate a head start and to offer enough food for thought to encourage creative solutions to their logging needs.

I hope you will take time to dig deeper into logrotate and figure out how to let it solve your logging quandaries.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • logrotate

    Take charge of your installation’s logfiles with logrotate.

  • Admin Workshop: Logrotate

    Every multi-purpose Linux system produces an enormous amount of log data. To prevent your hard disk from overflowing, a rotating helper application archives logs and gets rid of obsolete data.

  • BleachBit

    Many Linux services and applications create a continuous log of their activities. BleachBit cleans up the resulting log files conveniently and efficiently.

  • check_logfiles

    The Nagios check_logfiles plugin helps you monitor your logfiles – even if the logs rotate and change names.

  • Argus

    Argus helps you monitor the flow of data on your network, detect trends, discover worms and viruses, and analyze bandwidth usage.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95

News