Date: Tue, 14 Oct 1997 20:19:27 +1000 (EST) From: "Daniel O'Callaghan" <danny@panda.hilink.com.au> To: Studded <Studded@dal.net> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@FreeBSD.ORG> Subject: Re: Problem with rc.conf/rc.firewall Message-ID: <Pine.BSF.3.91.971014195421.5634D-100000@panda.hilink.com.au> In-Reply-To: <199710140043.RAA27934@mail.san.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <http://www.hilink.com.au/>; danny@hilink.com.au */
/* FreeBSD - works hard, plays hard... danny@freebsd.org */
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.971014195421.5634D-100000>