From owner-freebsd-rc@FreeBSD.ORG Tue May 10 03:39:30 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE177106566C; Tue, 10 May 2011 03:39:30 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id A8ABB8FC08; Tue, 10 May 2011 03:39:30 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p4A3dTbp005966; Mon, 9 May 2011 22:39:29 -0500 Received: from sbhfisltcgw01.FNFIS.COM (Not Verified[10.132.248.121]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Mon, 09 May 2011 22:39:41 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by sbhfisltcgw01.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 22:39:28 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 22:39:27 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Devin Teske In-Reply-To: <20110510030718.GA18435@DataIX.net> Date: Mon, 9 May 2011 20:39:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Jason Hellenthal X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 May 2011 03:39:28.0227 (UTC) FILETIME=[DD5E7B30:01CC0EC3] Cc: 'Doug Barton' , freebsd-rc@FreeBSD.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 03:39:31 -0000 On May 9, 2011, at 8:07 PM, Jason Hellenthal wrote: >=20 > Devin, >=20 > On Mon, May 09, 2011 at 06:53:43PM -0700, Devin Teske wrote: >> Jason, >>=20 >>> rc.conf or rc.conf.local override. What do you think ? everyone else ? = Doug ? >>=20 >> I talked about this with our lead developers and we think we came up with >> something that has real significant potential. >>=20 >> We suggest that your source the rc.cond.d/*.conf files: >>=20 >> a. After /etc/rc.conf >> b. Before /etc/rc.conf.local >>=20 >> 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 bo= th >> parties. >>=20 >> 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 overrid= es. >> Nothing would be capable of overriding /etc/rc.conf.local (which seems t= o suit >> the name -- "local" should indicate that the "non-local" can be inherite= d from a >> master configuration, perhaps site-wide or pod-specific). >>=20 >> What do you think? I think it would be the "happy median." >>=20 >=20 > I am somewhat sketchy of putting it between the two. Reason being is I=20 > know quite a few people that already place anything that has to do with= =20 > ports(7) into rc.conf.local just to keep it seperate from the systems=20 > rc.conf. >=20 > I can see that raising a few eyebrows. As of right now its thought of tha= t=20 > rc.conf and rc.conf.local get processed consecutively and would have to b= e=20 > explained quite rigorously how they actually fall in order. Only my=20 > opinion though, its up for grabs. >=20 > 1). If its sourced before then it can be considered user pre-defined=20 > defaults.=20 This sounds the most reasonable/desirable. In our hypothetical scenario whe= re the customer controls both rc.conf and rc.conf.local, we'd eventually co= me 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 g= o 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 si= te-wide specifics (NTP server specifics, etc.) are in the global /etc/rc.co= nf (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 ove= rride our /etc/rc.conf.d/product.conf files. Since we want to satisfy the customer, #1 becomes the only sensible approac= h. Sourcing /etc/rc.conf.d/*.conf before rc_conf_files. It then becomes a s= ort of shim to override /etc/defaults/rc.conf (but again, only if the direc= tory /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 -- p= erhaps to be used sparingly and only when the package is for a product that= takes control of a machine, IMHO >=20 > 2). If its sourced after then it becomes user defined overrides for=20 > anything in rc.conf or rc.conf.local=20 >=20 > 3). If placed between then I feel it becomes an extension of rc.conf=20 > leaving rc.conf.local to be the final say on all configs. This is=20 > intentionally what rc.conf.local was meant for anyway. >=20 >=20 > Really I personally do not object to either of the three listed above and= =20 > can see a point of view from all three sides but if I was forced to vote= =20 > for one of them I would probably have to go with 3. User feedback for thi= s=20 > 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 u= tilized (and these files override both rc.conf and rc.conf.local if they ex= ist). 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 /e= tc/defaults/rc.conf. This would allow the files to similarly be sourced any= time 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? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________