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
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
