Re: Moving rc.d scripts to base.tgz

[Julio Merino <jmmv%NetBSD.org@localhost>]

On Sat, Apr 16, 2011 at 12:51 PM,  <markucz%gmail.com@localhost> wrote:
>> Depends.  Is this a bug that you think should be addressed?  (I have
>> never had the need to change the default ordering of the execution of
>> these scripts, but my needs haven't been extraordinary... so I don't
>> know.)  If it is a bug, then it should be fixed and not worked-around
>> by users changing the scripts.
> I can't say it's really a bug. It's a design decision — good or bad — I don't
> agree with and want changed.

Why do you think that's a design decision?  It may just well be an
overlook of the implementation that really needs addressing.
(Conceptually, it seems like veriexec should really be loaded asap,
but I don't know enough about it to make a call.)

Also, just curious: why do you care about bind and not fsck?  fsck
could equally be compromised.

> It's easier to change it on my machine only
> than force it down everybody else's throat, since they may have different
> ideas about what's right and what's wrong. So that's what I do: change it
> locally.

You can change anything you like locally; that's why you have the
source tree.  The point is: why is this change any different than,
say, a change to /bin/ls ?  (More below.)

>> If there is a legitimate need for users to change the ordering as part
>> of configuration [...]
> Legitimate? What do you mean by that? If it doesn't do what I want, I change
> it. Really, why do you think users shouldn't touch rc.d's contents?

By legitimate I meant: is it there any technical reason to allow
modifying these files *as configuration* instead of from the source
tree, other than "just because I want to"?  They are code.  If you
want to change code, fine, go change the source tree just as you would
do to modify any other binary or the kernel.

> Let me offer a different approach to this: move rc.d somewhere else,
> say /etc/defaults, and if there's a script with the same name in /etc/rc.d,
> execute that one instead. Then you may move /etc/defaults/rc.d to base and
> change etcupdate, postinstall, etc. accordingly.

It's an interesting idea.  But in the end, it just is an ugly
workaround for the fact that you can't change the ordering (which
arguably really is a configuration property) without modifying the
sources.  Also, there is nothing that says the programs in /etc/rc.d/
should be scripts; what if they were binaries?

-- 
Julio Merino / @jmmv