On 10/8/2014 8:04 AM, PGNd wrote:
> 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',
> We're unclear as to why network-pre was created -- how does Before=network-pre.target differ from Before=network.target? Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
