From owner-freebsd-stable Tue Oct 14 03:19:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA08110 for stable-outgoing; Tue, 14 Oct 1997 03:19:52 -0700 (PDT) (envelope-from owner-freebsd-stable) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA08105 for ; Tue, 14 Oct 1997 03:19:43 -0700 (PDT) (envelope-from danny@panda.hilink.com.au) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id UAA02278; Tue, 14 Oct 1997 20:19:28 +1000 (EST) Date: Tue, 14 Oct 1997 20:19:27 +1000 (EST) From: "Daniel O'Callaghan" To: Studded cc: "freebsd-stable@freebsd.org" Subject: Re: Problem with rc.conf/rc.firewall In-Reply-To: <199710140043.RAA27934@mail.san.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Doug, On Mon, 13 Oct 1997, Studded wrote: > the kernel from the same kernel config file I used with the > 2.2-970901-STABLE sources previously that included ipfw. I set the > firewall option to YES in rc.conf, and set the type to OPEN. > > A gold star to anyone who has already spotted the problem, the > rc.firewall script expects "${firewall_type}" = "open", not OPEN, and > it bombed out. IMO putting the firewall_type option rc.conf is a big > mistake. It loses big in functionality what little it makes up for in > convenience, especially when I'm 600 miles from the machine. My first proposal to committers was that firewall_type would be in rc.firewall, but it was pointed out that the model being progressively adopted is to put more config into rc.conf and less into other rc.*. I can't really see any advantage in putting firewall_type in rc.firewall, other than that it would force the user to read (or at least see) the first lines of rc.firewall. But the comment in rc.conf next to firewall_type clearly informs the user to see rc.firewall for a fuller explanation, and lines 5-15 of rc.firewall list the available values for rc.firewall. I grant the case-sensitivity is awkward, and I'll look into it, but firewall_type will stay in rc.conf for the moment. > little-used options from an already crowded rc.conf. Suggestion number > two is to make the type open BY DEFAULT, and let the person change it > if need be. There is really no reason to set up stumbling blocks that Two years ago, when I submitted patches for the TCP fragment offset bug, prompting Poul-Henning Kamp to rewrite most of the ipfw code, there was a function which allowed the user to set the default "policy" to open or closed. PHK changed this to default closed all of the time to lower the chances of a machine being set up which was "open" while the administrator thought it was "closed". I can't count the number of times I've built a kernel, rebooted, and been unable to telnet to the machine. I'm a slow learner, I guess. Rather than change the default policy I changed rc.network so that it would print warnings on the console if a kernel with firewall functionality was booted and there were no appropriate settings in rc.conf. I can't think of anything better to do than that, myself, but I'm open to suggestions (other than "default policy open"). As I've said, I'll look into the case-sensitivity... regards, /* Daniel O'Callaghan */ /* HiLink Internet danny@hilink.com.au */ /* FreeBSD - works hard, plays hard... danny@freebsd.org */