On 28/04/2015 17:52, Ed W wrote:
Sorry, was slow to notice your reply. I will benchmark this
immediately. While I'm doing that I noticed...
- I'm using this *really* in the form "reenable iface", ie I really
call "disable" + "enable"
- It's used when a dynamic PPP connection (re)starts, eg a 3G PPP
connection because the IP address changes on the interface.
- I observe I'm currently "cheating" and I manually call the
"undo_networking" script as this avoids a call into the firewall
script, but this is obviously not terribly future proof or neat...
- Would you be amenable to either adding a "force" flag or "re-enable"
option which simply calls disable/enable?
Code for reenable would be at the bottom of firewall script, something
like the following (untested for error handling):
....
reenable)
[ $# -eq 1 ] && exit 0
shift
[ $# -ne 1 ] && usage 2
mutex_on
if product_is_started; then
detect_configuration
disable_provider $1
enable_provider $1
fi
mutex_off
status=0
;;
....
Does this work for you?
I tested the above and error handling causes a problem... My desired
outcome would be that it's possible to call "reenable" regardless of the
current status of the interface. However, if it's already "disabled",
then calling disable a second time causes a "startup_error" which bails
us out before we call enable.
Changing this seems to require a more invasive code change? Is this a
direction you would be willing to consider?
Thanks
Ed W
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
