Solution 1 :
Il y a un dbpurgeage paramètre dans fail2ban.conf , qui indique le nombre de jours de données à conserver dans la base de données. La valeur par défaut est un jour (1d ), alors essayez de le réduire à quelques heures :
dbpurgeage = 8h
Ce paramètre est couplé avec findtime :cela n'a aucun sens d'avoir un findtime plus long que dbpurgeage .
Modifier (2021) :La note ci-dessous était vraie au moment de la rédaction. Cependant, de nos jours, consultez neingeist répondez plutôt.
Remarque obsolète :En regardant mon propre fail2ban base de données, le dbpurgeage le réglage ne semble pas fonctionner. Par conséquent, la seule solution consiste à supprimer les entrées manuellement. Par exemple, pour supprimer les entrées de l'année dernière, exécutez :
sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 \
"DELETE FROM bans WHERE DATE(timeofban, 'unixepoch') < '2020-01-01'; VACUUM;"
(le sqlite3 exécutable se trouve généralement dans le package homonyme).
Il semble qu'il n'y ait aucun moyen d'effectuer un VACUUM de la base de données sans sqlite effectuer une copie de la base de données dans le même répertoire. Cependant, vous pouvez copier le fichier sur un autre système de fichiers avant d'effectuer l'opération et ensuite recopier la base de données plus petite.
Solution 2 :
Vous pouvez mettre à jour vers 0.11.x (qui contient le code pour effectuer la purge), puis supprimer l'énorme base de données suivie d'un redémarrage de fail2ban. Il recréera la base de données. C'est la solution la plus simple et sans inconvénients pour la plupart des gens.
Alors que fail2ban 0.11.x contient en fait du code pour purger les anciennes entrées (ce n'était pas le cas de l'ancienne version !), il ne contient pas VACUUM . Une autre option consiste donc à attendre que fail2ban purge les anciennes entrées (cela se produit toutes les heures) et à effectuer un sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "VACUUM;" manuel . Sans le VACUUM le fichier de base de données conservera sa taille.