- setup process generates `build/fail2ban.service` from `files/fail2ban.service.in` using distribution related bin-path;
- bug-fixing by running setup with option `--dry-run` (note: specify option `--dry-run` before `install`, like `python setup.py --dry-run install`);
- test cases extended to cover dry-run.
The fail2ban server can take several seconds to shut down. This can
make Gentoo's start-stop-service time out and decide that stopping has
failed, even if it actually succeeds a few seconds later.
The default timeout for start-stop-service if --retry is not specified
appears to be 5 seconds. Increase that to 30 seconds to be sure that if
fail2ban-server is going to be able to stop, it has time to do so.
- starting service in normal mode (without forking)
- does not restart if service exited normally (exit-code 0, e.g. stopped via fail2ban-client)
- does not restart if service can not start (exit-code 255, e.g. wrong configuration, etc.)
- service can be additionally started/stopped with commands (fail2ban-client, fail2ban-server)
Currently, if fail2ban is killed (or crashes), its status will be
reported by '/etc/init.d/fail2ban status' as 'running' even though it
is not. Attempting to restart the service also fails, because Gentoo
unsuccessfully tries to stop the service.
By using start-stop-daemon and providing a pidfile, Gentoo will
instead report the status as 'crashed' and allow the service to be
restarted as normal.
These fixes are pretty pedantic, but they do simplify the script a
little.
* Checking the existence of a file/directory before creating/deleting
it adds complexity and raciness. There are better options.
* mkdir -p does the job of making sure a directory exists. (It only
fails if there's a filesystem error or something.)
* Likewise, rm -f doesn't fail if the file doesn't exist.
* rm -r isn't neccessary because the socket shouldn't be a directory.
(If it is for some reason, that should be an error.)
As a useful side effect, prevents "Unable to contact server. Is it
running?" mails from cron when fail2ban hasn't been (intentionally)
running nor thus logging anything either.
(a) use static-network-up, since it is more generic than the started networking event
(b) do not hook into network deconfiguration to speed up shutdown
(c) expect fork, per the use of the "-f" option
(d) use a variable for the run directory to make changing it simpler
(e) handle the situation of a left over socket file
(f) use the -f option to be able to track the PID
No longer directly exec the server, do not remove the PID file because it is unnecessary to do so. No longer respawns because Upstart can not track the process with the starter command.
Allows perf data from all jails to enable pnp4nagios to display a chart per jail when run with the command:
check_fail2ban -p -w 1 -c 5 -P /usr/bin/fail2ban-client
sample output:
CHECK FAIL2BAN ACTIVITY - CRITICAL - 9 detected jails with 5 current banned IP(s) | apache-noscript.currentBannedIP=0 sendmail.currentBannedIP=0 postfix.currentBannedIP=0 ssh-probe.currentBannedIP=3 ssh-ddos.currentBannedIP=0 apache-multiport.currentBannedIP=0 apache.currentBannedIP=0 ssh.currentBannedIP=2 apache-overflows.currentBannedIP=0
sebres