forked from extern/shorewall_code
a29ff62fbe
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1272 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
87 lines
3.0 KiB
Plaintext
Executable File
87 lines
3.0 KiB
Plaintext
Executable File
Shorewall 2.0.2-Beta 1
|
|
|
|
----------------------------------------------------------------------
|
|
Problems Corrected since 2.0.1
|
|
|
|
None.
|
|
|
|
-----------------------------------------------------------------------
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|