Date: Fri, 19 Apr 2002 21:56:24 -0500 (CDT) From: hawkeyd@visi.com (D J Hawkey Jr) To: DougB@freebsd.org, freebsd-stable@freebsd.org Subject: Re: /etc/defaults/rc.conf theory Message-ID: <200204200256.g3K2uOu10038@sheol.localdomain> In-Reply-To: <20020419181021.X18267-100000_zoot.corp.yahoo.com@ns.sol.net> References: <20020419225855.E7E575D05_ptavv.es.net@ns.sol.net> <20020419181021.X18267-100000_zoot.corp.yahoo.com@ns.sol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Being "just an user/admin", and not part of The Project, my opinions
probably won't carry much weight, but weigh in I will anyway...
In article <20020419181021.X18267-100000_zoot.corp.yahoo.com@ns.sol.net>,
DougB@FreeBSD.ORG writes:
> On Fri, 19 Apr 2002, Kevin Oberman wrote:
>
>> I really hate to see the suggestion that people copy files from
>> /etc/defaults to /etc. This really breaks the paradigm of having only
>> changes in defaults in /etc so that defaults can be changed with a
>> normal system update.
>
> But that was never the paradigm. There are a few different ideas
> about why the defaults file should exist (none of which I'm particularly
> fond of, btw) but silently changing defaults out from under the users
> isn't really all that good of an idea, no matter how well intentioned it
> might be.
I'm afraid I must side with Kevin. I'm not going to throw the word
"paradigm" around, but, from /etc/defaults/rc.conf:
# This is rc.conf - a file full of useful variables that you can set
# to change the default startup behavior of your system. You should
# not edit this file! Put any overrides into one of the ${rc_conf_files}
# instead and you will be able to update these defaults later without
# spamming your local configuration information.
#
# The ${rc_conf_files} files should only contain values which override
# values set in this file. This eases the upgrade path when defaults
# are changed and new features are added.
IMHO, you muddy, if not nullify, the abstract altogether. You are advocating
copying this file down to /etc, and editing it. There goes the concept of
"overriding the values contained in this file".
I don't know what you're definition of "paradigm" is, but yes, I believe
this is indeed a "paradigm shift". Oops. I used that word, didn't I?
> The one rational reason for having the defaults file is to create
> a reasonable environment at startup for fresh installs. Given that
> everything in inetd.conf is commented out, it's reasonable not to start
> that daemon. The sendmail issue is a little more enigmatic, given that in
> order for local processes to send outgoing mail it's now necessary to have
> a sendmail daemon running... it could be argued that changing the defaults
> in both branches is reasonable at this point. (Technically, there is
> another good reason for the defaults file, namely that new options should
> always be defaulted to off when they are introduced. However, that is both
> abused, and not used consistently, so I'd much rather see
> /usr/share/examples/rc/*, or something to that effect. But I digress.)
This rather sounds more like "rationale" than "rational". It seems to me
your using one fuzzy/broken/flawed thing to justify changing another.
>> While the new mergemaster option helps with this, I would really rather
>> not see rc.conf (and other files) become large and not trivial to scan
>> over.
>
> The problem is, if an option exists, it has to be documented
> somewhere. While fraught with danger, the existing situation isn't
> HORRIBLE... but it does need help.
Rather like highy-paid (and already rich) senators and representatives
declaring that the Welfare State overhaul won't be horrible for those
most destitute that are in it. Did any of them ask those most needy how
horrible it would be?
OK, ok, lotso rhetoric there. Sorry. But you know what? Your "horrible"
ain't mine, and mine ain't Harry's. /etc/rc.conf in 4.5-RELEASE is
almost 400 lines long. My own /etc/rc.conf is not even 40 lines long.
When a normally live server is down to single-user mode, and in the home
stretch of the "installworld process", and your boss is breathing down
your neck, what do you want to look at, a diff of a 400-line file, or
a diff of a 40-line file?
>> Of course, people SHOULD pay attention to whet mergemaster has to say,
>> but even I have messed up when updating an important server and not
>> watching all of the things mergemaster showed in an effort to get the
>> system back on-line quickly.
>
> I agree that we should provide safety nets whenever possible...
> that's been one of my main areas of work in the project. But, at some
> point, it's still on you when you push 'i' for install. This ain't
> windows. :)
Easy to say from your Airion (sp?), as you throw the MFC switch, with
little real-time pressure on your shoulders. Eh? Oh. Sorry. More need-
less rhetoric. I apologize again.
All except one of the files in /etc/defaults make use of language similar
to that which I quote above, and you're advocating changing one. Are you
taking on the responsibility of changing them all, then, in the name of
consistancy? Will you do so _before_ the next formal release? And will
you somehow make all these changes known to all admins, well before they
begin their "makeworld process" or new installation, _including_ those
that don't follow this mailing list (for whatever reason of _their_
circumstance or choosing), in a concerted effort to minimize unforeseen
confusion and/or damage?
Now, to be fair to you, I am not subscribed to this list (which may
further negate my unsolicited input), but do try to monitor it via an
Usenet "mirror" on a daily basis, and I missed your reasoning for this
change, and it may indeed have more substance than this "Head's Up".
Having said that, I wonder how many others may have, too? By this one,
on it's own, the change seems rather gratuitous (p'raps a bad choice of
word; no offense meant in my using it).
I don't know how long things have been as they are now (i.e., 4.5-REL),
as I've really only been immersed if FreeBSD since 4.2-REL, but I'm
already _very_ used to the current relationship between the files in
/etc/defaults and those in /etc. It is direct, concise, and, best of
all, brief. Brief, in this context, is good.
I'm sorry if this reads strongly. I've tried to stay on the polite side
during this message, but I feel strongly that you're making a mistake
here that will be felt - badly - by many, many people, perhaps at the
time when they need it least. I don't mean to be a Luddite, but neither
do I see any real need for this change. Not at this time, anyway.
I know that the rc and periodic structures are changing to something more
SysV-ish for 5.0-REL (I have that right, don't I?). If you must go this
direction, can't you wait until then, when a "paradigm shift" occurs for
a [more] rational reason [than stated with this "Head's Up"], and we'll
have to digest and adapt to a major change anyway?
OK, I'm off my soapbox now. I feel better for voicing my two-cents' worth.
Have I made a fool of myself yet?
Dave
--
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204200256.g3K2uOu10038>