Menu
▾
▴
#71 Change the mechanism for ignorecommand to use STDOUT instead of exit codes.
I know this has been brought up before, but the best searching I've managed has yet to turn up anything approching an explanation.
So I'm asking again... why does ignorecommand rely on exit codes? Why can't it use STDOUT instead? I understand the need to have errors logged when they occur... but fail2ban currently logs successful execution of scripts as errors and, in doing so, clutters up the log files with meaningless whitenoise. The end result of this is that if an actual error were to occur... it would be far more likely to go unnoticed.
It seems to me it would be a simple thing to have fail2ban's ignorecommand feature watch stdout for it's responce instead. 0 (or any "falsy" value) for success and 1 (or any "truthy" value) for failure... but to stdout... not as an exit code. This leaves exit codes available to be used to signal an error condition without cluttering up the logs when there really isn't one.
It's also worth noting that keeping the falsy=success / truthy=failure relationship solves for commands called in scripts erroniously printing non-relevant info to STDOUT. This way to get the ignorecommand feature to work the script writer has to actively sanitize the output of his script (not unlike cron scripts) to ensure a falsy value is all that is returned when he wants a host/ip/net ignored by fail2ban. Another way to solve for this would be to require the success/failure output to be exact... and all other lines printed to stdout to be ignored.
I was going to post an example log... but just the errors produced from this in a single day was more than four megabytes so Pastebin refused it. I'll say that agian... four megabytes of raw text... in just (not-really-)errors... from one ignorecommand script. 33,197 lines. What's more absurd than absurd? I don't know.
I also have no idea if this log contains any other kinds of errors. Because I'm not going to try to read four megabytes of text and I shouldn't have to rely on grep just to find the real errors. Real errors should all but jump out at me when I look at a log. Not be lost in a haystack of not-really-errors errors.