From owner-freebsd-rc@FreeBSD.ORG Mon Mar 19 04:39:11 2007 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2C4916A4D4 for ; Mon, 19 Mar 2007 04:39:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.freebsd.org (Postfix) with SMTP id A709C13C487 for ; Mon, 19 Mar 2007 04:39:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 30862 invoked by uid 399); 19 Mar 2007 04:39:05 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 19 Mar 2007 04:39:05 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45FE13E5.9060902@FreeBSD.org> Date: Sun, 18 Mar 2007 21:39:01 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Kian Mohageri References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> <45FC7EAE.803@FreeBSD.org> <45FC90CE.3020605@gmail.com> <45FDD5C3.1070305@FreeBSD.org> <45FDF284.3040008@gmail.com> In-Reply-To: <45FDF284.3040008@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mark Andrews , freebsd-rc@freebsd.org Subject: Re: rc.order wrong (ipfw) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 04:39:11 -0000 Kian Mohageri wrote: > I agree VERY MUCH with this sort of approach. It would be a much > cleaner solution than completely separate handling of all of these > different problems. I'm trying to get an idea of what all of the major > problems with the current order are, and these are the ones I'm aware of: > > - ipfw blocks by default (names unresolvable, rtsol breaks) > - ipf/pf pass by default (services are unprotected) > > I think a firewall_boot script (similar to what you've proposed) could > potentially solve all of these problems. I'm glad that you like the idea in principal, however I'm sorry to say that I don't see eye to eye with your suggestion of modifying the early behavior instead of the late behavior. I believe (for whatever that's worth) that firewalls (and firewall rules) _should_ be loaded prior to the interfaces coming up. If someone wants to have dynamic rules, rules that rely on name resolution, or rules for non-physical (e.g., cloned) interfaces, that's fine, but IMO those are the exception, not the rule. Furthermore (and I'm betraying a prejudice here) I think that firewall rules that rely on name resolution are absolutely nuts, and I say that with many years of experience as a professional DNS and system administrator. Therefore I believe strongly that the default behavior should be changed to load all firewalls (and rules) before netif, and that those who want to do firewall-related things that require netif or routing to be up should be the ones who have to opt in to the new script. That said, I think you and I have expressed our opinions pretty clearly on these points, so I'd suggest that we let someone else have a turn. Doug -- This .signature sanitized for your protection