Date: Sun, 8 May 2011 18:08:32 -0400 From: Jason Hellenthal <jhell@DataIX.net> To: Garrett Cooper <yanegomi@gmail.com> Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. Message-ID: <20110508220832.GH3527@DataIX.net> In-Reply-To: <D1670EA4-437A-4D79-A5FC-8EE4D05466BA@gmail.com> References: <20110508191336.GC3527@DataIX.net> <C7EC90A2-936C-44E1-BC5E-E249399AF9AB@gmail.com> <20110508202636.GF3527@DataIX.net> <D1670EA4-437A-4D79-A5FC-8EE4D05466BA@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Pql/uPZNXIm1JCle Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Garrett, On Sun, May 08, 2011 at 02:19:17PM -0700, Garrett Cooper wrote: > On May 8, 2011, at 1:26 PM, Jason Hellenthal wrote: >=20 > >=20 > > Garrett, > >=20 > > 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 th= at=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 = have=20 > >>> patched it up... > >>>=20 > >>> Let me explain: As determined by rc.subr load_rc_config, config's fr= om=20 > >>> rc.conf.d are loaded by the scripts $name as an argument to load_rc_c= onfig=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 inconvenien= t as=20 > >>> the user has no direct way to know that a variable used by nfsd is al= so=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 = for=20 > >>> the user to utilize by rc.conf(5) but yet without much knowledge of t= he=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 configurati= on=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 undistur= bed=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 = to=20 > >>> turn a configuration file off by using chmod(1). You can turn nfsc1.c= onf > >>> 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 someth= ing=20 > >>> in the rc.conf file and left to discover what you just disabled was a= lso=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 f= or=20 > >>> another. > >>>=20 > >>>=20 > >>> This is a small addition that fixes currently broken undesirable aspe= cts=20 > >>> of the configuration system that deals with the rc.conf.d directory w= ith 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 feed= back=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 -p= erm +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 don= e to make this more secure/robust using "-print0" | xargs, but it's up to y= ou 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 n= ecessarily the best course of action. > >=20 > > 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). >=20 > Yes, but the above method used avoids simple E2BIG problems. It just does= n't properly deal with filenames that break on IFS, etc though (that's part= of where I was leading, but I said "security" instead. >=20 > > As for the security sense if someone has a way to write to that directo= ry=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 su= n!=20 > > plus anyting under most of the rest of the system. >=20 > Yes that's true. BTW, what about $local_startup? I can do that. I can see why that would be an awesome aspect to provide.=20 If its available it would be nice if ports could just dump example configs= =20 in there un-enabled waiting to be edited. Ill get to that in a while. At least for the moment the same thing is=20 still possible through /etc/rc.conf.d/ for any port that uses the rc=20 subsystem as it works just like rc.conf. >=20 > > I do like the approach though. Thank you. >=20 --=20 Regards, (jhell) Jason Hellenthal --Pql/uPZNXIm1JCle Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxxRfAAoJEJBXh4mJ2FR+eroIAJ+ArcIPmOg/jHQpMTdq+hDW CBUeoKZBGWmbZFwwtB3jfBHMOAdsy4ehKyimnDQx/yv1BskEs+FiY+nmZcDEcW94 PKZzOoCOv+tz5hIxHj33m9d5QTBhFxst0Y1HMSZfr/zKDB7ho32RzE41FtsHDENF 0Gn6q6CZFW81OLEeoihrwwJ+iEjNdmSAUcASID3T1JLmDlNB3Zke/yELyP0/AfSe eG41WZHux/7IUOX+a/1a2D9Zmwhfet/w9PmHsFPiRqyWfvC1DAL9ZZl2S1618Gq5 D2f/S29HeSvfIncMh2v5+wwyyoBVN2xQrGBJPuDlfGLBQHvFiFDF+AL2+PKA2r4= =tbvP -----END PGP SIGNATURE----- --Pql/uPZNXIm1JCle--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110508220832.GH3527>