Le format Fail2ban n’est pas vraiment adapté à la philosophie de mon programme.
Cependant, ton idée a du mérite : elle enlèverait certainement un frein à l’utilisation de Pyruse...
Il est probablement possible de faire un convertisseur, qui lit la configuration de fail2ban et la transforme en configuration pour Pyruse.
Ce qui est dommage, c’est qu’un tel convertisseur ne serait sans doute pas capable de détecter les redondances et ainsi optimiser le fichier de configuration ; autrement dit : quel gain pour l’utilisateur ?
Je prévois par ailleurs quelques difficultés, notamment le fait qu’avec un peu de volonté, n’importe quoi peut être fait dans la configuration de fail2ban (cf. l’article que j’ai mis en lien dans le corps de la dépêche) : il faut donc récupérer chaque extrait de code (shell) et l’appeler par un module « wrapper » fait pour appeler du shell.
Bref, on va se retrouver avec un fichier de configuration non optimisé, qui n’utilise que des filtres et actions ad-hoc (aucun module standard), pour finalement exécuter du shell, et tout ça dans un mode opératoire nettement moins testé que la même configuration dans Fail2ban. Je ne suis pas optimiste...
[^] # Re: Support des filtres & actions au "format fail2ban"
Posté par Yves (site web personnel) . En réponse à la dépêche Pyruse 1.0 : pour remplacer Fail2ban et autres « scruteurs » de journaux sur un GNU/Linux moderne. Évalué à 4.
Le format Fail2ban n’est pas vraiment adapté à la philosophie de mon programme.
Cependant, ton idée a du mérite : elle enlèverait certainement un frein à l’utilisation de Pyruse...
Il est probablement possible de faire un convertisseur, qui lit la configuration de fail2ban et la transforme en configuration pour Pyruse.
Ce qui est dommage, c’est qu’un tel convertisseur ne serait sans doute pas capable de détecter les redondances et ainsi optimiser le fichier de configuration ; autrement dit : quel gain pour l’utilisateur ?
Je prévois par ailleurs quelques difficultés, notamment le fait qu’avec un peu de volonté, n’importe quoi peut être fait dans la configuration de fail2ban (cf. l’article que j’ai mis en lien dans le corps de la dépêche) : il faut donc récupérer chaque extrait de code (shell) et l’appeler par un module « wrapper » fait pour appeler du shell.
Bref, on va se retrouver avec un fichier de configuration non optimisé, qui n’utilise que des filtres et actions ad-hoc (aucun module standard), pour finalement exécuter du shell, et tout ça dans un mode opératoire nettement moins testé que la même configuration dans Fail2ban. Je ne suis pas optimiste...