shorewall_code/Shorewall2/releasenotes.txt
2004-04-21 20:12:23 +00:00

95 lines
3.5 KiB
Plaintext
Executable File

Shorewall 2.0.2-Beta 1
----------------------------------------------------------------------
Problems Corrected since 2.0.1
1) The /etc/init.d/shorewall script installed on Debian by install.sh
failed silently due to a missing file
(/usr/share/shorewall/wait4ifup). That file is not part of the
normal Shorewall distribution and is provided by the Debian
maintainer.
-----------------------------------------------------------------------
Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:
1) Dynamic Zone support.
If you don't need to use the "shorewall add" and "shorewall delete"
commands, you should set DYNAMIC_ZONES=No in
/etc/shorewall/shorewall.conf .
New Features:
1) The previous implementation of dynamic zones was difficult to
maintain. I have changed the code to make dynamic zones optional
under the control of the DYNAMIC_ZONES option in
/etc/shorewall/shorewall.conf.
2) In earlier Shorewall 2.0 releases, Shorewall searches in order the
following directories for configuration files.
a) The directory specified in a 'try' command or specified using
the -c option.
b) /etc/shorewall
c) /usr/share/shorewall
In this release, the CONFIG_PATH option is added to shorewall.conf.
CONFIG_PATH contains a list of directory names separated by colons
(":"). If not set or set to a null value (e.g., CONFIG_PATH="") then
"CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed.
Now Shorewall searches for shorewall.conf according to the old
rules and for other configuration files as follows:
a) The directory specified in a 'try' command or specified using
the -c option.
b) Each directory in $CONFIG_PATH is searched in sequence.
In case it is not obvious, your CONFIG_PATH should include
/usr/share/shorewall and your shorewall.conf file must be in the
directory specified via -c or in a try command, in /etc/shorewall
or in /usr/share/shorewall.
For distribution packagers, the default CONFIG_PATH is set in
/usr/share/shorewall/configpath. You can customize this file to
have a default that differs from mine.
3) Previously, in /etc/shorewall/nat a Yes (or yes) in the LOCAL column
would only take effect if the ALL INTERFACES column also contained
Yes or yes. Now, the LOCAL columns contents are treated
independently of the contents of the ALL INTERFACES column.
4) The folks at Mandrake have created yet another kernel module
naming convention. As a consequence, beginning with this release,
if MODULE_PREFIX isn't specified in shorewall.conf, then the default
value is "o gz ko o.gz ko.gz".
5) An updated bogons file is included in this release.
6) In /etc/shorewall/rules and in action files generated from
/usr/share/shorewall/action.template, rules that perform logging can
specify an optional "log tag". A log tag is a string of alphanumeric
characters and is specified by following the log level with ":" and
the log tag.
Example:
ACCEPT:info:ftp net dmz tcp 21
The log tag is appended to the log prefix generated by the LOGPREFIX
variable in /etc/shorewall/conf. If "ACCEPT:info" generates the log
prefix "Shorewall:net2dmz:ACCEPT:" then "ACCEPT:info:ftp" will
generate "Shorewall:net2dmz:ACCEPT:ftp " (note the trailing blank).
The maximum length of a log prefix supported by iptables is 29
characters; if a larger prefix is generated, Shorewall will issue a
warning message and will truncate the prefix to 29 characters.