(Not technically a bug, yet very counter-intuitive and prone to breakage) Runit nftables service imports "/etc/nftables.conf" instead of the more sensible "/etc/nftables/nftables.conf"

[TeusLollo]

Is this a new report?

Yes

System Info

Void 5.15.82_1 x86_64 GenuineIntel notuptodate rFFF

Package(s) Affected

runit-nftables-20200123_2

Does a report exist for this bug with the project's home (upstream) and/or another distro?

No response

Expected behaviour

Code of /etc/sv/nftables/run is as follows (No modifications by me, pure vanilla package config file):

#!/bin/sh
[ ! -r /etc/nftables.conf ] && exit 0
nft -f /etc/nftables.conf
exec chpst -b nftables pause

It should thus import a given configuration from /etc/nftables.conf as an nft ruleset (If any), and subsequently pause itself. The service itself will just be stuck into a self-terminating loop if it can't locate such a file.

Actual behaviour

Yes, I have disabled any other firewall/ip-tables ruleset service that may have been active before.

Relevant outputs are as follows:

ls -l /var/service/nftables 
lrwxrwxrwx 1 root root 16 Dec 14 23:20 /var/service/nftables -> /etc/sv/nftables

Double-checking I didn't mess up with service enabling.

ls -l /etc/nftables/nftables.conf 
-rw-r--r-- 1 root root 1398 Dec 15 00:01 /etc/nftables/nftables.conf

Notice how the nftables sub-directory resides into /etc directory, and how I, following what most guides would tell about nft configurations, I put an nft ruleset into /etc/nftables/nftables.conf

However:

#!/bin/sh
[ ! -r /etc/nftables.conf ] && exit 0
nft -f /etc/nftables.conf
exec chpst -b nftables pause

Attempts to load /etc/nftables.conf instead of the more sensible /etc/nftables/nftables.conf (The latter being the de-facto standard, according to most nft guides, and the default location for the nft ruleset in both Archlinux and Gentoo Linux).

The result is not having a valid nft ruleset for the service to import, resulting into a self-terminating looping behavior at 1-second intervals.

Output of sudo nft list ruleset is, obviously empty, since /etc/sv/nftables/finish/ executes a nft flush ruleset every time the service goes down (Every second, thus, given the looping self-terminating pattern)

Steps to reproduce

1. Install runit-nftables-20200123_2
2. Put a valid nft ruleset into /etc/nftables/nftables.conf (What most guides will tell you to do)
3. Do a sudo ln -s /etc/sv/nftables /var/service
4. Do a sudo sv once nftables (No errors)
5. Do a sudo sv up nftables
6. Do a sudo sv status nftables multiple times in quick succession (Service is down in 1-second intervals).
7. Be stuck for hours trying to figure out what you did wrong (You didn't, service configuration is counter-intuitive instead)

This is what happened to me, and what WILL happen to most users, by following the vast majority of guides about setting up an nft ruleset.

I spent about two hours and an half double-checking service directories, rebuilding my initramfs and reading into its config, modprobing modules, reading about nf_tables, and rewriting and validating my nft ruleset (Remember, /etc/sv/nftables/run will not deliver any errors into system logs, since it technically ends with a 0 even if it doesn't find a /etc/nftables.conf)

Only at the last moment I peeked into /etc/sv/nftables/run, and realized the script expects a /etc/nftables.conf, instead of the more sensible /etc/nftables/nftables.conf (De-facto standard according to most guides, and indeed the most common configuration among linux distros, as can be easily confirmed by going through most distro wikis).

It's not technically an error, of course, yet, since the nftables-1.0.5_2 (I guess) already creates an /etc/nftables/ sub-directory (Otherwise mostly empty, except for the /etc/nftables/osf/pf.os file) it seems rather counter-intuitive to subsequently require for the nft ruleset to be into /etc/nftables.conf instead (Who would have guessed it?).

At the very least, if maintainers deem this a "won't fix|not a bug" scenario, it should be mentioned into the Void Handbook that, unlike most linux distro, Void Linux expects its nft ruleset into /etc/nftables.conf, NOT /etc/nftables/nftables.conf (As most guides and wikis will otherwise tell you).

Obviously, I do not deem anyone at fault. It technically still works, and I presume the maintainer had his own reasons to establish such a setup.

Yet, since we in fact have a /etc/nftables/ sub-directory provided by nftables-1.0.5_2 (I guess), it should be taken advantage of, otherwise such a directory will only contain one /etc/nftables/osf/pf.os file, which is just more documentation for nf_tables.

I also presume such a setup may eventually produce some degree of maintenance burden, given how, currently, virtually no firewalls operate exclusively on nf_tables. Yet, in the future, I bet those that will may require (Optionally, at least) a valid nft ruleset into /etc/nftables/nftables.conf.

Regardless, thanks for all past, present, and future efforts by developers and maintainers. Do keep up the good work.

[paper42]

This is documented in https://docs.voidlinux.org/config/network/firewalls.html#nftables and changing the default location would be a breaking change.

runit-nftables installs a core service, the nftables service is provided by the nftables package.

[TeusLollo]

Never mind, then.

I must have miss-read that part (After two hours and a half of bickering with configurations, I must have been exhausted), and assumed the /etc/nftables/ directory was meant for the nft ruleset. I guess most users too would assume so going in first-time into nft configuration.

Still, it's kinda weird having one mostly-empty /etc/nftables/ directory, while the really critical nft ruleset is expected to reside into /etc/nftables.config. At least it's documented, unless you end-up miss-reading like I did.

I presume there must be some reason for establishing such a setup, although I'm not familiar enough with Void packaging to know for sure. I may eventually learn more.

Thus, since there's technically not a bug, and since it's actually intended to work this way, I'm closing this.

Thanks to everyone for their efforts, regardless.

[paper42]

Arch also uses /etc/nftables.conf, so I am not sure what's the issue. The service was clearly failing to start and reading the service file or the handbook section would uncover you are using the wrong path.