From owner-freebsd-rc@FreeBSD.ORG Sun May 8 20:26:42 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 98157106566C for ; Sun, 8 May 2011 20:26:42 +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 4C9C58FC0A for ; Sun, 8 May 2011 20:26:42 +0000 (UTC) Received: by iwn33 with SMTP id 33so5468114iwn.13 for ; Sun, 08 May 2011 13:26:41 -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=Xv/ViLyyDlfHTzQpsE4ZHI0v+FwHBOQ4MIGXF34dXNk=; b=vFAhS60duTGT+W+PBMMM3Ze8ztLcJIl0p5QpV537SPR7Jd9ENmyxbug14Mgp+PgrMl 1vEzORaFYgDgFpF9gb2nGyP/NIEQgF1PZzgdtal6Nwm2QnF5DWnpCpnEkpOehICc+XO5 VdDpsw0qJ6M+F6ft/y3hT71QfhONqIClmBvV4= 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=CA2Ck6xu6UyRijHMjZWBF+Rtj+sJjQvpuFhukBELICW5GvBGrwYKPZqU2H+n5iJ3XW P1+yv32LqO3vzxI/soqn3tdrm6oZdaq7RNak0RYCsLqQ7I4Ps+TXg1LLZF6oHpkX1gWY 4FJy/mjFVhwq3F26lJIDO9aj8TNb9kWPbNRdU= Received: by 10.43.63.72 with SMTP id xd8mr4965599icb.215.1304886400833; Sun, 08 May 2011 13:26:40 -0700 (PDT) Received: from DataIX.net ([99.190.84.116]) by mx.google.com with ESMTPS id e12sm2121861ics.7.2011.05.08.13.26.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 13:26:39 -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 p48KQaTK010357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 16:26:37 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48KQaiO010356; Sun, 8 May 2011 16:26:36 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 16:26:36 -0400 From: Jason Hellenthal To: Garrett Cooper Message-ID: <20110508202636.GF3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cHMo6Wbp1wrKhbfi" 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: Sun, 08 May 2011 20:26:42 -0000 --cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Garrett, On Sun, May 08, 2011 at 01:13:12PM -0700, Garrett Cooper wrote: > On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote: >=20 > >=20 > > List, - Please reply-to freebsd-rc@freebsd.org > >=20 > > Recently I have been going over some changes in the configurations that= =20 > > are possible with the rc subsystem and to my dismay I have found some= =20 > > inconsistencies with in particular the way rc.conf.d directory is=20 > > processed and the arguments that are supplied to load_rc_config so I ha= ve=20 > > patched it up... > >=20 > > Let me explain: As determined by rc.subr load_rc_config, config's from= =20 > > rc.conf.d are loaded by the scripts $name as an argument to load_rc_con= fig=20 > > and thus only the name being parsed is is available to be used in the= =20 > > rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient = as=20 > > the user has no direct way to know that a variable used by nfsd is also= =20 > > needed by mountd or the same for various other scripts in the rc.d=20 > > directory. At this time these config's are explained to be available fo= r=20 > > the user to utilize by rc.conf(5) but yet without much knowledge of the= =20 > > inner workings of the rc subsystem it would be quite the feat to do. > >=20 > >=20 > > The attachment[1] keeps this functionality the same while introducing a= =20 > > more convenient approach for the user to modularize their configuration= =20 > > however they see fit within a couple constraints that work very well.= =20 > >=20 > >=20 > > What does it do ?: As stated above, current functionality is undisturbe= d=20 > > while allowing the user to create config's by any name they so desire a= s=20 > > long as it has an extension of ".conf", also introducing the ability to= =20 > > 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 > >=20 > >=20 > > Why ? Simple. How many times have you been bitten by disabling somethin= g=20 > > in the rc.conf file and left to discover what you just disabled was als= o=20 > > used by another daemon but that daemon is now not starting ? This is a = way=20 > > to virtualize your configuration allowing you to add multiple _enable= =3D=20 > > lines to different configurations for different roles. For instance=20 > > rpcbind is used by both samba and nfs*. With this you can add=20 > > rpcbind_enable to both a configuration for samba and nfs and when you= =20 > > disable one service you know that you have not disabled a dependent for= =20 > > another. > >=20 > >=20 > > This is a small addition that fixes currently broken undesirable aspect= s=20 > > of the configuration system that deals with the rc.conf.d directory wit= h a=20 > > SysV style init approach that is just as flexible. This should apply=20 > > cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedba= ck=20 > > has been received Ill update the manual page with any suggestions=20 > > regenerate the patch to accommodate and file a PR. > >=20 > >=20 > > 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch >=20 > Doing: >=20 > find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -perm= +111 | while read _modular_conf; do > debug "Sourcing $_modular_conf" > . "$_modular_conf" > done >=20 > might be better. There's some more magic that could ultimately be done t= o make this more secure/robust using "-print0" | xargs, but it's up to you = how you might want to go about solving that problem. > Also, I don't know if depending on a .conf file to be executable is nece= ssarily the best course of action. > Cheers! > -Garrett Yeah I see what you are getting at there and I came across thinking the=20 same thing. Fortunately /etc/rc.conf.d/*.conf is only one level deep=20 without using find(1). As for the security sense if someone has a way to write to that directory= =20 then most likely they are not going to be looking into placing anything in= =20 that directory as theyll have rights to change anything under the rc sun!= =20 plus anyting under most of the rest of the system. I do like the approach though. Thank you. --=20 Regards, (jhell) Jason Hellenthal --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxvx7AAoJEJBXh4mJ2FR+Sg8H/j1SFy+QKO9q/twKyAZKcu+v BLjH4RciB3SeSYX7BDZHM2mbxo81ITERT9D9ONe865AzA57rHOc3BxgdbI/NJ5aK oS4n0cJc/QTpg8g9boG+SIr5Ucq6U2eaQOnWafyvRsCIolqcoyvsqsy9UpTNRQYl lNf7Y1T8FpsG9CPq3+qrd18TM5pAq46gWIJpXy8AFZKjGqR3p7fuVPkfNApr7T+V 5zVtuCYkrS1aL+nBUF1Bihct1u694X9XUTiRL0oMM8JmVFAc7dY14Rb0wtq1LKYJ 7jHibCa7YoatMHdHMEVb7q7ClCFu752h3jL+F4z0ce2WK21J1QBfxN3R8uoXp4M= =DEMi -----END PGP SIGNATURE----- --cHMo6Wbp1wrKhbfi--