Re: Moving rc.d scripts to base.tgz

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Mon, Apr 18, 2011 at 12:29:33AM +0000, David Holland wrote:

> 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.

ls is a standard that most people rely on.

maintenance scripts are part of the system configuration.


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

Many people don't use /etc/daily.local because they add their own
cronjobs. But on other systems augmenting daily is so popular, they
even have their own directory for maintenance scripts so you can
just drop them their instead of editing a single daily.local script.
And since that is an advantage they use the same scheme to keep
the standard maintenance tasks.


>  > 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.

When I say that I only needed to add new checks and not to modify
standard checks and therefore daily.local was enough you can't just
say no.


>  > 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?

Then why did you say that I now have to write or hack other people's
scripts?


>  > > 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.

It also makes it harder for sysadmins to intentionally introduce
sensible configurations.


>  > 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.

You claimed that changes to scripts in /usr/libexec should go to
the source tree.


>  > > 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.

You still have rc.local and you can still edit the scripts in /etc
and this is even supported by the update process.

I don't see how that strips flexibility and I see that you don't
know any examples eithers.


> 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.

You can't replace passwd with a script (unless you are Plan 9) without
killing compatibility.


>  > 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.

Now we have a benefit. ls /etc generates shorter output.


> One of the reasons it's desirable to kick these files out of /etc is
> that they're executable, yes.

That's questionable because there are so many files in /etc that
while not executable themselves direct programs to execute scripts
and moving things out of /etc just spreads sensitive information.
Protecting all of /etc seems to be a much easier approach with
no impact to compatibility.

Also, where does this put /etc/daily.local? Moving /etc/daily is
fine and necessary for security, but keeping /etc/daily.local
where it is doesn't harm? Again, you have to lock all /etc.


> I have one set of reasons for this
> (based on usability and configuration management concerns)

Let's hear.



Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."