> 3) Previously, the install scripts included in the Shorewall packages
> were very restrictive. They could either be run to install directly
> onto the system in a distribution-dependent way, or they could
> install into a directory in a distribution-independent way. This
> limited their usefullness to packagers.
>
> Beginning with this release, the install scripts handle the install
> system and the target system independently. When running an
> installer, the following environmental variables can be set:
>
> a) BUILD - Describes the system where the installer is
> running. Accepted values are:
>
> cygwin - Cygwin running u\nder a Microsoft OS
> apple - OS X
> debian - Debian,Ubuntu,etc.
> redhat - Fedora,RHEL,Centos,Foobar,etc.
> slackware - Slackware
> archlinux - Arch Linux
> linux - Generic Linux
>
Is there a definite list of all arch-dependent variables used to define
these various "profiles"? If so, what are they?
Also, what happens if I want to use a different install directory - say
"/opt/shorewall"?
In addition, shorewall's uninstall.sh is bound to fail miserably,
because it is littered with absolute/assumed path names, so it is
completely useless given the above setup. Not to mention that if I want
to update a remote installation (say, shorewall-lite on embedded device)
there is currently no way I could do that easily without messing about
and wasting hours of my time.
> The choice of HOST and TARGET follow the naming of similar macros
> in rpm and autoconf.
>
You mean "HOST" and "BUILD", surely?
> Additionally, support has been added for sourcing a file containing
> option settings. The file name is 'shorewall-pkg.config' in the
> parent directory of the untar'ed package file.
>
Similar to my question above - could you list the set of variables
used/configurable by install.sh for each arch?
> 6) A SWITCH column has been added to /etc/shorewall/masq. This column
> allows for enabling and disabling a rule based on a setting in
> /proc/net/nf_condition. See shorewall-masq(5) for details.
>
masq:
~~~~~
eth0 10.1.1.7/30 41000-42000
shorewall compile passes, then I get the following iptables error:
iptables-restore v1.4.12.2: Need TCP, UDP, SCTP or DCCP with port
specification
masq:
~~~~~
eth0 10.1.1.7/30 41000-42000 udp +ntp-ports[dst,dst]
Compiling /etc/shorewall/masq...
ERROR: Invalid/Unknown tcp port/service (+ntp-ports[dst)
ntp-ports is 2 dimensional: proto:port
the following iptables statement is perfectly legit (given the above
SNAT bug for having to always specify the protocol):
iptables -t nat -A eth0_masq -p 17 -s 10.1.1.7/30 -m set --match-set
ntp-ports dst,dst -j MASQUERADE --to-ports 41000-42000
> 7) The rules compiler now issues a warning when the 'src' ipset flag
> is used in a destination column or the 'dst' ipset flag is used in
> a source column.
>
Mar 18 02:02:19 test1 shorewall[28538]: WARNING: The 'dst' ipset flag
is used in a Source column : /etc/shorewall/rules (line 21)
Mar 18 02:02:19 test1 shorewall[28538]: WARNING: The 'dst' ipset flag
is used in a Source column : /etc/shorewall/rules (line 22)
Mar 18 02:02:19 test1 shorewall[28538]: WARNING: The 'dst' ipset flag
is used in a Source column : /etc/shorewall/rules (line 23)
Mar 18 02:02:19 test1 shorewall[28538]: WARNING: The 'dst' ipset flag
is used in a Source column : /etc/shorewall/rules (line 24)
The above warnings are produced as a result of completely legitimate use
of the 'dst' column in statements like "ACCEPT $FW:+some-set[dst]
net:+some-other-set", so shorewall should be amended to *not* issue these!
Also, I am still getting these during compilation:
shorewall[1439]: Compiling /etc/shorewall/blrules...
shorewall[1439]: WARNING: Ipset whitelist does not exist
shorewall[1439]: Compiling /etc/shorewall/rules...
shorewall[1439]: WARNING: Ipset voip-blacklist does not exist
shorewall[1439]: WARNING: Ipset XXX does not exist
[...ad nauseum...]
shorewall[1439]: WARNING: Ipset ZZZ does not exist
The above still has not been fixed, though it was reported to you
before. It is true that these ipsets "do not exists", but are created as
a result of execution of "init", so in effect they do exists.
> 10) The 'update' command now omits non-default settings of
> WIDE_TC_MARKS and HIGH_ROUTE_MARKS from the updated .conf file.
>
"shorewall update" does not function if files are in a non-standard
directory (.back files renamed, but new files placed in the default
directory). For example, if I just have a placeholder shorewall.conf
file in /etc/shorewall and everything else is in, say, /opt/shorewall,
"shorewall update" is royally screwed!
In addition to the above bugs:
DNAT bugs
1. There is currently *no* support for ipsets in DNAT whatsoever! The
following should be a perfectly legitimate statement:
"DNAT net:+external-net $FW:10.1.1.1 udp +proxy-ports", which should
be translated to:
"-A net_dnat -p 17 -m set --match-set proxy-ports dst -m set
--match-set external-net src -j DNAT --to-destination 10.1.1.1", but
shorewall chokes on it.
2. Using shorewall to prepare remote configuration files for
shorewall-lite I get the following little gems (I used "shorewall
compile" and activated full tracing):
rules
~~~~~
DNAT wan:10.2.1.0/24 lan:10.1.2.6:1700 tcp 1701 - 10.2.2.2
Compiling /home/mr-4/shorewall/rules...
ERROR: Internal error in Shorewall::Chains::set_rule_option at
/usr/share/perl5/Shorewall/Chains.pm line 727 :
/home/mr-4/shorewall/rules (line 17) at
/usr/share/perl5/Shorewall/Config.pm line 834
Shorewall::Config::fatal_error('Internal error in
Shorewall::Chains::set_rule_option at /usr/...') called at
/usr/share/perl5/Shorewall/Config.pm line 868
Shorewall::Config::assert('') called at
/usr/share/perl5/Shorewall/Chains.pm line 727
Shorewall::Chains::set_rule_option('HASH(0x1710ac8)', 'conntrack',
'--ctorigdst 10.2.2.2') called at /usr/share/perl5/Shorewall/Chains.pm
line 806
Shorewall::Chains::transform_rule('-p 6 --dport 1700 -m conntrack
--ctorigdstport 1701 -s 10.2.1...') called at
/usr/share/perl5/Shorewall/Chains.pm line 1016
Shorewall::Chains::push_rule('HASH(0x16e4d68)', '-p 6 --dport 1700
-m conntrack --ctorigdstport 1701 -s 10.2.1...') called at
/usr/share/perl5/Shorewall/Chains.pm line 1164
Shorewall::Chains::add_rule('HASH(0x16e4d68)', '-p 6 --dport 1700 -m
conntrack --ctorigdstport 1701 -s 10.2.1...', 1) called at
/usr/share/perl5/Shorewall/Chains.pm line 5942
Shorewall::Chains::expand_rule('HASH(0x16e4d68)', 0, '-p 6 --dport
1700 -m conntrack --ctorigdstport 1701 ', '10.2.1.0/24', 10.1.2.6,
10.2.2.2, 'ACCEPT', '', 'DNAT', ...) called at
/usr/share/perl5/Shorewall/Rules.pm line 2280
Shorewall::Rules::process_rule1(undef, 'DNAT', '',
'wan:10.2.1.0/24', 'lan:10.1.2.6:1700', 'tcp', 1701, '-', 10.2.2.2, ...)
called at /usr/share/perl5/Shorewall/Rules.pm line 2434
Shorewall::Rules::process_rule() called at
/usr/share/perl5/Shorewall/Rules.pm line 2577
Shorewall::Rules::process_rules(0) called at
/usr/share/perl5/Shorewall/Compiler.pm line 794
Shorewall::Compiler::compiler('script', 'firewall', 'directory',
'/home/mr-4/shorewall', 'verbosity', 1, 'timestamp', 0, 'debug', ...)
called at /usr/libexec/shorewall/compiler.pl line 130
make: *** [compile] Error 25
rules
~~~~~
DNAT- wan:10.2.1.0/24 lan:10.1.2.6:1700 tcp 1701 - 10.2.2.2
Compiling /home/mr-4/shorewall/rules...
WARNING: The destination zone (lan) is ignored in DNAT rules :
/home/mr-4/shorewall/rules (line 17) at
/usr/share/perl5/Shorewall/Rules.pm line 1891
Shorewall::Rules::process_rule1(undef, 'DNAT-', '',
'wan:10.2.1.0/24', 'lan:10.1.2.6:1700', 'tcp', 1701, '-', 10.2.2.2, ...)
called at /usr/share/perl5/Shorewall/Rules.pm line 2434
Shorewall::Rules::process_rule() called at
/usr/share/perl5/Shorewall/Rules.pm line 2577
Shorewall::Rules::process_rules(0) called at
/usr/share/perl5/Shorewall/Compiler.pm line 794
Shorewall::Compiler::compiler('script', 'firewall', 'directory',
'/home/mr-4/shorewall', 'verbosity', 1, 'timestamp', 0, 'debug', ...)
called at /usr/libexec/shorewall/compiler.pl line 130
rules
~~~~~
DNAT wan:10.2.1.0/24 10.1.2.6:1700 tcp 1701 - 10.2.2.2
Compiling /home/mr-4/shorewall/rules...
ERROR: Unknown destination zone (10.1.2.6) :
/home/mr-4/shorewall/rules (line 17) at
/usr/share/perl5/Shorewall/Config.pm line 834
Shorewall::Config::fatal_error('Unknown destination zone
(10.1.2.6)') called at /usr/share/perl5/Shorewall/Rules.pm line 1901
Shorewall::Rules::process_rule1(undef, 'DNAT', '',
'wan:10.2.1.0/24', '10.1.2.6:1700', 'tcp', 1701, '-', 10.2.2.2, ...)
called at /usr/share/perl5/Shorewall/Rules.pm line 2434
Shorewall::Rules::process_rule() called at
/usr/share/perl5/Shorewall/Rules.pm line 2577
Shorewall::Rules::process_rules(0) called at
/usr/share/perl5/Shorewall/Compiler.pm line 794
Shorewall::Compiler::compiler('script', 'firewall', 'directory',
'/home/mr-4/shorewall', 'verbosity', 1, 'timestamp', 0, 'debug', ...)
called at /usr/libexec/shorewall/compiler.pl line 130
3. Crap status messages included in the compiled "firewall" file for use
on the remote machine, messages like:
progress_message2 Processing /home/mr-4/shorewall/init ... - it
should be just "Procesing init" as that directory is on my BUILD, not
HOST ("/home/mr-4/shorewall/" does *not* exist on HOST)
4. Wrong "SHOREWALL_SHELL" message: in non-standard configuration
(Android, for example - yes I *do* use shorewall-lite there!) the
directory structure is _very_ different from the standard Linux one, and
the location of the shell is also different. Since I compile "firewall"
and "firewall.conf" on a Linux BUILD, but deploy this (via a heavily
modified Makefile) to Android device, the location and name of the bash
shell is very different on BUILD and HOST, but during compilation I get
this non-nonsensical message:
WARNING: The program specified in SHOREWALL_SHELL does not exist or
is not executable; falling back to /bin/sh
This needs to be removed. I also get this:
/usr/share/shorewall/lib.cli-std: line 61: id: command not found
which is also nonsensical as "id" does exist, but it is in a different
location.
This all stems from the fact that throughout shorewall, various paths
are "assumed" and there is no central place from where those are picked
up - the whole thing is a mess!
It would be nice if shorewall had a single file (maybe similar to
shorewall-pkg.config, but on the installed machine where shorewall
functions) where it stores various path names and program names etc and
not have them scattered all over the place. Not to mention that if I
want to remove shorewall this would be nigh-impossible without messing
with my system for hours!
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
