Subject: Re: `rc.local.conf': bad name
To: None <tech-userlevel@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 07/31/2000 12:49:24
[ On Monday, July 31, 2000 at 15:37:37 (+0100), Andy Doran wrote: ]
> Subject: Re: `rc.local.conf': bad name
>
> Simon Burge <simonb@netbsd.org> wrote:
> 
> > Todd Vierling wrote:
> > 
> > > This isn't a config file for rc.local; it's a local configuration overrides
> > > file for rc.conf.  Therefore, shouldn't this be named `rc.conf.local' (note
> > > the swap of the last two parts)?
> >
> > If I recall correctly, the logic was that all config files end in ".conf".
> > Eg, "less /etc/*.conf".
> 
> The rc.local.conf thing is irritatating. I agree with Todd.

Me TOO!  I've already changed it to /etc/rc.conf.local in my systems.

The issue of course is how do you provide a template file for the user
to edit without creating a merge nightmare.

I've been torn between the FreeBSD scheme of moving rc.conf to
/etc/defaults; and the idea of gettting rid of it completely,
incorporating the defaults directly into the various scripts.

In either case you'd start with an almost entirely empty /etc/rc.conf
(i.e. with just a comment at the top referring to the relevant
documentation).

For the latter I would suggest providing a simple hook in /etc/rc.subr
et al that'll spit out the user-adjustable values in sh syntax.  The
user could append that output to /etc/rc.conf and edit it to suite,
hopefully only keeping those values that have been changed from their
defaults.

The other "solution" is to do something like what Postfix does that'll
keep the same full /etc/rc.conf template and encourage people to edit it
directly.  Then provide a command (ala 'postconf -n') that'll print only
the non-default settings so that these can be applied to a new copy of
/etc/rc.conf.  This probably does mean storing the defaults directly in
the script(s) in such a way that they can still be examined after the
current configuration is loaded, and indeed so that a template
/etc/rc.conf can be generated directly with all the defaults.  Then so
long as the old scripts are kept during an upgrade the admin can use
them to dump the old configuration changes and make sure that they've
all been preserved once they've been applied to the new /etc/rc.conf and
indeed much of this could be automated in the long run.

-- 
							Greg A. Woods

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