Mason Loring Bliss writes:
> Maybe I'm confused here, but it seems like what we're now providing as
> /etc/rc.conf is an amazing leap backwards from what we used to provide.
> We used to have something that was nicely documented and approachable.
> Now one must check /etc/default/rc.conf and copy over variables. This
> isn't nearly as nice, IMHO. It's a lot more work for the user.

[See below. Bear with my long post on this; I've tried to explain
the history behind this change]


> Is the plan to have a tool which manages this configuration stuff? I'm
> not grasping the big picture. One of the things I used to tout about
> NetBSD was easy configuration. I'd very much like to see us go back to
> having a single /etc/rc.conf and a way to easily detect changes.
> 
> Perhaps this could be based on how folks typically track kernel config
> file changes - keep a copy of the default file, and diff that against
> a copy of the new default file to see what needs to be changed in the
> actual in-use file. I'm sure this could be automated easily enough to
> take much of the grunt work out of it.

The rationale for the change to make things easier - in the long run -
for users to manage /etc/rc.conf (and other similar config files such
as {daily,weekly,monthly}.conf and security.conf).

With the `old' mechanism, most people would modify the as shipped
/etc/rc.conf as appropriate for their environment. They might even
use version control to keep track of changes (RCS, CVS, ...)

Then, during a (manual) upgrade of /etc (to take advantage of new
programs or startup, or changed options - such as the replacement
of portmap with rpcbind), you might want to find out what changed,
so you'd run diff(1) between /usr/src/etc/rc.conf and /etc/rc.conf.
Of course, because you'd changed /etc/rc.conf for your site
preferences, it was a bit difficult to peruse the diff(1) output for
stuff that you changed versus stuff that was changed in the source
tree. I speak from long experience fighting this battle :/

A while ago someone had added support for /etc/rc.local.conf, which
was read at the end of /etc/rc.conf. Some comments on that change:

	* Certain people started using this as a way to add overrides
	  to /etc/rc.conf and kept /etc/rc.conf `virginal'. I picked
	  this habit up from Matt Green, because it made sense.

	* There were some concerns on the lists a couple of months ago
	  about the name /etc/rc.local.conf; some felt it should have
	  been /etc/rc.conf.local or something else. As usual (on
	  these sysadmin management issues), there wasn't any
	  consensus on what name to use.

	* I also had a concern that having /etc/rc.conf unchanged with
	  local overrides in /etc/rc.local.conf may make support a
	  little harder because you'd have to tell someone to possibly
	  another location (the latter file) to find out why a file
	  was starting.

	* Some of the other config files (daily.conf et al) could have
	  had similar `local overrides' for similar reasons, but the
	  naming problem (see above) also applied.


After considering this problem for a while, and discussing it with a
few other sysadmins I know who also have experience with running a
variety of large systems, I decided on the following:

	* Have default config files in /etc/default, that are read
	  from the `master' file in /etc. This makes it easier to
	  run diff(1) to find out what's changed between /etc/default
	  and /usr/src/etc/default without your local config changes
	  ``getting in the way''.

	  Some debate has since occurred about the choice of name,
	  as SVR4 has /etc/default for a slightly different purpose.
	  Whilst this is true;
		- the files in /etc/default on those systems generally
		  don't end in `.conf'
		- the files are ``defaults'' (rather than examples)
		- even if they were examples, /usr/share/examples/etc
		  wasn't appropriate, since /usr/ may not be mounted
		- I didn't want the change held up for another month
		  because of a pointless debate about the choice of
		  the name (maybe I'm too cynical...)

	* The /etc/foo.conf files source /etc/default/foo.conf, and
	  allow you to override the options in the latter fairly
	  easily.

	* We needed a method that made it much easier for future
	  upgrades than the then current /etc/rc.conf did.


If you want the in-line documentation, I suggest the following techniques:
	* Go to the end of /etc/rc.conf. Using your favourite editor
	  `read' /etc/default/rc.conf into the end of the file, and
	  modify as appropriate. In (n)vi, this is
		ESC G :r /etc/default/rc.conf ESC
	  :-)

	* Open two buffers in your editor; one for /etc/rc.conf and
	  one for /etc/default/rc.conf. Again, in nvi this is:
		ESC :E /etc/default/rc.conf
	  one you're already editing /etc/rc.conf. Use ^W in command
	  mode to flip windows :-)

	* Run screen(1), and have one session open with an editor on
	  /etc/rc.conf and another reading rc.conf(5).

Even with the in-line documentation, I generally find I refer to
rc.conf(5) anyway; it's usually more detailed than the short sentence
that describes a particular feature.


> Another thing that would work if we want to stick with the "master file,
> overrides file" model is a tool (virc?) to invisibly handle changes -
> a tool that would merge in the overrides for purposes of administrator
> editing, and split them back out on saving changes. This would result
> in files essentially identical to what we've got now, but we wouldn't
> be losing the nice in-band comments and documentation.
> 
> Is anyone working on such a tool? Do we want such a tool? Does anyone
> else see the present system as something of a loss? Am I missing some-
> thing that makes the present system *not* a loss in terms of the things
> I've mentioned, above? I'll be happy to work on such a tool if no one
> else is doing it and if folks see it as The Right Thing.

I considered virc, especially for the ill-fated idea of migrating the
system config to separate files (one for each rc.d script), which I
tossed out after implementing locally and realising it was going to be
a pain to manage.

I feel that requiring such a tool (virc) to effectively manage your
configuration would be a step backwards. Having it as a helper utility
might be useful, but I don't think it would be that much of a win.


I hope that helps to explain why I made the change. I feel that it
will provide benefits in the long run for ease of management and
easier upgrades of /etc/{daily,weekly,monthly,security,rc}.conf
that we've provided in prior releases or even within -current.

Luke.