From owner-freebsd-rc@FreeBSD.ORG Sun May 8 21:54:41 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 B9D8D106566C for ; Sun, 8 May 2011 21:54:41 +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 6CC648FC12 for ; Sun, 8 May 2011 21:54:41 +0000 (UTC) Received: by iwn33 with SMTP id 33so5507236iwn.13 for ; Sun, 08 May 2011 14:54:40 -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=gR+wdfx0INHZlFKB05JEFQnLJ0OkBNhc21+nb6UAuCM=; b=brhbLVFY0Be2DfD5AcSF4igTXHKjPk6Msyh7P+R15xYupoI6MgonIO8TGcqoKhMjwY H/K7dy6SFYbnI+8T9GWxBpZaf1DmyOq9IA90gKATCB7L7E4amCDR2FRchlOBHMUkV7Ov XkNjVkmB1eurjrd/w6oAwO04XMu4VE630zQ6Y= 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=hznuZrMTZ+BWicJMOO5lHcWYYAruepVIcQf7Urls9yjqlpuX0WjINZMSWShyzjx78H dSfIfPmc3QMIij3mxgfU1tW1v/Hboud4SciAegvgWoawugTib6jOk12+llTrVKls1uwu XDpKgsWoNm1Mv6OHRHRarqzCOFAhiGSt3q5Co= Received: by 10.42.133.72 with SMTP id g8mr5566466ict.80.1304891680276; Sun, 08 May 2011 14:54:40 -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 y10sm2346551iba.29.2011.05.08.14.54.38 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 14:54: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 p48LsYdj013411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 17:54:35 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48LsWu6013410; Sun, 8 May 2011 17:54:32 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 17:54:32 -0400 From: Jason Hellenthal To: Devin Teske Message-ID: <20110508215432.GG3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ryJZkp9/svQ58syV" Content-Disposition: inline In-Reply-To: <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> 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: Garrett Cooper , 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 21:54:41 -0000 --ryJZkp9/svQ58syV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Devin, On Sun, May 08, 2011 at 01:59:40PM -0700, Devin Teske wrote: >=20 > On May 8, 2011, at 1:13 PM, Garrett Cooper wrote: >=20 > > 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 tha= t=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 h= ave=20 > >> patched it up... > >>=20 > >> Let me explain: As determined by rc.subr load_rc_config, config's fro= m=20 > >> rc.conf.d are loaded by the scripts $name as an argument to load_rc_co= nfig=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 als= o=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 f= or=20 > >> the user to utilize by rc.conf(5) but yet without much knowledge of th= e=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 configuratio= n=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 undisturb= ed=20 > >> while allowing the user to create config's by any name they so desire = as=20 > >> long as it has an extension of ".conf", also introducing the ability t= o=20 > >> turn a configuration file off by using chmod(1). You can turn nfsc1.co= nf > >> 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 somethi= ng=20 > >> in the rc.conf file and left to discover what you just disabled was al= so=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 fo= r=20 > >> another. > >>=20 > >>=20 > >> This is a small addition that fixes currently broken undesirable aspec= ts=20 > >> of the configuration system that deals with the rc.conf.d directory wi= th 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 feedb= ack=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 -pe= rm +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= to make this more secure/robust using "-print0" | xargs, but it's up to yo= u 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 ne= cessarily the best course of action. > >=20 >=20 > First, let me add that I really like the idea. This makes it akin to our = /usr/local/apache2/conf.d/ directory where we place our various configs by = many names, but always ending in `.conf'. >=20 > I'm anticipating the day where I can have /etc/rc.d/foo.conf and /etc/rc.= d/bar.conf, each configuring multiple (likely unrelated) services. >=20 > Better still, /etc/rc.d/jail1.conf, /etc/rc.d/jail2.conf, etc. etc. (I th= ink you just made my -- and everyone else whom uses jails -- day/week/month= /year). >=20 > However, I agree with GC that depending on a .conf file to be executable = is a bit non-standard, even if it is sourced like a shell-script (though I = can understand the historical heritage as /usr/local/etc/rc.d/ used to requ= ire both `.sh' suffix and executable bits; but that is not to condone treat= ing `rc.conf.d' like `rc.d' in any way). > I do agree with the -x bit concern yes. But thinking of the users to=20 enable disable a particular config without having to open a editor is=20 mainly why I have put that in place. It allows a lot of flexibility without= =20 a lot of extra work while also introducing the ability to check if a=20 particular configuration is enabled by checking the bit rather than=20 sourcing for a _enable. Since these are only config files there will/should never be a=20 config_enable for them as they are only config's, so providing a SysV init= =20 style way of enabling/disabling them at will is prime. using mv(1), rm(1)= =20 or possibly having to open a editor on multiple versions of the same=20 config to disable a certain portion is far from ideal. I really don't want to see the rc system subjected to a find(1) every time= =20 it needs to do a load_rc_config since it can be done quicker with in-shell= =20 testing. I think a lot of people would agree with this. I would suggest at least for those that doubt the SysV style way of=20 enabling disabling scripts give it a try for a couple weeks then report=20 back. If feed back is strong discouraging it then we can probably come to= =20 common ground and find a way to work with both those who would like it and= =20 those who don't by default. I do have a pretty good idea what would work=20 to make it happen both ways but I really would like to advocate this in=20 place as it is now first. Thanks you again Devin, Appreciate the feedback. --=20 Regards, (jhell) Jason Hellenthal --ryJZkp9/svQ58syV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxxEYAAoJEJBXh4mJ2FR+hSYH/2/h5KU+v/wqH46BKLqHDZbN iYygPjp4c3QI8ZDimL7t13XxCtg5zndvLEr09qsG5g085mvHuY3PMitPOlQ5rcX9 1Q0TH1+tlWl9X92qCEfRoSGDS3Rs3otvfsOzeeZbxMgBxy1bU5mNNdfylZ6l/A05 p80K+/gYZqN0U2BNOOeFy2bb1qCfBiVDuk3n0XaIKQJdUKs1vr4GMNKd54Ft5r/9 spr2R0FtDSgk2cFzH+s5tbuFmgH4Yyg3Z7n+0bL8mDr5vTNVVXZDTCEGdoGUihXp X6moaipShOBtXIew6oWt86lVNYUG2I80o40z/1Q59aGvKQ3Nt+JuPwDgxuFmCJM= =q7WR -----END PGP SIGNATURE----- --ryJZkp9/svQ58syV--