Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Jun 2007 05:30:23 GMT
Subject:   Re: conf/78762: [ipfw] [patch] /etc/rc.d/ipfw should excecute  $firewall_script not read it
Message-ID:  <>

Next in thread | Raw E-Mail | Index | Archive | Help
The following reply was made to PR conf/78762; it has been noted by GNATS.

To: "Sean McNeil" <>
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.
 > 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.

Want to link to this message? Use this URL: <>