fail2ban/files/fail2ban-openrc.init.in

87 lines
3.1 KiB
Plaintext
Raw Normal View History

#!/sbin/openrc-run
# This file is part of Fail2Ban.
#
# Fail2Ban is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# Fail2Ban is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with Fail2Ban; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
#
# Author: Sireyessire, Cyril Jaquier
#
files/fail2ban-openrc*: let start-stop-daemon manage the server. There are two ways that it would make sense to write the OpenRC service script for fail2ban: 1. Use the fail2ban-client program to stop, start, reload, etc. the server; and try to figure out whether or not it worked afterwards. 2. Use the start-stop-daemon program built into OpenRC to manage the fail2ban-server process. This works only for starting and stopping, because the "reload" command is sent over an undocumented protocol, but has the benefit that you get immediate feedback about the result of calling fail2ban-server. The existing service script combined the two in a way that appeared to work, but didn't make too much sense. It used start-stop-daemon to initiate the fail2ban-client program with either a "start" or "stop" argument. So long as everything goes fine, that appears to work. But the start-stop-daemon is not actually monitoring the fail2ban-client program; it's supposed to be monitoring the fail2ban-server process that gets started as side-effect. The existing stop() function does not do quite what you'd expect; for example the "stop" command is never sent. Again, the daemon does ultimately get stopped so long as the hard-coded PID file contains what you think it does -- so it "works" -- but is misleading. This commit changes everything to use the second approach above, where start-stop-daemon manages everything. This was done mainly to simplify the service script, because now the default start() and stop() phases can be used, allowing us to delete them from our copy. One might worry that there is some special magic behind "fail2ban-client start" and "fail2ban-client stop", however that does not appear to be the case. Admittedly, if in the future those two commands begin to do something nonstandard, the service script would need to be changed again to take the first approach above and use fail2ban-client for everything.
2018-07-15 18:08:33 +00:00
description="Ban hosts that cause multiple authentication errors"
description_reload="reload configuration without dropping bans"
extra_started_commands="reload"
# Can't (and shouldn't) be changed by the end-user.
#
# Note that @BINDIR@ is already supplied by the build system. Some
# day, it might be nice to have @RUNDIR@ supplied by the build system
# as well, so that we don't have to hard-code /run here.
FAIL2BAN_RUNDIR="/run/${RC_SVCNAME}"
FAIL2BAN_SOCKET="${FAIL2BAN_RUNDIR}/${RC_SVCNAME}.sock"
files/fail2ban-openrc*: let start-stop-daemon manage the server. There are two ways that it would make sense to write the OpenRC service script for fail2ban: 1. Use the fail2ban-client program to stop, start, reload, etc. the server; and try to figure out whether or not it worked afterwards. 2. Use the start-stop-daemon program built into OpenRC to manage the fail2ban-server process. This works only for starting and stopping, because the "reload" command is sent over an undocumented protocol, but has the benefit that you get immediate feedback about the result of calling fail2ban-server. The existing service script combined the two in a way that appeared to work, but didn't make too much sense. It used start-stop-daemon to initiate the fail2ban-client program with either a "start" or "stop" argument. So long as everything goes fine, that appears to work. But the start-stop-daemon is not actually monitoring the fail2ban-client program; it's supposed to be monitoring the fail2ban-server process that gets started as side-effect. The existing stop() function does not do quite what you'd expect; for example the "stop" command is never sent. Again, the daemon does ultimately get stopped so long as the hard-coded PID file contains what you think it does -- so it "works" -- but is misleading. This commit changes everything to use the second approach above, where start-stop-daemon manages everything. This was done mainly to simplify the service script, because now the default start() and stop() phases can be used, allowing us to delete them from our copy. One might worry that there is some special magic behind "fail2ban-client start" and "fail2ban-client stop", however that does not appear to be the case. Admittedly, if in the future those two commands begin to do something nonstandard, the service script would need to be changed again to take the first approach above and use fail2ban-client for everything.
2018-07-15 18:08:33 +00:00
# The fail2ban-client program is also capable of starting and stopping
# the server, but things are simpler if we let start-stop-daemon do it.
command="@BINDIR@/fail2ban-server"
pidfile="${FAIL2BAN_RUNDIR}/${RC_SVCNAME}.pid"
# We force the pidfile/socket location in this service script because
# we're taking responsibility for ensuring that their parent directory
# exists and has the correct permissions (which we can't do if the
# user is allowed to change them).
command_args="${FAIL2BAN_OPTIONS} -p ${pidfile} -s ${FAIL2BAN_SOCKET}"
retry="30"
depend() {
use logger
after iptables
}
checkconfig() {
"${command}" ${command_args} --test
}
start_pre() {
# If this isn't a restart, make sure that the user's config isn't
# busted before we try to start the daemon (this will produce
# better error messages than if we just try to start it blindly).
#
# If, on the other hand, this *is* a restart, then the stop_pre
# action will have ensured that the config is usable and we don't
# need to do that again.
if [ "${RC_CMD}" != "restart" ] ; then
checkconfig || return $?
fi
checkpath -d "${FAIL2BAN_RUNDIR}"
}
stop_pre() {
# If this is a restart, check to make sure the user's config
# isn't busted before we stop the running daemon.
if [ "${RC_CMD}" = "restart" ] ; then
checkconfig || return $?
fi
}
reload() {
files/fail2ban-openrc*: let start-stop-daemon manage the server. There are two ways that it would make sense to write the OpenRC service script for fail2ban: 1. Use the fail2ban-client program to stop, start, reload, etc. the server; and try to figure out whether or not it worked afterwards. 2. Use the start-stop-daemon program built into OpenRC to manage the fail2ban-server process. This works only for starting and stopping, because the "reload" command is sent over an undocumented protocol, but has the benefit that you get immediate feedback about the result of calling fail2ban-server. The existing service script combined the two in a way that appeared to work, but didn't make too much sense. It used start-stop-daemon to initiate the fail2ban-client program with either a "start" or "stop" argument. So long as everything goes fine, that appears to work. But the start-stop-daemon is not actually monitoring the fail2ban-client program; it's supposed to be monitoring the fail2ban-server process that gets started as side-effect. The existing stop() function does not do quite what you'd expect; for example the "stop" command is never sent. Again, the daemon does ultimately get stopped so long as the hard-coded PID file contains what you think it does -- so it "works" -- but is misleading. This commit changes everything to use the second approach above, where start-stop-daemon manages everything. This was done mainly to simplify the service script, because now the default start() and stop() phases can be used, allowing us to delete them from our copy. One might worry that there is some special magic behind "fail2ban-client start" and "fail2ban-client stop", however that does not appear to be the case. Admittedly, if in the future those two commands begin to do something nonstandard, the service script would need to be changed again to take the first approach above and use fail2ban-client for everything.
2018-07-15 18:08:33 +00:00
# The fail2ban-client uses an undocumented protocol to tell
# the server to reload(), so we have to use it here rather
# than e.g. sending a signal to the server daemon. Note that
# the reload will fail (on the server side) if the new config
# is invalid; we therefore don't need to test it ourselves
# with checkconfig() before initiating the reload.
ebegin "Reloading ${RC_SVCNAME}"
"@BINDIR@/fail2ban-client" ${command_args} reload
eend $? "Failed to reload ${RC_SVCNAME}"
}