Solución 1:
Hay un dbpurgeage parámetro en fail2ban.conf , que indica cuántos días de datos se deben mantener en la base de datos. El valor predeterminado es un día (1d ), así que intenta reducirlo a un par de horas:
dbpurgeage = 8h
Esta configuración se combina con findtime :no tiene sentido tener un findtime más de dbpurgeage .
Editar (2021) :La siguiente nota era cierta en el momento de escribirla. Sin embargo, hoy en día echa un vistazo a neingeist responde en su lugar.
Nota obsoleta :Mirando mi propio fail2ban base de datos, el dbpurgeage la configuración no parece estar funcionando. Por lo tanto, la única solución es eliminar las entradas manualmente. Por ejemplo, para eliminar las entradas del año pasado, ejecute:
sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 \
"DELETE FROM bans WHERE DATE(timeofban, 'unixepoch') < '2020-01-01'; VACUUM;"
(el sqlite3 el ejecutable suele estar en el paquete homónimo).
Parece que no hay forma de realizar un VACUUM de la base de datos sin sqlite realizando una copia de la base de datos en el mismo directorio. Sin embargo, puede copiar el archivo a otro sistema de archivos antes de realizar la operación y luego volver a copiar la base de datos más pequeña.
Solución 2:
Puede actualizar a 0.11.x (que contiene el código para realizar la purga) y luego eliminar la enorme base de datos seguido de un reinicio de fail2ban. Volverá a crear la base de datos. Esta es la solución más sencilla y sin inconvenientes para la mayoría de las personas.
Si bien fail2ban 0.11.x en realidad contiene código para purgar entradas antiguas (¡la versión anterior no lo tenía!), no VACUUM . Entonces, otra opción es esperar a que fail2ban elimine las entradas antiguas (sucede cada hora) y realizar un sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "VACUUM;" manual. . Sin el VACUUM el archivo de la base de datos permanecerá en su tamaño.