[RFE]: Ability to Rescan Database File For New Bans

[tldawson]

Feature request type

The ability to rescan the database for new bans in a clustered fail2ban setup.

Description

For clustered servers, it would be useful to store a central dbfile on an NFS and have each instance of fail2ban point to the NFS dbfile. It would be nice to be able to run a command like fail2ban-client reload dbfile in order to pull new bans from the central dbfile, or have it automatically check for new bans every so often.
Currently I have to restart the service in order to pull new bans from the dbfile onto each instance.

Considered alternatives

Another solution might be to support mysql as a backend since a lot of people are already using that in their application stack... but we'd still need some sort of ability to pull fresh bans from the db.

Any additional information

Also, I'm not sure if fail2ban can handle concurrent writes when two instances are trying to update the dbfile at the same time. Does anyone know if it does?

[sebres]

Currently I have to restart the service in order to pull new bans from the dbfile onto each instance.

Why?
fail2ban sql-database is available to read for multiple readers (depending on sqlite version, but if it is not too old)...
So you could do this:

sqlite3 'file:/var/lib/fail2ban/fail2ban.sqlite3?mode=ro' "$sql"

As well as backup it to another file, etc.

As regards rescan or (re)ban ability: see #2909 (in particular #2909 (comment) has a small example how you could do this, just read from some database and not from file).
Newest version also supporting notification about single attempts (protocol got extended to signal every particular failure).

As regards the clustering facility (e. g. fail2ban network), there is another RFE - #881 (may be you'd find some idea from there helpful also).

I'm not sure if fail2ban can handle concurrent writes ...
Does anyone know if it does?

Although WAL mode of sqlite3 permits simultaneous readers and writers, but I still don't see why you need it resp. what exactly you can do with database what you can not do with fail2ban client (communication protocol) or which advantages such in-place "upgrade" of database may provide (without to force fail2ban to reload it hereafter, what would be again very similar to restart).

Anyway fully fail2ban network support (active-active mode) is planed and I have an experimental branch doing it over ssh (still need to extract this to some public interface to be fully configurable and adjustable to support some other communication way).