https://agir.april.org/https://agir.april.org/favicon.ico?15861920342019-05-31T00:17:58ZGestionnaire de projets de l'AprilAdmins - Anomalie #3724: Les logs fail2bans ne sont jamais purgéeshttps://agir.april.org/issues/3724?journal_id=140882019-05-31T00:17:58ZChristian P. Momoncmomon@april.org
<ul><li><strong>Sujet</strong> changé de <i>Les logs fail2bans ne sont jamais purgés</i> à <i>Les logs fail2bans ne sont jamais purgées</i></li></ul> Admins - Anomalie #3724: Les logs fail2bans ne sont jamais purgéeshttps://agir.april.org/issues/3724?journal_id=164382020-01-29T17:32:12ZChristian P. Momoncmomon@april.org
<ul><li><strong>Statut</strong> changé de <i>Nouveau</i> à <i>Confirmé</i></li><li><strong>Version cible</strong> changé de <i>Backlog</i> à <i>Janvier 2020</i></li></ul><p>Le phénomène est à nouveau devenu gênant aujourd'hui, notamment sur virola.<br />Action de QGuLL :<br /><pre>
18:06 < QGuLL> 3614 Wed 29 Jan 2020 01:47:27 PM UTC /usr/bin/sqlite3 -echo fail2ban.sqlite3 "delete FROM bans where timeofban < strftime('%s','now','-30 day'); SELECT changes(); vacuum"
18:09 < QGuLL> j'ai fais que la commande sql
18:10 < QGuLL> j'ai stoppé fail2ban
18:10 < QGuLL> j'ai lancé le sqlite
18:10 < QGuLL> le fs était hs
18:10 < QGuLL> la charge montait sur toute l'infra
18:10 < QGuLL> j'ai fait ctrl-c
18:10 < QGuLL> j'ai mv
18:10 < QGuLL> j'ai fait start fail2ban, il a refait un sqlite vierge
18:10 < QGuLL> et là à 18h j'ai rm le mv que j'avais laissé de côté
</pre></p>
<p>Comme indiqué sur le gestionnaire de ticket du projet officiel :<br /><pre>
I've said already several times, purge will never called (only in test case):
</pre></p>
Donc sur tout le SI, il faut mettre en place :
<ul>
<li>un script ;</li>
<li>un cron ;</li>
<li>et une sonde (qui vérifie le cron et l'âge maxi des entrées de la base).</li>
</ul> Admins - Anomalie #3724: Les logs fail2bans ne sont jamais purgéeshttps://agir.april.org/issues/3724?journal_id=164742020-01-29T21:25:13ZQuentin Gibeauxapril.quentin@gibeaux.eu
<ul><li><strong>Assigné à</strong> mis à <i>Romain H.</i></li></ul> Admins - Anomalie #3724: Les logs fail2bans ne sont jamais purgéeshttps://agir.april.org/issues/3724?journal_id=164752020-01-29T21:25:22ZQuentin Gibeauxapril.quentin@gibeaux.eu
<ul><li><strong>Version cible</strong> changé de <i>Janvier 2020</i> à <i>Février 2020</i></li></ul> Admins - Anomalie #3724: Les logs fail2bans ne sont jamais purgéeshttps://agir.april.org/issues/3724?journal_id=167432020-02-22T13:55:31ZRomain H.
<ul><li><strong>Statut</strong> changé de <i>Confirmé</i> à <i>En cours de traitement</i></li></ul> Admins - Anomalie #3724: Les logs fail2bans ne sont jamais purgéeshttps://agir.april.org/issues/3724?journal_id=167442020-02-23T19:48:59ZRomain H.
<ul><li><strong>Statut</strong> changé de <i>En cours de traitement</i> à <i>Résolu</i></li><li><strong>% réalisé</strong> changé de <i>0</i> à <i>100</i></li></ul>J'ai ajouté la cron et la supervision sur :
<ul>
<li>bastion</li>
<li>mail</li>
<li>virola</li>
<li>calamus</li>
<li>galanga</li>
<li>guarana</li>
</ul>
<p>La cron supprime les entrées >= 30 jours, tous les matins à 6h30.<br />La supervision surveille qu'il n'y a pas d'entrée >= 31 jours.</p>
<p>Comme la DB est accessible uniquement par root, j'ai rajouté une configuration à <em>sudo</em> pour permettre à l'utilisateur <em>nagios</em> d’exécuter le script.</p>
<p>Les DB de <em>calamus</em> , <em>galanga</em> et <em>guarana</em> étaient trop grosses pour permettre l’exécution du script sans faire beaucoup d'I/O, j'ai réinitialisé la DB.</p> Admins - Anomalie #3724: Les logs fail2bans ne sont jamais purgéeshttps://agir.april.org/issues/3724?journal_id=167882020-02-26T21:17:19ZQuentin Gibeauxapril.quentin@gibeaux.eu
<ul><li><strong>Statut</strong> changé de <i>Résolu</i> à <i>Fermé</i></li></ul>