Subject: Re: Proposed rc.d changes....
To: Luke Mewburn <>
From: David Brownlee <>
List: tech-userlevel
Date: 05/01/2000 16:15:52
On Mon, 1 May 2000, Luke Mewburn wrote:

> 3. Reworking the configuration mechanism (replacing rc.conf)
> 	After many discussions with a variety of people, it appears
> 	that the configuration mechanism for rc.d should have the
> 	following attributes:
> 		* simple/stable
> 		* easy to manage by a user
> 		* easy to manage by system/automated scripts
> 		* easy to upgrade
> 	Whilst rc.conf is easy to manage by a user, it's not trivial
> 	to safely update it mechanically, nor is it easy to upgrade.
> 	My proposal is to replace rc.conf with separate
> 	/etc/rc.conf.d/foo config files, one for each service, with
> 	contents similar to:
> 		foo=NO
> 		foo_flags="-q ex0 -p 667"
> 	The primary concern with such an approach (and it's one I've
> 	had) is that it's not as easy for a user to manage multiple
> 	services at once (or setup a system from scracth).  If a tool
> 	is provided (e.g, virc(8)) which presents /etc/rc.conf.d/* as
> 	a single editor buffer, which then rewrites /etc/rc.conf.d as
> 	necessary once the editor is successfully exitted, then I
> 	believe that this concern will be addressed.

	If you have a tool that can take N rc.conf.d files, put them
	into a single file, allow it to be edited and then safely split
	everything back into individual config files then you have just
	about all the functionality needed to be able to mechanically
	update or upgrade a single rc.conf, particularly if you keep a
	copy of the stock rc.conf around and have an option to list all
	changes form the default.

> 4. Supporting pkgsrc rc.d scripts
> 	I suggest that the pkgsrc system is setup such that we supply
> 	and install rc.d scripts that are written to work as our
> 	system scripts do, in that:
> 		* our configuration mechanism is used
> 		* the rc.subr helper functions are used
> 		* appropriate PROVIDE/REQUIRE dependancy elements are set
> 	Also, by default, the package should setup things such that
> 	the program is started by default, since this is the principle
> 	of least surprise (and effort :-) for the majority of our
> 	users.  Of course, I suggest that we add support to install
> 	it disabled with something like an mk.conf variable such as

	I like all this. We should try to feedback the startup scripts to
	package authors, and havd good docs in manages, website, and
	ideally /etc/rc.README or /etc/rd.d/README

				   -- Value design over hype --