I have spent about 4 hours on this one: I am trying to force shorewall to *not* recompile my whole configuration every time it starts and no matter what I try, it doesn''t seem to work at all. I have AUTOMAKE=Yes, I also tried to set LEGACY_FASTSTART to either Yes or No (none of that seems to have an effect), but shorewall insists on compiling everything every time. Normally I wouldn''t worry about that too much, but since I am now using shorewall-init as well, every time my network device changes its state, the firewall takes between 2 and 3 minutes to be reset, thanks to this compilation/recompilation malarkey not working as it should. Is there a fix for this? In addition, the shorewall-init sysv script provided for Fedora is absolutely riddled with bugs, but this is for another day as sorting out the above problem is of higher priority for me. Thanks. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 05/04/2013 04:38 AM, Dash Four wrote:> I have spent about 4 hours on this one: I am trying to force shorewall > to *not* recompile my whole configuration every time it starts and no > matter what I try, it doesn''t seem to work at all. > > I have AUTOMAKE=Yes, I also tried to set LEGACY_FASTSTART to either Yes > or No (none of that seems to have an effect), but shorewall insists on > compiling everything every time. > > Normally I wouldn''t worry about that too much, but since I am now using > shorewall-init as well, every time my network device changes its state, > the firewall takes between 2 and 3 minutes to be reset, thanks to this > compilation/recompilation malarkey not working as it should. Is there a > fix for this? >I use AUTOMAKE=Yes and it always works reliably: root@gateway:~# shorewall restart Restarting Shorewall.... Initializing... Processing /etc/shorewall/init ... Processing /etc/shorewall-common/tcclear ... Setting up ARP filtering... Setting up Route Filtering... Setting up Martian Logging... Setting up Accept Source Routing... Setting up Proxy ARP... Adding Providers... Null Routing the RFC 1918 subnets Setting up Traffic Control... Preparing iptables-restore input... Running /usr/local/sbin/iptables-restore... Preparing arptables-restore input... Running /sbin/arptables-restore... IPv4 Forwarding Enabled Processing /etc/shorewall/started ... done. root@gateway:~# touch /etc/shorewall/shorewall.conf root@gateway:~# shorewall restart Compiling... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... Loading Modules... Running /etc/shorewall/compile... Compiling /etc/shorewall/zones... Compiling /etc/shorewall/interfaces... Compiling /etc/shorewall/hosts... ... Optimizing Ruleset... Creating iptables-restore input... Compiling /etc/shorewall/stoppedrules... Shorewall configuration compiled to /var/lib/shorewall/.restart The compiled script is /var/lib/shorewall/.restart Restarting Shorewall.... Initializing... Processing /etc/shorewall/init ... Processing /etc/shorewall-common/tcclear ... Setting up ARP filtering... Setting up Route Filtering... Setting up Martian Logging... Setting up Accept Source Routing... Setting up Proxy ARP... Adding Providers... Null Routing the RFC 1918 subnets Setting up Traffic Control... Preparing iptables-restore input... Running /usr/local/sbin/iptables-restore... Preparing arptables-restore input... Running /sbin/arptables-restore... IPv4 Forwarding Enabled Processing /etc/shorewall/started ... done. root@gateway:~# If you ''sh -x ${SBINDIR}/shorewall restart'' and look for the call to the function ''uptodate'', you can see which file on your CONFIG_PATH is triggering the recompile. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> If you ''sh -x ${SBINDIR}/shorewall restart'' and look for the call to the > function ''uptodate'', you can see which file on your CONFIG_PATH is > triggering the recompile. >You may be on to something... Here is what I''ve discovered: My init.d shorewall script has the following command line during start: $shorewall $OPTIONS start $config_file_dir 2>&1 | $logger $shorewall is, as you rightly guessed, "/usr/sbin/shorewall". $OPTIONS used to be "-V0", but I changed it to "-V1" to see what is happening. $config_file_dir is set as "/etc/shorewall". Now, when I have this command line shorewall *always* recompiles without fail. However, when I execute "$shorewall $OPTIONS start" (without the config_file_dir parameter), then everything seems to be OK. When I follow your advice above and do "sh -x $shorewall $OPTIONS start 2>&1 | $logger" there is no problem with it either. So, could it be that when "config_file_dir" is specified shorewall does something which isn''t supposed to be doing? I''ve also now fixed the shorewall-init script from Fedora (thank god!), but need some time to iron a few things out and can post the changes if you have the time to look at these. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 05/04/2013 08:35 AM, Dash Four wrote:> > Tom Eastep wrote: >> If you ''sh -x ${SBINDIR}/shorewall restart'' and look for the call to the >> function ''uptodate'', you can see which file on your CONFIG_PATH is >> triggering the recompile. >> > You may be on to something... Here is what I''ve discovered: My init.d > shorewall script has the following command line during start: > > $shorewall $OPTIONS start $config_file_dir 2>&1 | $logger > > $shorewall is, as you rightly guessed, "/usr/sbin/shorewall". $OPTIONS > used to be "-V0", but I changed it to "-V1" to see what is happening. > $config_file_dir is set as "/etc/shorewall". Now, when I have this > command line shorewall *always* recompiles without fail. However, when I > execute "$shorewall $OPTIONS start" (without the config_file_dir > parameter), then everything seems to be OK. > > When I follow your advice above and do "sh -x $shorewall $OPTIONS start > 2>&1 | $logger" there is no problem with it either. So, could it be that > when "config_file_dir" is specified shorewall does something which isn''t > supposed to be doing? >Shorewall ignores the setting of AUTOMAKE when a directory name is specified on the run-line. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 5/4/13 8:35 AM, "Dash Four" <mr.dash.four@googlemail.com> wrote:>I''ve also now fixed the shorewall-init script from Fedora (thank god!), >but need some time to iron a few things out and can post the changes if >you have the time to look at these.Sure. Thanks, -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:>> I''ve also now fixed the shorewall-init script from Fedora (thank god!), >> but need some time to iron a few things out and can post the changes if >> you have the time to look at these. >> > > Sure. >That will have to wait until tomorrow as I haven''t finished clearing up the mess I was in since yesterday. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> On 05/04/2013 08:35 AM, Dash Four wrote: > >> Tom Eastep wrote: >> >>> If you ''sh -x ${SBINDIR}/shorewall restart'' and look for the call to the >>> function ''uptodate'', you can see which file on your CONFIG_PATH is >>> triggering the recompile. >>> >>> >> You may be on to something... Here is what I''ve discovered: My init.d >> shorewall script has the following command line during start: >> >> $shorewall $OPTIONS start $config_file_dir 2>&1 | $logger >> >> $shorewall is, as you rightly guessed, "/usr/sbin/shorewall". $OPTIONS >> used to be "-V0", but I changed it to "-V1" to see what is happening. >> $config_file_dir is set as "/etc/shorewall". Now, when I have this >> command line shorewall *always* recompiles without fail. However, when I >> execute "$shorewall $OPTIONS start" (without the config_file_dir >> parameter), then everything seems to be OK. >> >> When I follow your advice above and do "sh -x $shorewall $OPTIONS start >> 2>&1 | $logger" there is no problem with it either. So, could it be that >> when "config_file_dir" is specified shorewall does something which isn''t >> supposed to be doing? >> >> > > Shorewall ignores the setting of AUTOMAKE when a directory name is > specified on the run-line. >That explains it then, though I think this behaviour is wrong - shorewall should be capable of doing the same checks when a custom config directory is specified and then make a decision on whether to compile or not. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 05/04/2013 05:21 PM, Dash Four wrote:> > > Tom Eastep wrote:>> Shorewall ignores the setting of AUTOMAKE when a directory name is >> specified on the run-line. >> > That explains it then, though I think this behaviour is wrong - > shorewall should be capable of doing the same checks when a custom > config directory is specified and then make a decision on whether to > compile or not.The ability to specify a directory on the command line is intended to be used for temporary or test configurations. I disagree that there is any need to honor AUTOMAKE for such configurations and, in fact, I think it would be a detriment. If I have a special configuration that I use infrequently, honoring AUTOMAKE with that configuration would probably result in an attempt to restart using the config to be ignored. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> On 05/04/2013 05:21 PM, Dash Four wrote: > >> That explains it then, though I think this behaviour is wrong - >> shorewall should be capable of doing the same checks when a custom >> config directory is specified and then make a decision on whether to >> compile or not. >> > > The ability to specify a directory on the command line is intended to be > used for temporary or test configurations. I disagree that there is any > need to honor AUTOMAKE for such configurations and, in fact, I think it > would be a detriment. If I have a special configuration that I use > infrequently, honoring AUTOMAKE with that configuration would probably > result in an attempt to restart using the config to be ignored. >I disagree. If I am running shorewall using custom configuration directory (as was the case with me for the past 2+ years), then I need to specify this and expect all shorewall.conf options to be honoured. As you know, on all my dmz machines I am running live images, which have, essentially, read-only root (including the "default" /etc/shorewall) - when any changes, even though preserved in ram for the duration of the OS session, are lost on reboot and that is the main reason for using custom shorewall config directory. Anyway, I am getting something odd since I''ve started using shorewall-init - during boot I see this (this is from /var/log/boot.log): Bringing up loopback interface: SIOCADDRT: Network is unreachable SIOCADDRT: Network is unreachable I can''t see any problems accessing the loopback device and the routes in ''local'' seems OK, so I am a bit bemused by this message. Any ideas? ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
On 05/04/2013 06:54 PM, Dash Four wrote:> > > Tom Eastep wrote: >> On 05/04/2013 05:21 PM, Dash Four wrote: >> >>> That explains it then, though I think this behaviour is wrong - >>> shorewall should be capable of doing the same checks when a custom >>> config directory is specified and then make a decision on whether to >>> compile or not. >>> >> >> The ability to specify a directory on the command line is intended to be >> used for temporary or test configurations. I disagree that there is any >> need to honor AUTOMAKE for such configurations and, in fact, I think it >> would be a detriment. If I have a special configuration that I use >> infrequently, honoring AUTOMAKE with that configuration would probably >> result in an attempt to restart using the config to be ignored. >> > I disagree. If I am running shorewall using custom configuration > directory (as was the case with me for the past 2+ years), then I need > to specify this and expect all shorewall.conf options to be honoured.Then configure CONFDIR to point to where you actually put the configuration files. While you can have multiple configuration directories on a system, there is only one ${VARDIR}/${PRODUCT}/firewall. It is therefore not possible to provide sane behavior of AUTOMAKE for more than one configuration directory. -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
Tom Eastep wrote:> On 05/04/2013 06:54 PM, Dash Four wrote: > >> Tom Eastep wrote: >> >>> On 05/04/2013 05:21 PM, Dash Four wrote: >>> >>> >>>> That explains it then, though I think this behaviour is wrong - >>>> shorewall should be capable of doing the same checks when a custom >>>> config directory is specified and then make a decision on whether to >>>> compile or not. >>>> >>>> >>> The ability to specify a directory on the command line is intended to be >>> used for temporary or test configurations. I disagree that there is any >>> need to honor AUTOMAKE for such configurations and, in fact, I think it >>> would be a detriment. If I have a special configuration that I use >>> infrequently, honoring AUTOMAKE with that configuration would probably >>> result in an attempt to restart using the config to be ignored. >>> >>> >> I disagree. If I am running shorewall using custom configuration >> directory (as was the case with me for the past 2+ years), then I need >> to specify this and expect all shorewall.conf options to be honoured. >> > > Then configure CONFDIR to point to where you actually put the > configuration files. > > While you can have multiple configuration directories on a system, there > is only one ${VARDIR}/${PRODUCT}/firewall. It is therefore not possible > to provide sane behavior of AUTOMAKE for more than one configuration > directory. >I''ve managed to get around the above problem and shorewall-init is now running OK, save for a few glitches - since this is veering a bit off topic, I''ll start a new thread on the development forum and take it from there. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It''s a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2