Date: Sun, 8 May 2011 15:52:06 -0700 From: Devin Teske <dteske@vicor.com> To: Devin Teske <dteske@vicor.com> Cc: Garrett Cooper <yanegomi@gmail.com>, Jason Hellenthal <jhell@DataIX.net>, freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. Message-ID: <D0B755B8-B222-49F4-BC6D-545231B7384A@vicor.com> In-Reply-To: <F7C06E06-1913-4D29-B37F-7B07A0AE121A@vicor.com> References: <20110508191336.GC3527@DataIX.net> <C7EC90A2-936C-44E1-BC5E-E249399AF9AB@gmail.com> <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> <20110508215432.GG3527@DataIX.net> <F7C06E06-1913-4D29-B37F-7B07A0AE121A@vicor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 8, 2011, at 3:35 PM, Devin Teske wrote: > Jason, >=20 > On May 8, 2011, at 2:54 PM, Jason Hellenthal wrote: >=20 >>=20 >> Devin, >>=20 >> 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 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 >>>=20 >>> First, let me add that I really like the idea. This makes it akin to ou= r /usr/local/apache2/conf.d/ directory where we place our various configs b= y many names, but always ending in `.conf'. >>>=20 >>> I'm anticipating the day where I can have /etc/rc.d/foo.conf and /etc/r= c.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 = think you just made my -- and everyone else whom uses jails -- day/week/mon= th/year). >>>=20 >>> However, I agree with GC that depending on a .conf file to be executabl= e 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 re= quire both `.sh' suffix and executable bits; but that is not to condone tre= ating `rc.conf.d' like `rc.d' in any way). >>>=20 >>=20 >> 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 >=20 > What about: >=20 > cd /etc/rc.conf.d > mv myfoo.conf{,.bak} >=20 > Simply renaming the file to not end in ".conf" should suffice. This shoul= d counter the need for checking if the file is executable (which I still cl= aim is a bit odd). >=20 >=20 >> mainly why I have put that in place. It allows a lot of flexibility with= out=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. >>=20 >> 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 in= it=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. >=20 > Wouldn't it be easier to explain to a novice that "if the file ends in ``= .conf''" (period) rather than "if the file ends in ``.conf'' and its execut= able bit is set"? >=20 > I'd think the former is simpler than the latter and that the user can sim= ply use mv(1). >=20 >=20 >>=20 >> I really don't want to see the rc system subjected to a find(1) every ti= me=20 >> it needs to do a load_rc_config since it can be done quicker with in-she= ll=20 >> testing. I think a lot of people would agree with this. >=20 > I didn't say anything about using find (that was GC). But while we're tal= king about it... >=20 > I agree on that point. I'd think this would be much faster (and be tolera= nt of files with spaces in their name; though not newlines): >=20 > ls /etc/rc.conf.d/*.conf | ( IFS=3D' > ' > while read file; do > [ -f "$file" ] || continue > . "$file" || exit $FAILURE > done > ) || debug "something went wrong" >=20 > Keeping to ls(1) and shell builtins. Ignore that implementation. I second Jilles all-builtin solution using `for' globbing (no forking exter= nal processes or sub-shells). Slight modification for brevity: for _modular_conf in /etc/rc.conf.d/*.conf; do [ -f "$_modular_conf" -a -x "$_modular_conf" ] || continue debug "Sourcing $_modular_conf" . "$_modular_conf" done Though I still think it ought to be: for _modular_conf in /etc/rc.conf.d/*.conf; do [ -f "$_modular_conf" ] || continue debug "Sourcing $_modular_conf" . "$_modular_conf" done Tuppence. --=20 Cheers, Devin >=20 >=20 >>=20 >> 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 >=20 > GC and I aren't arguing that the SysV style is not helpful (if I read GC'= s post correctly). Just that these aren't wholly to-be considered SysV syst= em startup scripts, but instead "config files". If they had an interpreter = she-bang (e.g., #!/bin/sh), program-flow, or other logic, I'd not disagree = with the checking of the executable bit. But since these files are by-desig= n going to nearly always be KEY=3DVALUE pairs, I find it odd to think of th= em as anything other than just regular text files. >=20 > I think of the files in /etc/rc.conf.d/ as extensions of rc.conf(5) and t= he notion that permissions might possibly matter on rc.conf(5) would be equ= ally foreign to me. >=20 > I'm aware that both rc.conf(5), the local variant, and newly-conceived rc= .conf.d/*.conf are really in-truth just shell scripts sourced into the curr= ent interpreter. So in-reality they can contain any valid sh(1) syntax. Tho= ugh in-practice the only script of its kind that routinely contains more th= an just KEY=3DVALUE pairs is /etc/defaults/rc.conf (which defines the `sour= ce_rc_confs' function). >=20 > However, I find it to be more common that engineers and technicians think= of rc.conf(5) as a flat text file, and thus will think of the `*.conf' fil= es in /etc/rc.conf.d/ similarly, as text files. Thus it is my objection tha= t the any permission other than the read-bit be checked. >=20 >=20 >> back. If feed back is strong discouraging it then we can probably come t= o=20 >> common ground and find a way to work with both those who would like it a= nd=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. >=20 > I think that I could live with the read-bit being a toggle. However, the = more experienced user may scratch his head, rationalizing that `root' shoul= d be able to read anything (that is, unless something explicitly prevents i= t such as perhaps TrustedBSD MACs). >=20 > Right now, I'm still thinking that the best solution is to: >=20 > a. Put into packages: /etc/rc.conf.d/name.conf.sample > b. User enablement: mv /etc/rc.conf.d/name.conf{.sample,} > c. User disablement: mv /etc/rc.conf.d/name.conf{,.bak} >=20 > That's at least how I tend to think/operate. I know I can't speak for all= of the dozens of field engineers in our corporation, but I've at least wit= nessed this behavior as a standard while troubleshooting machines. >=20 >=20 >> Thanks you again Devin, Appreciate the feedback. >=20 > No problem. I always appreciate yours as well. > --=20 > Devin >=20 > _____________ >=20 > The information contained in this message is proprietary and/or confident= ial. If you are not the intended recipient, please: (i) delete the message = and all copies; (ii) do not disclose, distribute or use the message in any = manner; and (iii) notify the sender immediately. In addition, please be awa= re that any message addressed to our domain is subject to archiving and rev= iew by persons other than the intended recipient. Thank you. > _____________ > _______________________________________________ > freebsd-rc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-rc > To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0B755B8-B222-49F4-BC6D-545231B7384A>