[ On Sunday, December 30, 2001 at 16:54:39 (+0700), Robert Elz wrote: ]
> Subject: Re: Allowing ${name}_path to be set in "rc.conf", was Re: Keeping /etc/defaults and /etc/rc.d in-sync 
>
> Perhaps - but in general which scripts get run at shutdown (and for that
> matter at startup - though rc.conf control of on/off mostly avoids that
> issue) is something that should be user configurable.   It is now - but
> it is by editing rc.d scripts.

Hmmm.... this particular issue of which scripts get run at shutdown
could be much better managed by using another variable, such as
${name}_shutdown, which could be set in /etc/defaults/rc.conf to do what
we do now with the shutdown keyword.  I.e. always run all scripts at
shutdown, with a command "shutdown" instead of "stop", and then only
those for which ${name}_shutdown is set to "YES" would actually do the
"stop" action.

(This is what I was alluding to by saying that some of these problems
seemed more like design flaws and that they're best fixed by fixing the
underlying design instead of throwing another hack on top of the
existing hack.)

> Or are you suggesting that no-one's system be permitted to run in anything
> but the one true way?

no, of course not!  ;-)

>   | That's a pretty big 'iff'....
> 
> No, it isn't - I have had reason to want things started in different
> orders on a number of occasions.  Some of those were doubtless bugs
> that should be (and I think have been) fixed - others were just my
> perversity.

bugs and perversity: That's what I meant by 'iff'!  ;-)

> But some can't be done in one true way really.  Which comes first, ntpd
> or named?   If it is named, then its initial measurements of the RTTs
> to various servers might be skewed by the time adjustments made by ntpd
> (or ntpdate) when it starts.  On the other hand, if ntpd (or ntpdate) is
> run first, then I can't put names in ntpd.conf, only IP addresses (or the
> names have to be in /etc/hosts) - which makes my config be at the mercy of
> someone else's decision to renumber their systems.   There's no "right"
> answer to this - which is important, if either, depends upon local
> circumstances.

This is an example of an implementation bug, and yes given the other
assumptions within the system I think there is one "right" answer.  In
this case since ntpd and ntpdate both allow either a DNS name or an IP
address there must be DNS resolver service available before either
ntpdate or ntpd are started, and since we've already conceded that DNS
resolver service implies named must be running then /etc/rc.d/ntp*
"MUST" depend on named.

If instead named's RTT measurements are considered more important then
the solution is to require that all "addresses" given in /etc/ntp.conf
be given only as IP addresses.  That's perhaps a bigger change with more
dire conscequences and on first glance I don't think named's RTT
measurements are that important (especially given the relatively low
chance that any of them will be affected for the long term either by a
clock jump caused by ntpdate or a clock skew caused by ntpd).

> What's more, NetBSD currently (seems to) recognise this - ntpdate and
> named are unordered with respect to each other in rc.d - so you kind of
> get random choice as to which will start first.   That is, unless broken
> by some other tie breaker - which appears (without going to study the code
> in rcorder again) to be the lexical ordering of the names (ie: named comes
> immediately before ntpdate in my system's startup order).

That's what I mean -- most of these examples are going to be bugs.
Nobody thought about the issue and nothing concrete was done about it.

As for the generic problem of being able to adjust the order, well
that's more of a design flaw.  Whether that's a flaw in 'rcorder', or in
the way the scripts are written, is a separate question.

I do like your idea of adding the '-i' (include), '-o' (omit), and
especially the '-d' (dependency list) options to rcorder, with the
implication that parameters for rcorder can be provided in /etc/rc.conf,
either directly as a list of command line arguments, or perhaps with a
more sophisticated set of variables controlling these options.


>   | And how do you suggest the build do that without storing original copies
>   | somewhere they won't be edited (eg. /etc/defaults/rc.d/*) so they can be
>   | compared with the active copies in /etc/rc.d?
> 
> I didn't suggest that that could be done without doing that did I?
> 
> That's certainly an option (all the standard rc.d scripts together total
> of the order of 100KB - a trivial volume).
> 
> But if that were too much, and at the expense of not providing the user
> with a "what did I change in that script that stopped it being updated?"
> mechanism, it could also be done by keeping md5 output of the scripts
> (which then costs of the order of 5KB).

Anyone updating from source certainly won't notice 100KB either way.

The more generic problem of updating all of /etc with binary upgrades is
perhaps best dealt with separately.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>