Shorewall users - Oct 2014 - SW 4.6.4+' systemd service files' Before=/After= dependency on 'network.target' -- should that be 'network-pre.target' and 'network-online.target'?

In current SW git sources, systemd service files assign dependency order with
respect to the "network.target",

	cd ./code
	grep network `find . | grep service`                                
		./Shorewall-init/shorewall-init.service:Before=network.target
		./Shorewall6-lite/shorewall6-lite.service:After=network.target
		./Shorewall-lite/shorewall-lite.service:After=network.target
		./Shorewall/shorewall.service:After=network.target
		./Shorewall6/shorewall6.service:After=network.target

As I undertstand intent, shorewall-init.service is to start/exec before any
network functionality is up, and shorewall{,6}{,-lite}.service are to start
after the network is up.

In the case of shorewall configs that have mandatory/required interface
dependencies for multiple interfaces, "after the network is up" needs
to be after ALL of the interfaces are up.

The dependency on network.target, however, enables the parallelized start after
network functionality is 1st available -- i.e., after any/single interface is
initialized.  If a multi-interface SW config to fail, e.g., on 'isusble'
tests ...

Reading @

	@ http://www.freedesktop.org/software/systemd/man/systemd.special.html


there are *three* network-related targets,

	network-pre.target

		This passive target unit may be pulled in by services that want to run before
any network is set up, for example for the purpose of setting up a firewall. All
network management software orders itself after this target, but does not pull
it in.


	network.target

		This unit is supposed to indicate when network functionality is available, but
it is only very weakly defined what that is supposed to mean, with one
exception: at shutdown, a unit that is ordered after network.target will be
stopped before the network -- to whatever level it might be set up then -- is
shut down. It is hence useful when writing service files that require network
access on shutdown, which should order themselves after this target, but not
pull it in. Also see Running Services After the Network is up for more
information. Also see network-online.target described above.

		systemd automatically adds dependencies of type After= for this target unit to
all SysV init script service units with an LSB header referring to the
"$network" facility.

	network-online.target

		Units that strictly require a configured network connection should pull in
network-online.target (via a Wants= type dependency) and order themselves after
it. This target unit is intended to pull in a service that delays further
execution until the network is sufficiently set up. What precisely this requires
is left to the implementation of the network managing service.

		Note the distinction between this unit and network.target. This unit is an
active unit (i.e. pulled in by the consumer rather than the provider of this
functionality) and pulls in a service which possibly adds substantial delays to
further execution. In contrast, network.target is a passive unit (i.e. pulled in
by the provider of the functionality, rather than the consumer) that usually
does not delay execution much. Usually, network.target is part of the boot of
most systems, while network-online.target is not, except when at least one unit
requires it. Also see Running Services After the Network is up for more
information.

		All mount units for remote network file systems automatically pull in this
unit, and order themselves after it. Note that networking daemons that simply
provide functionality to other hosts generally do not need to pull this in.

With those definitions, and the need to correctly accommodate multi-interface SW
configs, is it not more appropriate to

		./Shorewall-init/shorewall-init.service
			...
-			Before=network.target
+			Before=network-pre.target
			...

where network-pre target was added to specifically deal with fw 'leaks',

	[systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
	http://lists.freedesktop.org/archives/systemd-devel/2014-June/019772.html

and

		./Shorewall/shorewall.service
			...
-			After=network.target
+			After=network-online.target
			...

		./Shorewall-lite/shorewall-lite.service
			...
-			After=network.target
+			After=network-online.target
			...

		./Shorewall6/shorewall6.service
			...
-			After=network.target
+			After=network-online.target
			...

		./Shorewall6-lite/shorewall6-lite.service
			...
-			After=network.target
+			After=network-online.target
			...


deal with the multi-interface use case

?

Locally, I'm currently using these changes -- in conjunction with additional
fail2ban and openvpn dependencies -- and they eliminate the @boot SW startup
failure due to missing/not-yet-initialized interfaces.

I do not yet know the issues this might cause, if any, with distro-packaging.


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk