Date: Sun, 8 May 2011 14:19:17 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Jason Hellenthal <jhell@DataIX.net> Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. Message-ID: <D1670EA4-437A-4D79-A5FC-8EE4D05466BA@gmail.com> In-Reply-To: <20110508202636.GF3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <C7EC90A2-936C-44E1-BC5E-E249399AF9AB@gmail.com> <20110508202636.GF3527@DataIX.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 8, 2011, at 1:26 PM, Jason Hellenthal wrote: >=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 = 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 = have=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_config=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 = for=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 = undisturbed=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.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 = something=20 >>> in the rc.conf file and left to discover what you just disabled was = also=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 = aspects=20 >>> of the configuration system that deals with the rc.conf.d directory = with 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 = feedback=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 to 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 necessarily 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). Yes, but the above method used avoids simple E2BIG problems. It just = doesn't properly deal with filenames that break on IFS, etc though = (that's part of where I was leading, but I said "security" instead. > 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. Yes that's true. BTW, what about $local_startup? > I do like the approach though. Thank you. Thanks :). -Garrett=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D1670EA4-437A-4D79-A5FC-8EE4D05466BA>