From owner-freebsd-rc@FreeBSD.ORG Tue May 10 05:35:39 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 271581065673; Tue, 10 May 2011 05:35:39 +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 C1E1A8FC1E; Tue, 10 May 2011 05:35:38 +0000 (UTC) Received: by iwn33 with SMTP id 33so6978059iwn.13 for ; Mon, 09 May 2011 22:35:38 -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=M7X8puAIzoPXJyQ71JPPBVElIKON5sM3tLSgSi7QyfM=; b=bLODkbn1bIPSQKAxT1Pqi6DECQf7krs7yIckw02HLjoPaBHjzfpPNSIWjpwZthugSU dK7swtS3rnoy5Emc/09sHb1LoWUlPII/DTlcGktfO9ZT1UzlYRIAYovdnziMg9u2BEkt 4DdaMUaH/gwk2FtBuioUst8bQWpCwhAdq5oq0= 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=P9DQf8EOBjLqcOSHSohF+kcjN+KbcxUwo44JBwmFiqSDw0zHyM0y9eRLylbX48BXEn Zm8inEcB7W4hUOYcDCQLBajjBWKDr4NqsM9szpV/dfTDF7DY9lKF4NzWopO1GIWwPp+0 XdyFO0m8in5EmagHJs+27Hu9bUhF1lQW4iBoQ= Received: by 10.42.159.65 with SMTP id k1mr7486094icx.174.1305005738117; Mon, 09 May 2011 22:35:38 -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 uf10sm2719914icb.5.2011.05.09.22.35.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 22:35:37 -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 p4A5ZYqi032171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2011 01:35:34 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4A5ZYSP032170; Tue, 10 May 2011 01:35:34 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 10 May 2011 01:35:34 -0400 From: Jason Hellenthal To: Doug Barton Message-ID: <20110510053534.GD18435@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org> <20110509235746.GC2558@DataIX.net> <4DC8A592.2090202@FreeBSD.org> <20110510040822.GB18435@DataIX.net> <4DC8C52E.9040203@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u65IjBhB3TIa72Vp" Content-Disposition: inline In-Reply-To: <4DC8C52E.9040203@FreeBSD.org> 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: 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:35:39 -0000 --u65IjBhB3TIa72Vp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 09, 2011 at 09:55:10PM -0700, Doug Barton wrote: > This will be my last post on this topic unless something new arises.=20 > Please don't cc me on any more responses. >=20 > On 05/09/2011 21:08, Jason Hellenthal wrote: > > > > Doug, > > > > On Mon, May 09, 2011 at 07:40:18PM -0700, Doug Barton wrote: > >> On 05/09/2011 16:57, Jason Hellenthal wrote: > >>> > >>> Doug, > >>> > >>> On Mon, May 09, 2011 at 04:27:54PM -0700, Doug Barton wrote: > >> > >>> Sorry Doug but rc.conf.d is already laid out for the user to use as > >>> mentioned by rc.conf(5) with a suggested use but unfortunately has qu= ite a > >>> few side effects that I am not going to bother re-writing about again. > >> > >> I read what you have written to date, but I don't see anything other > >> than "It doesn't work the way I want it to." I just re-read the > >> description in rc.conf.5, and I think it's clear, but I wouldn't object > >> to suggestions to improve it. > >> > >>> In reply to your previous email here is one exercise that should point > >>> out the broken functionality fairly clearly or at least I hope clearly > >>> enough that you realize how a normal user would look at it. > >>> > >>> From scratch, no rc.conf. > >> > >> No normal user would do that, so I reject your premise. :) > >> > > > > Ok let me re-state that because you seem to have taken that litterally = as > > absolutely no rc.conf. "A rc.conf but without the needed nfs related > > parts" This is an example!. >=20 > Hence the smiley. >=20 > >>> Setup a NFS server with lockd, statd, mountd, > >>> rpcbind using only rc.conf.d/${_name} namespace and then try starting > >>> these services using service(8) and /etc/rc.d/* files. Then read > >>> rc.conf(5) and tell me the suggestion for jail makes sense. > >> > >> The various nfs-related options are a particularly pathological case, = no > >> one is disputing that. However, for the vast majority of purposes the > >> one-name-at-a-time method works fine. And given that most users don't > >> need anything even approaching the type of functionality that you're > >> proposing, I still don't see a problem. > >> > > > > I was not asking your you opinion of the way it works. You asked for an > > example and one was given and you seem to be all opposed to even going > > through and testing out that example to see where the stumbling blocks = are > > as you apparently have no recognition of them now. NFS is not the only = case. >=20 > To the extent I understand your paragraph above, I don't think you=20 > really understand where I'm coming from at all. I don't need to follow=20 > your suggestion, I already know that for the particular pathological=20 > case you described the rc.conf.d method is not appropriate. >=20 > What you seem to be missing is that your suggestion is not necessary to= =20 > solve the problem. To the extent that it is necessary to provide a=20 > solution to this at all, multiple solutions already exist. >=20 > >>> I do not quite understand why you take such an opposition against > >>> something that fixes this broken functionality but yet retains its > >>> original use. > >> > >> Gordon has already stated it fairly eloquently, but I'll paraphrase. T= oo > >> much potential for user confusion, for too little benefit. I realize > >> that to you this sounds like a simple change, but the problem is that > >> when you add knobs, users twist them. So every change to something as > >> fundamental as the boot system needs to have really strong justificati= on. > >> > > > > Sadly at this point you still seem to not realize the complicated state > > that rc.conf.d is in. >=20 > I hope you'll understand if once again I respectfully disagree. >=20 > > This is not adding a new knob >=20 > I was using that in the colloquial sense. If you give users the chance=20 > to do something, some percentage of them will do it. >=20 > > and you seem to miss > > that part as well. This fixes that complication on the rc.conf.d direct= ory > > and it could be properly implemented in a way that it should have been = in > > the first place as the manual suggests. > > > > > > What do you propose to do with the manual page ? >=20 > What I'm saying is that IMO there is nothing in rc.conf.5 that is=20 > confusing, and if you believe that it needs to be clarified please feel= =20 > free to submit suggestions. >=20 Unfortuneately at Doug's request this will not be CC'd, but this is also=20 the intention of this thread as well. As stated earlier in the thread with= =20 my proposal to tidy this up I also said that once it is laid out for=20 something that is agreed upon that I would update the manual accordingly.= =20 Doing this before the said seen needed fixes to uncomplicate the use of=20 rc.conf.d would be be a great loss of time as it would require documenting= =20 every rc.d script, the names that are exported from them and putting=20 together every combination of such. This type of complexity is what is=20 trying to be avoided while still allowing the user to create well named=20 organized custom configurations. --=20 Regards, (jhell) Jason Hellenthal --u65IjBhB3TIa72Vp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyM6lAAoJEJBXh4mJ2FR+MR0IAIByeg1uoH3xqXKpWdAuc8U2 yIleF39vTuxowgTjn8kyk42UbHjcsKkIF+rV2L1BFyG5TwK4HDwwVaKGJ10OURby gEIIYWyBDyTtODaBDGtFG6uHc3aAXJF1DoV6LgIP1VVMk0kBU7vupk+6Og+xLaZc S1dzYEbPoSiHcgjw+dKqCr6IDO1AJHuXlk2/nBCgF4ao2GASjVNoeoHpgHR+ik+I un9tSftb4XcYAFnZEPTRglLVb0Ms5IcEVmHuk81sCdWz9tf0OjpdW6DYsIutrrff I71CWyocluBp/0ghOkLNlPxhza+vyGsmofxEd4Nib82VaGEaLEdq7ObKXc0wjcU= =ekDW -----END PGP SIGNATURE----- --u65IjBhB3TIa72Vp--