Subject: Re: The new rc.d stuff...
To: None <firstname.lastname@example.org>
From: Greywolf <email@example.com>
Date: 04/01/2000 23:14:53
On Sun, 2 Apr 2000 firstname.lastname@example.org wrote:
# [Note: rearranged a bit, and paragraph headings because I seem to
# have rambled on a bit. I feel that all I said is worth saying though.
# (well, of course I do, I wrote it. :) )]
# On Sat, Apr 01, 2000 at 09:13:25PM -0800, Greywolf wrote:
# > You may consider this a strong vote against any further fragmentation
# > of the RC configuration. I don't think it's a practical move. There
# > has GOT to be a better way of handling this without going the way of,
# > say, IRIX.
# I agree on this point.
# > Sigh. Luke, you know, I appreciate the effort that's going in here, but
# > splitting out rc.conf into a bunch of little files makes it a huge pain
# > in the patella when trying to configure the box. Never mind the cute
# and I agree here.
# > little script that will be required to enable/disable "features"
# > as needed. Not being able to read a single config file to determine
# > what is running on the system is really detrimental both in terms
# > of functionality as well as, yes, what makes this BSD.
# > As soon as I get DSL going, I'm going to set up a repository, if I can,
# > which will contain a preserved old-world-mode rc scheme. This will be
# > available for _and maintained by_ the people who determine that a monolithic
# > rc, a monolithic rc.conf or both are preferable to the nightmare that
# > a split-up rc.conf will be.
# However, I have to disagree on the idea of reverting to back to
# a monolithic /etc/rc. (although, you of course are free to setup whatever
# repository you want)
No, not "reverting". "Preserving". More what I'm aiming for is the
splinter crowd that feels a bit abandoned by the rc->rc.d move and
probably even more so by the rc.conf split. I'm not necessarily
saying that _everyone must run this way_. I just wish it possible for
those who desire to do so.
# [enable/disable util:]
# The enable/disable script seems like it is irrelevant to the
# basic operation of this system because it is not necessary. The default
# method of operation is the single config file modified using vi, emacs,... .
# Sure, it might be nice to have a util that can allow a configurable
# subset of users to change the configuration on certain commands, but I
# have a feeling that this is just asking for a bunch of security problems.
Splitting up security access among individuals is asking for that same
bunch of problems. Get a competent sysadmin and stop dicking with
# [show default config util:]
# [exit status dependancies:]
# Finally, the direction I think would be really cool for the rc.d
# scheme to move in is eventually allowing later scripts to depend on the
# actual exit status of what they depend on instead of just the
# PROVIDE/REQUIRE lines.
Makes LOTS of sense!
# [monolithic conversion scripts:]
# One great benefit of the rc.d scheme is that it is more flexible
# than the previous monolithic /etc/rc. If you really want to see a single
# script that runs at startup it is fairly easy to convert from /etc/rc.d to
# /etc/rc. You could even set things up so this happens as the first
# thing in the startup sequence (or perhaps the last in the shutdown) so
# you always have an up to date /etc/rc even if the contents of rc.d changes.
# This wouldn't be too hard even with the exit status dependencies.
# If you really want a single rc and rc.conf I urge you to implement
# a method somewhat similar to this instead of creating a NetBSD micro fragment.
# There doesn't seem to be much sense in dividing our efforts on two completely
# disjoint configuration methods when the features of both can be easily done.
Your suggestion is noted. I'll see if I can satisfy both ends,
to a degree.
BSD: More Nines.