From owner-freebsd-rc@FreeBSD.ORG Tue May 10 05:15:19 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 4B159106564A; Tue, 10 May 2011 05:15:19 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E3D5A8FC08; Tue, 10 May 2011 05:15:18 +0000 (UTC) Received: by iwn33 with SMTP id 33so6964626iwn.13 for ; Mon, 09 May 2011 22:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=O2v5xW54aCLogi78+TGc4Iin4yAPzgCEQn2Bqy1F7js=; b=JbCSWnXbYay3a0Xzmu2isCtj2iKZmQTzKo5qx1OUg2LKULrrFknqxf08PJUoYm+Fxk nKA3AueeHueXBII18m2jlwjuKYHPrxENWAdDhmbPTjpYtGMVmIV7BWiFDZk3/4j7DOp0 K1883wSeeujMHgjf2M/URdoJLTfhqtXjGBIKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=K7eJz85ZiQbNDjm7kh9pel2K5O+h0QS3n7GUecojQmvMu4r5pseJWhs13M/oLkCHp/ VjLnwXxErARH06LrW2Eyq6p/pQzxofdDo4Nz/wW+0fpZJAba+BwMfwJ4BAPYEbhkCGTo Zqwj1ffOcsDVgysCylEo8fe6p9TxuLTdo2djY= Received: by 10.43.54.200 with SMTP id vv8mr7110872icb.378.1305004518325; Mon, 09 May 2011 22:15:18 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id t1sm2958207ibm.38.2011.05.09.22.15.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 22:15:17 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4A5FEeI031464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2011 01:15:14 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4A5FEdD031463; Tue, 10 May 2011 01:15:14 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 10 May 2011 01:15:13 -0400 From: Jason Hellenthal To: Devin Teske Message-ID: <20110510051513.GC18435@DataIX.net> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O3RTKUHj+75w1tg5" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E 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 05:15:19 -0000 --O3RTKUHj+75w1tg5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Devin, On Mon, May 09, 2011 at 08:39:25PM -0700, Devin Teske wrote: >=20 > On May 9, 2011, at 8:07 PM, Jason Hellenthal wrote: >=20 > >=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 w= ith > >> 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/produ= ct.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 realiz= ed that if > >> you sourced them in-between the two files, that you could accommodate = both > >> 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 woul= d override > >> that. And finally, /etc/rc.conf.local would be end-all-be-all of overr= ides. > >> 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 inheri= ted 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 t= hat=20 > > rc.conf and rc.conf.local get processed consecutively and would have to= be=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 >=20 > This sounds the most reasonable/desirable. In our hypothetical scenario w= here 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 o= n a per-customer basis. In this case, adding something to their sup(1)/cvsu= p(1)-distributed rc.conf(5) would override the default. Support folks could= go home and the override is in-place, problem solved. >=20 > Conversely for either of the below scenarios, adding an override would th= en become more difficult. Ultimately in our scenario, the ifconfig_* elemen= ts 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 th= e rc_conf_files, the customer would be frustrated and end up throwing an /e= tc/rc.conf.d/zzz.conf into their sup(1)/cvsup(1) distributed directory to o= verride our /etc/rc.conf.d/product.conf files. >=20 > Since we want to satisfy the customer, #1 becomes the only sensible appro= ach. 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 dir= ectory /etc/rc.conf.d exists, which it shouldn't by-default in any installe= d distribution unless the owner/operator/developer adds one). >=20 > 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 th= at takes control of a machine, IMHO >=20 >=20 >=20 > >=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 a= nd=20 > > can see a point of view from all three sides but if I was forced to vot= e=20 > > for one of them I would probably have to go with 3. User feedback for t= his=20 > > type of thing is greatly needed & appreciated. >=20 > It was upon second thought that I actually have to change my vote to be #= 1 as the best option. >=20 > That would make /etc/rc.conf.d two things: >=20 > 1. /etc/rc.conf.d/NAME where NAME is /etc/rc.d/NAME or /usr/local/etc/rc.= d/NAME >=20 > 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). >=20 > 2. /etc/rc.conf.d/CUSTOM.conf where CUSTOM is anything you want. >=20 > 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 a= nytime NAME RCNG script is utilized (and these files override the defaults = in /etc/defaults/rc.conf). >=20 > 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. --=20 Regards, (jhell) Jason Hellenthal --O3RTKUHj+75w1tg5 Content-Type: application/pgp-signature -----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----- --O3RTKUHj+75w1tg5--