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

[Jason Hellenthal]

Jilles, & anyone in general, cherry-pick as needed.

On Mon, May 09, 2011 at 12:11:29AM +0200, Jilles Tjoelker wrote:
> I would say the opposite. jhell's original loop
> 
> +		for _modular_conf in /etc/rc.conf.d/*.conf; do
> +			if [ -f "$_modular_conf" -a -x "$_modular_conf" ]; then
> +				debug "Sourcing $_modular_conf"
> +				. $_modular_conf
> +			fi
> +		done
> 
> with a small change
> -				. $_modular_conf
> +				. "$_modular_conf"

Updated in changeset: 63:bf83c2313376, I missed that. Thanks for catching 
it.

I actually thought about adding another check just to be sure the variable 
wasnt empty and adding some text to the debug line like "Sourcing modular 
config $_modular_conf" in case for some reason it was NULL but I don't 
believe that will happen and if it did there is probably more serious 
problems with the system before it even gets to this point.

[ ! -n "$_modular_conf" ] && . "$_modular_conf"

Just to be sure but have not updated it in that way yet.

> 
> does not have any E2BIG problems, and also no problems with special
> characters. This is because the list of pathnames stays within sh; it is
> not passed to another program. If there is no matching file, the loop
> runs once for /etc/rc.conf.d/*.conf which does not exist and is
> therefore not sourced.
> 
> Any 'while read...' loop will handle pathnames with newlines
> incorrectly, and the simple ones also handle backslashes and certain
> whitespace incorrectly. Also, the proposed pipeline does not even work
> as the while loop is executed in a subshell, so the assignments in the
> sourced files are lost.
> 
> This post is not an endorsement of jhell's idea. I am not really
> convinced it is useful. For experimenting, the for command can be placed
> in /etc/rc.conf.
> 

Just to note, using if statements and such within what is normally to be 
determined as a config file can be quite unclean or messy or hard to 
navigate for most that look for a way to shift configurations around. The 
original idea behind this for the motivation is jail,nfs,rpcbind etc.

Where example: 

/etc/rc.conf.d/nfsserver.conf can contain:
* rpcbind_enable
* nfsexample_enable
* nfs_lockd_enable
* nfs_statd_enable

And:
/etc/rc.conf.d/nfsserver_nolocking.conf can contain:
* rpcbind_enable
* nfsexample_enable

And this is where the executable bit becomes handy that allows you to 
quickly chmod(1) one of them and yet still have rpcbind enabled for the 
other or chmod both and nolonger need rpcbind enabled. This can become 
even more extensive for jail use and ifconfig configuration but that is 
byond what could really be summed up on this thread.

The current use of rc.conf.d is nearly broken from the users point of view 
since it requires working knowledge of the names exported by each rc.d 
script in order to place the _enable values in the same name file under 
the rc.conf.d directory and yet while some scripts may not always get that 
value if it is only available under the jail name config. Thats a really 
rought way of handling it. Though I do see that exact facility as being 
useful if a user wanted to dump in some type of shell script to do some 
extra parsing or prestart work for a single instance that runs out of rc.d 
but this is not what rc.conf(5) suggests so it is quite misleading.


And yes I agree! This is the FreeBSD Project and as of this thread the 
modification made is solely that of myself and my view as I have witnessed 
it in the current configuration. And as which needs proper feedback from 
the community & developers before action is taken. This in-turn though is 
an addition/contribution that doesnt impede or change the way 
configuration is already done but to extend the options that are available 
to the end-user in a minimal constructive way. 


Thank you Jilles I appreciate the feedback and I look forward to hearing 
back from everyone.

-- 

 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/20110509/1fb749f8/attachment.pgp