From owner-freebsd-ipfw@FreeBSD.ORG Sun Jun 17 12:09:20 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47DB216A41F for ; Sun, 17 Jun 2007 12:09:20 +0000 (UTC) (envelope-from ozkan@mersin.edu.tr) Received: from mail.mersin.edu.tr (mail.mersin.edu.tr [193.255.128.3]) by mx1.freebsd.org (Postfix) with ESMTP id EF60213C455 for ; Sun, 17 Jun 2007 12:09:19 +0000 (UTC) (envelope-from ozkan@mersin.edu.tr) Received: from localhost (localhost.mersin.edu.tr [127.0.0.1]) by mail.mersin.edu.tr (Postfix) with ESMTP id 6E67E31F5A4 for ; Sun, 17 Jun 2007 14:49:16 +0300 (EEST) X-Virus-Scanned: amavisd-new at mersin.edu.tr Received: from mail.mersin.edu.tr ([127.0.0.1]) by localhost (yenimail.mersin.edu.tr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L5Wrx6u3T5X for ; Sun, 17 Jun 2007 14:49:15 +0300 (EEST) Received: from [10.0.50.20] (unknown [88.247.50.50]) by mail.mersin.edu.tr (Postfix) with ESMTP id 98CFA31F5A1 for ; Sun, 17 Jun 2007 14:49:15 +0300 (EEST) Message-ID: <46751FE4.2040804@mersin.edu.tr> Date: Sun, 17 Jun 2007 14:49:56 +0300 From: =?ISO-8859-9?Q?=D6zkan_KIRIK?= User-Agent: Mozilla Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: if_bridge & ipfw divert / fwd support at FreeBSD 6.2 ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2007 12:09:20 -0000 Hello, Does anybody have an idea about if ipfw fwd/divert/dummynet works with if_bridge on a FreeBSD 6.2 machine? Is there a patch for this? Luigi wrote a patch for 4.x, does it work under 6.2 ? With best regards, Ozkan KIRIK Mersin Universty From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 18 11:08:26 2007 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.org Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 249A716A400 for ; Mon, 18 Jun 2007 11:08:26 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0859213C447 for ; Mon, 18 Jun 2007 11:08:26 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5IB8PaJ017639 for ; Mon, 18 Jun 2007 11:08:25 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5IB8O5D017635 for freebsd-ipfw@FreeBSD.org; Mon, 18 Jun 2007 11:08:24 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Jun 2007 11:08:24 GMT Message-Id: <200706181108.l5IB8O5D017635@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2007 11:08:26 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] add a facility to modify DF bit of the o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet o kern/112708 ipfw ipfw is seems to be broken to limit number of connecti 13 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] ipfw dynamic rules lifetime feature o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses ports and port o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parser error) o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] Add setnexthop and defaultroute feature o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/111713 ipfw [dummynet] Too few dummynet queue slots o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci 24 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 18 17:53:08 2007 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F32ED16A468; Mon, 18 Jun 2007 17:53:07 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id CA39313C44B; Mon, 18 Jun 2007 17:53:07 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (maxim@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5IHr776053413; Mon, 18 Jun 2007 17:53:07 GMT (envelope-from maxim@freefall.freebsd.org) Received: (from maxim@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5IHr7gu053409; Mon, 18 Jun 2007 17:53:07 GMT (envelope-from maxim) Date: Mon, 18 Jun 2007 17:53:07 GMT From: Maxim Konovalov Message-Id: <200706181753.l5IHr7gu053409@freefall.freebsd.org> To: bu7cher@yandex.ru, maxim@FreeBSD.org, freebsd-ipfw@FreeBSD.org Cc: Subject: Re: kern/113388: [ipfw][patch] Addition actions with rules within specified set's X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2007 17:53:08 -0000 Synopsis: [ipfw][patch] Addition actions with rules within specified set's State-Changed-From-To: open->patched State-Changed-By: maxim State-Changed-When: Mon Jun 18 17:52:50 UTC 2007 State-Changed-Why: Committed to HEAD. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=113388 From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 18 18:00:17 2007 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04A1C16A421 for ; Mon, 18 Jun 2007 18:00:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id E83E313C457 for ; Mon, 18 Jun 2007 18:00:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5II0GPI053790 for ; Mon, 18 Jun 2007 18:00:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5II0Gn2053789; Mon, 18 Jun 2007 18:00:16 GMT (envelope-from gnats) Date: Mon, 18 Jun 2007 18:00:16 GMT Message-Id: <200706181800.l5II0Gn2053789@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/113388: commit references a PR X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2007 18:00:17 -0000 The following reply was made to PR kern/113388; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/113388: commit references a PR Date: Mon, 18 Jun 2007 17:52:44 +0000 (UTC) maxim 2007-06-18 17:52:38 UTC FreeBSD src repository Modified files: sys/netinet ip_fw2.c sbin/ipfw ipfw.8 ipfw2.c Log: o Make ipfw set more robust -- now it is possible: - to show a specific set: ipfw set 3 show - to delete rules from the set: ipfw set 9 delete 100 200 300 - to flush the set: ipfw set 4 flush - to reset rules counters in the set: ipfw set 1 zero PR: kern/113388 Submitted by: Andrey V. Elsukov Approved by: re (kensmith) MFC after: 6 weeks Revision Changes Path 1.201 +20 -2 src/sbin/ipfw/ipfw.8 1.106 +111 -39 src/sbin/ipfw/ipfw2.c 1.166 +60 -18 src/sys/netinet/ip_fw2.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Tue Jun 19 00:30:12 2007 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A180B16A41F for ; Tue, 19 Jun 2007 00:30:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4E76213C455 for ; Tue, 19 Jun 2007 00:30:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5J0UCfK082453 for ; Tue, 19 Jun 2007 00:30:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5J0UCOs082451; Tue, 19 Jun 2007 00:30:12 GMT (envelope-from gnats) Date: Tue, 19 Jun 2007 00:30:12 GMT Message-Id: <200706190030.l5J0UCOs082451@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Sean McNeil Cc: Subject: Re: conf/78762: [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewall_script not read it X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sean McNeil List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2007 00:30:12 -0000 The following reply was made to PR conf/78762; it has been noted by GNATS. From: Sean McNeil To: bug-followup@FreeBSD.org, jonw@whoweb.com Cc: Subject: Re: conf/78762: [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewall_script not read it Date: Mon, 18 Jun 2007 17:05:45 -0700 This is a bad idea and has broken the new feature of rcNG allowing us to place options into /etc/rc.conf.d/ipfw and /etc/rc.conf.d/ip6fw. The commit to src/etc/rc.d/ipfw revision 1.15 and src/etc/rc.d/ip6fw 1.9 have now broken this basic concept. IMHO, the correct thing is: Don't use exit in your firewall script. I offer 3 solutions, however, below. What has been broken: /etc/rc.conf.d/ipfw firewall_enable="YES" firewall_type="/etc/fw/rc.firewall.rules" /etc/rc.conf.d/ip6fw ipv6_firewall_enable="YES" ipv6_firewall_type="/etc/fw/rc.firewall6.rules" Now, this no longer works and I must once again pollute and move more stuff back into /etc/rc.conf. Namely, firewall_type="/etc/fw/rc.firewall.rules" ipv6_firewall_type="/etc/fw/rc.firewall6.rules" must now be in /etc/rc.conf or /etc/rc.conf.local. Solution: 1) revert to sourcing the rc.firewall script. 2) Fix rc.firewall and rc.firewall6 to somehow get stuff from /etc/rc.conf.d as it should (as ipfw and ip6fw?). 3) completely remove rc.conf.d support as more things fail to work with it. From owner-freebsd-ipfw@FreeBSD.ORG Tue Jun 19 05:30:23 2007 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA1EC16A469 for ; Tue, 19 Jun 2007 05:30:23 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8A46413C46A for ; Tue, 19 Jun 2007 05:30:23 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5J5UNgG006393 for ; Tue, 19 Jun 2007 05:30:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5J5UNYY006392; Tue, 19 Jun 2007 05:30:23 GMT (envelope-from gnats) Date: Tue, 19 Jun 2007 05:30:23 GMT Message-Id: <200706190530.l5J5UNYY006392@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: jonw@whoweb.com Cc: Subject: Re: conf/78762: [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewall_script not read it X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jonw@whoweb.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2007 05:30:24 -0000 The following reply was made to PR conf/78762; it has been noted by GNATS. From: jonw@whoweb.com To: "Sean McNeil" Cc: bug-followup@freebsd.org, jonw@whoweb.com Subject: Re: conf/78762: [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewall_script not read it Date: Tue, 19 Jun 2007 01:12:57 -0400 (EDT) Sourcing is intended to be used like "#include" for including libraries of functions and variable assignments, not running "scripts" that are intended to be executed. The fact that the shell executes code that is sourced, doesn't make it correct policy to use it as such and is indicative of someone finding a loophole for supporting /etc/rc.conf.d but forgetting the basics of real programming. Only the simplest of scripts will survive being sourced. Anyone who tries to build a complex script to support numerous conditions and branches is going to assume they can use an exit statement if they require one. I did. You can't call something a script and not support exiting, and suggesting to simply not use exit is the reason that we are discussing this now. Not using exit suits your requirements for including options from /etc/rc.conf.d fine, but doesn't suit my needs to actually execute a script that has conditions and branches based upon various OS configurations and from which I might need to exit immediately if certain conditions are met. It's wrong to call something a script (ie firewall_script) and treat it like an include file, so reverting to the previous functionality is not the correct solution. I must be missing something regarding your variables from rc.conf.d/ipfw not being included in the ipfw script. The load_rc_config routine looks for /etc/rc.conf.d/ipfw and sources that in before executing the startup code. Executing or sourcing firewall_script shouldn't have any impact on the rc.conf.d/ipfw variables. It sounds to me like the correct solution is to support both includes and executables. That can be done a couple of ways, maybe more. 1) If firewall_script is defined, execute it. If firewall_include is defined, source it. 2) Check the mode of firewall_script. If it's executable, execute it. If it's not executable, source it. Jon > This is a bad idea and has broken the new feature of rcNG allowing us to > place options into /etc/rc.conf.d/ipfw and /etc/rc.conf.d/ip6fw. The > commit to src/etc/rc.d/ipfw revision 1.15 and src/etc/rc.d/ip6fw 1.9 > have now broken this basic concept. > > IMHO, the correct thing is: Don't use exit in your firewall script. I > offer 3 solutions, however, below. > > What has been broken: > > /etc/rc.conf.d/ipfw > firewall_enable="YES" > firewall_type="/etc/fw/rc.firewall.rules" > > /etc/rc.conf.d/ip6fw > ipv6_firewall_enable="YES" > ipv6_firewall_type="/etc/fw/rc.firewall6.rules" > > Now, this no longer works and I must once again pollute and move more > stuff back into /etc/rc.conf. Namely, > > firewall_type="/etc/fw/rc.firewall.rules" > ipv6_firewall_type="/etc/fw/rc.firewall6.rules" > > must now be in /etc/rc.conf or /etc/rc.conf.local. > > Solution: > > 1) revert to sourcing the rc.firewall script. > 2) Fix rc.firewall and rc.firewall6 to somehow get stuff > from /etc/rc.conf.d as it should (as ipfw and ip6fw?). > 3) completely remove rc.conf.d support as more things fail to work with > it. > > > From owner-freebsd-ipfw@FreeBSD.ORG Tue Jun 19 06:10:09 2007 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F067A16A41F for ; Tue, 19 Jun 2007 06:10:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id DACD813C46C for ; Tue, 19 Jun 2007 06:10:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5J6A8KX009492 for ; Tue, 19 Jun 2007 06:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5J6A8RZ009491; Tue, 19 Jun 2007 06:10:08 GMT (envelope-from gnats) Date: Tue, 19 Jun 2007 06:10:08 GMT Message-Id: <200706190610.l5J6A8RZ009491@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Sean McNeil Cc: Subject: Re: conf/78762: [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewall_script not read it X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sean McNeil List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2007 06:10:09 -0000 The following reply was made to PR conf/78762; it has been noted by GNATS. From: Sean McNeil To: jonw@whoweb.com Cc: bug-followup@freebsd.org Subject: Re: conf/78762: [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewall_script not read it Date: Mon, 18 Jun 2007 23:02:21 -0700 On Tue, 2007-06-19 at 01:12 -0400, jonw@whoweb.com wrote: > Sourcing is intended to be used like "#include" for including libraries of > functions and variable assignments, not running "scripts" that are > intended to be executed. The fact that the shell executes code that is > sourced, doesn't make it correct policy to use it as such and is > indicative of someone finding a loophole for supporting /etc/rc.conf.d but > forgetting the basics of real programming. > > Only the simplest of scripts will survive being sourced. Anyone who tries > to build a complex script to support numerous conditions and branches is > going to assume they can use an exit statement if they require one. I > did. You can't call something a script and not support exiting, and > suggesting to simply not use exit is the reason that we are discussing > this now. Not using exit suits your requirements for including options > from /etc/rc.conf.d fine, but doesn't suit my needs to actually execute a > script that has conditions and branches based upon various OS > configurations and from which I might need to exit immediately if certain > conditions are met. > > It's wrong to call something a script (ie firewall_script) and treat it > like an include file, so reverting to the previous functionality is not > the correct solution. I must be missing something regarding your > variables from rc.conf.d/ipfw not being included in the ipfw script. The > load_rc_config routine looks for /etc/rc.conf.d/ipfw and sources that in > before executing the startup code. Executing or sourcing firewall_script > shouldn't have any impact on the rc.conf.d/ipfw variables. > > It sounds to me like the correct solution is to support both includes and > executables. That can be done a couple of ways, maybe more. > > 1) If firewall_script is defined, execute it. If firewall_include is > defined, source it. > > 2) Check the mode of firewall_script. If it's executable, execute it. If > it's not executable, source it. > > Jon Thank you, Jon. I like your suggestion. Indeed, having something named _script and sourcing it would be misleading. The problem is that when you execute the script you lose all assignments made in /etc/rc.d/ipfw and /etc/rc.firewall only sources /etc/rc.conf and /etc/rc.conf.local. Actually, I think your suggestion should have been applied and firewall_script should have been executed without forcing the shell with the /bin/sh or ".". That way you can direct which shell to use in the script (#!/bin/sh, #!/bin/csh) or in the assignment of $firewall_script and the default could be changed from "/etc/rc.firewall" to ". /etc/rc.firewall". Except then something would have to be done with the -z and -r tests, so that wouldn't quite work as is. Funny how such a little thing can become so complicated. If I understand you correctly about read vs. execute, it should look something like if [ -x "${firewall_script}" ]; then "${firewall_script}" else . "${firewall_script}" fi This would restore the rcNG /etc/rc.conf.d/ipfw setting ability and allow you to use the shell of your choosing. > > > This is a bad idea and has broken the new feature of rcNG allowing us to > > place options into /etc/rc.conf.d/ipfw and /etc/rc.conf.d/ip6fw. The > > commit to src/etc/rc.d/ipfw revision 1.15 and src/etc/rc.d/ip6fw 1.9 > > have now broken this basic concept. > > > > IMHO, the correct thing is: Don't use exit in your firewall script. I > > offer 3 solutions, however, below. > > > > What has been broken: > > > > /etc/rc.conf.d/ipfw > > firewall_enable="YES" > > firewall_type="/etc/fw/rc.firewall.rules" > > > > /etc/rc.conf.d/ip6fw > > ipv6_firewall_enable="YES" > > ipv6_firewall_type="/etc/fw/rc.firewall6.rules" > > > > Now, this no longer works and I must once again pollute and move more > > stuff back into /etc/rc.conf. Namely, > > > > firewall_type="/etc/fw/rc.firewall.rules" > > ipv6_firewall_type="/etc/fw/rc.firewall6.rules" > > > > must now be in /etc/rc.conf or /etc/rc.conf.local. > > > > Solution: > > > > 1) revert to sourcing the rc.firewall script. > > 2) Fix rc.firewall and rc.firewall6 to somehow get stuff > > from /etc/rc.conf.d as it should (as ipfw and ip6fw?). > > 3) completely remove rc.conf.d support as more things fail to work with > > it. > > > > > > > > >