Date: Mon, 9 May 2011 10:12:24 -0700 From: "Devin Teske" <dteske@vicor.com> To: "'Gordon Tetlow'" <gordon@tetlows.org>, <freebsd-rc@freebsd.org> Subject: RE: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. Message-ID: <01d201cc0e6c$47d4b180$d77e1480$@vicor.com> In-Reply-To: <BANLkTi=hozQBLUC15NsF2rky2OfFW=t_RQ@mail.gmail.com> References: <20110508191336.GC3527@DataIX.net> <BANLkTi=hozQBLUC15NsF2rky2OfFW=t_RQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-freebsd-rc@freebsd.org [mailto:owner-freebsd-rc@freebsd.org] > On Behalf Of Gordon Tetlow > Sent: Sunday, May 08, 2011 8:21 PM > To: freebsd-rc@freebsd.org > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > etc/rc.conf.d/*.conf namespace. >=20 > On Sun, May 8, 2011 at 12:13 PM, Jason Hellenthal <jhell@dataix.net> wrot= e: > > > > List, - Please reply-to freebsd-rc@freebsd.org > > > > Recently I have been going over some changes in the configurations > > that are possible with the rc subsystem and to my dismay I have found > > some inconsistencies with in particular the way rc.conf.d directory is > > processed and the arguments that are supplied to load_rc_config so I > > have patched it up... > > > > Let me explain: =A0As determined by rc.subr load_rc_config, config's > > from rc.conf.d are loaded by the scripts $name as an argument to > > load_rc_config and thus only the name being parsed is is available to > > be used in the rc.conf.d directory. Why is this bad ? Its not! but it > > is inconvenient as the user has no direct way to know that a variable > > used by nfsd is also needed by mountd or the same for various other > > scripts in the rc.d directory. At this time these config's are > > explained to be available for the user to utilize by rc.conf(5) but > > yet without much knowledge of the inner workings of the rc subsystem it > would be quite the feat to do. > > > > > > The attachment[1] keeps this functionality the same while introducing > > a more convenient approach for the user to modularize their > > configuration however they see fit within a couple constraints that work very > well. > > > > > > What does it do ?: As stated above, current functionality is > > undisturbed while allowing the user to create config's by any name > > they so desire as long as it has an extension of ".conf", also > > introducing the ability to 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 > > > > > > Why ? Simple. How many times have you been bitten by disabling > > something in the rc.conf file and left to discover what you just > > disabled was also used by another daemon but that daemon is now not > > starting ? This is a way to virtualize your configuration allowing you > > to add multiple _enable=3D lines to different configurations for > > different roles. For instance rpcbind is used by both samba and nfs*. > > With this you can add rpcbind_enable to both a configuration for samba > > and nfs and when you disable one service you know that you have not > > disabled a dependent for another. > > > > > > This is a small addition that fixes currently broken undesirable > > aspects of the configuration system that deals with the rc.conf.d > > directory with a SysV style init approach that is just as flexible. > > This should apply cleanly to current and stable/8 & 8.2-RELEASE > > systems. Once more feedback has been received Ill update the manual > > page with any suggestions regenerate the patch to accommodate and file = a PR. > > > > > > 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch >=20 > The problem with this is you can have 2 files with conflicting statements: >=20 > /etc/rc.conf.d/sshd: > sshd_enable=3D"YES" >=20 > /etc/rc.conf.d/aaa.conf: > sshd_enable=3D"NO" >=20 > It would probably be difficult to figure out that sshd will not start. Some time ago, I took it as a personal mission to write a script to help so= lve this very issue. Specifically, I wanted a script that could help me answer = this deceptively simple question (which parallels your inference): "Why isn't (insert name) starting?" When talking about RCNG scripts in the `rc.d' directories (either /etc/rc.d= or /usr/local/etc/rc.d), surely you are correct in identifying that multiple rc.conf(5) scripts can contain different ``*_enable'' values. The solution is to have a script that can tell you these two details: 1. What is the final value of ``*_enable'' 2. Which file assigns said final value If you have those two pieces of information, then unraveling a twisted configuration is easier. [Re-]welcome my sysrc(8) script: http://druidbsd.sourceforge.net/download/sysrc.txt Here's an example of how you [hypothetically] would use it to diagnose the = above situation (in which you have ``sshd_enable'' set to YES in /etc/rc.conf.d/s= shd and set to NO in /etc/rc.conf.d/aaa.conf): $ sysrc -v sshd_enable /etc/rc.conf.d/sshd: sshd_enable: YES NOTE: I say "hypothetically" above because [a] /etc/rc.conf.d/*.conf is currently not implemented yet, and [b] my sysrc(8) script does not yet sear= ch through `rc.conf.d'. What I'm proposing is that sysrc(8) could be expanded to support the new rc.conf.d standard, allowing you to solve the problem of "why is this start= ing" or "why is this not starting". >=20 > It gets even more interesting when you look at the different failure modes (sshd > starts in this case. Note the only difference is the sshd.conf vs sshd): > /etc/rc.conf.d/sshd.conf: > sshd_enable=3D"YES" >=20 > /etc/rc.conf.d/aaa.conf: > sshd_enable=3D"NO" >=20 > Note if you named it zzz.conf, sshd would not start. This is due to the f= act that the > patch loads the files in name order. >=20 I recommend sysrc(8) to help solve such confusions (though, admittedly the current version doesn't descend into rc.conf.d -- I'm waiting on some of th= is stuff to solidify before coding support for it). > Also, you now have 2 different namespaces colliding in /etc/rc.conf.d: > {name} and *.conf (with *.conf taking priority over {name}). Should I be naming > my scripts /etc/rc.conf.d/ssd.conf or /etc/rc.conf.d/sshd? > It's not clear. +1 I'm almost thinking that the proper thing to do would be to: 1. Modify the `load_rc_config' function of `/etc/rc.subr' to no longer chec= k for `/etc/rc.conf.d/$_name' 2. Modify the `source_rc_confs' function of `/etc/defaults/rc.conf' to load `/etc/rc.conf.d/*.conf' This would remove confusion over "/etc/rc.conf.d/sshd" versus "/etc/rc.conf.d/sshd.conf" > Also the fact that the behavior changes based on the > +x bit is a nuance that probably shouldn't be added. We have no > precedent for testing for the execute bit on a configuration file and I personally > wouldn't want to start now. +1 (again) > I think I generally am of the opinion that everything for service X shoul= d be in > /etc/rc.conf.d/X rather than scattering it among a lot of files. The scattering becomes a non-issue with sysrc(8) able to tell you where the= last effective assignment to a variable was. Doubly-so with this syntax: sysrc -av Which lists all non-default parameters and the files that they are configur= ed in (though, again admittedly, I need to add support for `rc.conf.d'). --=20 Devin _____________ 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?01d201cc0e6c$47d4b180$d77e1480$>