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.
Infos
- logrotate man page: http://linux.die.net/man/8/logrotate
- shred man page: http://linux.die.net/man/1/shred
« Previous 1 2 3 4
Buy this article as PDF
(incl. VAT)