Shortly after I release Shorewall 3.4.2, I will be issuing the first release
of the new development thread which I'm calling Shorewall4.

I'm announcing the new product ahead of time so that people will have a
chance to comment on the approach (and the product name) in advance of the
initial release.

Shorewall4 is going to be a companion product to Shorewall. It will include
a new compiler, written entirely in Perl.

Shorewall4 depends on Shorewall (3.4.2 or later). So if you want to use the
new compiler, you must install both Shorewall and Shorewall4.

Even if you install Shorewall4, you have a choice of which compiler you use.
The choice is specified in the shorewall.conf file so you can select the
compiler to use on a system-by-system basis when running Shorewall Lite on
remote systems.

I decided to make Shorewall4 a separate product for several reasons:

a) Embedded applications are unlikely to adopt Shorewall4; even Mini-Perl
has a substantial disk and Ram footprint.

b) Because of the gross incompatibilities between the new compiler and the
old (see below), migration to the new compiler must be voluntary.

c) By allowing Shorewall4 to co-exist with the current Shorewall stable
release (3.4), I'm hoping that the new compiler will get more testing and
validation than it would if I were to package it with a new development
version of Shorewall itself.

d) Along the same vein, I think that users will be more likely to experiment
with the new compiler if they can easily fall back to the old one if things
get sticky.

The good news:

a) The compiler has a small disk footprint (although Perl is large).
b) The compiler is very fast.
c) The compiler generates a firewall script that uses iptables-restore;
so the script is very fast.
d) Again -- use of the Perl compiler is optional! The old slow clunky
   Bourne-shell compiler will still be available and will be the default
   compiler.

The bad news:

There are a number of incompatibilities between the Perl-based compiler
and the Bourne-shell one. Here are some of them (I'm still in the process of
cataloging them).

a) The Perl-based compiler requires the following capabilities in your
   kernel and iptables.

   - addrtype match
   - conntrack match
   - extended multiport match

   These capabilities are available in current Linux distributions.

b) BRIDGING=Yes is not supported. The kernel code necessary to
   support this option was removed in Linux kernel 2.6.20 so it seems silly
   to spend time implementing support for it in a new compiler.

c) MAPOLDACTIONS=Yes is not supported. It's time to start using Macros if
   you haven't already.

d) The BROADCAST column in the interfaces file is essentially unused;
   if you enter anything in this column but '-' or 'detect', you will
   receive a warning (addrtype match is a much superior method if handling
   broadcasts and smurfs).

e) Because the compiler is now written in Perl, your compile-time
   extension scripts from earlier versions will no longer work. New
   compile-time extension scripts must be written in Perl.

f) Some run-time extension scripts are no longer supported because they
   make no sense (iptables-restore instantiates the new configuration
   atomically).

        continue
        initdone
        refresh
        refreshed

g) The 'refresh' command is now synonymous with 'restart'.

h) Currently, support for ipsets is untested. That will change with
   future releases but one thing is certain -- Shorewall is now out of the
   ipset load/reload business. Because the Netfilter ruleset is never
   cleared, there is no opportunity for Shorewall to load/reload your
   ipsets.

   So:
        
        i)   Your ipsets must be loaded before Shorewall starts.
        
        ii)  Your ipsets may not be reloaded until Shorewall is stopped or
             cleared.

        iii) If you specify ipsets in your routestopped file then
             Shorewall must be cleared in order to reload your ipsets.

   As a consequence, scripts generated by the Perl-based compiler will
   ignore /etc/shorewall/ipsets and will issue a warning if you set
   SAVE_IPSETS=Yes in shorewall.conf.

I welcome feedback and discussion,

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ [EMAIL PROTECTED]
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to