On 10/2/2014 8:05 PM, Alan McKay wrote: > My release notes told me to look here > > http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.27/releasenotes.txt > > Still not really seeing the forest through the trees ...
----------------------------------------------------------------------------
V. M I G R A T I O N I S S U E S
----------------------------------------------------------------------------
1) If you are currently using Shorewall-shell:
a) In shorewall.conf, if you have specified
"SHOREWALL_COMPILER=shell" then you must either:
- change that specification to "SHOREWALL_COMPILER=perl"; or
- change that specification to "SHOREWALL_COMPILER="; or
- delete the specification altogether.
Failure to do so will result in the following warning:
WARNING: SHOREWALL_COMPILER=shell ignored. Shorewall-shell
support has been removed in this release.
b) Review the migration issues at
http://www.shorewall.net/LennyToSqueeze.html and make changes as
required.
We strongly recommend that you migrate to Shorewall-perl on your
current Shorewall version before upgrading to Shorewall 4.4.0. That
way, you can have both Shorewall-shell and Shorewall-perl available
until you are certain that Shorewall-perl is working correctly for
you.
2) The 'shorewall stop', 'shorewall clear', 'shorewall6 stop' and
'shorewall6 clear' commands no longer read the 'routestopped'
file. The 'routestopped' file used is the one that was present at
the last 'start', 'restart' or 'restore' command.
IMPORTANT: If you modify the routestopped file, you must refresh or
restart Shorewall before the changes to that file take effect.
3) The old macro parameter syntax (e.g., SSH/ACCEPT) is now deprecated
in favor of the new syntax (e.g., SSH(ACCEPT)). The 4.4 documentation
uses the new syntax exclusively, although the old syntax
continues to be supported.
The sample configurations also use the new syntax.
4) Support for the SAME target in /etc/shorewall/masq and
/etc/shorewall/rules has been removed, following the removal of the
underlying support in the Linux kernel.
5) Supplying an interface name in the SOURCE column of
/etc/shorewall/masq is now deprecated. Entering the name of an
interface there will result in a compile-time warning:
WARNING: Using an interface as the masq SOURCE requires the
interface to be up and configured when Shorewall
starts/restarts
To avoid this warning, replace interface names by the corresponding
network(s) in CIDR format (e.g., 192.168.144.0/24).
6) Previously, Shorewall has treated traffic shaping class IDs as
decimal numbers (or pairs of decimal numbers). That worked fine
until IPMARK was implemented. IPMARK requires Shorewall to generate
class Ids in numeric sequence. In 4.3.9, that didn't work correctly
because Shorewall was generating the sequence "..8,9,10,11..." when
the correct sequence was "...8,9,a,b,...". Shorewall now treats
class IDs as hex, as do 'tc' and 'iptables'.
This should only be an issue if you have more than 9 interfaces
defined in /etc/shorewall/tcdevices and if you use class IDs in
/etc/shorewall/tcrules or /etc/shorewall/tcfilters. You will need
to renumber the class IDs for devices 10 and greater.
7) Support for the 'norfc1918' interface and host option has been
removed. If 'norfc1918' is specified for an entry in either the
interfaces or the hosts file, a warning is issued and the option is
ignored. Simply remove the option to avoid the warning.
Similarly, if RFC1918_STRICT=Yes or a non-empty RFC1918_LOG_LEVEL
is given in shorewall.conf, a warning will be issued and the option
will be ignored.
You may simply delete the RFC1918-related options from your
shorewall.conf file if you are seeing warnings regarding them.
Users who currently use 'norfc1918' are encouraged to consider
using NULL_ROUTE_RFC1918=Yes instead.
8) The install.sh scripts in the Shorewall and Shorewall6 packages no
longer create a backup copy of the existing configuration. If you
want your configuration backed up prior to upgrading, you will
need to do that yourself.
As part of this change, the fallback.sh scripts are no longer
released.
9) In earlier releases, if an ipsec zone was defined as a sub-zone of
an ipv4 or ipv6 zone using the special <child>:<parent>,... syntax,
CONTINUE policies for the sub-zone did not work as
expected. Traffic that was not matched by a sub-zone rule was not
compared against the parent zone(s) rules.
In 4.4.0, such traffic IS compared against the parent zone rules.
10) The name 'any' is now reserved and may not be used as a zone name.
11) Perl module initialization has changed in Shorewall
4.4.1. Previously, each Shorewall Perl package would initialize its
global variables for IPv4 in an INIT block. Then, if the
compilation turned out to be for IPv6,
Shorewall::Compiler::compiler() would reinitialize them for IPv6.
Beginning in Shorewall 4.4.1, the modules do not initialize
themselves in an INIT block. So if you use Shorewall modules
outside of the Shorewall compilation environment, then you must
explicitly call the module's 'initialize' function after the module
has been loaded.
12) Checking for zone membership has been tighened up. Previously,
a zone could contain <interface>:0.0.0.0/0 along with other hosts;
now, if the zone has <interface>:0.0.0.0/0 (even with exclusions),
then it may have no additional members in /etc/shorewall/hosts.
13) ADD_IP_ALIASES=No is now the setting in the released shorewall.conf
and in all of the samples. This will not affect you during upgrade
unless you choose to replace your current shorewall.conf with the
one from the release (not recommended).
14) The names of interface configuration variables in generated scripts
have been changed to ensure uniqueness. These names now begin with
SW_.
This change will only affect you if your extension scripts are
using one or more of these variables.
Old Variable Name New Variable Name
-----------------------------------------------------
iface_ADDRESS SW_iface_ADDRESS
iface_BCASTS SW_iface_BCASTS
iface_ACASTS SW_iface_ACASTS
iface_GATEWAY SW_iface_GATEWAY
iface_ADDRESSES SW_iface_ADDRESSES
iface_NETWORKS SW_iface_NETWORKS
iface_MAC SW_iface_MAC
provider_IS_USABLE SW_provider_IS_USABLE
where 'iface' is a capitalized interface name (e.g., ETH0) and
'provider' is the capitalized name of a provider.
15) If your /etc/shorewall/params (or /etc/shorewall6/params) file
sends output to Standard Output, you need to be aware that the
output will be redirected to Standard Error beginning with
Shorewall 4.4.16.
16) Beginning with Shorewall 4.4.17, the EXPORTPARAMS option is
deprecated. With EXPORTPARAMS=No, the variables set by
/etc/shorewall/params (/etc/shorewall6/params) at compile time are
now available in the compiled firewall script.
17) The 'iprange' and 'ipaddr' commands require the 'bc' utility.
18) Beginning with Shorewall 4.4.26, the WIDE_TC_MARKS and
HIGH_ROUTE_MARKS options are deprecated in favor of TC_BITS,
MARK_BITS, PROVIDER_BITS and PROVIDER_OFFSET. The 'shorewall
update' ('shorewall6 update') command will set these net options
based on the values of the deprecated ones.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
