On 30/11/2021 09:43, Martin Husemann wrote:
On Tue, Nov 30, 2021 at 09:10:35AM +0000, Stephen Borrill wrote:In rc.conf, npf=YES is sufficient, but you are advocating the setting needs to be duplicated if put into rc.conf.d.I think the confusion starts with the idea of enabling NPF by just putting the NPF=yes into scripts in /etc/rc.conf.d. It might have worked by pure luck in older releases, but it was wrong there too. I would argue that to enable it you should have NPF=yes in /etc/rc.conf, and to override special stuff in the $name script (which I can't think of reasonable uses for this case) you would put that overrides into /etc/rc.conf.d/$name.
In our products, we have a standard rc.conf and then a series of build scripts that configure and enable/disable services as required. We can switch between npf and ipfilter with a one-line change in a settings file, for example. We heavily rely on rc.conf.d functionality for this. We may put flags in there too.
I don't think putting name=YES into /etc/rc.conf.d/name is wrong or working by luck in general even if it is working by implication.
I think the "load_rc_config_var npf npf" line I've proposed in npf_boot is a neat solution (and similar for pf_boot). It basically says get the value of npf from wherever you may find it. It also avoids potential contamination of the environment compared to my original fix.
The split of /etc/rc.d/npf into two stages is analogous to swap1 and swap2. In that case, those scripts explicitly load_rc_config swap and do not take name into account.
-- Stephen