don't call process file inside of server thread calling of addLogPath (always retard it as pending event);
ensure to wake-up as soon as possible to process pending events (e. g. if file gets added).
- reject: BDAT/DATA from (gh-2927)
- (since regex is more precise now) token selector changed to `[A-Z]{4}`, e. g. no matter what a command is supplied now (RCPT, EHLO, VRFY, DATA, BDAT or something else)
- matches "Command rejected" and "Data command rejected" now
- RCPT from unknown, 504 5.5.2, need fully-qualified hostname, gh-2995
- 550 5.7.25 Client host rejected, gh-2996
review combining several regex to single one
This commit adds a new function checkconfig() to the OpenRC service
script. All it does is run the server with the "--test" flag in
addition to the usual command-line arguments.
The new command is not user-facing, but lets us avoid restarting the
daemon with a broken config. That helps when the user changes his
configuration while the daemon is running, and then tries to restart()
not knowing that the new config is broken. A priori, we would stop the
daemon and then the error would only become visible when the subsequent
start() command failed. Refusing to stop() with a broken configuration
is a nicer thing to do.
OpenRC functions will exit with the return code from the last command
by default, so there's no need for the "|| return 1" in our
single-line start_pre() phase.
The description of the "reload" OpenRC command just said that it would
reload the configuration, which is true but not totally helpful. This
commit updates it to mention that your existing bans won't be dropped,
in contrast with the "restart" command that does drop your bans.
This commit renames fail2ban-openrc.init to fail2ban-openrc.init.in,
and replaces the hard-coded value "/usr/bin" with "@BINDIR@"
therein. At build-time, setup.py will replace that string with the
correct value, and rename the file (without the ".in" suffix).
This mimics the procedure done for "fail2ban-service.in" entirely.
The socket location needs to be set in the service script for the same
reason that the PID file location does: because the service script is
taking responsibility for ensuring that its parent directory exists
and has the correct permissions. We can't do that if the end user is
allowed to move the PID file or socket somewhere else (without parsing
the config file, which has other security implications).
I've removed the stale socket cleanup from our OpenRC service script:
* Cleaning up stale sockets isn't really the job of the service script.
* The ability to ignore a stale socket is already built into the server.
With it gone, maybe the "-x" is a useful example to have in the conf
file (although it's commented-out by default, anyway).
Sergey G. Brester