Re: [Shorewall-users] shorewall reload / restart
On 08/11/2017 10:31 AM, Vieri Di Paola via Shorewall-users wrote: > > > From: Tom Eastep >> >> So why don't you simply leave that route in place all of the time? Just > >> define it in your distribution's networking config. > > I'm used to using rtrules, routes, and providers with shorewall. I > share those files with other members of the IT staff, and sometimes we > need to change which provider provides a given subnet. Of course, all > the routing (tables and rules) could be done by the OS, but it is more > convenient for me to have it all within shorewall. So long as the rtrules entries have a priority higher (numerically lower) than the main RT (1000), you would still have complete control in that way. >> The 'reload' command already supports the -n option. > > > If "reload -n" will NOT flush rules and tables previously created by > "start" or "restart" then I guess I could use that, and move out the > code I have in the files "stopped" and "started". > Yes -- the code in "stopped" and "started" isn't executed during 'reload' anyway. > >> 'reload' and 'start' are basically the same command. > > > ..."-n" meaning "leave the routing alone". > > In my case, I'd always use reload -n, except when making changes to > "rtrules", "routes", and "providers". > > Also, when shorewall "updates the routing tables/rules", it actually flushes > everything and creates anew, right? > > It doesn't really "update", or is it possible to do so? > It flushes and reloads, because it makes no assumptions about what the current configuration is. -- Tom Eastep\ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \___ signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
From: Tom Eastep > > So why don't you simply leave that route in place all of the time? Just > define it in your distribution's networking config. I'm used to using rtrules, routes, and providers with shorewall. I share those files with other members of the IT staff, and sometimes we need to change which provider provides a given subnet. Of course, all the routing (tables and rules) could be done by the OS, but it is more convenient for me to have it all within shorewall. > The 'reload' command already supports the -n option. If "reload -n" will NOT flush rules and tables previously created by "start" or "restart" then I guess I could use that, and move out the code I have in the files "stopped" and "started". > 'reload' and 'start' are basically the same command. ..."-n" meaning "leave the routing alone". In my case, I'd always use reload -n, except when making changes to "rtrules", "routes", and "providers". Also, when shorewall "updates the routing tables/rules", it actually flushes everything and creates anew, right? It doesn't really "update", or is it possible to do so? Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
On 08/11/2017 01:13 AM, Vieri Di Paola via Shorewall-users wrote: > > From: Tom Eastep >> >> The stopped state is NOT longer in 5.1. The compilation step is longer, > >> but the time to run the script once it is compiled should be very close >> to the same. > > OK, I don't know why I was previously getting such a long connection outage > while shorewall 5.1 was restarting, and I can't seem to reproduce this today. > > I also realize now (or correct me if I'm wrong) that the access rules and > routing tables are "still there" when shorewall is compiling and optimizing > rules. They are flushed afterwards, and there should be no big difference > between 5.0 and 5.1. > That is correct. > However, I must say that I've reproduced the following behavior several times > now. > > If I *only* have stoppedrules defined as: > > ACCEPT $IF_LAN $IF_CAIB > > (and no custom routing during the stopped state) > > then I'm still seeing messages like this one (during the time frame when > shorewall has flushed the routing tables): > > From 172.16.0.2 icmp_seq=7 Time to live exceeded > > This happens whether I "restart" or "reload" (tested on 5.1, and yes, also > 5.0, as you said should behave similarly). > > Of course, the ping statistics show that there were lost packets: > > 721 packets transmitted, 680 received, +2 errors, 5% packet loss > > Some corporate applications are either very sensitive or poorly programmed, > and do not tolerate packet loss. > > Now, if I also add the following routes as in this example: > > [ "stopped" file contains ] > route add -net 10.215.0.0/17 gw $ADDR_GW_CAIB > > [ "start" file contains ] > route del -net 10.215.0.0/17 > return 0 So why don't you simply leave that route in place all of the time? Just define it in your distribution's networking config. > > I can then test continuous pings to the CAIB zone from the LAN zone while I > restart/reload shorewall several times, and I am unable to reproduce the > "Time to live exceeded" issue. > In other words, I am not losing a single ping (5.1 and 5.0). > I don't know if this is mere randomness, but I've tried it once and again. > > BTW, I noticed that the shorewall start command has the -n option > which avoids updating the routing tables. Would it make sense for future > shorewall releases to include a similar -n option for the stop command > so Shorewall does not flush the routing tables during the stopped phase > or when reloading? The 'reload' command already supports the -n option. > Maybe additional -n0 and -0n options could be passed to the restart commands > so that: > 1) -n is equivalent to shorewall stop && shorewall start -n which is the way that it works today > 2) -0n is the same (equivalent to shorewall stop && shorewall start -n) > 3) -n0 is equivalent to shorewall stop -n && shorewall start > 4) -nn is equivalent to shorewall stop -n && shorewall start -n > The command "stop -n" should not flush "ip route" or "ip rule". > > > The reload command could also use the -n0, -0n, -nn options for the same > purpose. Unnecessary -- 'reload' and 'start' are basically the same command. The main difference being that UPnP rules and non-IPSET dynamic blacklisting is preserved during 'reload'. > > > I would also like to know if the INCLUDE directive is available in the > following files, and if the variables defined in the params file are also > available: > 1) start > 2) started > 3) stopped > Yes. -Tom -- Tom Eastep\ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \___ signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
From: Tom Eastep > > The stopped state is NOT longer in 5.1. The compilation step is longer, > but the time to run the script once it is compiled should be very close > to the same. OK, I don't know why I was previously getting such a long connection outage while shorewall 5.1 was restarting, and I can't seem to reproduce this today. I also realize now (or correct me if I'm wrong) that the access rules and routing tables are "still there" when shorewall is compiling and optimizing rules. They are flushed afterwards, and there should be no big difference between 5.0 and 5.1. However, I must say that I've reproduced the following behavior several times now. If I *only* have stoppedrules defined as: ACCEPT $IF_LAN $IF_CAIB (and no custom routing during the stopped state) then I'm still seeing messages like this one (during the time frame when shorewall has flushed the routing tables): >From 172.16.0.2 icmp_seq=7 Time to live exceeded This happens whether I "restart" or "reload" (tested on 5.1, and yes, also 5.0, as you said should behave similarly). Of course, the ping statistics show that there were lost packets: 721 packets transmitted, 680 received, +2 errors, 5% packet loss Some corporate applications are either very sensitive or poorly programmed, and do not tolerate packet loss. Now, if I also add the following routes as in this example: [ "stopped" file contains ] route add -net 10.215.0.0/17 gw $ADDR_GW_CAIB [ "start" file contains ] route del -net 10.215.0.0/17 return 0 I can then test continuous pings to the CAIB zone from the LAN zone while I restart/reload shorewall several times, and I am unable to reproduce the "Time to live exceeded" issue. In other words, I am not losing a single ping (5.1 and 5.0). I don't know if this is mere randomness, but I've tried it once and again. BTW, I noticed that the shorewall start command has the -n option which avoids updating the routing tables. Would it make sense for future shorewall releases to include a similar -n option for the stop command so Shorewall does not flush the routing tables during the stopped phase or when reloading? Maybe additional -n0 and -0n options could be passed to the restart commands so that: 1) -n is equivalent to shorewall stop && shorewall start -n 2) -0n is the same (equivalent to shorewall stop && shorewall start -n) 3) -n0 is equivalent to shorewall stop -n && shorewall start 4) -nn is equivalent to shorewall stop -n && shorewall start -n The command "stop -n" should not flush "ip route" or "ip rule". The reload command could also use the -n0, -0n, -nn options for the same purpose. I would also like to know if the INCLUDE directive is available in the following files, and if the variables defined in the params file are also available: 1) start 2) started 3) stopped Thanks, Vieri P.S.: the 5.1 system I'm configuring was installed ex-novo. I am NOT "shorewall upgrading" from 5.0 to 5.1. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
On 08/10/2017 09:21 AM, Vieri Di Paola via Shorewall-users wrote: > > > From: Tom Eastep > >> In both 'restart' and 'reload', the provider routing tables and rules> are >> purged then reloaded. But they were purged and reloaded on 5.0 as well. > > > OK, but since 5.0 had OPTIMIZE=0 the "cut" was almost gone unnoticed. > I'd like to keep OPTIMIZE=All in 5.1. > So, since the stopped state is way longer, how do I allow lan-caib and > lan-ibs traffic? > This alone in stoppedrules isn't enough: > ACCEPT $IF_LAN$IF_IBS > ACCEPT $IF_LAN$IF_CAIB > > Please correct me if I'm wrong, but I need to build the appropriate routing > table as soon as shorewall is in the stop state. > The stopped state is NOT longer in 5.1. The compilation step is longer, but the time to run the script once it is compiled should be very close to the same. And, if you set RESTART=reload, then a 'restart' will never enter the stopped state. -Tom -- Tom Eastep\ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \___ signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
From: Tom Eastep > In both 'restart' and 'reload', the provider routing tables and rules> are > purged then reloaded. But they were purged and reloaded on 5.0 as well. OK, but since 5.0 had OPTIMIZE=0 the "cut" was almost gone unnoticed. I'd like to keep OPTIMIZE=All in 5.1. So, since the stopped state is way longer, how do I allow lan-caib and lan-ibs traffic? This alone in stoppedrules isn't enough: ACCEPT $IF_LAN$IF_IBS ACCEPT $IF_LAN$IF_CAIB Please correct me if I'm wrong, but I need to build the appropriate routing table as soon as shorewall is in the stop state. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
On 08/10/2017 01:07 AM, Vieri Di Paola via Shorewall-users wrote: > I'm asking because I'm seeing two issues with the restart command when trying > to move from shorewall 5.0.14.1 to a more recent version (eg. 5.1.5.1). > > According to > http://www.shorewall.net/pub/shorewall/5.0/shorewall-5.0.14/releasenotes.txt, > the "restart" option should behave the same way. So, if RESTART=restart then > a "true" restart is done (stop&start). It won't be a "reload". > No. If you take an existing 5.0 configuration and do a 'shorewall update' on 5.1, THEN 'restart' will work the same as it did before the upgrade. If you build a new configuration of 5.1 and leave RESTART=restart, then 'restart' will behave differently than on 5.0. So if you want 'restart' to behave as it did in 5.0, then you must have RESTART=reload in shorewall.conf. > On both of my old and new shorewall systems, RESTART=restart. > ADMINISABSENTMINDED is also set to Yes. > > First issue: > > Here's what I see when I ping to a host in CAIB zone at 10.215.9.172 from a > host in LAN zone while running "shorewall restart". > > [...] > 64 bytes from 10.215.9.172: icmp_seq=4 ttl=59 time=4.06 ms > 64 bytes from 10.215.9.172: icmp_seq=5 ttl=59 time=2.77 ms > 64 bytes from 10.215.9.172: icmp_seq=6 ttl=59 time=2.30 ms > From 172.16.0.2 icmp_seq=7 Time to live exceeded > 64 bytes from 10.215.9.172: icmp_seq=8 ttl=59 time=2.97 ms > 64 bytes from 10.215.9.172: icmp_seq=9 ttl=59 time=4.23 ms > 64 bytes from 10.215.9.172: icmp_seq=10 ttl=59 time=2.98 ms > > This is the content of stoppedrules: > > ACCEPT $IF_LAN $IF_IBS > ACCEPT $IF_LAN $IF_CAIB > > The IP addr. 172.16.0.2 is on a gateway out the WAN interface. > > The providers file contains: > WAN 1 1 - $IF_WAN $ADDR_GW_WANtrack,primary > CAIB2 2 - $IF_CAIB$ADDR_GW_CAIB > track,fallback=1 > IBS 3 3 - $IF_IBS $ADDR_GW_IBS > track,fallback=1 > > The rtrules file contains: > - 10.215.0.0/17 CAIB11692 > > So I guess that if I wanted to allow all traffic from lan to caib and to ibs > then I would also have to modify the routing table. > I think I should do this in the "stopped" file with something like this: > > route add 10.215.0.0/17 gw $ADDR_GW_CAIB > > I haven't tried it though. Does it make sense? No. > > Also, would I need to remove the route entries listed in "stopped" when > shorewall starts again? Would I need to add something like this in the > "started" or "start" files? Which file BTW? (I would need to do that before > Shorewall starts handling routes) > > route del 10.215.0.0/17 > > Alternatively, if I could do without running the code in "stopped" and > "started" then I could issue a "shorewall reload". > However, I've seen the "From 172.16.0.2 icmp_seq=38 Time to live exceeded" > message even when issuing a "reload". > So it seems that in this particular case (maybe due to the providers&rtrules > settings) a reload and a restart behave alike (only tested with 5.0.14.1 as > 5.1.5.1 is not in production yet). > In both 'restart' and 'reload', the provider routing tables and rules are purged then reloaded. But they were purged and reloaded on 5.0 as well. > The second issue regards performance on a restart or a reload. > > Both of my systems (5.0 / 5.1) have the same ruleset of about 7000 lines. > Shorewall 5.0 is running on a "weak" server whereas 5.1 is on much more > powerful hardware. > > With 5.0: > > # time /etc/init.d/shorewall restart > [...] > real0m14.793s > user0m8.780s > sys 0m1.480s > > With 5.1: > > # time /etc/init.d/shorewall restart > [...] > real 0m45.981s > user 0m42.410s > sys 0m2.310s > > The difference between the two is staggering. > It's probably due to the OPTIMIZE option in shorewall.conf, right? Yes. > > In shorewall 5.0.14.1 the default value for OPTIMIZE is 0. > In 5.1.5.1 the default value is All despite the man page saying that "The > default value is zero which disables all optimizations" (that was true for > older versions). > > So I guess I have to set OPTIMIZE=0 or None in 5.1 in order to get similar or > better timings. Yes. > > BTW, I'm wondering if the OPTIMIZE option could somehow explain the other > issue I'm having in the ML thread "traffic issues through firewall router". > I'll do a test asap. > I doubt it. -- Tom Eastep\ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \___ signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engag
Re: [Shorewall-users] shorewall reload / restart
I'm asking because I'm seeing two issues with the restart command when trying to move from shorewall 5.0.14.1 to a more recent version (eg. 5.1.5.1). According to http://www.shorewall.net/pub/shorewall/5.0/shorewall-5.0.14/releasenotes.txt, the "restart" option should behave the same way. So, if RESTART=restart then a "true" restart is done (stop&start). It won't be a "reload". On both of my old and new shorewall systems, RESTART=restart. ADMINISABSENTMINDED is also set to Yes. First issue: Here's what I see when I ping to a host in CAIB zone at 10.215.9.172 from a host in LAN zone while running "shorewall restart". [...] 64 bytes from 10.215.9.172: icmp_seq=4 ttl=59 time=4.06 ms 64 bytes from 10.215.9.172: icmp_seq=5 ttl=59 time=2.77 ms 64 bytes from 10.215.9.172: icmp_seq=6 ttl=59 time=2.30 ms >From 172.16.0.2 icmp_seq=7 Time to live exceeded 64 bytes from 10.215.9.172: icmp_seq=8 ttl=59 time=2.97 ms 64 bytes from 10.215.9.172: icmp_seq=9 ttl=59 time=4.23 ms 64 bytes from 10.215.9.172: icmp_seq=10 ttl=59 time=2.98 ms This is the content of stoppedrules: ACCEPT $IF_LAN $IF_IBS ACCEPT $IF_LAN $IF_CAIB The IP addr. 172.16.0.2 is on a gateway out the WAN interface. The providers file contains: WAN 1 1 - $IF_WAN $ADDR_GW_WANtrack,primary CAIB2 2 - $IF_CAIB$ADDR_GW_CAIB track,fallback=1 IBS 3 3 - $IF_IBS $ADDR_GW_IBStrack,fallback=1 The rtrules file contains: - 10.215.0.0/17 CAIB11692 So I guess that if I wanted to allow all traffic from lan to caib and to ibs then I would also have to modify the routing table. I think I should do this in the "stopped" file with something like this: route add 10.215.0.0/17 gw $ADDR_GW_CAIB I haven't tried it though. Does it make sense? Also, would I need to remove the route entries listed in "stopped" when shorewall starts again? Would I need to add something like this in the "started" or "start" files? Which file BTW? (I would need to do that before Shorewall starts handling routes) route del 10.215.0.0/17 Alternatively, if I could do without running the code in "stopped" and "started" then I could issue a "shorewall reload". However, I've seen the "From 172.16.0.2 icmp_seq=38 Time to live exceeded" message even when issuing a "reload". So it seems that in this particular case (maybe due to the providers&rtrules settings) a reload and a restart behave alike (only tested with 5.0.14.1 as 5.1.5.1 is not in production yet). The second issue regards performance on a restart or a reload. Both of my systems (5.0 / 5.1) have the same ruleset of about 7000 lines. Shorewall 5.0 is running on a "weak" server whereas 5.1 is on much more powerful hardware. With 5.0: # time /etc/init.d/shorewall restart [...] real0m14.793s user0m8.780s sys 0m1.480s With 5.1: # time /etc/init.d/shorewall restart [...] real 0m45.981s user 0m42.410s sys 0m2.310s The difference between the two is staggering. It's probably due to the OPTIMIZE option in shorewall.conf, right? In shorewall 5.0.14.1 the default value for OPTIMIZE is 0. In 5.1.5.1 the default value is All despite the man page saying that "The default value is zero which disables all optimizations" (that was true for older versions). So I guess I have to set OPTIMIZE=0 or None in 5.1 in order to get similar or better timings. BTW, I'm wondering if the OPTIMIZE option could somehow explain the other issue I'm having in the ML thread "traffic issues through firewall router". I'll do a test asap. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
On 08/09/2017 12:56 AM, Vieri Di Paola via Shorewall-users wrote: > Hi, > > I read the shorewall man page regarding the "reload" and "restart" commands. > From a practical point of view and with default shorewall.conf settings in > 5.1, if I change/add/delete entries in the "rules" file, and issue the > "reload" command then I should expect the following: > > - existing connections will not be affected > - the "new rules" will be processed and applied > > Same thing should happen when changing entries in snat, mangle, routes, > rtrules. The params file should also be re-read. > > Correct? > > So, with shorewall >=5.0.15, when would it be useful to issue the "restart" > command? The only scenario I can think of is if I wanted to interrupt active > connections (or at least preserve only those in "stoppedrules"). > With ADMINISABSENTMINDED=Yes, active connections are not interrupted during restart. New connections not allowed by stoppedrules are denied during the time that the firewall is stopped. With RESTART=restart, doing a 'restart' allows the 'stop' and 'stopped' extension scripts to be executed whereas 'reload' does not. So if you have something in those scripts that you want done, then 'restart' is appropriate. -Tom -- Tom Eastep\ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \___ signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] shorewall reload / restart
Hi, I read the shorewall man page regarding the "reload" and "restart" commands. From a practical point of view and with default shorewall.conf settings in 5.1, if I change/add/delete entries in the "rules" file, and issue the "reload" command then I should expect the following: - existing connections will not be affected - the "new rules" will be processed and applied Same thing should happen when changing entries in snat, mangle, routes, rtrules. The params file should also be re-read. Correct? So, with shorewall >=5.0.15, when would it be useful to issue the "restart" command? The only scenario I can think of is if I wanted to interrupt active connections (or at least preserve only those in "stoppedrules"). Regards, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
> shorewall save > shorewall restart > That, to me, seems the best alternative and I amended my init.d script to replace the existing reload with the above two statements. It works and I like it. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
On 9/30/10 11:50 AM, Mr Dash Four wrote: > >> man shorewall and look for 'safe-restart'. >> > shorewall safe-restart it is then, except, is there a way I could get > away with the prompt and let shorewall decide if there were no > errors to assume the new configuration, but if there were to > automatically restore the old one (i.e. bypass the prompt and act > intelligently)? shorewall save shorewall restart > If there were errors there is no way I could see them when I am > prompted (as they are shown in the syslog). Please try it before complaining about how you wrongly think it works. -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 \ signature.asc Description: OpenPGP digital signature -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
> man shorewall and look for 'safe-restart'. > shorewall safe-restart it is then, except, is there a way I could get away with the prompt and let shorewall decide if there were no errors to assume the new configuration, but if there were to automatically restore the old one (i.e. bypass the prompt and act intelligently)? If there were errors there is no way I could see them when I am prompted (as they are shown in the syslog). -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
On 9/30/10 10:44 AM, Mr Dash Four wrote: > >>> Shorewall stopped. <=== >>> >> >> At this point, Shorewall was stopped! That causes init to be invoked >> with $COMMAND=stop >> > Ah, I see! So, if there is any error in my config files (rules, secmarks > etc) running Shorewall gives up and stops and when I then execute > 'service shorewall reload' Shorewall starts (without a warning that I am > not actually 'reloading' but 'starting') and it then goes to execute my > /etc/shorewall/init with 'start', right? I wasn't aware of that behaviour. > >> If you don't like that, do '/sbin/shorewall save' with a good >> configuration. That will re-install that configuration rather than put >> the firewall in a safe configuration. >> > Is there a more straight-forward solution, for example, if I am trying > to reload/restart a running Shorewall and it sees that there is > something wrong with its configuration not to just panic and stop, but > to keep itself running or is that what 'shorewall save' does? Shorewall only "panics and stops" if one of the critical commands (like iptables-restore) fails. If there is a current 'saved' configuration, Shorewall attempts to restore that configuration. Otherwise, it performs the equivalent of 'shorewall stop'. > > Is there a safe-restart (for Shorewall to save itself when starting and > then if I try to reload/restart it with errors in its configuration > files shorewall to just reload itself with its previous - saved - > configuration)? If so, should I assume that Shorewall won't execute my > /etc/shorewall/init with 'start' (and therefore wipe out my entire ipset > configuration)? man shorewall and look for 'safe-restart'. > > >> Security zealots (including those in my >> division at HP) believe that sending a signal (even to yourself) is an >> evil thing that requires extensive vetting. >> > I don't know about sending a signal to yourself, but sending the wrong > signals to your young/pretty/attractive (delete or add as appropriate) > colleagues is known to often cause problems and land you in hot water. :-) -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 \ signature.asc Description: OpenPGP digital signature -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
>> Shorewall stopped. <=== >> > > At this point, Shorewall was stopped! That causes init to be invoked > with $COMMAND=stop > Ah, I see! So, if there is any error in my config files (rules, secmarks etc) running Shorewall gives up and stops and when I then execute 'service shorewall reload' Shorewall starts (without a warning that I am not actually 'reloading' but 'starting') and it then goes to execute my /etc/shorewall/init with 'start', right? I wasn't aware of that behaviour. > If you don't like that, do '/sbin/shorewall save' with a good > configuration. That will re-install that configuration rather than put > the firewall in a safe configuration. > Is there a more straight-forward solution, for example, if I am trying to reload/restart a running Shorewall and it sees that there is something wrong with its configuration not to just panic and stop, but to keep itself running or is that what 'shorewall save' does? Is there a safe-restart (for Shorewall to save itself when starting and then if I try to reload/restart it with errors in its configuration files shorewall to just reload itself with its previous - saved - configuration)? If so, should I assume that Shorewall won't execute my /etc/shorewall/init with 'start' (and therefore wipe out my entire ipset configuration)? > Security zealots (including those in my > division at HP) believe that sending a signal (even to yourself) is an > evil thing that requires extensive vetting. > I don't know about sending a signal to yourself, but sending the wrong signals to your young/pretty/attractive (delete or add as appropriate) colleagues is known to often cause problems and land you in hot water. >> my ipsets were loaded from the command line with: >> >> ipset -N tripple-set ipportnethash --network 10.1.2.0/24 >> ipset -A tripple-set 10.1.2.7,22,10.1.1.1/24 >> > > Do you check the exit status of all commands? Are you *sure* what was > executed? > Id did - I am absolutely certain it was executed as I issued ipset -L tripple-set afterwards and it was there. As it stands right now, even with the new version of xtables (1.29) I am unable to get *any* match on a triplet (ip-port-ip or ip-port-net) no matter what gimmicks I try... My only salvation (for the time being at least) is your new feature with combined ipset matches which, when I tried the last time, worked to absolute perfection. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
On 9/29/10 5:52 PM, Mr Dash Four wrote: > >> I have no idea what's going on on your system. >> > This is all very strange. After being able to reload shorewall a couple > of times (with NO errors, i.e. shorewall executing as it should), I > changed my rules file a couple of times, then loaded a few ipsets I > needed to test (see below) and amended the rules file again accordingly, > tried to reload again and this happened (from my syslog): > > Shorewall configuration compiled to /var/lib/shorewall/.restart > Restarting Shorewall... > iptables-restore v1.4.7: Set tripple-set doesn't exist. [tripple-set is > my newly loaded set] <- ** see below > Error occured at line: 118 > Try 'iptables-restore -h' bla bla bla > ERROR: iptables-restore failed. Input is in > /var/lib/shorewall/iptables-restore-input > ERROR: Shorewall restart failed > Shorewall stopped. <=== At this point, Shorewall was stopped! That causes init to be invoked with $COMMAND=stop If you don't like that, do '/sbin/shorewall save' with a good configuration. That will re-install that configuration rather than put the firewall in a safe configuration. > > At the same time I am getting my SELinux moaning (AVC) that it has > prevented the shell (/bin/sh) from issuing a process signal (presumably > TERM). Errors can be detected in a sub-shell so the Shorewall shell code tries to kill itself by 'kill $$'. Security zealots (including those in my division at HP) believe that sending a signal (even to yourself) is an evil thing that requires extensive vetting. > > **This error happens because 'stop/start' has been passed to my > /etc/shorewall/init file and ALL ipsets have been wiped out, including > those I've just loaded and now iptables cannot find tripple-set, which > forms part of my rules Again 'stop was passed'. > > my ipsets were loaded from the command line with: > > ipset -N tripple-set ipportnethash --network 10.1.2.0/24 > ipset -A tripple-set 10.1.2.7,22,10.1.1.1/24 Do you check the exit status of all commands? Are you *sure* what was executed? -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 \ signature.asc Description: OpenPGP digital signature -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
> I have no idea what's going on on your system. > This is all very strange. After being able to reload shorewall a couple of times (with NO errors, i.e. shorewall executing as it should), I changed my rules file a couple of times, then loaded a few ipsets I needed to test (see below) and amended the rules file again accordingly, tried to reload again and this happened (from my syslog): Shorewall configuration compiled to /var/lib/shorewall/.restart Restarting Shorewall... iptables-restore v1.4.7: Set tripple-set doesn't exist. [tripple-set is my newly loaded set] <- ** see below Error occured at line: 118 Try 'iptables-restore -h' bla bla bla ERROR: iptables-restore failed. Input is in /var/lib/shorewall/iptables-restore-input ERROR: Shorewall restart failed Shorewall stopped. At the same time I am getting my SELinux moaning (AVC) that it has prevented the shell (/bin/sh) from issuing a process signal (presumably TERM). **This error happens because 'stop/start' has been passed to my /etc/shorewall/init file and ALL ipsets have been wiped out, including those I've just loaded and now iptables cannot find tripple-set, which forms part of my rules my ipsets were loaded from the command line with: ipset -N tripple-set ipportnethash --network 10.1.2.0/24 ipset -A tripple-set 10.1.2.7,22,10.1.1.1/24 then I amended the rules file to include this set as part of a (meaningless) rule: ACCEPT:info $FW:+tripple-set[src,dst,dst] And issued a reload. Again, it is worth noting that the error does NOT happen every time (I will spend some time tomorrow to see what triggers it), but it definitely happens! -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
On 9/29/10 5:09 PM, Tom Eastep wrote: > I have no idea what's going on on your system. > > gateway:~# cat /etc/shorewall/init > # > # Shorewall version 4 - Init File > # > # /etc/shorewall/init > # > # Add commands below that you want to be executed at the beginning of > # a "shorewall start" or "shorewall restart" command. > # > # For additional information, see > # http://shorewall.net/shorewall_extension_scripts.htm > # > ### > echo "Here is init with \$COMMAND=$COMMAND" > > gateway:~# shorewall -qq restart > Here is init with $COMMAND=restart > gateway:~# Oh -- and: gateway:~# which shorewall /sbin/shorewall gateway:~# -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 \ signature.asc Description: OpenPGP digital signature -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
On 9/29/10 4:52 PM, Mr Dash Four wrote:
>
>> Then is sounds like /etc/init.d/shorewall is generating '/sbin/shorewall
>> stop; /sbin/shorewall start' for the 'reload' command. So
>> /etc/shorewall/init will be invoked twice; once with $COMMAND=stop and
>> once with $COMMAND=start. That's the way it works and there is nothing
>> to 'fix'.
>>
> /etc/init.d/shorewall:
>
> restart() {
> # Note that we don't simply stop and start since shorewall has a built in
> # restart which stops the firewall if running and then starts it.
> echo -n $"Restarting Shorewall: "
> $shorewall $OPTIONS restart $config_file_dir 2>&1 | $logger
> retval=${PIPESTATUS[0]}
> if [[ $retval == 0 ]]; then
> touch $lockfile
> success
> else # Failed to start, clean up lock file if present
> rm -f $lockfile
> failure
> fi
> echo
> return $retval
> }
>
>
> ...
>
> restart|reload|force-reload)
> restart
> ;;
>
>
>> Note that to execute the sequence of ipset commands that you want to
>> execute, Shorewall must be in the stopped state. So the above sequence
>> is appropriate if you want to reload your ipsets.
>>
> Nope, you've lost me. I do NOT want the sequence in the init file to be
> executed when I am issuing 'reload' or 'restart' (in other words, 'stop'
> and then 'start' to be passed to my init file) as the ipsets are already
> loaded (and I have created new ones from the command line).
I have no idea what's going on on your system.
gateway:~# cat /etc/shorewall/init
#
# Shorewall version 4 - Init File
#
# /etc/shorewall/init
#
# Add commands below that you want to be executed at the beginning of
# a "shorewall start" or "shorewall restart" command.
#
# For additional information, see
# http://shorewall.net/shorewall_extension_scripts.htm
#
###
echo "Here is init with \$COMMAND=$COMMAND"
gateway:~# shorewall -qq restart
Here is init with $COMMAND=restart
gateway:~#
-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 \
signature.asc
Description: OpenPGP digital signature
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
> Then is sounds like /etc/init.d/shorewall is generating '/sbin/shorewall
> stop; /sbin/shorewall start' for the 'reload' command. So
> /etc/shorewall/init will be invoked twice; once with $COMMAND=stop and
> once with $COMMAND=start. That's the way it works and there is nothing
> to 'fix'.
>
/etc/init.d/shorewall:
restart() {
# Note that we don't simply stop and start since shorewall has a built in
# restart which stops the firewall if running and then starts it.
echo -n $"Restarting Shorewall: "
$shorewall $OPTIONS restart $config_file_dir 2>&1 | $logger
retval=${PIPESTATUS[0]}
if [[ $retval == 0 ]]; then
touch $lockfile
success
else # Failed to start, clean up lock file if present
rm -f $lockfile
failure
fi
echo
return $retval
}
...
restart|reload|force-reload)
restart
;;
> Note that to execute the sequence of ipset commands that you want to
> execute, Shorewall must be in the stopped state. So the above sequence
> is appropriate if you want to reload your ipsets.
>
Nope, you've lost me. I do NOT want the sequence in the init file to be
executed when I am issuing 'reload' or 'restart' (in other words, 'stop'
and then 'start' to be passed to my init file) as the ipsets are already
loaded (and I have created new ones from the command line).
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
On 9/29/10 4:29 PM, Mr Dash Four wrote: > >> What do you mean by 'init script'? Do you mean /etc/init.d/shorewall or >> do you mean /etc/shorewall/init? >> > /etc/shorewall/init (it relies on "$COMMAND" = start to do its job) Then is sounds like /etc/init.d/shorewall is generating '/sbin/shorewall stop; /sbin/shorewall start' for the 'reload' command. So /etc/shorewall/init will be invoked twice; once with $COMMAND=stop and once with $COMMAND=start. That's the way it works and there is nothing to 'fix'. Note that to execute the sequence of ipset commands that you want to execute, Shorewall must be in the stopped state. So the above sequence is appropriate if you want to reload your ipsets. -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 \ signature.asc Description: OpenPGP digital signature -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
> What do you mean by 'init script'? Do you mean /etc/init.d/shorewall or > do you mean /etc/shorewall/init? > /etc/shorewall/init (it relies on "$COMMAND" = start to do its job) -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload/restart
On 9/29/10 4:07 PM, Mr Dash Four wrote: > My shorewall init script has a conditional block on $COMMAND = start and > it wipes out all my existing ipsets (flushes them first) with 'ipset -F' > and 'ipset -X' and then reloads them from a predefined script. > > That's all well and good, but when I do 'service shorewall reload' it > does not pass 'reload' to the init script, but executes it twice, > passing 'stop' and then 'start' which completely screws up my system as > I use the 'reload' to test dynamically loaded sets without having to > reboot the whole system. > > Could that be fixed so that my init script knows it is a reload (or > restart) and not just stop/start? What do you mean by 'init script'? Do you mean /etc/init.d/shorewall or do you mean /etc/shorewall/init? -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 \ signature.asc Description: OpenPGP digital signature -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] shorewall reload/restart
My shorewall init script has a conditional block on $COMMAND = start and it wipes out all my existing ipsets (flushes them first) with 'ipset -F' and 'ipset -X' and then reloads them from a predefined script. That's all well and good, but when I do 'service shorewall reload' it does not pass 'reload' to the init script, but executes it twice, passing 'stop' and then 'start' which completely screws up my system as I use the 'reload' to test dynamically loaded sets without having to reboot the whole system. Could that be fixed so that my init script knows it is a reload (or restart) and not just stop/start? -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
