Re: Moving rc.d scripts to base.tgz

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Apr 18, 2011 at 12:16:08AM +0200, Michael van Elst wrote:
 > > Yes it is, really; the claim is that if the configuration support is
 > > adequate then the need to make custom changes should largely or
 > > entirely go away.
 > 
 > Read your own words.

Yes?

 > >  > > No, because then you have to write shell script (or worse, hack
 > >  > > someone else's) to get the behavior you want.
 > 
 > You don't have to write shell script or hack someone else's if the
 > functionality is already provided and configurable.
 > 
 > You _can_ write shell script or hack someone else's for anything else.

Likewise, you don't have to write C or hack someone else's if the
functionality you want is already in /bin/ls. You *can* do it if you
need something else. Most people find that they don't need to hack
/bin/ls, because it already includes every option they could possibly
want.

Again, I don't see why the periodic maintenance scripts are or should
be special compared to any other programs on the system.

 > > No, but it has plenty of other costs. And remember, nobody's
 > > suggesting that you can't have /etc/daily.local,
 > 
 > That's because turing-complete configuration is suddenly good? :)

No, because it's not feasible to include in /etc/daily all possible
programs/checks that someone might think of.

However, most people don't and shouldn't need or use /etc/daily.local.

 > I never edited /etc/daily (except for fixing a bug) but augmented
 > it in /etc/daily.local, but then this was about additional checks
 > and not about modifying standard checks.

No, it wasn't. This discussion (ever since it veered away from the rc
scripts) has been about whether /etc/{daily,security,weekly,monthly}
can be moved to /usr/libexec or whether they need to stay in /etc
because sysadmins need to be able to edit them.

 > You see that I am not against standard scripts or simple configuration.
 > It is a good thing to have, but it is not the end.

uh... that's obvious, isn't it?

 > > Yes indeed, but it also means that the range of possible
 > > configurations ceases to include a wide variety of non-sensible (which
 > > often includes broken, inoperable, erratic, failing mysteriously, see
 > > Windows for examples) configurations. This is a feature.
 > 
 > Do you intend to provide such non-sensible configurations? 

Of course I don't. That's the point. It also makes it harder for
sysadmins to accidentally introduce such configurations when they
meant to do something else.

 > And why should this be better when the scripts are modified in
 > /usr/libexec instead of in /etc ?

As the point of putting the scripts in /usr/libexec is to *not* modify
them, I'm now confused.

 > > Do you want to bring back starting the network and all daemons from
 > > /etc/rc.local? That gives much more flexibility than ifconfig.* and
 > > rc.conf, after all.
 > 
 > It doesn't

Oh, it certainly does. I'm sure if you dig up the flamewars from the
introduction of rc.d, or the addition of the old network config
script, or whatever, that you can find any number of examples of
things that are allegedly no longer possible or now unreasonably
difficult. Many of the examples will turn out to be mistaken, or straw
men or meretricious or otherwise bogus, just as in this thread, but
almost certainly not all.

or for a more glaring example, you could propose to replace
/etc/passwd (and friends) with a script that outputs password file
entries on demand. This would avoid the need for lots of special-case
configuration and nsswitch code. Want to import some users but not
others from NIS? Just edit the script a little. But we don't do this,
and we shouldn't, and hopefully everyone here can agree that it'd be a
bad idea.

 > and as written above, this is not about config options
 > vs. scripting. It is about not preventing scripting when necessary
 > (or just wanted).

It is about whether certain files currently found in /etc are really
supposed to be sysadmin-editable configuration, or if they aren't and
can therefore be moved out of /etc where they'll no longer be
occupying screen and brain space.

One of the reasons it's desirable to kick these files out of /etc is
that they're executable, yes. I have one set of reasons for this
(based on usability and configuration management concerns) and tls has
another (based on security) but the premise is that it won't reduce
functionality. There's been a claim that it would, but it so far
hasn't been substantiated.

-- 
David A. Holland
dholland%netbsd.org@localhost