/var/log/btmp may be using up a lot of space in your
When I was looking around the
/var on my Fedora Core 5 scratch
machine to see where all the disk space was being used as part of
the last entry, I was startled to discover
/var/log/btmp was a 100M file (and by far the largest thing in
/var/log). This was a surprise to me, because I had never heard of the
It turns out that
btmp is used to record bad logins (some of you
are already wincing), just like
/var/log/wtmp records good ones. My
scratch machine is on the Internet, with an unscreened SSH daemon,
and thus just like everyone else sees a constant flux of brute
force ssh login attempts. Nothing seems to age
/var/log/btmp, so it has been busily accumulating a pile of entries
every day since the machine was first brought up on April 28th.
(If you are curious, the
lastb command will read and dump the file.
Or you can just use '
last -f /var/log/btmp'. You'll want to pipe it
through the pager of your choice.)
Somewhat to my displeasure,
btmp records even login attempts to
nonexistent user names. Logging nonexistent usernames is a moderate
security exposure, because people do occasionally accidentally enter
their password as their username; if you log unknown user names, you're
sooner or later going to have a plaintext log of someone's password.
/var/log/btmp will apparently shut the whole thing down.
In this day and age, I suspect that there's no particular point in
logging bad logins on any machine on the Internet, unless you are
interested in generating some statistics; the noise is likely to
overwhelm any possible signal.
My current view of Linux system filesystem sizes
Here's my current thoughts on how big system filesystems (or partitions, depending on what you like to call them) should be for new systems. This assumes that you have lots of disk space to play around with.
Also, note that I run non stripped down Fedora Core systems; in fact, I have a tropism towards installing most everything in sight, just so I have its documentation handy in case I need to poke at it. A stripped down system would fit in much, much less.
One of my big principles of system partitions is that I want them to be big enough that they won't run out of space during the inevitable operating system upgrades over the next five year to ten years. Painful, bitter experience has taught me that distributions only get bigger, sometimes lots bigger; given today's very big disks, a large safety margin is very cheap insurance.
||5G||The big space eater here is
||512M||This probably only really needs to be 100M or so, but I am nervous about sudden space expansions and future versions of Fedora Core deciding on random (but large) minimum space requirements here.|
||20G||Lack of space in
||5G||This is either vast overkill or not enough,
depending on what you are doing in
|swap||2G||This much is probably overkill for my machines, but insurance is cheap. It also insures against random (but large) minimum swap space requirements in future versions of the Fedora Core installer, which have happened before.|
For scale, current disk usage on a more or less stock Fedora Core 5 AMD 64 machine, with a lot of things installed, is about:
/var includes 642M of
/var/lib/mach, which has a relatively
complete 32-bit Fedora Core 5 development environment plus some
extra bits, and 335M of
/var/cache/mach, which is presumably related
(On the other hand, this mach install neatly demonstrates that you can get Fedora Core 5 into much less space than I usually give it.)