Its probably worth including this info in an FAQ - can one of the
	www elves handle? :)

                David/absolute
			       -- www.netbsd.org: A pmap for every occasion --


On Sun, 10 Sep 2000, Luke Mewburn wrote:

> 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.
>