As discussed at Bug 282984 a year ago, having libxo for tabular output of pfctl is a nice feature that may fill the gap between using libpfctl and parsing pfctl output. libpfctl still requires coding in C and pfctl stdout has somewhat weak API guarantees and no machine-readable output besides `-s labels`. I'm opening this bug to announce that I'm finally got my hands dirty with regards to partial libxo support for -s timeouts|memory|info|labels|Tables|Interfaces and -Tshow. I doubt that I'll be able to craft a meaningful patch for `-s rules`. I'm not even sure that putting the rules into procrustean bed of json/xml is close to Doing The Right Thing. :-) I'll do my best to align labels with the spirit of meilfaro's ndp, garga's arp and netstat patches.
> I doubt that I'll be able to craft a meaningful patch for `-s rules`. Honestly, I don't think you should even try. It's far less obvious to me that there's even a use case for it in the first place, and it's also likely to be more invasive that changing the output for things like info, labels or tables. Which in turn will make patches easier to include. If you do want to try, do that last.
(In reply to Kristof Provost from comment #1) I totally agree. The only use-case I know for `--libxo -s rules` is to run `--libxo -s rules -vv` to get counters for the specific rule-number. It's an imaginary case to me, but it might sound like something realistic in some cases, e.g. it might be an input to some rule reordering machinery. I've not looked at the port in bug 284321 yet, but similar code might have a reason to consume those counters under some circumstances as well. And `-s labels` shows only rules having labels, so... :-) There might be some way to stitch libxo and `-s rules` together, but, absolutely, it'll be the last patch within the patchset. If any. The possible way to go I see is to make `--libxo -s rules` output somewhat similar to `--libxo -s labels` with the rule itself being serialized as a plain string. Otherwise I'd rather avoid `--libxo -s rules` altogether if it becomes to complex to review & merge.
The question would be what the libxo output for rules should look like. Should it just print the rules as a (id, rule, counters) tuples or should the rules be also broken up into their action and arguments? The later would be more work to implement, but would make it possible to write a quick jq oneline to e.g. rewrite an anchor.
(In reply to crest from comment #3) I plan to keep it as (id, rule, label, counters). I'm unaware of a use-case that benefits from splitting ${rule} into bits and justifies extra effort. My two agenda points are stats/monitoring & table updates automation. Is there a good reason to rewrite anchor in an semi-unattended way? I mean, I expect `Serializer | sed | Deserializer` to be equally good in most cases, the output still needs a review by a pair of eyes equipped with `diff`. Am I missing something? I'm not a heavy pf(4) user, just a maintainer of a dozen of OPNsense boxes — so I don't know how pf evolved over time within FreeBSD codebase, how it was extended, if rule format was changed, what were API/ABI guarantees, and so on. That's why I also don't feel I'm the right person to craft a pf.conf.json & pf.conf.xml format :-)
> should the rules be also broken up into their action and arguments? For me having rules, states and source nodes dumped into json would greatly improve the code for pf tests. Many tests I wrote over the last year or so check if proper states have been created and if proper amount of packets went through them. The tests use awk to convert the current multiline output into single lines, and then those are checked with grep. That is unnecessary complicated, prone to errors, makes things like comparing numbers hard. I think that fully splitting the output, not keeping any multi-word regexaple strings, would help here.