eyJhb changed the topic of #nixos-on-your-router to: NixOS on your Router || https://logs.nix.samueldr.com/nixos-on-your-router
<jasom> andi-: like you just write a bunch of nftables commands?
<andi-> Yes, I generate them with nix
<jasom> in 20.09, it looks like it's just networking.nftables.ruleset as a string; did you write some functions to help out with that or are there already such tools that I'm missing?
<jasom> Though reading docs from nftables.org it doesn't look too bad.
teto has quit [Ping timeout: 260 seconds]
<andi-> jasom: yeah that is all I use for it. It has a huge list of static rules and some others that are generated from my custom modules.
<andi-> Looking at the structure of nftables rules I wasn't yet motivated to write a nixos module that supports all the potential options. One of the blockers for me is verification of the configuration before we apply it. nftables can only be verified as root as the syntax is finally checked in the kernel... Currently I just spawn a VM when building the config to ensure the rules do not have
<andi-> that isn't great
teto has joined #nixos-on-your-router
<NinjaTrappeur> The nftables syntax is pretty wide. I don't think re-writing the AST in Nix has much value, especially when looking at the implementation complexity it'll involve.
* NinjaTrappeur likes the nftables syntax
<NinjaTrappeur> I had no idea this was a thing
<NinjaTrappeur> So yeah, I guess we could map this json interface :/
<NinjaTrappeur> It'd probably help in terms of overriding. That being said, I'm not 100% sure it'd worth the trouble.
<andi-> NinjaTrappeur: hahaha, look at the jsonschema of that ;)
<andi-> it was an empty document the last time I checked
<andi-> mhhm maybe that change din the last 6 months
* andi- checks upstream source
<NinjaTrappeur> Why do you want a formal grammar when you can have a man page full of examples? :P
<NinjaTrappeur> Fair point, let's forget about that :)
<andi-> That + requiring KVM to verify the confi really turns me away from creating a general purpose module. We are missing something like `ferm` for nftables that ensures the config is valid (as much as possible)
<hexa-> what bothers me is that most of their examples are from the cmdline
<hexa-> who would ever use a production firewall like that?
<andi-> nice discussion on the ferm <> nftables topic
<andi-> this is what really scares me: https://bugzilla.netfilter.org/show_bug.cgi?id=1434#c4
<andi-> the kernel version decides if syntax is valid..
<hexa-> true, but
<hexa-> subchain grouping \o/
<andi-> >= 5.1-rc1
<hexa-> 5.9-rc1
<hexa-> but still, that is such a convenience feature
<hexa-> they can truly learn alot from ferm
<hexa-> that comment is very spot on
superherointj has joined #nixos-on-your-router
<jasom> Hmm, I wonder how tightly coupled the parsing is to the implementation; it might be possible to extract the parsing code from the kernel, but maybe that's wishful thinking.
<hexa-> sounds like manual labor :)
<hexa-> on a moving target
<jasom> hexa-: if it's sufficiently decoupled it could probably be mostly automated, and eventually mainlined
<andi-> jasom: I actually looked at that some time ago
<andi-> and it looks sufficiently well structured
<andi-> My idea back then was to add an API to the kernel that exports the valid schema
<andi-> you could at least du some unpriv. validation
<andi-> but that doesn't solve the case where buildtime system != runtime system
laduke-132 has joined #nixos-on-your-router
<flokli> jasom: isn't there libkernel for these things
<flokli> eeeh, LKL I mean (Linux Kernel Library)