Github messages for voidlinux
 help / color / mirror / Atom feed
* [ISSUE] (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"
@ 2022-12-15  0:32 TeusLollo
  2022-12-15  6:56 ` paper42
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: TeusLollo @ 2022-12-15  0:32 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 5201 bytes --]

New issue by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/41100

Description:
### 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 firewall 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 the good work. 

^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-12-15 10:06 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-15  0:32 [ISSUE] (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
2022-12-15  6:56 ` paper42
2022-12-15  7:47 ` paper42
2022-12-15  9:57 ` [ISSUE] [CLOSED] " TeusLollo
2022-12-15  9:57 ` TeusLollo
2022-12-15 10:06 ` paper42
2022-12-15 10:06 ` [ISSUE] [CLOSED] " paper42

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).