Date: Tue, 10 May 2011 01:15:13 -0400 From: Jason Hellenthal <jhell@DataIX.net> To: Devin Teske <dteske@vicor.com> Cc: 'Doug Barton' <dougb@FreeBSD.org>, freebsd-rc@FreeBSD.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. Message-ID: <20110510051513.GC18435@DataIX.net> In-Reply-To: <FAE3414F-7FBD-4524-9076-4E1DA330117C@vicor.com> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <20110509233825.GB2558@DataIX.net> <010b01cc0eb5$3c6456e0$b52d04a0$@vicor.com> <20110510030718.GA18435@DataIX.net> <FAE3414F-7FBD-4524-9076-4E1DA330117C@vicor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyMnhAAoJEJBXh4mJ2FR+dSYH/3isBPFBDTg2tVVq9VMiXl43 nz9Vwa9Ikkd8hNK/pPn6J32n1Yb6/Scq7qkt2Gud31ffyHtHRozk8TL4WxUtNh2s IjI+4rYScQuY8GweXBmat8u90GRErJ7fJxrZSIloXDg0TjkzLYRkZXGPao5aRhM8 GFpI9PlPn4hEGm9Q1ScBNxKkX131ztoRN5yWu2vAox+9/Lf7OiH0+zSBYnjkpd90 j8XAFX9vHsFGbEPWXfAnk2Mhsecqd9j7Cs5wwcNDGsRnHHAoKdssYRt+3KSc7Vfp BV0yJX7oUnMvitGT/gwTeGcba1mhijjJtEc3F0uu5Lz9J3TYc3I+KyO9J4HMxtI= =bDPs -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110510051513.GC18435>