Bug 503852
| Summary: | fail2ban fails to ban because of rsyslog | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan Kamens <jik> | ||||
| Component: | fail2ban | Assignee: | Axel Thimm <axel.thimm> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 11 | CC: | drees76, theinric, thoger | ||||
| Target Milestone: | --- | Keywords: | Patch | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 0.8.4-23.fc11 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-09-04 04:03:13 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: |
|
||||||
|
Description
Jonathan Kamens
2009-06-03 01:24:13 UTC
Created attachment 346338 [details]
patch to check inode as well a first line for log rotation
Adding rsyslog maintainer to CC, as it might be worth checking if this should not be addressed in rsyslog too. Doing a quick test, it seems that rsyslog restart message is written time-stamped to messages, but with no timestamp to secure: # tail -n1 /var/log/messages /var/log/secure ==> /var/log/messages <== Jun 3 08:48:47 localhost rsyslogd: [origin software="rsyslogd" swVersion="3.21.10" x-pid="1711" x-info="http://www.rsyslog.com"] restart ==> /var/log/secure <== rsyslogd: [origin software="rsyslogd" swVersion="3.21.10" x-pid="1711" x-info="http://www.rsyslog.com"] restart The message written to /var/log/secure is actually a bug in rsyslog - it shouldn't be there at all. This will be fixed in the next update. A workaround to get rid of the message in the current version is to add this to your configuration file: $ErrorMessagesToStderr off By default, all messages written to files contain a time-stamp. This can be changed in the configuration, though. This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Any movement on this bug? I don't see a relevant corresponding rsyslog bug. It's affecting me on both F10 and F11. I think it'd be nice to have the bug fixed both ways (the inode patch in fail2ban plus fix the error message in rsyslog on restart). I apologize, it's not affecting me on F10, only on F11. New rsyslog release which should fix its part of the problem is available from updates-testing. I do not see what information you are asking me for. (In reply to comment #8) > New rsyslog release which should fix its part of the problem is available from > updates-testing. (In reply to comment #9) > I do not see what information you are asking me for. Sorry, I thought the rsyslog fix is all there was needed, isn't it? (In reply to comment #0) > More generally, the assumption that all log file lines are timestamped and > therefore that the first line of the new log file will always differ from the > first line of the old one is invalid. Other than the bug in rsyslog, could you give another example? Thanks! I do not know of any other log files on my system that are monitored by logrotate and affect this problem. But I really don't see how that's particularly relevant. I don't use all packages that have logrotated log files, so there may be one I know about. And someone could configure logrotate to monitor an arbitrary file that isn't in an RPM maintained by Fedora, or a new Fedora logrotated file could be added that has this problem at any point in the future. The bug in logrotate that cause this problem has been identified and is obvious from examining the code, and I've provided a patch. Why not just fix it? Doh! GOt confused. Of course I meant fail2ban, not logrotate. I've reported this issue to the upstream maintainer of fail2ban, so you can CLOSED / UPSTREAM it if you wish. jik (In reply to comment #11) > [...explanation on why the patch is necessary...] > The bug in logrotate that cause this problem has been identified and is obvious > from examining the code, and I've provided a patch. Why not just fix it? OK, thanks for explaining, it needs fixing, of course. (In reply to comment #13) > I've reported this issue to the upstream maintainer of fail2ban, so you can > CLOSED / UPSTREAM it if you wish. I prefer to fix it in the package until the next upstream release does so itself, thanks for the patch and expect a fixed package soon. For reference could you post the bug's URL you filed upstream here as well (maybe under the URL field)? Thanks! I don't think the author of fail2ban uses a publicly accessible bug-tracking system. At least, I couldn't find it. I sent him an email message. jik fail2ban-0.8.3-21.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/fail2ban-0.8.3-21.fc10 fail2ban-0.8.3-21.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/fail2ban-0.8.3-21.fc11 fail2ban-0.8.3-21.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update fail2ban'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-9094 fail2ban-0.8.3-21.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update fail2ban'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9103 (In reply to comment #15) > I don't think the author of fail2ban uses a publicly accessible bug-tracking > system. At least, I couldn't find it. I sent him an email message. He uses sourceforge resources, so you can file it there, if you like. I would recommend doing so, because currently fail2ban's development has stalled even with people looking for forking it and having the patches all in one place will make managing a new release easier. LOL. Turns out I did that in June and forgot I'd done it: https://sourceforge.net/tracker/?func=detail&aid=2800279&group_id=121032&atid=689044 fail2ban-0.8.3-22.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. fail2ban-0.8.4-23.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/fail2ban-0.8.4-23.fc11 fail2ban-0.8.4-23.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/fail2ban-0.8.4-23.fc10 fail2ban-0.8.4-23.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. fail2ban-0.8.4-23.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. |