Re: init script config files
Cool - this could really happen. Here are a couple of comments.
On Fri, 7 Jul 2000, Joey Hess wrote:
> 2. If we move to this type of file, we have to worry about what happens if a
> user modified it, it is a conffile, and a new version of a package adds a
> variable to it; the user meanwhile has no such variable in their modified
> file, and things die a horrible flaming death (eg, rm -rf /$NEWVAR)
There are two ways around this, but both would require a bit of policy.
First, we could force the init.d scripts to use the -u command line option
to the shell. (If an unset variable is referenced, the script will die. -
sorta like -e for the inst scripts.) This is a quick and easy way to
guarantee that "rm -rf /$UNSET" never occurs. The longer and better way
would be to use ${var:?error} (this is a kshism - I'd have to
check to see if it's valid in bash) for each variable value used in the
init.d script. This will spit out "error" on stderr if $var is unset.
> I have one further concern -- why is it called /etc/default? The answer
> is probably lost in the mists of time (Miquel, do you know?), but if we
> start putting the actual defaults in the init scripts, and just reading
> in the config files to override, it's a really bad name. Perhaps we
> should find a better one -- /etc/rc.config.d/? Well, perhaps, unless
> more thasn init scripts end up using the directory. I can imagine it's
> be useful for /etc/cron.foo/ scripts too.
/etc/default/ is what Solaris uses, so I imagine that has something to do
with it. /etc/rc.config.d/ is from HP-UX. AIX's start-up scripts are
lost back in the stone ages (still doing most everything from
/etc/inittab), so I guess that the "industry" never reached a
consensus... :)
What if we did this?
/etc/rc.config.d/sendmail.default
/etc/rc.config.d/sendmail
(or /etc/rc.config.d/sendmail.override)
.
.
.
And so on. Always source sendmail.default first, so that we know we have
sane values. If "sendmail" is there, source it too. This way, users can
take a peek at the .default file to see what should in their file, and we
can add important variables at anytime because .default would come with
the package (but *not* be a conffile - users should never modify it).
Anything the user adds configures will be there, and remain there (until a
package purge?).
Anyway, just a few thoughts...
tony
tony@mancill.com | Girl afraid... where do his intentions lay?
http://www.debian.org | Or does he even have any? (The Smiths)
Reply to: