# /etc/init.d/shorewall restart * Please use 'svc_stop; svc_start' and not 'start; stop' to * restart the service in its custom 'restart()' function. * Run shorewall without arguments for more info. * Stopping firewall... [ ok ] * Starting firewall... [ ok ] Reproducible: Always Steps to Reproduce: 1. /etc/init.d/shorewall restart Actual Results: * Please use 'svc_stop; svc_start' and not 'start; stop' to * restart the service in its custom 'restart()' function. * Run shorewall without arguments for more info. * Stopping firewall... [ ok ] * Starting firewall... [ ok ] Expected Results: * Stopping firewall... [ ok ] * Starting firewall... [ ok ]
same error msg as #25168, which is wrong
*** Bug 55576 has been marked as a duplicate of this bug. ***
Bug 55576 does not seem a duplicate of this bug. Will you change the 'start; stop' with 'stop; start' ??
You're right, it's not a duplicate, but we can handle them both in the same bug. One problem is that runscript.sh says "start; stop" when it means "stop; start". This is trivial but could be fixed. The second problem is much more gross. runscript.sh's restart case actually greps the initscript for instances of svc_stop and svc_start. I'll try to come up with a more elegant way to handle this... though it could just be fixed by removing the custom restart function in the shorewall init script.
Go on then :)
ok, I fixed both problems
Verified: in CVS. There's a small problem: The output of the shorewall rules is shown! ----- # /etc/init.d/shorewall restart * Restarting firewall... Loading /usr/share/shorewall/functions... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... Restarting Shorewall... Initializing... Shorewall has detected the following iptables/netfilter capabilities: NAT: Available Packet Mangling: Available Multi-port Match: Available ... -----
I don't know anything about shorewall really, I just fixed the problem reported in this bug by putting a comment in the initscript containing the keywords that runscript.sh was grepping for. Perhaps it would be better to remove the custom restart function entirely, then shorewall would be entirely shutdown and restarted whenever you run /etc/init.d/shorewall restart So the question is, "Is it a problem that the rules are shown?" If it is a problem, then I'll rip out the custom restart function from the initscript. If it is not a problem, then... who cares? I'll reopen this bug so that it stays on the radar for the moment. Please respond with your opinion
In fact it shows the reule processing only when restarting, so it's not much anoying... I'll check the script and see what is missing. By the way, Currently: /etc/init.d/shorewall start -----> /sbin/shorewall start /etc/init.d/shorewall stop -----> /sbin/shorewall stop /etc/init.d/shorewall restart -----> /sbin/shorewall restart That is NOT correct. shorewall stop locks internet traffic from and to the interfaces. Restart does the same thing, but as it's a restart, we can say that it makes some logic. shorewall clear clears the rules of iptables and establishes ACCEPT policies. In my point of view, if you stop the firewall, you mean that you want to turn it off, that is, to revert to the state where there was no firewall. To achieve that: /etc/init.d/shorewall stop -----> /sbin/shorewall clear About the restart one, if you exec '/sbin/shorewall restart', what it does is: '/sbin/shorewall stop; /sbin/shorewall start'. In this one, it depends on what you want to achieve. Wanna lock the connections and apply rules after that? Or do you wanna clear the rules and start the firewall over?
By the way, restart() { ebegin "Restarting firewall" /sbin/shorewall restart eend $? } That's why the rule processing is shown. To avoid it: /sbin/shorewall restart 1>/dev/null One last thing, do we want 2>&1 /dev/null? Or is it ok to show processing errors? Personally I don't care.
The current restart is really bloated. But I would rather use something like /sbin/shorewall restart > /var/log/shorewall-restart.log btw the firewall was designed to allow no connections when stopped so /etc/init.d/shorewall stop -----> /sbin/shorewall stop should be OK imho. But another script action that disables the firewall would be useful.
the remaining issues are not ones with baselayout
The behaviour of stop is wanted in a firewall, I've added a clear function to the init script to clear the firewall rules, and /dev/null'd restart output. fixed in portage...