[RFC][Change-Request] Create usefulness in rc.subr
etc/rc.conf.d/*.conf namespace.
Jason Hellenthal
jhell at DataIX.net
Sun May 8 22:08:38 UTC 2011
Garrett,
On Sun, May 08, 2011 at 02:19:17PM -0700, Garrett Cooper wrote:
> On May 8, 2011, at 1:26 PM, Jason Hellenthal wrote:
>
> >
> > Garrett,
> >
> > On Sun, May 08, 2011 at 01:13:12PM -0700, 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.
> >
> > Yeah I see what you are getting at there and I came across thinking the
> > same thing. Fortunately /etc/rc.conf.d/*.conf is only one level deep
> > without using find(1).
>
> Yes, but the above method used avoids simple E2BIG problems. It just doesn't properly deal with filenames that break on IFS, etc though (that's part of where I was leading, but I said "security" instead.
>
> > As for the security sense if someone has a way to write to that directory
> > then most likely they are not going to be looking into placing anything in
> > that directory as theyll have rights to change anything under the rc sun!
> > plus anyting under most of the rest of the system.
>
> Yes that's true. BTW, what about $local_startup?
I can do that. I can see why that would be an awesome aspect to provide.
If its available it would be nice if ports could just dump example configs
in there un-enabled waiting to be edited.
Ill get to that in a while. At least for the moment the same thing is
still possible through /etc/rc.conf.d/ for any port that uses the rc
subsystem as it works just like rc.conf.
>
> > I do like the approach though. Thank you.
>
--
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/40ead7bc/attachment.pgp
More information about the freebsd-rc
mailing list