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

[Jason Hellenthal]

Devin,

On Mon, May 09, 2011 at 08:39:25PM -0700, Devin Teske wrote:
> 
> 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?


Not to break existing behavior the way they stand:
[...]
/etc/defaults/rc.conf
/etc/rc.conf.d/CUSTOM
/etc/rc.conf
/etc/rc.conf.local
/etc/rc.conf.d/NAME


If I understood that correctly then yes.


-- 

 Regards, (jhell)
 Jason Hellenthal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20110510/71415222/attachment.pgp