[RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace.

Sun May 8 21:54:41 UTC 2011

Devin,

On Sun, May 08, 2011 at 01:59:40PM -0700, Devin Teske wrote:
> 
> On May 8, 2011, at 1:13 PM, Garrett Cooper wrote:
> 
> > On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote:
> > 
> >> 
> >> List, - Please reply-to freebsd-rc at 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:  As 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= 
> >> 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
> > 
> > 	Doing:
> > 
> > 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
> > 
> > 	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.
> > 
> 
> 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'.
> 
> 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.
> 
> 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/month/year).
> 
> 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 require both `.sh' suffix and executable bits; but that is not to condone treating `rc.conf.d' like `rc.d' in any way).
>

I do agree with the -x bit concern yes. But thinking of the users to 
enable disable a particular config without having to open a editor is 
mainly why I have put that in place. It allows a lot of flexibility without 
a lot of extra work while also introducing the ability to check if a 
particular configuration is enabled by checking the bit rather than 
sourcing for a _enable.

Since these are only config files there will/should never be a 
config_enable for them as they are only config's, so providing a SysV init 
style way of enabling/disabling them at will is prime. using mv(1), rm(1) 
or possibly having to open a editor on multiple versions of the same 
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 
it needs to do a load_rc_config since it can be done quicker with in-shell 
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 
enabling disabling scripts give it a try for a couple weeks then report 
back. If feed back is strong discouraging it then we can probably come to 
common ground and find a way to work with both those who would like it and 
those who don't by default. I do have a pretty good idea what would work 
to make it happen both ways but I really would like to advocate this in 
place as it is now first.

Thanks you again Devin, Appreciate the feedback.

-- 

 Regards, (jhell)
 Jason Hellenthal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20110508/1b74c939/attachment.pgp