Soluzione 1:
C'è un dbpurgeage parametro in fail2ban.conf , che indica quanti giorni di dati conservare nel database. Il valore predefinito è un giorno (1d ), quindi prova a ridurlo a un paio d'ore:
dbpurgeage = 8h
Questa impostazione è abbinata a findtime :non ha senso avere un findtime più lungo di dbpurgeage .
Modifica (2021) :La nota sotto era vera al momento della scrittura. Comunque al giorno d'oggi dai un'occhiata a neingeist rispondi invece.
Nota obsoleta :Guardando il mio fail2ban database, il dbpurgeage l'impostazione non sembra funzionare. Pertanto l'unica soluzione è eliminare le voci manualmente. Ad esempio, per eliminare le voci dell'anno scorso eseguire:
sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 \
"DELETE FROM bans WHERE DATE(timeofban, 'unixepoch') < '2020-01-01'; VACUUM;"
(l'sqlite3 l'eseguibile si trova solitamente nell'omonimo pacchetto).
Sembra che non ci sia modo di eseguire un VACUUM del database senza sqlite eseguire una copia del database nella stessa directory. Tuttavia puoi copiare il file su un altro filesystem prima di eseguire l'operazione e poi copiare il database più piccolo.
Soluzione 2:
È possibile aggiornare a 0.11.x (che contiene il codice per eseguire l'eliminazione) e quindi eliminare l'enorme database seguito da un riavvio di fail2ban. Ricreerà il database. Questa è la soluzione più semplice senza inconvenienti per la maggior parte delle persone.
Sebbene fail2ban 0.11.x contenga effettivamente il codice per eliminare le vecchie voci (la versione precedente no!), non fa VACUUM . Quindi un'altra opzione è aspettare che fail2ban elimini le vecchie voci (succede ogni ora) ed eseguire un sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "VACUUM;" manuale . Senza il VACUUM il file del database manterrà le sue dimensioni.