On Jan 31,  6:04pm, 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.

     No, you're not confused...

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

     You're right, this wasn't exactly the wisest decision...

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

     Here, here...

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

     This was one of the suggestions that was made in a previous
discussion about this topic.  This idea makes a lot of sense and would
be a perfect solution to the problem at hand.  Another suggestion was
to use RCS, but I think that would be overkill for most sites.
However, as long as it didn't get in my way, like the current change
does, I wouldn't object.

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

     However, you completely failed to do that, and instead have made
things harder.

} With the `old' mechanism, most people would modify the as shipped
} /etc/rc.conf as appropriate for their environment. They might even

     Yes, of course; they are, after all, config files.

} 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 tool to do a three way merge between the old config file, the
modified one, and the new config file could easily be developed to
assist with this.

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

     No, it doesn't.  It's the same thing that you created now (look in
one file for the available options and their defaults, then make the
change in another file).

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

     Yep, having the exact same information in multiple places is a
surefire way to create a disaster.

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

     Why didn't you just call the directory "/etc/orig" and stuff an
extra copy of each config file in it?  This would have solved the above
problem without causing extra problems.

} 	  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

     Being examples, would imply that they aren't the production copy;
therefore, this is irrelevent.

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

     NetBSD, isn't about doing what's convenient, it's about doing
what's right.  Ramming through a change without discussing it, because
you don't feel like dealing with the discussion goes against that
principle, and is grossly irresponsible.  Besides, for your efforts,
you're going to get the discussion now and get hammered for ramming
through an ill-advised change without discussing it.

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

     Except that it isn't that easy to see what needs to be changed.

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

     But, not at expense of general administration.  I only upgrade
machines once every two or three years, whereas I spend a lot more time
doing general admin.  [insert above paragraph NetBSD being about doing
the right thing]

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

     All of these are hacks, and none of them would be necessary were
it not for your recent ill-advised change.

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

     I have never looked at that manpage.  For those that know what
they are doing, the variables are pretty much self-explanatory, and the
short comments are more then enough.  Anyways, I just took a look at
that manpage on a 1.4.2 box (I don't have a 1.5 box handy at the
moment), and found it to be incomplete.

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

     Yes, most definitely; but, see above suggestion about /etc/orig
for how I think it should be fixed.

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

     No.

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

     Well, that is definitely one good thing.

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

     However, you're change is a step down the road leading to the
requirement of just such a tool.

} 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

     It certainly doesn't do this.

} easier upgrades of /etc/{daily,weekly,monthly,security,rc}.conf
} that we've provided in prior releases or even within -current.

     It may do this, but at great expense.

}-- End of excerpt from Luke Mewburn
he grunt work out of it.

     This was one of the suggestions that was made in a previous
discussion about this topic.  This idea makes a lot of sense and would
be a perfect solution to the problem at hand.  Another suggestion was
to use RCS, but I think that would be overkill for most sites.
However, as long as it didn't get in my way, like the current change
does, I wouldn't object.

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

     However, you completely failed to do that, and instead have made
things harder.

} With the `old' mechanism, most people would modify the as shipped
} /etc/rc.conf as appropriate for their environment. They might even

     Yes, of course; they are, after all, config files.

} 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 tool to do a three way merge between the old config file, the
modified one, and the new config file could easily be developed to
assist with this.

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

     No, it doesn't.  It's the same thing that you created now (look in
one file for the available options and their defaults, then make the
change in another file).

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

     Yep, having the exact same information in multiple places is a
surefire way to create a disaster.

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

     Why didn't you just call the directory "/etc/orig" and stuff an
extra copy of each config file in it?  This would have solved the above
problem without causing extra problems.

} 	  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

     Being examples, would imply that they aren't the production copy;
therefore, this is irrelevent.

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

     NetBSD, isn't about doing what's convenient, it's about doing
what's right.  Ramming through a change without discussing it, because
you don't feel like dealing with the discussion goes against that
principle, and is grossly irresponsible.  Besides, for your efforts,
you're going to get the discussion now and get hammered for ramming
through an ill-advised change without discussing it.

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

     Except that it isn't that easy to see what needs to be changed.

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

     But, not at expense of general administration.  I only upgrade
machines once every two or three years, whereas I spend a lot more time
doing general admin.  [insert above paragraph NetBSD being about doing
the right thing]

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

     All of these are hacks, and none of them would be necessary were
it not for your recent ill-advised change.

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

     I have never looked at that manpage.  For those that know what
they are doing, the variables are pretty much self-explanatory, and the
short comments are more then enough.  Anyways, I just took a look at
that manpage on a 1.4.2 box (I don't have a 1.5 box handy at the
moment), and found it to be incomplete.

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

     Yes, most definitely; but, see above suggestion about /etc/orig
for how I think it should be fixed.

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

     No.

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

     Well, that is definitely one good thing.

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

     However, you're change is a step down the road leading to the
requirement of just such a tool.

} 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

     It certainly doesn't do this.

} easier upgrades of /etc/{daily,weekly,monthly,security,rc}.conf
} that we've provided in prior releases or even within -current.

     It may do this, but at great expense.

}-- End of excerpt from Luke Mewburn