[systemd-bugs] [Bug 80169] RFE: please introduce more special targets for facilities like entropy, or netfilter rules

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80169

Zbigniew Jedrzejewski-Szmek <zbyszek at in.waw.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #11 from Zbigniew Jedrzejewski-Szmek <zbyszek at in.waw.pl> ---
(In reply to comment #10)
> >network-pre.target means "network prerequisites"
> >as much as "before network". This name is good
> >because it follows the general naming, and we
> >can easy have a number of such targets
> >(remote-fs-pre, network-pre, cryptsetup-pre, ...)
> 
> To be honest... it seems extremely ugly to me... I mean the concept itself.
> Cause ordering is done via After=/Before=, i.e. semantically... ordering
> should be done by naming.
> Cause what's next? Someone needs something that runs after networking, and
> we get network-post.target. And someone else needs something that is network
> related but runs even before network-pre.target... what then?
> network-pre-pre.target?
After=network.target means exactly what it seems to mean. So network-pre.target
and network.target cover pretty much all common cases.

If you need more specific dependencies, they can be specified on the level
of individual units.

> Authors of unit files (and I think we rather want to have the unit files
> upstream and not per distro) can then rest assured, that *if* a package that
> provides such facility is installed on a system... it will be pulled in.
> systemd should of course not implement this functionality by itself.
> 
> Example:
> I have a unit file for the postfix.service... since we (would) teach people
> to do so, Wietse adds
> Requires=network-secured.target
> After=network-secured.target
No, no, no. Individual services should be able to listen (securely) at any
point
in time. Teaching them about network configuration stages is very wrong.

BTW. we already have the equivalent of dns.target — nss-lookup.target.

> >I see some merit in adding a firewall.target, with the meaning
> >"firewall has been configured".
> While I don't insist on my proposed name "network-secured.target" I think
> firewall isn't good either.
> Neither would I take "packet-filter" or something like that.
> 
> I guess my idea is to also hook in other services that secure the
> network,... fail2ban is a prominent example (even though this would also act
> on the firewall)... but think of some network intrusion detection system,
> that one may want to have running before any daemon starts up.
Great. They can run Before=network-pre.target. I think that this shows
why existing targets are sufficient.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20140623/b76d5c73/attachment.html>