Subject: Re: An idea to simplify future updates of (some) /etc files for new releases
To: Ted Lemon <>
From: Curt Sampson <>
List: current-users
Date: 06/06/1997 00:36:10
On Thu, 5 Jun 1997, Ted Lemon wrote:

> Maybe the right solution to the /etc/rc.conf question is to have the
> defaults defined in /etc/rc, and to have /etc/rc.conf be empty, but
> you can override the defaults from there.

Well, there are a couple of problems with this. One is that rc.conf
currently documents everything that runs; we'd still have to leave
in everything as comments if we want to maintain this, which still
leaves the same upgrade problem if the `documentation' (as to what
can be done) is to be upgraded with new releases.

The other problem is that rc.conf really needs to be changed;
Charles Hannum and I chatted a bit about this the other day, and
we were pretty much in agreement that daemons should be explicitly
enabled, rather than just running with default options if no
variables are set. There are a couple of good reasons for this,
one is that when on upgrades to a new version of current but forgets
or doesn't want to upgrade one's rc.conf, new daemons shouldn't
just turn themselves on by default. Another is that if rc.conf gets
broken (vanishes, in part or in whole, for example) on a production
system it's basic security sense that things should default to
`off' rather than `on.'

My current thought on the matter is that we need something like:

xntpd=DEFAULT	xntpdopts=""		# default: -p /var/run/
inetd=YES	inetdopts="-l"		# default: no options

where the daemon name is set to

    NO		don't run it
    YES		run it with daemonopts on the command line
    DEFAULT	run it with nice default options

This might also end up being a nice way to integrate with our
install routine; we could have /etc/rc check for the existence of
rc.conf and, if it doesn't exist, run an install dialogue to create
a new /etc/rc.conf and appropriate adjunct files.

Now folks have been suggesting a third level of redirection; I
think this is fine, if necessary, but should be done by the system
administrator, rather than by the distribution. If I have a consistent
rc.conf across a dozen machines, except for a few local changes,
it makes sense to use the same rc.conf on all machines (distributed
with rdist or whatever) and add a line to it at the end to source
rc.conf.local, which can change any settings that are local to that
machine alone (such as the hostname and gateway, for example).
Since I'm making local changes to rc.conf anyway, it's hardly a
burden to add a local change to source rc.conf.local.


Curt Sampson		Info at
Internet Portal Services, Inc.		`And malt does more than Milton can
Vancouver, BC   (604) 257-9400		 To justify God's ways to man.'