Sorry to beat a dead horse, but what I thought was a harmless error took down
Exim last night. I've posted previously (as have others) about this error in
my Exim paniclog:
2004-02-10 01:06:04 1AqTqC-00083u-Rd string_sprintf expansion was longer than
8192
It happened about once per minute. It was caused by installing all these great
new rulesets (Tripwire, Chickenpox, etc.). These sets are similar in that
they are a large collection of small rules which combine to make an effective
set. The problem is that each small rule outputs its own entry in the SA
report. After hitting a bazillion little rules, the report swells to a huge
size, and when inserted into email headers, generates the above error.
I was just ignoring the errors for the time being, figuring those emails were
probably spam anyway. What I didn't know is that every time that error hit,
Exiscan didn't clean up that message's directory in the scan dir
(/var/spool/exim/scan on my system). Eventually the directory hit the max
filesystem limit for number of files/dirs and Exim started rejecting incoming
mail with "temporary local error".
I realize that's Exiscan's fault, but I think it drives home my contention
that reporting every little hit on these huge rulesets is a Bad Thing(tm). As
Chris Santerre said today in another thread, this has been a period of many
new rules and and heavy rule development. As these new rules show up, I'm
sure we'll see reports get longer still. Surely there is a point at which a
reasonable limit must be placed, especially for the
"Tripwire"/"Chickenpox"-type rules. Additionally, the output from these types
of rules is very verbose, and while interesting, most times I don't really
care _exactly_ which strings of random crap it's hit on this particular
message. :) I'd just like to know it's doing the job and probably how many
total rules and points have been hit for each set.
I'm not sure if SA includes that kind of functionality, but IMHO, it would be
a good thing to have. Another nice feature would be a configurable cap on
report size.
In the mean time I've altered my report to be smaller. However, I consider
that a work-around, not a fix. The error could still happen with my more
terse report, if enough rules hit.
PS:
In creating my new report, I'm trying to use _TESTSSCORES()_, but I'd like a
newline as the delimiter. I've tried \n and ^M, but \n is just printed and ^M
doesn't seem to have an effect at all. Any ideas?
--
Matt
Systems Administrator
Local Access Communications
360.330.5535
Exim last night. I've posted previously (as have others) about this error in
my Exim paniclog:
2004-02-10 01:06:04 1AqTqC-00083u-Rd string_sprintf expansion was longer than
8192
It happened about once per minute. It was caused by installing all these great
new rulesets (Tripwire, Chickenpox, etc.). These sets are similar in that
they are a large collection of small rules which combine to make an effective
set. The problem is that each small rule outputs its own entry in the SA
report. After hitting a bazillion little rules, the report swells to a huge
size, and when inserted into email headers, generates the above error.
I was just ignoring the errors for the time being, figuring those emails were
probably spam anyway. What I didn't know is that every time that error hit,
Exiscan didn't clean up that message's directory in the scan dir
(/var/spool/exim/scan on my system). Eventually the directory hit the max
filesystem limit for number of files/dirs and Exim started rejecting incoming
mail with "temporary local error".
I realize that's Exiscan's fault, but I think it drives home my contention
that reporting every little hit on these huge rulesets is a Bad Thing(tm). As
Chris Santerre said today in another thread, this has been a period of many
new rules and and heavy rule development. As these new rules show up, I'm
sure we'll see reports get longer still. Surely there is a point at which a
reasonable limit must be placed, especially for the
"Tripwire"/"Chickenpox"-type rules. Additionally, the output from these types
of rules is very verbose, and while interesting, most times I don't really
care _exactly_ which strings of random crap it's hit on this particular
message. :) I'd just like to know it's doing the job and probably how many
total rules and points have been hit for each set.
I'm not sure if SA includes that kind of functionality, but IMHO, it would be
a good thing to have. Another nice feature would be a configurable cap on
report size.
In the mean time I've altered my report to be smaller. However, I consider
that a work-around, not a fix. The error could still happen with my more
terse report, if enough rules hit.
PS:
In creating my new report, I'm trying to use _TESTSSCORES()_, but I'd like a
newline as the delimiter. I've tried \n and ^M, but \n is just printed and ^M
doesn't seem to have an effect at all. Any ideas?
--
Matt
Systems Administrator
Local Access Communications
360.330.5535