At 6:36 PM +0100 2/1/02, Erik Trulsson wrote:
>Consider that the actual code in the various rc* start scripts is
>in most cases of the form:
>
>if foo_enable==yes
> do stuff
>else
> do nothing
The RC scripts are starting up in a "known" environment (loosely
speaking). Enough is known about that environment that the code
in question knows there there is no need to do anything to turn
off the service if the rc.conf file has blah_enable=NO. When
'lpd_enable=no', for instance, then it is very reasonable for
the startup scripts to assume that absolutely nothing needs to
be done to turn off lpd. We pretty much "know" it ain't running,
so why write code to turn it off?
I imagine it's futile to argue this, if you're going to argue it
based on the implementation-details in rc.conf, instead of asking
"what should we do?" from the point of view of what would make
the most sense to the most users.
As a support person, I also like to think of another question.
Given that some users will get it "wrong" no matter which way
we do this, then which "wrong" is the one that we can handle
the most gracefully?
In this discussion, there have been two suggestions as to how
'firewall_enable=no' should behave.
1) if the firewall is compiled in the kernel, then "=no"
means that the firewall is blocking all packets, no
matter what other rules might be lying around. The
machine is completely locked down from network access
(ie, the present behavior).
or 2) no matter how the kernel is compiled, "=no" means the
machine acts as if there is no firewall installed. Ie,
it accepts all packets. No packets are blocked. The
machine is wide open.
If the user *expects* 1, but we actually implement 2, then the
machine is wide-open when they did not expect that. My position
is that we can *easily* do something to help that person
immediately realize that they did not get what they expected.
If the user *expects* 2, but we implemented 1, then the machine
is locked down. If the user is not sitting at the console of
the machine, then there is absolutely nothing which can be done
(from a coding perspective) to help that person out. They must
have a keyboard and monitor on that machine, and they must go
to the machine and login via that console.
I understand the first "error" (where the machine ends up completely
open) is not desirable. It is very very bad. However, I think we
can write some code to help out that user. That user is extremely
likely to be sitting at the console, and they are extremely likely
to want to log into that console, and there is nothing which prevents
them from logging in. We can provide warning messages for that user,
and they can immediately fix the "error".
But I think the second "error" is also very bad, and there is no
way for us to address it via coding. It might be a pretty major
hassle for that person to fix the problem (particularly if they
did this over a remote connection, and the machine is far away).
And yes, the user should be brilliant and a complete expert before
they change any setting in any file on a unix box, but hearing that
"they were stupid" is not much of a soothing consolation to the user
when they are hit with a situation like this. As a support person,
it is pretty rare that the user is happy when they find out "they
were stupid" for making a perfectly reasonable assumption, based on
how everything else in rc.conf seems (to them) to work. No, they
did not read the code to see what the 'else' case of every "enable"
option does, but they did notice that every time they set
"blah_enable=no", they found that when the system came up "blah"
was not running. It *is* reasonable for them to assume the same
behavior would be true for network_enable=no.
I understand the reasoning of people who think the present behavior
is logical. However, we can write code which helps those people if
we pick what seems (to them) to be the illogical behavior. We do
not have that option for the group of people who happen to use a
different set of logical reasoning to come to the opposite conclusion.
--
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute or [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
