>> 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
