forked from pool/nftables
Implement nftables.service for static firewall configurations (bsc#1237277) #1
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "mgerstner/nftables:master"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
It seems users are missing this service which is not part of the
upstream project but present in most other Linux distributions. It
allows to setup simple static nftables based firewalls via configuration
files.
This should be proposed upstream instead. There has got to be a reason they do not have such service units yet.
This also totally collides with SuSEfirewall/firewalld.
Implement nftables.service for static firewall configurations (bsc#1237277)to WIP: Implement nftables.service for static firewall configurations (bsc#1237277)It's not colliding, because it is the responsibility of the system admin not to use both at the same time. And we do have a customer request to add this service.
I can add a
Conflicts=statement to the systemd unit to prevent accidental activation of both this service and firewalld. SUSEFirewall is not a candidate here since it is deprecated and doesn't even support nftables.Otherwise this service does not harm at all. It is purely opt-in, won't be activated by default. It is just a couple of files extra. We are not to judge what customers and users want to have. If they want to have a simple static firewall written manually then this is fine with me.
On the other hand, we have also gotten complaints from upstreams for developing bespoke/NIH solutions and, at times, getting called out for producing "bastardized packages". For reason like these, the "upstream first" idea exists, to at least try to find a common solution before throwing in the towel.
I'm not throwing in the towel, I'm fulfilling a customer request. I looked at what other distributions do. This here is not perverting an upstream approach, it is filling a gap. I can approach upstream in parallel, but addressing this feature request has time constraints, we need it for SLE-16 development. So please cooperate here. I'm bugowner of
nftablesafter all. Otherwise I'd have to switch over the package to my own Gitea branch.This is the kind of deviation I was afraid of seeing, and why I feel Upstream First is important. Yes, please contact them as soon as possible, that will help making the case. Having to switch the file location later because #1 was merged "due to time constraints" surely is not all that great for the end-user (sysadmin) who's wondering why, on the next reboot, the ruleset is no longer loaded.
I acknowledge that one does not always find a consensus with upstreams — this is what I meant with "throwing the towel [w.r.t. upstream]" — and that's ok, if the distro-specific modification was argued for and the result documented. That is the goal.
The current situation is because organization creation was disabled in this Gitea instance midway unfortunately. But even if the backstorage wasn't Git but OBSSCM, the change would leave a bad taste if it had unresolved questions like path choice.
Placing config files in /usr/etc when they are not read from that location also seems a bit strange; traditionally (open)SUSE would put such files in %_docdir instead.
Mine is more inspired by the way Fedora does it. I think it's a good idea to have a dedicated directory and have support for splitting the rules up into smaller pieces contained in separate files.
The deviation is already there, we're only late to the party. I will approach upstream, but don't have high hopes that a usable solution will be available any time soon. Certainly not soon enough for SLE-16 development. That's just reality.
It's my first time working with Gitea, and yes the situation is less than ideal IMHO. There seem to be many questions unresolved. But I have to work with what we have at the moment.
True. This whole
/usr/etcapproach does not go well with some things like this here. Other distros offer an empty rule set by default for this service but I don't think this makes any sense. When the service is enabled then it should also have a usable custom config.I can move the file to %_docdir and also add that Conflicts= towards firewalld. I don't think I'll find time to do that before the weekend any more, though.
I'll take care of it, then.
https://lore.kernel.org/netfilter-devel/20250228205935.59659-1-jengelh@inai.de/T/#u
Ah thanks for forwarding that to upstream. No reaction so far, though, it seems.
I incorporated your suggestions and some other fixes
WIP: Implement nftables.service for static firewall configurations (bsc#1237277)to Implement nftables.service for static firewall configurations (bsc#1237277)Now that the change is in Tumbleweed I notice that the behaviour of
systemctl start nftables.serviceis still a bit unfortunate. Even if the service is not configured (config file condition fails) firewalld.service is stopped (because it is now conflicting). This leaves the system without any firewall.That is more of a systemd issue, though. It shouldn't stop conflicting services if the service to be started doesn't even meet the conditions to be started.
Got a system bug report link?