Shorewall users - Aug 2014 - Best practices for daemon dependency management & dynamic IP handling?

On my linux/64 edge router/firewall, I run

	shorewall-lite
	shorewall6-lite
	openvpn
	bind9/named
	fail2ban

shorewall-lite is configured as MultiISP with 2 providers:

	* a StaticIP broadband ISP
	* an OpenVPN connection

That StaticIP will change soon to a non-static, dynamically (as defined by the
ISP) allocated IP.

I'd appreciate 2 bits of help:

	(1) a review of my startup dependencies
	(2) best practice for dealing with Dynamic IP -- in shorewall-lite (and
elsewhere?) is it still 'lsm'?

Nothing's broken, and I'm not looking to fix an immediate problem;
I'm looking for a 2nd set of eyes, and some chat about best practices.

Re: Startup Dependencies ...

All services are managed by systemd.

I've set up a 'jungle' of dependencies to try to make sure that
startup @ boot is functional & efficient.  I've 3 criteria that I'm
trying to meet:

	(1) no hangs waiting for not-yet-ready services
	(2) everything 'up' and functional once booted
	(3) no inadvertent exposure by firewall before it's fully up

Looking at boot-up logs, and checking state immediately after startup, it
appears to be working correctly.  Just in case I'm missing something key or
obvious, I'd appreciate any look-over/comments about the following
dependencies:

	cat shorewall-lite.service
		[Unit]
		Description=shorewall-lite
		After=syslog.target network.target
		Before=shorewall-lite.target fail2ban.service
		Wants=fail2ban.service
		Requires=network.target
		...

	cat shorewall6-lite.service
		[Unit]
		Description=shorewall6-lite
		After=syslog.target network.target shorewall-lite.target
		Before=shorewall6-lite.target fail2ban.service openvpn.target
		Wants=fail2ban.service
		Requires=network.target
		...

	cat fail2ban.service
		[Unit]
		Description=fail2ban
		After=syslog.target network.target shorewall-lite.target
		Before=fail2ban.target
		Requires=shorewall-lite.target shorewall6-lite.target
		...

	cat openvpn.service
		[Unit]
		Description=openvpn
		After=syslog.target network.target shorewall-lite.target named.target
		Before=openvpn.target
		Requires=network.target shorewall-lite.target
		...

	cat named.service
		[Unit]
		Description=bind9/named
		After=syslog.target network.target shorewall-lite.target
shorewall6-lite.target
		Before=named.target
		Requires=network.target
		...

Is anything ^^ nonsense, missing, or otherwise problematic?


Re: Dynamic IP management ...

Currently my StaticIP config for shorewall-lite includes simply

	/zones
		net    EXTIF   
optional,physical=eth0,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=0,sourceroute=0
		...

	/providers
		prov1    1    1    main    EXTIF    detect    track,balance    INTIF
		...

I manage & compile centrally, pushing to remote instances.  Even with
StaticIP, I've a convenience parameter

	/params
		...
		ROUTER_eth0_IP4=$(/usr/local/bin/ssh -F /usr/local/etc/ssh/ssh_config -l root
$ROUTER_eth1_IP4 "/usr/sbin/shorewall-lite call
find_first_interface_address_if_any eth0")
		...

At local compile/push, this appears to correctly determine the remote's
(static) IP, and populate the $ROUTER_eth0_IP4 variable for use as needed.

The moment $ROUTER_eth0_IP4 becomes changeable -- either predictably at router
reboot / DHCP lease renewal, or randomly when the networks hiccups obviously
shorfewall needs to be made aware.

Reading the MultiISP docs, I see that lsm is used.  Is that still the
recommended approach?

As the Dynamic IP will be acquired via DHCP, I could see monitoring externally
to shorewall, then triggering a reload of SW -- and any other services (OpenVPN,
named, etc) that need update.

What's the current best practice -- from the perspective of shorewall?

Thanks!

------------------------------------------------------------------------------