Re: Pas mal

Hello 😅
Je vais répondre à tes remarques, même si d'autres l'ont déjà fait

utiliser une commande, c'est old school

Je pense que j'ai deux contre-arguments plus concrets. Une commande, c'est :

• super simple à implémenter
• super versatile

Je n'ai pas envie de recoder des trucs déjà implémentés par journalctl, tail, docker logs, etc... J'estime que ces commandes sont optimisées. Au bout de plusieurs semaines, une commande journalctl a utilisé moins d'une minute de temps de CPU, et je n'ai pas envie de compétiter !

ssh:
 follow: sshd

Il y a des distributions qui appellent ce service ssh, d'autres sshd, d'autres openssh.
Il y a des distributions qui utilisent systemd/journald, d'autres rsyslog, d'autres un plain text...
Je pense qu'hardcoder tous ces noms, tous ces paths, tous ces protocoles, dans reaction, c'est me tirer une balle dans le pied !

Le programme peut maintenant choisir d'utiliser nftables, iptables ou autre, en fonction du système.

Idem, je ne préfère pas que le programme détermine lui-même quel système existe, quel système est en place... Je pense que c'est la porte ouverte à une flopée de bugs plus ou moins sournois.

---

Comme mentionné par quelqu'un d'autre, il est possible d'approcher ta syntaxe avec JSONnet :

local systemd(service) = ['journalctl', '-fu', service + '.service'];
local ban(action) = ['ip46tables', '-w', '-A', 'reaction', '-s', '<ip>', '-j', action];
{
 streams: {
 ssh: {
 cmd: systemd('sshd'),
 filters: {
 failedlogin: {
 ...
 actions: {
 banip: ban('DROP'),
 },
 },
 },
 },
 },
}

Actuellement, le code de reaction fait ~1200 lignes de code, et ça me va bien !
Si je voulais implémenter/hardcoder autant de trucs, ben, déjà, je voudrais pas le faire haha, et ensuite, j'aurais plus de code dédié à des cas spécifiques qu'au coeur de ce que fait reaction : lire la stdout d'un programme, matcher des regexes dessus, et lancer des actions quand il y a un certain nombre de matches.