The Shorewall team is pleased to announce the availability of Shorewall 4.5.1. Problems Corrected: 1) This release includes all defect repair from versions 4.5.0.1-4.5.0.3. 2) The Shorewall-init installer now installs the proper init script on Redhat and Fedora. 3) A typo has been corrected in the blrules man pages. 4) Previously, if the interface appearing in the HOSTS column of /etc/shorewall6/hosts was not defined in /etc/shorewall6/interfaces, then the compiler would terminate with a Perl diagnostic: Can''t use an undefined value as a HASH reference at /usr/share/shorewall/Shorewall/Zones.pm line 1817, <$currentfile> line ... 5) The handling of the LIBEXEC and PERLLIB variables was broken in the base 4.5.0 release. Simon Mater has supplied a fix which is included in this release. 6) On systems running systemd, init scripts are no longer installed in /etc/rc.d/init.d. 7) The Shorewall Init installer now correctly detects the use of systemd. 8) On systems running systemd, the installer now installs /sbin/shorewall-init. That file has not existed previously, even though shorewall-init.service is trying to use it. 9) The compiler was previously failing to validate the contents of the LENGTH and TOS columns in /etc/shorewall/tcrules. The contents of those columns are now validated by the compiler and an appropriate error message is issued if validation fails. 10) The column headings in the tos files are now in the proper order. Previously, the SOURCE PORT and DEST PORT columns were reversed. New Features: 1) Support is now included for IMQ. This takes the form of of IMQ(<number>) in the MARK/CLASSIFY column of /etc/shorewall/tcrules. 2) It is no longer necessary to specify a MARK value for the default class under a device that does not specify the ''classify'' option. Simple set the MARK column to ''-'' in the default class. 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 under a Microsoft OS apple - OS X debian - Debian,Ubuntu,etc. redhat - Fedora,RHEL,Centos,Foobar,etc. slackware - Slackware archlinux - Arch Linux linux - Generic Linux If BUILD is not set, then the installer uses its existing algorithm for detecting the current OS and distribution. b) HOST - Describes the system where the installed package will run. - For Shorewall and Shorewall6, the possible values are the same as for BUILD. - If HOST is not set, the value of BUILD (through setting or detection) is used. - For Shorewall-lite and Shorewall6-lite, the possible choices are debian, redhat, suse, slackware, archlinux and linux. - For Shorewall-init, the possible choices are debian, redhat, and suse. c) INITDIR - Gives the absolute path name of the directory containing the init scripts. The choice of HOST and TARGET follow the naming of similar macros in rpm and autoconf. As part of these changes, LIBEXEC and PERLLIB must now hold an absolute pathname. So, for example, if you have been using LIBEXEC=libexec you will need to change to LIBEXEC=/usr/libexec 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. 5) The .spec files included with each package have undergone considerable revision. When running the package ./install.sh script: a) The setting for LIBEXEC is taken from the standard ''_libexecdir'' rpm macro. b) The setting for PERLLIB is taken from the standard ''perl_privlib'' rpm macro. c) The setting for INITDIR is taken from the standard ''_initddir'' rpm macro. d) The setting of BUILD is detected by the install script. e) The setting for TARGET is taken from the standard ''_vendor'' rpm macro. The rpms included with Shorewall are built with these settings of the standard rpm-supplied macros: %_libexecdir /usr/libexec %perl_privlib /usr/share/shorewall %_initddir /etc/init.d %_vendor suse The setting of %perl_sitelib is chosen for portability, since there seems to be no common location for site-specific Perl modules among the rpm-based distributions. 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. 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. 8) Support has been added for matching and setting the "Differentiated Services Code Point" (DSCP) field in the IP header. See shorewall-tcrules(5) and shorewall6-tcrules(5) for details. 9) "Run-time gateway variables" are now supported. These variables have names that are composed of a percent sign (''%'') followed by the logical name of an interface defined in /etc/shorewall/interfaces. They are expanded to the IP address of the default gateway out of the corresponding interface. Example: %eth0 expands to the IP address of the default gateway out of eth0. See http://www.shorewall.net/configuration_file_basics.htm#Variables for details. 10) The ''update'' command now omits non-default settings of WIDE_TC_MARKS and HIGH_ROUTE_MARKS from the updated .conf file. 11) The ''isusable'' extension script is no longer installed by default. Users wishing to install it may simply copy it from /usr/share/shorewall[6]/configfiles. 12) Support has been added for seting the "Type of Service" (TOS) header field in shorewall-tcrules(5) and shorewall6-tcrules(5). See the manpages for details. As part of this change, use of the shorewall-tos(5) and shorewall6-tos(5) files is deprecated and a warning is issued on the first rule in each file. Thank you for using Shorewall, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> 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
On 3/18/12 8:58 AM, "Mr Dash Four" <mr.dash.four@googlemail.com> 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 >SpecificationFix 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-42000Currently, 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 25I''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 130That 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 130This 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
>> 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 >Yeah, I see. Rather grim this, particularly that none of this is remotely configurable. Most embedded devices (routers, smartphones etc) do not use this type of hierarchy at all. If I had a single file, which shorewall was using, then all I have to do is tweak this and proceed. As it is, I need to muck about with various shorewall components to get it working, just!>> 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? >Any setup, which isn''t using "standard" path names hard-coded in unistall.sh - have a look!>> 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. >I am open to suggestions then as to how to make this work, also bearing in mind that due to Netfilter stupidity I have to always specify the protocol (the nf devs might change that as I already raised that issue, but when - I have no idea).> >>> 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. >That is correct - and you''ve done a rather splendid job, but I don''t seem to remember telling you to change things in the rules file - the use of mixed ''src'' and ''dst'' identifiers in the rules file is perfectly reasonable/legitimate as I''ve illustrated in the example above. So, make your mind up whether you wish to deploy this throughout shorewall (and restrict legitimate uses) or whether you wish to do the right thing and restrict it only in cases where it makes no sense. It is up to you now!> >> 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 >Try again! I remember asking to have a warning when a given ipset _does not exist_, not when _it is not used yet_ as is the case with the example I''ve given above.> >>> 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" >What is that supposed to mean? Your "shorewall update" command is not working, so smart-arse comments like the one above won''t get you far. On all my systems I have shorewall.conf file in /etc/shorewall, consisting of a single line - "INCLUDE <real_path>/shorewall.conf" - to include my own shorewall.conf file used for that particular configuration (this was your idea by the way, if I remember correctly!). When I execute "shorewall update", it is not doing what''s supposed to be doing, so I doubt that you getting rather upset or cracking smart-arse comments like the one above would help fixing that particular bug!> I''m unable to reproduce this -- please send me a test case with > capabilities file. >I will, but it won''t be today as I''ll be rather busy in the coming days - will see if I could get it done by mid-week, if I can.>> 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Š. >It is rather annoying!>> 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? >As I already pointed out in the above post, I have turned on all tracing and debugging when running this, but I''ll prepare a test case with capabilities file for you.>> 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. >Installing/uninstalling/upgrading shorewall(-lite) on systems which do not have standard FHS is particularly painful! I have managed to fix most of the issues I was getting, but then if/when I need to upgrade, I have to go through all this again and I simply don''t have the inclination, nor desire to go through with it - I don''t have a couple of hours to spend messing about with patch/diff/sed/grep etc. to fix this - I''d rather have a single file where all my shorewall(-lite) settings/paths are and tweak those! ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> The Shorewall team is pleased to announce the availability of Shorewall > 4.5.1. >...> > 12) Support has been added for seting the "Type of Service" (TOS) > header field in shorewall-tcrules(5) and shorewall6-tcrules(5). See > the manpages for details. As part of this change, use of the > shorewall-tos(5) and shorewall6-tos(5) files is deprecated and a > warning is issued on the first rule in each file.Hi Tom an all, I have an issue with tos in RHEL5 (RHEL6 works fine). The following in tcrules: 1:P 0.0.0.0/0 0.0.0.0/0 tcp - ssh - - - Minimize-Delay Results in Running /sbin/iptables-restore... iptables-restore v1.3.5: Bad TOS value `0x10/0x3f'' Error occurred at line: 32 Try `iptables-restore -h'' or ''iptables-restore --help'' for more information. ERROR: iptables-restore Failed. Input is in /var/lib/shorewall/.iptables-restore-input The line in question is: -A tcpre -p 6 --sport 22 -m tos --tos 0x10/0x3f -j MARK --set-mark 1 Any chance this can be fixed so it works on older and newer systems? I don''t like to stick with shorewall-4.5.0 on affected hosts. Thanks, Simon ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/19/2012 07:22 AM, Simon Matter wrote:> Hi Tom an all, > > I have an issue with tos in RHEL5 (RHEL6 works fine). The following in > tcrules: > > 1:P 0.0.0.0/0 0.0.0.0/0 tcp - ssh > - - - Minimize-Delay > > Results in > > Running /sbin/iptables-restore... > iptables-restore v1.3.5: Bad TOS value `0x10/0x3f'' > Error occurred at line: 32 > Try `iptables-restore -h'' or ''iptables-restore --help'' for more information. > ERROR: iptables-restore Failed. Input is in > /var/lib/shorewall/.iptables-restore-input > > The line in question is: > -A tcpre -p 6 --sport 22 -m tos --tos 0x10/0x3f -j MARK --set-mark 1 > > > Any chance this can be fixed so it works on older and newer systems? I > don''t like to stick with shorewall-4.5.0 on affected hosts.Hi Simon, Commit 287a44be527ca7afab4e8c5075da162991b95334 corrects this issue and will be included in 4.5.1.1. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> On 03/19/2012 07:22 AM, Simon Matter wrote: > >> Hi Tom an all, >> >> I have an issue with tos in RHEL5 (RHEL6 works fine). The following in >> tcrules: >> >> 1:P 0.0.0.0/0 0.0.0.0/0 tcp - ssh >> - - - Minimize-Delay >> >> Results in >> >> Running /sbin/iptables-restore... >> iptables-restore v1.3.5: Bad TOS value `0x10/0x3f'' >> Error occurred at line: 32 >> Try `iptables-restore -h'' or ''iptables-restore --help'' for more >> information. >> ERROR: iptables-restore Failed. Input is in >> /var/lib/shorewall/.iptables-restore-input >> >> The line in question is: >> -A tcpre -p 6 --sport 22 -m tos --tos 0x10/0x3f -j MARK --set-mark 1 >> >> >> Any chance this can be fixed so it works on older and newer systems? I >> don''t like to stick with shorewall-4.5.0 on affected hosts. > > Hi Simon, > > Commit 287a44be527ca7afab4e8c5075da162991b95334 corrects this issue and > will be included in 4.5.1.1.Thanks Tom, it works well! Simon ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/18/2012 03:57 PM, Mr Dash Four wrote:> > >>> 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 >> > Yeah, I see. Rather grim this, particularly that none of this is > remotely configurable. Most embedded devices (routers, smartphones etc) > do not use this type of hierarchy at all. If I had a single file, which > shorewall was using, then all I have to do is tweak this and proceed. As > it is, I need to muck about with various shorewall components to get it > working, just! > >>> 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? >> > Any setup, which isn''t using "standard" path names hard-coded in > unistall.sh - have a look!Okay -- so we can summarize by saying that Shorewall currently doesn''t handle platforms that don''t follow the Linux FHS.> >>> 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. >> > I am open to suggestions then as to how to make this work, also bearing > in mind that due to Netfilter stupidity I have to always specify the > protocol (the nf devs might change that as I already raised that issue, > but when - I have no idea).This should work: eth0:+ntp-ports[dst] 10.1.1.7/30 41000-42000 udp> >> >>>> 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. >> > That is correct - and you''ve done a rather splendid job, but I don''t > seem to remember telling you to change things in the rules file - the > use of mixed ''src'' and ''dst'' identifiers in the rules file is perfectly > reasonable/legitimate as I''ve illustrated in the example above. So, make > your mind up whether you wish to deploy this throughout shorewall (and > restrict legitimate uses) or whether you wish to do the right thing and > restrict it only in cases where it makes no sense. It is up to you now! >I''ve added a new option in 4.5.2 that allows you to turn this on and off as you choose. But the implementation will remain consistent across all configuration files.>> >>> 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 >> > Try again! I remember asking to have a warning when a given ipset _does > not exist_, not when _it is not used yet_ as is the case with the > example I''ve given above.These warnings may also be suppressed using the same option mentioned above.> >> >>>> 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" >> > What is that supposed to mean? Your "shorewall update" command is not > working, so smart-arse comments like the one above won''t get you far.Again -- Shorewall currently doesn''t handle non-standard file hierarchies; I get it!> > On all my systems I have shorewall.conf file in /etc/shorewall, > consisting of a single line - "INCLUDE <real_path>/shorewall.conf" - to > include my own shorewall.conf file used for that particular > configuration (this was your idea by the way, if I remember correctly!). > > When I execute "shorewall update", it is not doing what''s supposed to be > doing, so I doubt that you getting rather upset or cracking smart-arse > comments like the one above would help fixing that particular bug!Again -- Shorewall currently doesn''t handle non-standard file hierarchies; I get it!> >> I''m unable to reproduce this -- please send me a test case with >> capabilities file. >> > I will, but it won''t be today as I''ll be rather busy in the coming days > - will see if I could get it done by mid-week, if I can. > >>> 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Š. >>Will be fixed in 4.5.2.> >>> 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? >> > As I already pointed out in the above post, I have turned on all tracing > and debugging when running this, but I''ll prepare a test case with > capabilities file for you.In my tests, the message is suppressed when using the -e option; which is the proper procedure> >>> 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. >> > Installing/uninstalling/upgrading shorewall(-lite) on systems which do > not have standard FHS is particularly painful! > > I have managed to fix most of the issues I was getting, but then if/when > I need to upgrade, I have to go through all this again and I simply > don''t have the inclination, nor desire to go through with it - I don''t > have a couple of hours to spend messing about with patch/diff/sed/grep > etc. to fix this - I''d rather have a single file where all my > shorewall(-lite) settings/paths are and tweak those!I hear you. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/20/2012 08:04 AM, Tom Eastep wrote:>>>> "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!> Again -- Shorewall currently doesn''t handle non-standard file > hierarchies; I get it!After I sent this, I realized that Shorewall already handles this condition. Simply shorewall update [options] <directory-where-you-put-your-files> -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
>> Any setup, which isn''t using "standard" path names hard-coded in >> unistall.sh - have a look! > > Okay -- so we can summarize by saying that Shorewall currently doesn''t > handle platforms that don''t follow the Linux FHS.If we do that, we won''t do it justice! uninstall.sh has most, if not all of its removal paths hard-coded, like so: rm -f /etc/rc*.d/*$(basename $FIREWALL) rm -f /sbin/shorewall rm -f /sbin/shorewall-*.bkout rm -rf /usr/share/shorewall/version rm -rf /etc/shorewall rm -rf /etc/shorewall-*.bkout rm -rf /var/lib/shorewall rm -rf /var/lib/shorewall-*.bkout rm -rf ${PERLLIB}/Shorewall/* rm -rf ${LIBEXEC}/shorewall rm -rf /usr/share/shorewall/configfiles/ rm -rf /usr/share/shorewall/Samples/ rm -rf /usr/share/shorewall/Shorewall/ rm -f /usr/share/shorewall/lib.cli-std rm -f /usr/share/shorewall/lib.core rm -f /usr/share/shorewall/compiler.pl rm -f /usr/share/shorewall/prog.* rm -f /usr/share/shorewall/module* rm -f /usr/share/shorewall/helpers rm -f /usr/share/shorewall/action* rm -f /usr/share/shorewall/init rm -rf /usr/share/shorewall-*.bkout This not going to work on all platforms supported by shorewall. Removal of the shorewall "product" (shorewall-lite/shorewall/shorewall6/shorewall-lite6 etc etc) won''t be complete. "custom" configuration (similar to the one I pointed out to in my previous post) won''t be fully removed either. "Upgrade" by uninstalling/installing is therefore out of the question without spending some extra time delving in and this is also prone to errors. I know you''ve heard that from me once or twice before, but if you had a single file describing various paths on the host used for shorewall installation, that won''t be a problem at all.>> I am open to suggestions then as to how to make this work, also bearing >> in mind that due to Netfilter stupidity I have to always specify the >> protocol (the nf devs might change that as I already raised that issue, >> but when - I have no idea). > > This should work: > > eth0:+ntp-ports[dst] 10.1.1.7/30 41000-42000 udpIf I do that, I am bound to get one of those daft warnings telling me to sod off using ''dst'' in the SOURCE column - but you already knew that, didn''t you?> I''ve added a new option in 4.5.2 that allows you to turn this on and off > as you choose. But the implementation will remain consistent across all > configuration files.So, employing - quite legitimately - ''dst'' in the SOURCE column (and vice-versa) in the rules file or doing something similar (as in your example above) is going to be treated by shorewall in exactly the same way as any other nonsensical - and outright wrong - combination I care to put in any of my other configuration files (I used masq as an example, but I am sure there are others too), instead of shorewall doing the right thing and issuing warnings *only* in cases where this is wrong? Wow! Brilliant thinking that, congratulations!>> Try again! I remember asking to have a warning when a given ipset _does >> not exist_, not when _it is not used yet_ as is the case with the >> example I''ve given above. > > These warnings may also be suppressed using the same option mentioned above.What good would that do? Absolutely nothing, nada! What is the point of suppressing warnings when I want to *only* be notified when a given ipset name does not exist and not when it is not found by shorewall for whatever reason - prior to executing init (or any other startup/compilation file)?>>>> 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Š. >>> > > Will be fixed in 4.5.2.Thanks!>> I have managed to fix most of the issues I was getting, but then if/when >> I need to upgrade, I have to go through all this again and I simply >> don''t have the inclination, nor desire to go through with it - I don''t >> have a couple of hours to spend messing about with patch/diff/sed/grep >> etc. to fix this - I''d rather have a single file where all my >> shorewall(-lite) settings/paths are and tweak those! > > I hear you.OK, I managed to create a small test case and I think I found what is causing these DNAT errors - there is something odd/weird in my capabilities file which is seriously tripping shorewall. I tried to use my own "standard" capabilities file (the one I deploy on the dev machine here) and everything works as expected. I am privately-attaching an archive (don''t know whether the ML could handle attachments) which contains my whole test case setup as well as the output I am getting when compiling my firewall{.conf} files. Let me know if you need anything else from me. Just in case it isn''t clear - the reason I am using an "older" capabilities file is because I can''t afford to spend hours upgrading shorewall on that system until either I find that time or a better (understand easier to use and less time-consuming) alternative for upgrading of shorewall becomes available. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 22 March 2012 01:03, Mr Dash Four <mr.dash.four@googlemail.com> wrote:>>> Any setup, which isn''t using "standard" path names hard-coded in >>> unistall.sh - have a look! >> >> Okay -- so we can summarize by saying that Shorewall currently doesn''t >> handle platforms that don''t follow the Linux FHS. > If we do that, we won''t do it justice! uninstall.sh has most, if not all of its removal paths hard-coded, like so: >[snip] If you care about clean removal of files, surely you should be using the package management system on your distribution of choice. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> If you care about clean removal of files, surely you should be using > the package management system on your distribution of choice. >Surely you''d think I thought of that before starting this discussion? Of course I did, but using "package management system" is not always possible, otherwise I won''t bother with uninstall.sh at all. Besides, if "package management system" was always available then uninstall.sh won''t be needed, would it? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 22 March 2012 12:48, Mr Dash Four <mr.dash.four@googlemail.com> wrote:> >> If you care about clean removal of files, surely you should be using >> the package management system on your distribution of choice. >> > Surely you''d think I thought of that before starting this discussion? Of > course I did, but using "package management system" is not always > possible, otherwise I won''t bother with uninstall.sh at all. Besides, if > "package management system" was always available then uninstall.sh won''t > be needed, would it?Do you send emails to the maintainers of all the software you use demanding they develop an uninstall capability for you? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> Do you send emails to the maintainers of all the software you use > demanding they develop an uninstall capability for you? >Can you read? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/21/2012 06:03 PM, Mr Dash Four wrote:>>> Any setup, which isn''t using "standard" path names hard-coded in >>> unistall.sh - have a look! >> >> Okay -- so we can summarize by saying that Shorewall currently >> doesn''t handle platforms that don''t follow the Linux FHS. > If we do that, we won''t do it justice! uninstall.sh has most, if not > all of its removal paths hard-coded, like so: > > rm -f /etc/rc*.d/*$(basename $FIREWALL) rm -f /sbin/shorewall rm -f > /sbin/shorewall-*.bkout > > rm -rf /usr/share/shorewall/version rm -rf /etc/shorewall rm -rf > /etc/shorewall-*.bkout rm -rf /var/lib/shorewall rm -rf > /var/lib/shorewall-*.bkout rm -rf ${PERLLIB}/Shorewall/* rm -rf > ${LIBEXEC}/shorewall rm -rf /usr/share/shorewall/configfiles/ rm -rf > /usr/share/shorewall/Samples/ rm -rf /usr/share/shorewall/Shorewall/ > rm -f /usr/share/shorewall/lib.cli-std rm -f > /usr/share/shorewall/lib.core rm -f > /usr/share/shorewall/compiler.pl rm -f /usr/share/shorewall/prog.* > rm -f /usr/share/shorewall/module* rm -f > /usr/share/shorewall/helpers rm -f /usr/share/shorewall/action* rm > -f /usr/share/shorewall/init rm -rf /usr/share/shorewall-*.bkout > > This not going to work on all platforms supported by shorewall. > Removal of the shorewall "product" > (shorewall-lite/shorewall/shorewall6/shorewall-lite6 etc etc) won''t > be complete. "custom" configuration (similar to the one I pointed out > to in my previous post) won''t be fully removed either. > > "Upgrade" by uninstalling/installing is therefore out of the question > without spending some extra time delving in and this is also prone to > errors. > > I know you''ve heard that from me once or twice before, but if you had > a single file describing various paths on the host used for shorewall > installation, that won''t be a problem at all.I''ve been beavering away at such a thing which will be in the next Beta.> >>> I am open to suggestions then as to how to make this work, also >>> bearing in mind that due to Netfilter stupidity I have to always >>> specify the protocol (the nf devs might change that as I already >>> raised that issue, but when - I have no idea). >> >> This should work: >> >> eth0:+ntp-ports[dst] 10.1.1.7/30 41000-42000 udp > If I do that, I am bound to get one of those daft warnings telling me > to sod off using ''dst'' in the SOURCE column - but you already knew > that, didn''t you?That is a destination column.> >> I''ve added a new option in 4.5.2 that allows you to turn this on >> and off as you choose. But the implementation will remain >> consistent across all configuration files. > So, employing - quite legitimately - ''dst'' in the SOURCE column (and > vice-versa) in the rules file or doing something similar (as in your > example above) is going to be treated by shorewall in exactly the > same way as any other nonsensical - and outright wrong - combination > I care to put in any of my other configuration files (I used masq as > an example, but I am sure there are others too), instead of shorewall > doing the right thing and issuing warnings *only* in cases where this > is wrong? Wow! Brilliant thinking that, congratulations!Patches cheerfully accepted.> >>> Try again! I remember asking to have a warning when a given ipset >>> _does not exist_, not when _it is not used yet_ as is the case >>> with the example I''ve given above. >> >> These warnings may also be suppressed using the same option >> mentioned above. > What good would that do? Absolutely nothing, nada! > > What is the point of suppressing warnings when I want to *only* be > notified when a given ipset name does not exist and not when it is > not found by shorewall for whatever reason - prior to executing init > (or any other startup/compilation file)?There is currently code generated for creating ipsets (as hash:ip) that don''t exist. Unfortunately, that code is broken in the current releases :-( I''ve corrected the code and have added a warning message.> Just in case it isn''t clear - the reason I am using an "older" > capabilities file is because I can''t afford to spend hours upgrading > shorewall on that system until either I find that time or a better > (understand easier to use and less time-consuming) alternative for > upgrading of shorewall becomes available.It''s on its way. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> I''ve been beavering away at such a thing which will be in the next Beta. >I''ll give you a hand with the testing as I am eager to get this out probably as much as you do! ;-) I''ll have some more time available next week, so I envisage plenty of time for shorewall testing.>>> This should work: >>> >>> eth0:+ntp-ports[dst] 10.1.1.7/30 41000-42000 udp >>> >> If I do that, I am bound to get one of those daft warnings telling me >> to sod off using ''dst'' in the SOURCE column - but you already knew >> that, didn''t you? >> > > That is a destination column. >The above actually gives an error (invalid interface or something daft like that). The correct syntax would be eth0::+ntp-ports[dst], though my point about having warnings only in places where it matters still stands.>> So, employing - quite legitimately - ''dst'' in the SOURCE column (and >> vice-versa) in the rules file or doing something similar (as in your >> example above) is going to be treated by shorewall in exactly the >> same way as any other nonsensical - and outright wrong - combination >> I care to put in any of my other configuration files (I used masq as >> an example, but I am sure there are others too), instead of shorewall >> doing the right thing and issuing warnings *only* in cases where this >> is wrong? Wow! Brilliant thinking that, congratulations! >> > > Patches cheerfully accepted. >I'''' gladly provide it if I knew perl. Unfortunately, perl as a language is as foreign to me as a japanese.> There is currently code generated for creating ipsets (as hash:ip) that > don''t exist. Unfortunately, that code is broken in the current releases :-( > > I''ve corrected the code and have added a warning message. >Thanks!> It''s on its way. >I found two other (non-critical) issues yesterday: 1. OWNER_MATCH sniffing Your "OWNER_MATCH" capability is currently sniffed by the following in lib.cli: qt $g_tool -A $chain -m owner --uid-owner 0 -j ACCEPT && OWNER_MATCH=Yes While this may indicate owner match is available, it does not properly account for "-m owner --uid-owner root" (note that this is a name, not a numeric representation!), which might not be available on all systems (only numeric value may be available with no name-to-number mapping). In other words, your "OWNER_MATCH" is in fact UID_MATCH. If you need to implement a proper OWNER_MATCH, then you have to use "qt $g_tool -A $chain -m owner --uid-owner root -j ACCEPT && OWNER_MATCH=Yes" instead. The reason I am highlighting this and make this distinction is because in my case "-m owner --uid-owner 0" works quite happily, but if I have "-m owner --uid-owner root" that produces an error as nss and other such user-mapping services although implemented, are non-standard (hence why I had this "id not found" error message a while ago). So, what I think you can do is have two separate capabilities: UID_MATCH (formerly OWNER_MATCH) which has the above sniffer, but also have another - new - OWNER_MATCH, which sniffs by using a name, i.e. "-m owner --uid-owner root". 2. During start, using the latest 4.5.1 version of shorewall I get the following warnings: Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, <$currentfile> line 13. Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, <$currentfile> line 14. Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, <$currentfile> line 15. Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, <$currentfile> line 16. Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, <$currentfile> line 22. Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, <$currentfile> line 23. Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, <$currentfile> line 24. Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, <$currentfile> line 25. Don''t know what that really is and whether I should be worried, but it seems shorewall is working without any issues. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 3/25/12 9:14 AM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> I''ve been beavering away at such a thing which will be in the next Beta. >> >I''ll give you a hand with the testing as I am eager to get this out >probably as much as you do! ;-) > >I''ll have some more time available next week, so I envisage plenty of >time for shorewall testing.Good. I''ll upload Beta3 today.> >I found two other (non-critical) issues yesterday: > >1. OWNER_MATCH sniffing > >Your "OWNER_MATCH" capability is currently sniffed by the following in >lib.cli: >qt $g_tool -A $chain -m owner --uid-owner 0 -j ACCEPT && OWNER_MATCH=Yes > >While this may indicate owner match is available, it does not properly >account for "-m owner --uid-owner root" (note that this is a name, not a >numeric representation!), which might not be available on all systems >(only numeric value may be available with no name-to-number mapping). > >In other words, your "OWNER_MATCH" is in fact UID_MATCH. If you need to >implement a proper OWNER_MATCH, then you have to use "qt $g_tool -A >$chain -m owner --uid-owner root -j ACCEPT && OWNER_MATCH=Yes" instead. > >The reason I am highlighting this and make this distinction is because >in my case "-m owner --uid-owner 0" works quite happily, but if I have >"-m owner --uid-owner root" that produces an error as nss and other such >user-mapping services although implemented, are non-standard (hence why >I had this "id not found" error message a while ago). > >So, what I think you can do is have two separate capabilities: UID_MATCH >(formerly OWNER_MATCH) which has the above sniffer, but also have >another - new - OWNER_MATCH, which sniffs by using a name, i.e. "-m >owner --uid-owner root".I''ll look at it.> >2. During start, using the latest 4.5.1 version of shorewall I get the >following warnings: > >Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in >numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, ><$currentfile> line 13. >Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in >numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, ><$currentfile> line 14. >Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in >numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, ><$currentfile> line 15. >Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in >numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, ><$currentfile> line 16. >Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in >numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, ><$currentfile> line 22. >Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in >numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, ><$currentfile> line 23. >Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in >numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, ><$currentfile> line 24. >Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in >numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, ><$currentfile> line 25. > >Don''t know what that really is and whether I should be worried, but it >seems shorewall is working without any issues.I also ran into that the other day. It''s harmless, and I''ve eliminated the noise in Beta3. -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
On 23/03/12 02:19, Mr Dash Four wrote:>> Do you send emails to the maintainers of all the software you use >> demanding they develop an uninstall capability for you? > Can you read?Hi Mr Dash, If i''m understanding Jonathan''s emails correctly, i would interpret his sentiments roughly as follows (my words, not his): You''re being a demanding jerk. Not cool. Please stop. The basic thing you''re trying to achieve (installation of Shorewall on a non-FHS-compliant Linux build) is at least a minority corner case, and quite probably a ridiculous waste of time. Tom has been very tolerant (i would say indulgent) in accommodating your demands; you could at least be polite and respectful about it. Regards, Paul ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> You''re being a demanding jerk. Not cool. Please stop. >Can you read? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure