On Aug 2,  5:31am, Greywolf wrote:
} On Sun, 16 Apr 2000, John Nemeth wrote:
} # On Aug 24,  5:01pm, Robert Elz wrote:
} [ testing for stuff to have been predefined and, if not defined, define it. ]
} # 
} #      I'm not sure I like this idea.  Not only does it spread
} # configuration information all over the place, but it puts the same
} # configuration information in multiple places.  One of the first things
} # you learn in database design, is that you put a single piece of data in
} # one place and replicate it as necessary.  The problem with this design
} # is that I have to look in multiples places to figure out how things are
} # configured, and I have to keep in mind which location takes
} # precedence.  This will really complicate system maintence.  Of course,
} # as you say, I can use whatever method I want.  The problem would mainly
} # happen when I have to solve a crisis on a system maintained by somebody
} # else (mind you, inexperienced system administrators can produce all
} # sorts of "interesting" situations).
} 
} This is why I had suggested warnings if conflicting config information
} had been defined, as well as a way to configure which setting would
} override the other.

     That's just noise.  In my case, I would want to rc.conf to be the
only source of config info, and rc.conf.d should be completely
ignored.  I shouldn't have to maintain the latter, just so that I don't
have a noisy boot.  It would be rather silly to have to put the same
information in two places.  That would double the administrative work
of maintaining system startup for no good reason.

} John, you look like you've had the same experiences I have -- I can't
} count your years, so I don't know for sure, but mine have stretched across
} the last sixteen years.

     Ten years professionally.  But, I would say that if you have
fairly broad experience and you've kept up to date, then after five
years or so, counting the number of years doesn't have a lot of
experience.  If for no other reason then that this industry changes
rapidly, so what one did ten years ago only has minimal relevance to
what one does today.

} I respect Robert's opinion, and, in fact, his suggestion triggered me to

     Sure.  He obviously has a lot of experience.  However, his
experience is different from mine and isn't completely applicable.  His
experience seems to be in running a large site with many machines;
whereas, my experience is more in running many sites with few
machines.

} flesh it out a bit more.  Hopefully we will have the ability to select
} which config method will take precedence.
} 
} The battle for a non-split /etc/rc is more or less lost (I intend to

     I agree with this, so I'm not even going to bother trying to fight
it.  I only have time to tilt at so many windmills.

} provide a fix soon).  The battle for a non-split rc.conf is not
} yet decided, and there will be proponents from both sides.  I will main-

     Yep.

} tain that a flexible solution to the rc.conf problem is more workable than
} is a solution to the rc problem.  I will also maintain that the flexible
} rc.conf solution will allow more control of what happens on a box as far
} as configuration goes.

     It remains to be seen if this can be done in a way that makes
sense and that both sides will like (or, at least not outright hate).

}-- End of excerpt from Greywolf