Pas de bol, la logique (plus que la syntaxe) de nftables (telle qu'exposée par Patrick Mac Hardy, c'est évidement moins visible dans l'exemple de la dépêche) est encore a des années lumières d'être aussi simple et naturelle que celle de pf, d'où la plainte justifié de l'auteur de la dépêche : "c'est un véritable cadeau empoisonné car il faudra tout réapprendre.". La syntaxe est elle-aussi moins bonne, mais c'est moins grave à mes yeux.
On garde, par exemple, au coeur de l'outil, l'ensemble des concepts de chaines et tables, qui correspondent effectivement à ce qui se trouve coté noyau chez linux, mais qui ne sont certainement pas la façon la plus ergonomique d'exposer les choses à l'utilisateur (et donc avec la nécessité, toujours, de garder en tête leurs contextes respectifs d'application, leurs ordres de traitement, etc., qui font qu'aujourd'hui la sécurité effectivement assurée par un gros firewall iptables based est très difficile à vérifier en le lisant seulement (ie. sans le tester), à la différence de pf). La syntaxe reste assez verbeuse à priori, mais tout de même en net progrès par rapport à iptables (véritable langage et non plus options cli d'un binaire, notion d'implicites selon le contexte, par ex...). Mais ce qui aurait été à revoir fondamentalement n'a pas changé : la possibilité de faire des rulesets vraiment propres structurés, lisibles, au moins linéairement ; les sauts de chaines sont aux configuration structurées précisément ce que le GOTO était à la programmation à l'époque de Djikstra....
Quelques progrès tout de même, qui nous rapprochent un brin de pf, comme la possibilité de tester la syntaxe d'un ruleset avant de le charger (enfin !). Reste qu'il est vraiment dommage que Mac Hardy ai préféré s'amuser à inventer son langage à lui plutôt que de reprendre au moins l'interface utilisateur de pf.
[^] # Re: Bonne nouvelle
Posté par herodiade . En réponse au journal NFtables, successeur d'Iptables. Évalué à 10.
On garde, par exemple, au coeur de l'outil, l'ensemble des concepts de chaines et tables, qui correspondent effectivement à ce qui se trouve coté noyau chez linux, mais qui ne sont certainement pas la façon la plus ergonomique d'exposer les choses à l'utilisateur (et donc avec la nécessité, toujours, de garder en tête leurs contextes respectifs d'application, leurs ordres de traitement, etc., qui font qu'aujourd'hui la sécurité effectivement assurée par un gros firewall iptables based est très difficile à vérifier en le lisant seulement (ie. sans le tester), à la différence de pf). La syntaxe reste assez verbeuse à priori, mais tout de même en net progrès par rapport à iptables (véritable langage et non plus options cli d'un binaire, notion d'implicites selon le contexte, par ex...). Mais ce qui aurait été à revoir fondamentalement n'a pas changé : la possibilité de faire des rulesets vraiment propres structurés, lisibles, au moins linéairement ; les sauts de chaines sont aux configuration structurées précisément ce que le GOTO était à la programmation à l'époque de Djikstra....
Quelques progrès tout de même, qui nous rapprochent un brin de pf, comme la possibilité de tester la syntaxe d'un ruleset avant de le charger (enfin !). Reste qu'il est vraiment dommage que Mac Hardy ai préféré s'amuser à inventer son langage à lui plutôt que de reprendre au moins l'interface utilisateur de pf.
NIH to the rescue !