Bug#318731: [Logcheck-devel] Bug#318731: spamd rule does not work
[EMAIL PROTECTED](Jamie L. Penman-Smithson) 18.07.05 14:38
Once upon a time "Jamie L. Penman-Smithson " shaped the electrons to say...
>On Sun, 2005-07-17 at 20:19 +0200, Rainer Zocholl wrote:
>> [EMAIL PROTECTED](Jamie L. Penman-Smithson) 17.07.05 13:31
>>>since all log messages have trailing
>>>spaces stripped before they are processed, your rule will never
>>>match anything.
>>
>> Sorry, i wasn't aware of that and throught something wiered inside
>> logcheck. That's why i file a bug.
>>
>> Too i was not warned that testing rules with "egrep -f"
>> is not recommandable/is senseless, because logcheck modifies the
>> logfile reads.
>There's a paragraph in README.logcheck-database:
Yes, i found that sentence meanwhile.
Previously i stopped reading because the part above did not
look very interessing and i thought that were all the same theme,
because there "suddenly" where no subtitles.
That's always the problem between the "knowing (deverloper)" and
the "just only user" to fidn teh right way of documenting.
(Logcheck documentation is really good, compared to several other OOS).
The developer knows that it is there, but the user have to read
tons and tons of text and try to weight what'S relevant and what can
be omitted/neglected..
A subtitle like
Testing Your New Rules
==
before that would have eaesd reading a lot!
>| To test new rules, you can grep your log file, and remove trailing
>| space with something like this:
>|
>| sed -e 's/[[:space:]]*$//' /var/log/syslog | egrep \
>| '^\w{3} [ :0-9]{11} oempc wwwoffled\[[0-9]+\]: \
>| WWWOFFLE (On|Off)line\.$'
>|
>| If the log line is displayed, then your regex works.
>> I don't want "littering" logcheck mails with messages i
>> can't change. That's to dangerous as some day no one will
>> take a look into the file.
>Then find out which users config is causing the problem?
Yes. And as long as i am searching, i wanted to suppress the message,
not to oversee important notes.
>If your users config files are in the same directory, something like
>egrep -H " RBL" * might find the culprit.
>Or "find / -name foobar.cf -exec grep -H " RBL" \{\} \;"
I tried searching "RBL", but, qwww, did not find.
Maybe it was too late in that evening?
>That'll only work if your config files have identical names, if they
>are named after the user, you could try something similar to:
>cat /etc/passwd | egrep -v "^[[:alnum:]]+:x:[0-9]{1,2}:.*$" | cut -f 1
>-d ":" > .users && for i in $(cat .users); do find /foo -name $i.cf
>-exec grep -H " RBL" \{\} \;; done ; rm .users
I would not hesitate to run a grep over the entire disk.
The disk is only 80GB, so let it run 1h or maybe 2h.
It's a computer, it's his job, isn't it?
>> Which words did you use?
>Argument "RBL" "isn't numeric in addition"
I did too. Funny, or not so funny...
Sometimes i have the feeling googles knows who is searching ;-)
>> I tried "Argument isn't numeric in addition" etc. with spamd and
>> without and only see that others asking the same.
>You may or may not already know, but placing quotation marks around
>words causes Google to search for the entire phrase[1], rather than
>occurrences of the individual words.
Yes, i added the """ only here.
I too serach with "RBL" like you did.
Very wiered, tah i did not get any hit into the bugzilla of
spamassasin.
>The first result from that is relevant to your problem, as are most of
>the other results from the first page.
>[1] http://www.google.co.uk/help/basics.html#phrases
*~*!
My google jumps to "google.de"...regardless which language i choose.
And it's known that google is censoring the result country specific.
Maybe the censorment detect "bad words" in your URL?
But we are going offtopic, and the problem is solved!
Thanks a lot!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318731: [Logcheck-devel] Bug#318731: spamd rule does not work
On Sun, 2005-07-17 at 20:19 +0200, Rainer Zocholl wrote:
> [EMAIL PROTECTED](Jamie L. Penman-Smithson) 17.07.05 13:31
> >since all log messages have trailing
> >spaces stripped before they are processed, your rule will never match
> >anything.
>
> Sorry, i wasn't aware of that and throught something wiered inside logcheck.
> That's why i file a bug.
>
> Too i was not warned that testing rules with "egrep -f"
> is not recommandable/is senseless, because logcheck modifies the logfile
> reads.
There's a paragraph in README.logcheck-database:
| To test new rules, you can grep your log file, and remove trailing
| space with something like this:
|
| sed -e 's/[[:space:]]*$//' /var/log/syslog | egrep \
| '^\w{3} [ :0-9]{11} oempc wwwoffled\[[0-9]+\]: \
| WWWOFFLE (On|Off)line\.$'
|
| If the log line is displayed, then your regex works.
> >Finally, this message indicates a _PROBLEM_ with your spamassassin
> >configuration, ignoring it _will not_ make the problem disappear.
>
> I assume it's problem in some users config...
>
> I don't want "littering" logcheck mails with messages i
> can't change. That's to dangerous as some day no one will
> take a look into the file.
Then find out which users config is causing the problem?
If your users config files are in the same directory, something like
egrep -H " RBL" * might find the culprit. Or "find / -name foobar.cf
-exec grep -H " RBL" \{\} \;"
That'll only work if your config files have identical names, if they are
named after the user, you could try something similar to:
cat /etc/passwd | egrep -v "^[[:alnum:]]+:x:[0-9]{1,2}:.*$" | cut -f 1
-d ":" > .users && for i in $(cat .users); do find /foo -name $i.cf
-exec grep -H " RBL" \{\} \;; done ; rm .users
> >Ignoring errors is not a good strategy. See bug #3853 in SA's bugzilla
> >(which I found within 5 seconds using Google)
>
> I have several(!) times tried google and did not find any useful hints
> or solution.
>
> Which words did you use?
Argument "RBL" "isn't numeric in addition"
> I tried "Argument isn't numeric in addition" etc. with spamd and without
> and only see that others asking the same.
You may or may not already know, but placing quotation marks around
words causes Google to search for the entire phrase[1], rather than
occurrences of the individual words.
The first result from that is relevant to your problem, as are most of
the other results from the first page.
[1] http://www.google.co.uk/help/basics.html#phrases
--
-Jamie L. Penman-Smithson <[EMAIL PROTECTED]>
t: +44 1273 424795; f: +44 1273 424795
PGP: C0A7 955E EED6 A309 23D7 863B C76A 26A3 F0DC FCA8
never send mail to: [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Bug#318731: [Logcheck-devel] Bug#318731: spamd rule does not work
[EMAIL PROTECTED](Jamie L. Penman-Smithson) 17.07.05 13:31
>Your rule has a trailing space,
i know that. Without it did not work either.
>since all log messages have trailing
>spaces stripped before they are processed, your rule will never match
>anything.
Sorry, i wasn't aware of that and throught something wiered inside logcheck.
That's why i file a bug.
Too i was not warned that testing rules with "egrep -f"
is not recommandable/is senseless, because logcheck modifies the logfile reads.
>Removing the trailing space should fix the problem:
>^\w{3} [ :0-9]{11} [._[:alnum:]-]+ spamd\[[0-9]+\]: Argument \"RBL\"
>isn't numeric in addition \(\+\)
>at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 244.$
Yes! I wonder why it did not work some days before...
>Finally, this message indicates a _PROBLEM_ with your spamassassin
>configuration, ignoring it _will not_ make the problem disappear.
I assume it's problem in some users config...
I don't want "littering" logcheck mails with messages i
can't change. That's to dangerous as some day no one will
take a look into the file.
>Ignoring errors is not a good strategy. See bug #3853 in SA's bugzilla
>(which I found within 5 seconds using Google)
I have several(!) times tried google and did not find any useful hints
or solution.
Which words did you use?
I tried "Argument isn't numeric in addition" etc. with spamd and without
and only see that others asking the same.
http://www2.list.logwatch.org:81/pipermail/logwatch/2004-February/000459.html
no access..
http://www.dclug.org.uk/archive/2004/09/msg00214.html
no answer
http://www.mailarchives.org/list/spam-assassin/msg/2004/11717
no answer
etc.
The error is very common.
>which was the result of misconfiguration:
>> --- Additional Comments From [EMAIL PROTECTED] 2004-10-01
>> 10:05 ---
>> This type of issue has always been something like:
>>
>> score FOO_RULE RBL 3
>>
>> somewhere in the configuration files. Could be in any of
>> the /etc/mail/spamassassin/*.cf files, or in
>> user_prefs, or anywhere your SA installation gets configuration data
>> from.
>Fix the problem in your SA configuration.
"find the user with the wrong config!" ;-)
Rainer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318731: [Logcheck-devel] Bug#318731: spamd rule does not work
package logcheck
merge 317642 318731
tags 318731 wontfix
thanks
On Sun, 2005-07-17 at 12:33 +0200, Rainer Zocholl wrote:
> Package: logcheck
> Version: "most recent stable"
Use apt to find the version number, "most recent stable" is pretty
useless.
Don't open multiple bug reports about the same issue. There is already
#317642. This isn't a problem with logcheck, it's a problem with _your
own_ rules, therefore this isn't a bug and the BTS isn't really the best
place, there's the logcheck-users mailing list which would be better.
Read README.logcheck-database, it explains, in detail, how to write
rules and how to test them correctly.
> i can't block the spamd warning.
>
> Why?
Your rule has a trailing space, since all log messages have trailing
spaces stripped before they are processed, your rule will never match
anything. Removing the trailing space should fix the problem:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ spamd\[[0-9]+\]: Argument \"RBL\"
isn't numeric in addition \(\+\)
at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 244.$
Finally, this message indicates a _PROBLEM_ with your spamassassin
configuration, ignoring it _will not_ make the problem disappear.
Ignoring errors is not a good strategy. See bug #3853 in SA's bugzilla
(which I found within 5 seconds using Google) which was the result of
misconfiguration:
> --- Additional Comments From [EMAIL PROTECTED] 2004-10-01 10:05
> ---
> This type of issue has always been something like:
>
> score FOO_RULE RBL 3
>
> somewhere in the configuration files. Could be in any of
> the /etc/mail/spamassassin/*.cf files, or in
> user_prefs, or anywhere your SA installation gets configuration data
> from.
Fix the problem in your SA configuration.
--
-Jamie L. Penman-Smithson <[EMAIL PROTECTED]>
t: +44 1273 424795; f: +44 1273 424795
PGP: C0A7 955E EED6 A309 23D7 863B C76A 26A3 F0DC FCA8
never send mail to: [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
