[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"

[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]

[-- 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. 

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"

[paper42]

[-- 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.

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"

[paper42]

[-- 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.

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"

[TeusLollo]

[-- 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. 

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"

[TeusLollo]

[-- 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. 

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"

[paper42]

[-- 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.

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"

[paper42]

[-- 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.