[ On Thursday, April 18, 2002 at 01:15:20 (-0400), Andrew Brown wrote: ]
> Subject: Re: post-installation and rc.d enhancements
>
> >>> Clearly (?) only a single file for user parameter changes is required.
> >
> >>Exactly. But "/etc/rc.conf" is sourced *before* "/etc/rc.conf.d/$name",
> >
> >That presumably is a bug :-)
> >If the various conf files are processed in the correct order, life is
> >much simpler for everyone.
> 
> no, that's the intended behavior.  rc.conf is for settings.  rc.conf.d
> is for overriding those settings.

more importantly if some system administration assistant tool is going
to muck with rc.conf.d/* files then those things need to be read last so
they can have the final say and the user who only knows how to use the
admin tool will see the desired effect.....

>  rc.conf.d can also provide scoped
> pieces of sh stuff that don't belong in rc.conf.  for example: here's
> my /etc/rc.conf.d/ssh file:
> 
> 	if [ "$sshd" = pkgsrc ]; then
> 		sshd=YES
> 		command="/usr/pkg/sbin/${name}"
> 		required_files="/etc/${name}_config"
> 		start_precmd=:
> 		extra_commands="reload"
> 	fi
> 
> which allows me to set a machine to YES, NO, or pkgsrc.  neat, eh?

No, that's very far from "neat" -- adding more state to what's normally
know to effectively be treated as a boolean flag is nasty, not neat!  ;-)

This, like named, is a perfect example of why multiple namespaces for
rc.d scripts (and configuration parameters) must exist.

The so-called "chaining" scheme is the best way to maintain 100%
consistency between all hierarchies, though with some care it should be
possible to have multiple hierarchies on the root filesystem with the
runtime dependencies mixed, but the configuration parameters separate.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>