Date:        Thu, 30 Mar 2000 03:10:33 +0100 (BST)
    From:        Scott Aaron Bamford <sab@ansic.net>
    Message-ID:  <Pine.NEB.4.21.0003300304430.10034-100000@blip.fish.poo>


  | thats the start of my current /etc/rc.d/named , set up that way so rc.conf
  | overrides the individuals

I would still prefer not to have an rc.conf at all.

  | if you move it to read:
  | 
  | . /etc/rc.subr
  | . /etc/rc.conf
  | 
  | named=YES               named_flags=""
  | 
  | then the flags in the file override /etc/rc.conf

Which has what purpose left exactly?   To define rc_configured ?

  | so my named manager with rights
  | to /etc/rc.d/named can only change it.

Yes, that's fine, but not optimal.   Rights to change /etc/rc.d/named
isn't what I had in mind.   The ability to change a startup script is the
same as the ability to do anything at all, as that script can do anything
at all.   The ability to control what args are passed to named, and
whether or not named is started provides much less of an opportunity to
make a mess.

Hence I'd prefer something like

	. /etc/rc.subr
	named=NO		named_flags=""

(default to off in the script for most things, though a few make sense
to default to on)

	if opt_enabled named
	then
		named=YES
		named_flags=$( opt_flags named $)
	fi

Not just ". /etc/opts/named" or something, as then anything can be put
in that script.

But the opt_enabled function can be redefined at particular sites to
work however they desire it - if rc.conf is what they like, then it
could be as simple as

	. /etc/rc.conf
	checkyesno $1
	return $?

or it could be something much more protected (eg: an enhanced version of)

	case $(grep "^$1=" /etc/opts/$1 $) in
	*YES)	return 0;;
	*NO)	return 1;;
	esac

so it provides an individual file per option, and no opportunity
at all for commands in that file to get executed.

kre