Re: spamassassin in my procmailrc fills up mail.log

I'm guilty - no substantiative procmail content here, just ramblings about 
hardware, logging, and backups.
At 13:01 2004-10-31 +0100, Ruud H.G. van Tol wrote:

> Orthogonally: if you keep your 'rotated logs' (I mean the old logs)
> on a separate disk, than that disk only has to spin once a week,
> which will keep even an IDE-disk alive for years.
I archive the old (>2 months or so) logs off to a central host from which I 
burn archives (including other stuff, such as a copy of all my email 
folders which are in a set of monthly rotated files) to optical media (DVDs 
and CDs), then upon verification, I purge the original magnetic copies so 
that they're not continuing to consume space on the cyclic magnetic 
backups.  Not much concern about the log archive drive taking a dump.  Of 
course, RAID generally handles single drive failure concerns anyway.  Yea, 
all of my logs to the beginning of time are not sitting on one disc, but I 
generally don't need access to all the logs simultaniously, and if I'm 
starting with a target date for an event, locating the disc which those 
(compressed) logs reside on is easy enough.
The main system HD is still the one you need to fret about failing 
(certainly if you're not running a RAID configuration), and the un-archived 
"live" logs are still at risk of being lost if that occurs.  If you're 
running backups (as you should), then the old logs are preserved on the 
backup anyway, which largely negates the need for a separate drive for them 
(which is a device still subject to failure, so it should be backed up or 
archived anyway, even if not nightly or whatever your backup frequency 
is).  Beyond a couple of months, I generally don't have a large need to 
refer to logs - I like having them because they're useful to refer to when 
diagnosing an oddity (and for legal purposes), but I don't often need to go 
digging back beyond about 2 months (or even 3, which provides a nice "90 
days" window), which is why that's about all I keep on the hosts themselves.
I also don't use IDE drives for server applications - actually, only just a 
couple of years ago I went to IDE for a new workstation (which still sports 
SCSI for a variety of peripherals), and I use some older IDE drives in 
caddies for a test workstation (multiple OS loads I can swap in and 
out).  An ISP I do work for does use IDE in a hotswap tray for offsite 
network backups, because the media is so inexpensive (go price DLT media 
some time, and keep in mind the need to be around to swap media when you 
exceed the drive capacity).  In this case though, the drives are not 
serving constant duty, are not subject to multi process thrashing, and 
don't have a large number of individual files to thrash either.
> My communication server here is a very old Linux-machine (Pentium 75 
> without CPU-fan) that has been running for ages.
Use what works (even IDE <g>).  Being able to keep older hardware in 
operation because you're running an OS and tools (such as procmail) that do 
not make unreasonable demands for base-level hardware doesn't 
hurt.  There's a widespread mentality of "gee, cpu/ram/disk is so cheap, 
just buy a new system," but when you've got many hosts, that whole upgrade 
at every opportunity approach gets (very) costly and time consuming, not to 
mention extremely wasteful.  Environmentcal concerns about power 
consumption are a riot too - the energy and raw materials expended building 
new parts could keep an older machine running for quite a while, nevermind 
the toxic materials used in the production.  Much the same applies to cars 
- the important thing is to properly maintain old one, including keeping it 
in tune (and, unless I'm sending my car off to the crusher, it isn't as if 
it's being taken out of service - I'd be selling it to someone else who 
would continue to be driving it).
That's not to say I don't appreciate running fast hardware (or cars <g>), 
but every server I deal with isn't upgraded all the time, and I'll admit 
I'm managing a few which wouldn't make much of a windows desktop platform 
these days (raise your hand if you're running a recent windoze on a sub-GHz 
host).  Thankfully, I'm not running windows on 'em though, so this isn't a 
concern.
I've got a couple of 486-100 (or even 66MHz, I can't remember), low profile 
systems with a couple of NIC cards in them and bejeezusly small old IDE HDs 
(sub-200MB), with a load of FreeSCO <http://www.freesco.org/> on them 
(which would run from floppy, but I've tossed it on the tiny HD since it's 
faster and environmentally sealed unlike the heads of a floppy drive) for 
use as isolation NAT routers when I'm doing some testing on a 
workbench.  For that purpose, a stronger CPU would just be at idle more 
often when the systems are powered up, and generally, they're not.  Yea, a 
linksys NAT device is cheap enough and would serve much the same purpose, 
but I already had this hardware, and the software is so much more configurable.
> The IDE-harddisk was already old when put in. It runs fetchmail every 5 
> minutes and sleeps in between, so I called it sleepy.
FTR, there are some camps that recognize that starting a motor is the most 
stressful thing a motor can do - maintaining a fixed-rate spin is both 
electrically and physically less stressful than spinning it up from a dead 
stop.  Almost all HDs eventually suffer from "stiction" - a condition where 
the motor will eventually fail to be able to spin up because of bearing 
problems.  Granted, not running some drive that spins at 10K or 15K RPM 
24/7 is going to generate far less heat and wear on the bearings, but 
frequent starts are going to take their toll - it is when the bearings get 
the most torque and they're subjected to the most variation.
Anyway, that's enough from me on hardware - it's all very OT for procmail.

---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.


____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail