Fix TOS processing; Update release notes

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5731 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2007-03-28 17:43:09 +00:00
parent a983cc2a61
commit d08dca7c6b
3 changed files with 46 additions and 28 deletions

View File

@ -37,7 +37,8 @@ use Shorewall::Proc;
use strict; use strict;
our @ISA = qw(Exporter); our @ISA = qw(Exporter);
our @EXPORT = qw( add_common_rules our @EXPORT = qw( process_tos
add_common_rules
setup_mac_lists setup_mac_lists
process_criticalhosts process_criticalhosts
process_routestopped process_routestopped
@ -59,13 +60,13 @@ my @rule_chains;
my $sectioned = 0; my $sectioned = 0;
sub process_tos() { sub process_tos() {
my $chain = 'pretos'; my $chain = $capabilities{MANGLE_FORWARD} ? 'fortos' : 'pretos';
my $stdchain = 'PREROUTING'; my $stdchain = $capabilities{MANGLE_FORWARD} ? 'FORWARD' : 'PREROUTING';
if ( -s "$ENV{TMP_DIR}/tos" ) { if ( -s "$ENV{TMP_DIR}/tos" ) {
progress_message2 'Setting up TOS...'; progress_message2 'Setting up TOS...';
my $pretosref = new_chain 'mangle' , 'pretos'; my $pretosref = new_chain 'mangle' , $chain;
my $outtosref = new_chain 'mangle' , 'outtos'; my $outtosref = new_chain 'mangle' , 'outtos';
open TOS, "$ENV{TMP_DIR}/tos" or fatal_error "Unable to open stripped tos file: $!"; open TOS, "$ENV{TMP_DIR}/tos" or fatal_error "Unable to open stripped tos file: $!";
@ -107,6 +108,9 @@ sub process_tos() {
} }
close TOS; close TOS;
add_rule $mangle_table->{$stdchain}, "-j $chain";
add_rule $mangle_table->{OUTPUT}, "-j outtos";
} }
} }

View File

@ -750,6 +750,10 @@ sub compiler( $ ) {
progress_message2 "$doing TC Rules..."; progress_message2 "$doing TC Rules...";
setup_tc; setup_tc;
# #
# TOS
#
process_tos;
#
# Setup Masquerading/SNAT # Setup Masquerading/SNAT
# #
progress_message2 "$doing Masq file..."; progress_message2 "$doing Masq file...";

View File

@ -40,33 +40,35 @@ d) Use of the perl compiler is optional! The old slow clunky
The bad news: The bad news:
There are a number of incompatibilities between the Perl-based compiler There are a number of incompatibilities between the Perl-based compiler
and the Bourne-shell one. and the Bourne-shell one. Some of these will probably go away by first
official release but some will not.
a) The Perl-based compiler requires the following capabilities in your a) The Perl-based compiler requires the following capabilities in your
kernel and iptables. kernel and iptables.
- addrtype match - addrtype match (may be relaxed later)
- conntrack match - conntrack match (may be relaxed later)
- multiport match - multiport match (will not be relaxed)
These capabilities are in current distributions. These capabilities are in current distributions.
b) The Bourne-shell compiler goes to great pain (in some cases) to b) The Bourne-shell compiler goes to great pain (in some cases) to
break very long port lists ( > 15 where port ranges in lists count break very long port lists ( > 15 where port ranges in lists count
as two ports) into individual rules. I'm removing the ugliness as two ports) into individual rules. In the new compiler, I'm
required to do that (at least initially). The new compiler just avoiding the ugliness required to do that. The new compiler just
gives you an error. It will also give you an error if you insert a gives you an error if your list is too long. It will also give you
port range into a port list and you don't have extended multiport an error if you insert a port range into a port list and you don't
support. Now that Netfilter has features to deal reasonably with have extended multiport support. Now that Netfilter has features to
port lists, I see no reason to duplicate those features in deal reasonably with port lists, I see no reason to duplicate those
Shorewall. features in Shorewall.
c) BRIDGING=Yes is not supported. The kernel code necessary to c) BRIDGING=Yes is not supported. The kernel code necessary to
support this option was removed in Linux kernel 2.6.20. support this option was removed in Linux kernel 2.6.20.
d) The BROADCAST column in the interfaces file is essentailly unused; d) The BROADCAST column in the interfaces file is essentailly unused;
if you enter anything in this column but '-' or 'detect', you will if you enter anything in this column but '-' or 'detect', you will
receive a warning. receive a warning. This will be relaxed if and when the addrtype
match requirement is relaxed.
e) Because the compiler is now written in Perl, your compile-time e) Because the compiler is now written in Perl, your compile-time
extension scripts from earlier versions will no longer work. extension scripts from earlier versions will no longer work.
@ -83,7 +85,8 @@ g) Some run-time extension scripts are no longer supported because they
refresh refresh
refreshed refreshed
h) The /etc/shorewall/tos file now has a format similar to the tcrules. h) The /etc/shorewall/tos file now has zone-independent SOURCE and DEST
columns as do all other files except the rules and policy files.
The SOURCE column may be one of the following: The SOURCE column may be one of the following:
@ -95,6 +98,12 @@ h) The /etc/shorewall/tos file now has a format similar to the tcrules.
[all:]<address>[,...] [all:]<address>[,...]
[all:]<interface>[:<address>[,...]] [all:]<interface>[:<address>[,...]]
This is a perminent change. The old zone-based rules have never
worked right and this is a good time to replace them. I've tried to
make the new syntax cover the most common cases without requiring
change to existing files. In particular, it will handle the tos file
released with Shorewall 1.4 and earlier.
i) Currently, support for ipsets is untested. That will change with i) Currently, support for ipsets is untested. That will change with
future releases but one thing is certain -- Shorewall is now out of the future releases but one thing is certain -- Shorewall is now out of the
ipset load/reload business. With scripts generated by the Perl-based ipset load/reload business. With scripts generated by the Perl-based
@ -135,21 +144,22 @@ Using the New compiler
By default, the old Bourne-shell based compiler will be used. By default, the old Bourne-shell based compiler will be used.
There is one change in Shorewall operation that is triggered when To use the new compiler, add this to shorewall.conf:
/usr/share/shorewall-perl exists and is either a directory or a symbolic
link that points to a directory: Your params file will be processed
with the shell's '-a' option set which will automatically export any
variables that you set or create in that file. Since the params file is
processed before shorewall.conf, using the -a option assures that the
settings of your params variables are available to the new compiler
should it be used.
To actually use the new compiler, add this to shorewall.conf: SHOREWALL_COMPILER=perl
SHOREWALL_PERL=Yes
If you add this setting to /etc/shorewall/shorewall.conf then by If you add this setting to /etc/shorewall/shorewall.conf then by
default, the new compiler will be used on the system. If you add it to default, the new compiler will be used on the system. If you add it to
shorewall.conf in a separate directory (such as a Shorewall-lite export shorewall.conf in a separate directory (such as a Shorewall-lite export
directory) then the new compiler will only be used when you compile directory) then the new compiler will only be used when you compile
from that directory. from that directory.
Regardless of the setting of SHOREWALL_COMPILER, there is one change in
Shorewall operation that is triggered simply by installing
shorewall-perl. Your params file will be processed with the shell's
'-a' option which causes any variables that you set or create in that
file to be automatically exported. Since the params file is processed
before shorewall.conf, using -a insures that the settings of your
params variables are available to the new compiler should it's use be
specified in shorewall.conf.