From owner-freebsd-stable Fri Feb 1 13:52:41 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id A3F5937B405; Fri, 1 Feb 2002 13:52:19 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id g11LqC9111512; Fri, 1 Feb 2002 16:52:12 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020201173641.GA48397@student.uu.se> References: <15448.64681.401219.163184@guru.mired.org> <5F46C986-16DB-11D6-8CEC-00039359034A@mac.com> <20020201173641.GA48397@student.uu.se> Date: Fri, 1 Feb 2002 16:52:07 -0500 To: Erik Trulsson , Paul Fardy From: Garance A Drosihn Subject: Re: *_enable="YES" behavior is bogus Cc: current@FreeBSD.ORG, stable@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message