Bug 460993
| Summary: | logwatch doesn't match some postfix log lines (status code not parsed) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Greg Wickham <greg> |
| Component: | logwatch | Assignee: | Ivana Varekova <varekova> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.2 | CC: | azelinka, flint42, ovasik, ralph |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-01-13 12:19:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
Created attachment 315705 [details]
Found several more instances where the rules don't match valid log entries.
The following lines weren't matched either Attached second patch addresses these.
NOQUEUE: reject: RCPT from unknown[61.49.240.117]: 554 5.7.1
<rypxtnzjbvmo45>: Relay access denied; from=<w535969>
to=<rypxtnzjbvmo45> proto=SMTP helo=<a-xha8s0sq9tn0y>
74BE41BBD1C: to=<user>, relay=local, delay=3.6, delays=3.6/0.01/0/0,
dsn=2.0.0, status=sent (delivered to maildir)
Note - both patches were prepared on different systems so aren't combined. Comment on attachment 315705 [details]
Found several more instances where the rules don't match valid log entries.
wasn't made against 7.3-6.el5
Created attachment 315706 [details]
patch against logwatch-7.3-6-el5 to match postfix
Lines with an included status code weren't matched. Suggested fixup is:
} elsif (($User) = ($ThisLine =~ /^[a-zA-Z0-9]+: reject: RCPT from (?:[^
]*): [0-9]+ (?:[0-9]\.[0-9]\.[0-9] )?<([^ ]*)>:(?:[^:]+: )?User unknown in(?:
\w+)+ table/)) {
The inclusion of (?:[0-9]\.[0-9]\.[0-9] ) optionally matching the status code
fixes the issue.
Also, status code again affecting matching of relay denied:
NOQUEUE: reject: RCPT from unknown[61.49.240.117]: 554 5.7.1
<rypxtnzjbvmo45>: Relay access denied; from=<w535969>
to=<rypxtnzjbvmo45> proto=SMTP helo=<a-xha8s0sq9tn0y>
i'v encounted some similar problems like : NOQUEUE: filter: RCPT from n52c.bullet.mail.sp1.yahoo.com[66.163.168.186]: <n52c.bullet.mail.sp1.yahoo.com[66.163.168.186]>: Client host triggers FILTER smtp-dspam:[127.0.0.1]:10027 and other things like NOQUEUE: reject: RCPT from unknown[212.165.149.42]: 554 5.7.1 Service unavailable; Client host [212.165.149.42] blocked using cbl.abuseat.org; Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=212.165.149.42; from=<evillestr> to=<xxxxxxxxxx> proto=ESMTP helo=<212-165-149-42.reverse.newskies.net> i got thousand of line like that everyday. what i did is to update the /usr/share/logwatch/scripts/services/postfix and /usr/share/logwatch/default.conf/services/postfix.conf with the latest version from http://www.mikecappella.com/logwatch/ (http://www.mikecappella.com/logwatch/release/postfix-logwatch-1.38.01.tgz). I edited /usr/share/logwatch/scripts/services/postfix to remove the first line ( #!/usr/bin/perl -T). now, i have a good output. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0033.html |
Created attachment 315621 [details] patch for /usr/share/logwatch/scripts/services/postfix In /usr/share/logwatch/scripts/services/postfix line 221 lines with an included status code aren't matched. Suggested fixup is: } elsif (($User) = ($ThisLine =~ /^[a-zA-Z0-9]+: reject: RCPT from (?:[^ ]*): [0-9]+ (?:[0-9]\.[0-9]\.[0-9] )?<([^ ]*)>:(?:[^:]+: )?User unknown in(?: \w+)+ table/)) { The inclusion of (?:[0-9]\.[0-9]\.[0-9] ) optionally matching the status code fixes the issue. This was consistently reproduced with logwatch-7.3-6.el5 Attached is a patch.