Re: CVS commit: src/etc/rc.d

[Martin Husemann <martin%duskware.de@localhost>]

On Tue, Nov 30, 2021 at 10:11:36AM +0000, Stephen Borrill wrote:
> 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.

You could achive that too by including "local" files from your generic 
/etc/rc.conf (like: ". /etc/conf/firewall", maybe even guarded by tests
for existance).

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

If we want to support that, we should document it and have tests for
it. Currently I would not guess this could work after reading the manual,
and would not think about such usage when extending/modifying anything in
/etc/rc*.

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

Yes, and I am not objecting that detail.

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

We should ammend the documentation Robert cited to say something like
"in general $name, but in exceptional cases a well known service name
is used instead (like: swap, npf, ...)".

Martin