Re: Size of wtmp files
From: P Gentry (rdgentry1_at_cablelynx.com)
Date: 26 Apr 2004 12:09:45 -0700
Graham Nicholls <email@example.com> wrote in message news:<firstname.lastname@example.org>...
> SuSE 7.2 runs cron.daily, which among other things, rotates /var/log/wtmp,
> keeping the file below a defined size of 400k.
> Does anyone know why wtmp is kept so small - is writing to it inefficient
> (as users log out - perhaps updatnig records?) above a certain size?
A number of reasons for choosing any particular size are possible --
main one being that logrotate can compress then email the rotated
> With a lot of users, you see, this file is getting several times a month,
> thus limiting the use of the 'last' command. ...
Not sure what you mean here -- getting rotated? Review the man page
for logrotate to configure it the way you want. In any case you
should always keep your logs and use a tool to help manage them the
way you are comfortable with. Last has a number of options that can
help without additional tools.
> ... OK, I can (and have) written
> a script to run 'last' repeatedly on zcatted versions of the rotated files,
> but this is clumsy. My question is, does anyone forsee problems in either
> not bothering to rotate /var/log/wtmp, or allowing the file to grow to 10s
> of megabytes?
If you allow any logging facility to grow a file without limits, you
run the risk of exhausting disk space accidentally or as a result of
an attack. Not to mention that without routine removal/storage of
logs, an attacker has full reign to edit the log files with impunity.
I don't really understand the "inconvenience" you have with logrotate
and last. Do you regularly scan the _rotated_ files for anomolies or
inconsistencies? Many people will run scripts using last to
automatically pull entries every X minutes and redirect to another
file, etc. _before_ rotation and scan the redirected results. And you
don't _have_ to compress the files at all or you can use gunzip to
decompress them if that's handier than zcat.
These classic tools are quite scriptable. That being the case, why
take the "easy" route of allowing any log file to grow to obscene and
wasteful size on a machine that presumably can make better use of the
disk space resource?
Mangaing log files is rather like managing backups, once you develop a
strategy and tools, it's not that difficult most of the time. It's
just another resource to be managed to suit your needs.
Take a careful look at the man pages of logrotate and last and review
your current /etc/logrotate.conf file. You might be surprised how
much you can accomplish with crafty configuration and a few simple
scripts/cron jobs. Beyond that there are a number of pre-written,
more sophisticated, more complex tools -- choose your poison.
email above disabled