Subject: Possible design of the new rc.d rc.conf stuff.
To: None <firstname.lastname@example.org>
From: None <email@example.com>
Date: 04/17/2000 19:32:42
On Sun, Apr 16, 2000 at 05:23:36PM -0700, Greywolf wrote:
> If a hammer decision is made to split rc.conf to the four winds, NetBSD
> will have completely lost its sanity. I am hoping that the rc.conf
> designer will take this into account.
After a brief discussion elsewhere concerning splitting rc.conf
I've decided that I no longer agree with the need to keep rc.conf all
The view I have now, which I is very clear in my head, is
that there are four things that the configuration system should have:
1) Default values for everything that gets started which
should be easy to set for a newly added package.
2) The ability to have a either a rc.conf or a /etc/rc.config/*
3) The ability to specify which of rc.conf or rc.config/* takes
4) The ability to see what the defaults and actual values are.
I pieced together much of this mail from what I understood people
said they wanted from the system earlier in this thread.
In order for #1 to be easily doable the default values for configuration
variables for a particular program need to be separate from all others.
The obvious place for this is /etc/rc.d/* since each program already has
one of its own files there. For easy viewing the default values would
also be listed in comments starting with "# DEFAULT: ...
This would allow it to be easily processed into a proto rc.conf file
or rc.config/* files.
This would also allow added software to get itself up and running without
the need to understand and modify any config files by just dropping its
script in /etc/rc.d.
rc.conf would still exist. It's purpose would be to define a couple of
variables including "conf_dir_preferred" which would determine whether
rc.conf should override rc.config/* or the other way around.
rc.conf would be read by all rc.d/* scripts while script rc.config/<foo>
would only be read by rc.d/<foo>.
To make the selection of which config to prefer as transparent to rc.d/*
as possible a rc_init function would be added to rc.subr which would look
conf_dir_preferred=`(. /etc/rc.conf ; echo $conf_dir_preferred)`
if checkyesno conf_dir_preferred ; then
if [ -r /etc/rc.config/`basename $0` ]; then
. /etc/rc.config/`basename $0`
if [ -r /etc/rc.config/`basename $0` ] ; then
. /etc/rc.conf/`basename $0`
And a rc.d/foo script would look like:
# PROVIDE: foo
# REQUIRE: noodle
# DEFAULT: foo=NO
# DEFAULT: foo_flags="-x"
...rest of file...
So the result would be:
If you want a monolithic rc.conf you set conf_dir_preferred=YES,
"rm /etc/rc.config/*" and add configuration lines to rc.conf.
If you want split configuration files set conf_dir_preferred=NO, delete
all configuration lines (if any) from rc.conf and create or edit the
the appropriate files in /etc/rc.config.
If you don't want either of these, "rm -r rc.conf rc.config" and set the
values directly in the /etc/rc.d scripts.
Note that this is completely backwards compatible with a rc.conf file from
As for seeing the defaults or the actual values in a reasonable
fashion a script which does a "grep DEFAULT /etc/rc.d/*" and merges any
changes into rc.conf or rc.config/* would be needed. This doesn't seem
hard and I think I saw someone mention that they started on a something
that does this.
The default rc.conf in this scheme could look prett much the same
except that everythin would be commented out. The rc.config
directory would initially be empty. The choice of which method
to use for configuration would be entirely, and easily, under the
control of the sysadmin.
So what problems does anyone see with this?