* Re: (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 [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
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: paper42 @ 2022-12-15 6:56 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
New comment by paper42 on void-packages repository
https://github.com/void-linux/void-packages/issues/41100#issuecomment-1352634687
Comment:
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 notables package.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: (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 [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 ` TeusLollo
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: paper42 @ 2022-12-15 7:47 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
New comment by paper42 on void-packages repository
https://github.com/void-linux/void-packages/issues/41100#issuecomment-1352634687
Comment:
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: (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 [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 ` TeusLollo
2022-12-15 9:57 ` [ISSUE] [CLOSED] " TeusLollo
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: TeusLollo @ 2022-12-15 9:57 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
New comment by TeusLollo on void-packages repository
https://github.com/void-linux/void-packages/issues/41100#issuecomment-1352816670
Comment:
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ISSUE] [CLOSED] (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 [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
` (2 preceding siblings ...)
2022-12-15 9:57 ` TeusLollo
@ 2022-12-15 9:57 ` TeusLollo
2022-12-15 10:06 ` paper42
2022-12-15 10:06 ` paper42
5 siblings, 0 replies; 7+ messages in thread
From: TeusLollo @ 2022-12-15 9:57 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 5234 bytes --]
Closed 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 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ISSUE] [CLOSED] (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 [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
` (3 preceding siblings ...)
2022-12-15 9:57 ` [ISSUE] [CLOSED] " TeusLollo
@ 2022-12-15 10:06 ` paper42
2022-12-15 10:06 ` paper42
5 siblings, 0 replies; 7+ messages in thread
From: paper42 @ 2022-12-15 10:06 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 5234 bytes --]
Closed 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 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: (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 [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
` (4 preceding siblings ...)
2022-12-15 10:06 ` paper42
@ 2022-12-15 10:06 ` paper42
5 siblings, 0 replies; 7+ messages in thread
From: paper42 @ 2022-12-15 10:06 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]
New comment by paper42 on void-packages repository
https://github.com/void-linux/void-packages/issues/41100#issuecomment-1352827556
Comment:
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.
^ permalink raw reply [flat|nested] 7+ messages in thread