From owner-freebsd-rc@FreeBSD.ORG Mon May 9 13:46:24 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 ADEAF106564A for ; Mon, 9 May 2011 13:46:24 +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 634CA8FC1C for ; Mon, 9 May 2011 13:46:24 +0000 (UTC) Received: by iwn33 with SMTP id 33so6127381iwn.13 for ; Mon, 09 May 2011 06:46:23 -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=YaIx4huGMhiL+rKwdlIUrQRgAQDIHJ7l+kUNDlQ31ts=; b=YSx+2H0U1LnqOUSrk+aNvE6QYIf0znpzYb3t1BbWzj7abHyqf+Z1p6Y+OFH+t/okKr a2fLHLeqIogbdPiGS0yc8FXshkM3Ah9lNf/F0ymukpbfSqkPy0HIM4XAxiYwpgvKU1i3 UzWLsyduGOxiPEKBVkIFnc89IYckJLuCTsohM= 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=cA6bBzGmmCsR6yw/d1XVz3pBbE50lL0qTDJd+IbxsJqZSWLBwcKUJbS4dYssfha4hQ VwiaeqQibNka3mzVFUrAxGrR7HM1uoP4dYa0W3tYmvvaC8f9oRw43PkYqA6WOTrW+hTc 6AXzcquqUD5Vp3tWTVWT9OPiVL+PLHKZfRqik= Received: by 10.42.137.10 with SMTP id w10mr6765151ict.347.1304948783690; Mon, 09 May 2011 06:46:23 -0700 (PDT) Received: from DataIX.net ([99.190.84.116]) by mx.google.com with ESMTPS id c16sm326117ibe.41.2011.05.09.06.46.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 06:46:22 -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 p49DkI30075870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 09:46:18 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p49DkHlo075869; Mon, 9 May 2011 09:46:17 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Mon, 9 May 2011 09:46:17 -0400 From: Jason Hellenthal To: Gordon Tetlow Message-ID: <20110509134617.GA28036@DataIX.net> References: <20110508191336.GC3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" 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: 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: Mon, 09 May 2011 13:46:24 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Gordon, On Sun, May 08, 2011 at 08:20:56PM -0700, Gordon Tetlow wrote: > On Sun, May 8, 2011 at 12:13 PM, Jason Hellenthal wrot= e: > > > > List, - Please reply-to freebsd-rc@freebsd.org > > > > Recently I have been going over some changes in the configurations that > > are possible with the rc subsystem and to my dismay I have found some > > inconsistencies with in particular the way rc.conf.d directory is > > processed and the arguments that are supplied to load_rc_config so I ha= ve > > patched it up... > > > > Let me explain: =A0As determined by rc.subr load_rc_config, config's fr= om > > rc.conf.d are loaded by the scripts $name as an argument to load_rc_con= fig > > and thus only the name being parsed is is available to be used in the > > rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient = as > > the user has no direct way to know that a variable used by nfsd is also > > needed by mountd or the same for various other scripts in the rc.d > > directory. At this time these config's are explained to be available for > > the user to utilize by rc.conf(5) but yet without much knowledge of the > > inner workings of the rc subsystem it would be quite the feat to do. > > > > > > The attachment[1] keeps this functionality the same while introducing a > > more convenient approach for the user to modularize their configuration > > however they see fit within a couple constraints that work very well. > > > > > > What does it do ?: As stated above, current functionality is undisturbed > > while allowing the user to create config's by any name they so desire as > > long as it has an extension of ".conf", also introducing the ability to > > turn a configuration file off by using chmod(1). You can turn nfsc1.conf > > off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > > > > > > Why ? Simple. How many times have you been bitten by disabling something > > in the rc.conf file and left to discover what you just disabled was also > > used by another daemon but that daemon is now not starting ? This is a = way > > to virtualize your configuration allowing you to add multiple _enable=3D > > lines to different configurations for different roles. For instance > > rpcbind is used by both samba and nfs*. With this you can add > > rpcbind_enable to both a configuration for samba and nfs and when you > > disable one service you know that you have not disabled a dependent for > > another. > > > > > > This is a small addition that fixes currently broken undesirable aspects > > of the configuration system that deals with the rc.conf.d directory wit= h a > > SysV style init approach that is just as flexible. This should apply > > cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedba= ck > > has been received Ill update the manual page with any suggestions > > regenerate the patch to accommodate and file a PR. > > > > > > 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch >=20 > The problem with this is you can have 2 files with conflicting statements: >=20 > /etc/rc.conf.d/sshd: > sshd_enable=3D"YES" >=20 > /etc/rc.conf.d/aaa.conf: > sshd_enable=3D"NO" >=20 > It would probably be difficult to figure out that sshd will not start. >=20 Note that this is not really a problem with multiple configuration files=20 that ``you'' create but more-so one that can happen in even the smallest of= =20 single configuration files. This gives you the ability to name the=20 configuration files what you want without restriction and organize them in= =20 a way that fits ``your'' needs. When a part of your configuration becomes= =20 large enough that you feel a need to separate that from the rest and name= =20 it appropriately then this enables you to do exactly that. > It gets even more interesting when you look at the different failure > modes (sshd starts in this case. Note the only difference is the > sshd.conf vs sshd): > /etc/rc.conf.d/sshd.conf: > sshd_enable=3D"YES" >=20 > /etc/rc.conf.d/aaa.conf: > sshd_enable=3D"NO" >=20 > Note if you named it zzz.conf, sshd would not start. This is due to > the fact that the patch loads the files in name order. >=20 > Also, you now have 2 different namespaces colliding in /etc/rc.conf.d: > {name} and *.conf (with *.conf taking priority over {name}). Should I > be naming my scripts /etc/rc.conf.d/ssd.conf or /etc/rc.conf.d/sshd? > It's not clear. Also the fact that the behavior changes based on the > +x bit is a nuance that probably shouldn't be added. We have no > precedent for testing for the execute bit on a configuration file and > I personally wouldn't want to start now. >=20 > I think I generally am of the opinion that everything for service X > should be in /etc/rc.conf.d/X rather than scattering it among a lot of > files. >=20 I hope it wasn't implied anywhere that you should do anything other than=20 what you feel is best with your own configuration. > The fundamental problem you describe is a legitimate one (service Y > has a dependency on X, so autostart X). Perhaps there is another way > to achieve the same results by having the startup for Y detecting that > X is not running an issuing a onestart command to the service? >=20 That is just one small aspect of this but think service groups or profiles= =20 that when you would rather have one service configured in a way that=20 allows it to run different when on a home LAN than it does when your away. Dump you rc.conf to two place. home-lan.conf and away-lan.conf and use=20 chmod to turn one or the other off. You can still have a global set of=20 services enabled in rc.conf but still be able to choose a way for them to= =20 act by adding the _flags or even _enable rc_vars to each. Since this processes after rc.conf* you could treat those config's as just= =20 modifiers to get a certain behavior as they override what is in rc.conf*=20 in the same way that rc.conf overrides etc/defaults/rc.conf. How you name= =20 them can clearly depict what it does as well. This is one reason why I=20 mainly went with adding the -x bit because these can coexist with a full=20 rc.conf but be changed quickly when you want a certain behavior.=20 There is no one configuration that suits everyone, how you implement your= =20 configuration shouldn't be limited to the constraints of having to shell=20 script something out to get what you need. Thanks. --=20 Regards, (jhell) Jason Hellenthal --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNx/AoAAoJEJBXh4mJ2FR+tuUH/RZu2ynZpnX1qi7CCmIKWvqP QKvMWWVeGRE08SY29euvLjwa8fhwMrqhVvEsT/8ZaT8OiNlAwTo2QIxgDniMPrlu qbZ2kVGSQX+N9PeXl3Ah4wquAd1cQLrrFmleyVCEj+R3E2KyLT7FwOMskR4Otbx3 BGLAcI0HQRP3OQJINkwzpcthGkY5L9zmbQe3Xvvde0LUaFYk/+MMOy1H+oFnciWv Agw4jPGjYJERBdFMCiCfEqWItwXSOBSGnUsyQav+OPyq/ZAM3OjnYoMIBraOmwur MRh+kUKj+/fI7kSiW8qrMcqqC2Bo3QtxwsSW27OHU+RSA4wm3E6+ymiUBrjyRIE= =e4Sy -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx--