On 3/18/12 8:58 AM, "Mr Dash Four" <[email protected]> wrote:
> >> 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? http://www.shorewall.net/Install.htm#Locations > >Also, what happens if I want to use a different install directory - say >"/opt/shorewall"? Not possible currently. Relates to your suggestion near the end of this email. > >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. Above setup? > >> The choice of HOST and TARGET follow the naming of similar macros >> in rpm and autoconf. >> >You mean "HOST" and "BUILD", surely? Yes > >> 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? The names of the variables are immaterial since they cannot be specified externally but rather are set based on HOST and BUILD. The URL I included above describes where the various components are installed. > >> 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 Fix is commit 56f66bd966a06bcb386b354d9345bd410e14178a in the master branch. > >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 Currently, Shorewall does not accept an ipset name in *any* PORT column. > >> 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! These warnings were added in response to you railing about Shorewall accepting [src] in the INTERFACE column of the masq file which is a destination column. So decide what you really want. > >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. Again, you asked for this warning and you got it. But this warning and the one above are removed in commit > >> 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! Patient: "Dr., it hurts when I do this". Doctor: "Then don't do that" > >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. Not a bug -- the product works as documented but I'll consider adding such support. > >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 I'm unable to reproduce this -- please send me a test case with capabilities file. > >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 That is working as intended, so I assume that you are complaining that the WARNING message mentions 'DNAT' rather than 'DNAT-'? > >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 This is also working as intended. You have changed DNAT- to DNAT and omitted the destination zone. > >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) SighÂ. > >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. Fix in commit e47ae4f26ebcc9794023b82a06f940b086b949f1. >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! You are talking out of the wrong orifice -- Line 61 in lib.cli-std reads: if [ -z "$g_export" -a "$(id -u)" = 0 ]; then Do you get the above diagnostic when using the '-e' option? > >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! Yeah, I've been considering that for a while, but haven't mustered the energy to do it. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ 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
