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

Sun May 8 22:35:40 UTC 2011

Jason,

On May 8, 2011, at 2:54 PM, Jason Hellenthal wrote:

> 
> 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 

What about:

	cd /etc/rc.conf.d
	mv myfoo.conf{,.bak}

Simply renaming the file to not end in ".conf" should suffice. This should counter the need for checking if the file is executable (which I still claim is a bit odd).

> 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.

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 executable bit is set"?

I'd think the former is simpler than the latter and that the user can simply use mv(1).

> 
> 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 didn't say anything about using find (that was GC). But while we're talking about it...

I agree on that point. I'd think this would be much faster (and be tolerant of files with spaces in their name; though not newlines):

ls /etc/rc.conf.d/*.conf | ( IFS='
'
	while read file; do
		[ -f "$file" ] || continue
		. "$file" || exit $FAILURE
	done
) || debug "something went wrong"

Keeping to ls(1) and shell builtins.

> 
> 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 

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 system 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-design going to nearly always be KEY=VALUE pairs, I find it odd to think of them as anything other than just regular text files.

I think of the files in /etc/rc.conf.d/ as extensions of rc.conf(5) and the notion that permissions might possibly matter on rc.conf(5) would be equally foreign to me.

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 current interpreter. So in-reality they can contain any valid sh(1) syntax. Though in-practice the only script of its kind that routinely contains more than just KEY=VALUE pairs is /etc/defaults/rc.conf (which defines the `source_rc_confs' function).

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' files in /etc/rc.conf.d/ similarly, as text files. Thus it is my objection that the any permission other than the read-bit be checked.

> 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.

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' should be able to read anything (that is, unless something explicitly prevents it such as perhaps TrustedBSD MACs).

Right now, I'm still thinking that the best solution is to:

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}

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 witnessed this behavior as a standard while troubleshooting machines.

> Thanks you again Devin, Appreciate the feedback.

No problem. I always appreciate yours as well.
-- 
Devin

_____________

The information contained in this message is proprietary and/or confidential. 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 aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________