Hi,
Sorry for the late reply
instead of introducing uci includes that configure nft includes, why
not
encode the chain/position etc. values directly into the path/filename
and
directly include the file if it exists at the expected location?
I was just wondering why not use the new feature you added to give other
packages the ability to add rules to fw4. The include feature was
exactly
what was missing for fw4 to add the posibility for other package adding
firewall rules to fw4(nftables=.
I think the above would be a lot more manageable since you'd just have
to
place partial .nft files which are then folded into the final ruleset
on fw4
start/reload.
Sorry, but I don't agree with the following reasons.
Let me briefly explain why.
All files under '/usr/share/firewall4/includes.d' are uci files. I can
see
all relevant options. I can set in the includes my own path. This is
relevant
for packages that updates the ruleset on events. If I do not want to be
this
rules persistent saved I could use a tmp file in the system
(strongswan).
Also the new include add by you already does have the state file
feature.
Which is relevant on reloading the ruleset.
In addition, it would make the ruleset.uc file confusing if I added the
same
feature again. Also, I would have to add two sections on include to
support
temporary rules, which I would not have to store under
'/usr/share/firewall4/includes.d/' but under
'/tmp/firewall4/includes.d/' for
example to support the not persistent feature.
We also use the include to add the helpers.
Last but not leased, if we now add an other possibility, then I don't
think
anyone knows where which file adds which rule!
From my point of view, it makes sense to use the include function from
you
with my extension. So I think the include feature is the better and
unified
solution.
Best Regards
Florian
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
