Update the check_fail2ban script #157
Conversation
…ios specs (like status, output, perfdata, help...). Also add a README which includes the content of f2ban.txt (which is now removed)
| # #################################################################### | ||
|
|
||
| # #################################################################### | ||
| # GPL v3 |
There was a problem hiding this comment.
minor: fail2ban is still under GPL >= 2, so it would be better if this piece also allows GPL v2, or do you have specific reservations?
There was a problem hiding this comment.
Good point!
Actually I left the copyright of my previous script (some kind of legacy :) ), but I have no reservation to change it in GPL v2.
At this point, I don't know the best practice: do I have to resend a new PR with the previous commits + a new one where I change the license?
There was a problem hiding this comment.
just commit to the same branch and push -- usually that commit automagically gets added to the PR. If not -- let us know
There was a problem hiding this comment.
(I just pushed the version with a GPLv2 licence, hope it will be ok for you :) )
|
Changes Unknown when pulling 4473603 on labynocle:master into * on fail2ban:master*. |
|
BTW is there a native nagios way to configure invocation of this script (eg env variables?) I thought to ask myself and then Fabian Wenk also brought up similar ideas on the list: it is possible to run fail2ban in non-root mode, and we have such mode of operation available. So for ideal situation, it would be nice to disable sudo invocation... or may be provide the user to sudo to? |
|
sudo is not mandatory actually. So it's not necessary but usually the nagios user have only very restricted permission. If you want I can update the README file to explain why you could have to use a sudo configuration, just let me know. :) |
|
I think I just misunderstood originally where I saw "sudo" ;) so it all looks good to me. I just hope that I (or someone else) gives it a try with a working nagios setup before we merge it You might be interested to look at (or may be even refer in README?) one of the ways how fail2ban could be used for banning without root access: https://github.com/fail2ban/fail2ban/blob/HEAD/doc/run-rootless.txt |
| exit $ERRORS{"UNKNOWN"}; | ||
| } | ||
|
|
||
| if(! -x $fail2ban_client_path) { |
There was a problem hiding this comment.
I will merge in a sec (if do not find anything else) but would be kind to extend check for if fail2ban-client is present there at all ;) ?
There was a problem hiding this comment.
Good point!
I can add it and it will become more easier for user to debug :)
|
yes -- if you could unify print statements appearance/functionality -- that would be great Also -- I think it would be even better if you could craft a unittest which would basically just
if we had such a unittest -- we could have some assurance that things work as they should! we might need to have perl installed for tests, but well -- that shouldn't be difficult ;) |
|
Ok let me see what can I do with it! :) |
Replace the check_fail2ban script by a new one which respects the Nagios specs (like status, output, perfdata, help...).
Also add a README which includes the content of f2ban.txt (which is now removed)
(PR according to a previous discussion)