Fix compilation failure on LEAF Bearing -- second pass; correct awkward wording in shorewall.conf comments

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3781 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb

Shorewall/changelog.txt

@@ -1,3 +1,7 @@
+Changes in 3.2.0 Beta 5
+
+1)  Fix compilation problem on LEAF Bering.
+
 Changes in 3.2.0 Beta 4
 
 1)  Fix 'routeback' with bridge ports.

Shorewall/compiler

@@ -8558,6 +8558,10 @@ compile_firewall() # $1 = File Name
     # END OVERLOADED FUNCTIONS
     #
 
+    #
+    # So that mktempdir doesn't have to jump through hoops when there isn't a working 'mktemp',
+    # we create the compiler's temporary directory in TMP_DIR
+    #
     STATEDIR=$TMP_DIR/compiler_state/
 
     mkdir $STATEDIR || fatal_error "Cannot create temporary directory in $TMP_DIR"
@@ -8972,7 +8976,6 @@ __EOF__
     fi
 
     rm -rf $TMP_DIR
-    rm -rf $STATEDIR
 
 }
 

Shorewall/releasenotes.txt

@@ -1,4 +1,4 @@
-Shorewall 3.2.0 Beta 4.
+Shorewall 3.2.0 Beta 5
 
 Note to users upgrading from Shorewall 2.x or 3.0
 
@@ -27,97 +27,20 @@ Note to users upgrading from Shorewall 2.x or 3.0
    Please see the "Migration Considerations" below for additional upgrade
    information.
 
-Problems Corrected in 3.2.0 Beta 4
+Problems Corrected in 3.2.0 Beta 5
 
-1)  Previously, the 'routeback' option was ignored in an entry in the
+1)  On systems such as LEAF Bering that either don't have the 'mktemp' utility
-    /etc/shorewall/hosts file that referred to a (set of) bridge port(s).
+   or whose 'mktemp' cannot create a temporary directory, firewall compilation
+   failed with the message:
 
-    Example:
+	ERROR: No Interfaces Defined
 
-	    dmz        xenbr0:vif+           routeback
+    after a shell error message indicating that the stripped interfaces
+    file in /tmp/shorewall-NNNN/ couldn't be opened.
 
-2)  Previously, if 'mktemp' was not installed on the firewall system and if
+Other changes in 3.2.0 Beta 5
-    a directory or file with the name /tmp/shorewall-<pid> existed (where <pid>
-    is the pid of the shell attempting to compile the Shorewall configuration),
-    then the current command would fail with error messages such as:
 
-    /usr/share/shorewall/compiler: 1: cannot create /tmp/shorewall-20000
+None.
-    ERROR: Cannot create temporary file in /tmp
-
-Other changes in 3.2.0 Beta 4
-
-1)  Shorewall now includes support for explicit routing rules when the
-    /etc/shorewall/providers file is used. A new file, /etc/shorewall/rtrules
-    can be used to add routing rules based on packet source and/or
-    destination.
-
-    The file has the following columns:
-
-		SOURCE(optonal) An ip address (network or host) that
-				matches the source IP address in a packet.
-				May also be specified as an interface
-				name optionally followed by ":" and an
-				address. If the define 'lo' is specified,
-				the packet must originate from the firewall
-				itself.
-
-		DEST(optional)  An ip address (network or host) that
-				matches the destination IP address in a packet.
-
-				If you choose to omit either SOURCE or DEST,
-				place "-" in the column. Note that you
-				may not omit both SOURCE and DEST.
-
-		PROVIDER        The provider to route the traffic through.
-				May be expressed either as the provider name
-				or the provider number.
-
-		PRIORITY
-				The rule's priority which determines the order
-				in which the rules are processed.
-
-				1000-1999   Before Shorewall-generated
-					    'MARK' rules
-
-				11000- 11999 After 'MARK' rules but before
-					    Shorewall-generated rules for
-					    provider interfaces.
-
-				26000-26999 After provider interface rules but
-					    before 'default' rule.
-
-				Rules with equal priority are applied in
-				the order in which they appear in the file.
-
-    Example: You want all traffic coming in on eth1 to be routed to the ISP1
-	     provider:
-
-	    #PROVIDER	PRIORITY	SOURCE			DEST
-	    ISP1	1000		eth1
-
-2)  Prior to now, it has not been possible to use connection marking in
-    /etc/shorewall/tcrules if you have a multi-ISP configuration that uses the
-    'track' option.
-
-    Beginning with this release, you may now set HIGH_ROUTE_MARKS=Yes in
-    shorewall.conf to effectively divide the packet mark and connection mark
-    into two 8-byte mark fields.
-
-    When you do this:
-
-	a) The MARK field in the providers file must have a value that is
-	   less than 65536 and that is a multiple of 256 (using hex
-	   representation, the values are 0x0100-0xFF00 with the low-order
-	   8 bits being zero).
-
-	b) You may only set those mark values in the PREROUTING chain.
-
-	c) Marks used for traffic shaping must still be in the range of 1-255
-	   and may still not be set in the PREROUTING chain.
-
-	d) When you SAVE or RESTORE in tcrules, only the TC mark value is
-	   saved or restored. Shorewall handles saving and restoring the
-	   routing (provider) marks.
 
 Migration Considerations:
 
@@ -513,3 +436,75 @@ New Features:
     Traffic from all other zones to 'chld' will be subject to the implicit
     CONTINUE policy.
 
+10) Shorewall now includes support for explicit routing rules when the
+    /etc/shorewall/providers file is used. A new file, /etc/shorewall/rtrules
+    can be used to add routing rules based on packet source and/or
+    destination.
+
+    The file has the following columns:
+
+		SOURCE(optonal) An ip address (network or host) that
+				matches the source IP address in a packet.
+				May also be specified as an interface
+				name optionally followed by ":" and an
+				address. If the define 'lo' is specified,
+				the packet must originate from the firewall
+				itself.
+
+		DEST(optional)  An ip address (network or host) that
+				matches the destination IP address in a packet.
+
+				If you choose to omit either SOURCE or DEST,
+				place "-" in the column. Note that you
+				may not omit both SOURCE and DEST.
+
+		PROVIDER        The provider to route the traffic through.
+				May be expressed either as the provider name
+				or the provider number.
+
+		PRIORITY
+				The rule's priority which determines the order
+				in which the rules are processed.
+
+				1000-1999   Before Shorewall-generated
+					    'MARK' rules
+
+				11000- 11999 After 'MARK' rules but before
+					    Shorewall-generated rules for
+					    provider interfaces.
+
+				26000-26999 After provider interface rules but
+					    before 'default' rule.
+
+				Rules with equal priority are applied in
+				the order in which they appear in the file.
+
+    Example: You want all traffic coming in on eth1 to be routed to the ISP1
+	     provider:
+
+	    #PROVIDER	PRIORITY	SOURCE			DEST
+	    ISP1	1000		eth1
+
+11) Prior to now, it has not been possible to use connection marking in
+    /etc/shorewall/tcrules if you have a multi-ISP configuration that uses the
+    'track' option.
+
+    Beginning with this release, you may now set HIGH_ROUTE_MARKS=Yes in
+    shorewall.conf to effectively divide the packet mark and connection mark
+    into two 8-byte mark fields.
+
+    When you do this:
+
+	a) The MARK field in the providers file must have a value that is
+	   less than 65536 and that is a multiple of 256 (using hex
+	   representation, the values are 0x0100-0xFF00 with the low-order
+	   8 bits being zero).
+
+	b) You may only set those mark values in the PREROUTING chain.
+
+	c) Marks used for traffic shaping must still be in the range of 1-255
+	   and may still not be set in the PREROUTING chain.
+
+	d) When you SAVE or RESTORE in tcrules, only the TC mark value is
+	   saved or restored. Shorewall handles saving and restoring the
+	   routing (provider) marks.

Shorewall/shorewall.conf

@@ -831,10 +831,10 @@ MAPOLDACTIONS=No
 #
 # Fast ESTABLISHED/RELATED handling
 #
-# Normally, Shorewall accepting ESTABLISHED/RELATED packets until these packets
+# Normally, Shorewall delays accepting ESTABLISHED/RELATED packets until these
-# reach the chain in which the original connection was accepted. So for packets
+# packets reach the chain in which the original connection was accepted. So
-# going from the 'loc' zone to the 'net' zone, ESTABLISHED/RELATED packets are
+# for packets going from the 'loc' zone to the 'net' zone, ESTABLISHED/RELATED
-# ACCEPTED in the 'loc2net' chain.
+# packets are ACCEPTED in the 'loc2net' chain.
 #
 # If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED packets are accepted
 # early in the INPUT, FORWARD and OUTPUT chains. If you set
@@ -856,18 +856,20 @@ FASTACCEPT=No
 # policy processing, set IMPLICIT_CONTINUE=No or IMPLICIT_CONTINUE=.
 #
 # Note that even with IMPLICIT_CONTINUE=Yes, you can override the implicit
-# CONTINUE policy for connections by adding an explicit policy (one that
+# CONTINUE policy by adding an explicit policy (one that does not contain
-# does not contain "all" in either the SOURCE or DEST columns).
+# "all" in either the SOURCE or DEST columns).
 
 IMPLICIT_CONTINUE=Yes
 
 #
 # Use high mark values for policy routing
 #
-# Normally, Shorewall restricts the set of mark values to 1-255. If this
+# Normally, Shorewall restricts the set of mark values to 1-255. If you set
-# HIGH_ROUTE_MARKS=Yes, Shorewall will rather restrict the set of mark values
+# HIGH_ROUTE_MARKS=Yes, Shorewall will rather restrict the set of routing
-# to 0x0100 to 0XFF00 to allow connection marks to be shared between traffic
+# mark values (those specified in the /etc/shorewall/providers file) to
-# shaping and policy routing (traffic shaping is always restricted to 1-255).
+# 0x0100 to 0XFF00 (with the low-order byte being zero). This allows
+# connection marks to be shared between traffic shaping and policy routing
+# (traffic shaping marks are always restricted to 1-255).
 #
 # Setting HIGH_ROUTE_MARKS=Yes requires that your kernel and iptables support
 # both the extended CONNMARK target and the extended connmark match