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

[Devin Teske]

> -----Original Message-----
> From: owner-freebsd-rc at freebsd.org [mailto:owner-freebsd-rc at freebsd.org]
> On Behalf Of Gordon Tetlow
> Sent: Sunday, May 08, 2011 8:21 PM
> To: freebsd-rc at freebsd.org
> Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr
> etc/rc.conf.d/*.conf namespace.
> 
> On Sun, May 8, 2011 at 12:13 PM, Jason Hellenthal <jhell at dataix.net> 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
> 
> The problem with this is you can have 2 files with conflicting statements:
> 
> /etc/rc.conf.d/sshd:
> sshd_enable="YES"
> 
> /etc/rc.conf.d/aaa.conf:
> sshd_enable="NO"
> 
> 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 solve
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/sshd
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 search
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 starting"
or "why is this not starting".


> 
> 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="YES"
> 
> /etc/rc.conf.d/aaa.conf:
> sshd_enable="NO"
> 
> Note if you named it zzz.conf, sshd would not start. This is due to the fact
that the
> patch loads the files in name order.
> 

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 this
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 check 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 should 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 configured in
(though, again admittedly, I need to add support for `rc.conf.d').
-- 
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.
_____________