[RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace.

[Devin Teske]

On May 9, 2011, at 8:07 PM, Jason Hellenthal wrote:

> 
> Devin,
> 
> On Mon, May 09, 2011 at 06:53:43PM -0700, Devin Teske wrote:
>> Jason,
>> 
>>> rc.conf or rc.conf.local override. What do you think ? everyone else ? Doug ?
>> 
>> I talked about this with our lead developers and we think we came up with
>> something that has real significant potential.
>> 
>> We suggest that your source the rc.cond.d/*.conf files:
>> 
>> a. After /etc/rc.conf
>> b. Before /etc/rc.conf.local
>> 
>> Half our developers said that it would be nice if /etc/rc.conf.d/product.conf
>> could override rc.conf(5) and the other half said it would be nice if it was the
>> other way around. Then we thought about it for a moment, and we realized that if
>> you sourced them in-between the two files, that you could accommodate both
>> parties.
>> 
>> In this setup, we'd have /etc/rc.conf be the initial override file that
>> overrides /etc/defaults/rc.conf. Then /etc/rc.conf.d/product.conf would override
>> that. And finally, /etc/rc.conf.local would be end-all-be-all of overrides.
>> Nothing would be capable of overriding /etc/rc.conf.local (which seems to suit
>> the name -- "local" should indicate that the "non-local" can be inherited from a
>> master configuration, perhaps site-wide or pod-specific).
>> 
>> What do you think? I think it would be the "happy median."
>> 
> 
> I am somewhat sketchy of putting it between the two. Reason being is I 
> know quite a few people that already place anything that has to do with 
> ports(7) into rc.conf.local just to keep it seperate from the systems 
> rc.conf.
> 
> I can see that raising a few eyebrows. As of right now its thought of that 
> rc.conf and rc.conf.local get processed consecutively and would have to be 
> explained quite rigorously how they actually fall in order. Only my 
> opinion though, its up for grabs.
> 
> 1). If its sourced before then it can be considered user pre-defined 
> defaults. 

This sounds the most reasonable/desirable. In our hypothetical scenario where the customer controls both rc.conf and rc.conf.local, we'd eventually come across the request from a customer to disable a product-wide feature on a per-customer basis. In this case, adding something to their sup(1)/cvsup(1)-distributed rc.conf(5) would override the default. Support folks could go home and the override is in-place, problem solved.

Conversely for either of the below scenarios, adding an override would then become more difficult. Ultimately in our scenario, the ifconfig_* elements are in /etc/rc.conf.local (and therefore cannot be distributed) and the site-wide specifics (NTP server specifics, etc.) are in the global /etc/rc.conf (distributed to all hosts in the site). So unless you source before the rc_conf_files, the customer would be frustrated and end up throwing an /etc/rc.conf.d/zzz.conf into their sup(1)/cvsup(1) distributed directory to override our /etc/rc.conf.d/product.conf files.

Since we want to satisfy the customer, #1 becomes the only sensible approach. Sourcing /etc/rc.conf.d/*.conf before rc_conf_files. It then becomes a sort of shim to override /etc/defaults/rc.conf (but again, only if the directory /etc/rc.conf.d exists, which it shouldn't by-default in any installed distribution unless the owner/operator/developer adds one).

I can then envision a package containing a /etc/rc.conf.d/product.conf -- perhaps to be used sparingly and only when the package is for a product that takes control of a machine, IMHO



> 
> 2). If its sourced after then it becomes user defined overrides for 
> anything in rc.conf or rc.conf.local 
> 
> 3). If placed between then I feel it becomes an extension of rc.conf 
> leaving rc.conf.local to be the final say on all configs. This is 
> intentionally what rc.conf.local was meant for anyway.
> 
> 
> Really I personally do not object to either of the three listed above and 
> can see a point of view from all three sides but if I was forced to vote 
> for one of them I would probably have to go with 3. User feedback for this 
> type of thing is greatly needed & appreciated.

It was upon second thought that I actually have to change my vote to be #1 as the best option.

That would make /etc/rc.conf.d two things:

1. /etc/rc.conf.d/NAME where NAME is /etc/rc.d/NAME or /usr/local/etc/rc.d/NAME

NAME files in /etc/rc.conf.d would be sourced anytime NAME RCNG script is utilized (and these files override both rc.conf and rc.conf.local if they exist).

2. /etc/rc.conf.d/CUSTOM.conf where CUSTOM is anything you want.

CUSTOM.conf files in /etc/rc.conf.d would be sourced before rc_conf_files (which include /etc/rc.conf and /etc/rc.conf.local) in source_rc_confs of /etc/defaults/rc.conf. This would allow the files to similarly be sourced anytime NAME RCNG script is utilized (and these files override the defaults in /etc/defaults/rc.conf).

Is that a correct approximation of your proposed final implementation?
-- 
Devin

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________