[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

--- Comment #10 from Christoph Anton Mitterer <calestyo at scientia.net> ---
>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?


And you still have the problem that, as I've said, network and network-pre can
more or less include anything or nothing.
Name and definition are IMHO _too_ generic and ambiguous.

I'd rather go the way to add more targets, which have a tightly defined meaning
and clear naming,... e.g. "network-secured.target", "dns.target"... if such are
needed.
Cause this really allows units to just depend on what they actually
need/want... while for network-pre.target... how should e.g. the author of a
postfix.service know what this really pulls in on distro XYZ?

One of the greater ideas of systemd was to just depend and start what you
really need... don't destroy this by such too generic names.



>OTOH, systemd cannot really make any promises that the
>network is secure, even after network-secured.target
>has been reached. *That* is something that we don't to do.
I've never said that systemd should make or want to make this promise.

What I want to do is, provide abstract or virtual facilities (as said, like
"network secured" or "entropy daemons loaded" or perhaps "auto backup system is
running"...
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

On Fedora, where the iptables package ships some loader scripts (IIRC),...
iptables would ship a unit file, that is (per default)
RequiredBy=network-secured.target.
On Debian where we have e.g. netfilter-persistent.... that package would do the
same.
Other packages like ferm/shorewall would do as well.

systemd would of course not guarantee that any such package is installed (this
is still the duty of the sysadmin to take care of),... but *if* such package is
installed... then one can be sure that postfix only starts if the netfilter
rules were _successfully_ loaded.

And should the local sysadmin want to start his services even though the rules
loading failed... he simply changes the unit file of e.g. netfilter-persistent
from RequiredBy= to WantedBy=network-secured.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.



>This would provide a measure of interchangedness between
>various firewall configuration mechanisms. Would that work for you?
Well it's really not just providing such target. I you just add this and no one
uses it, it's worthless.
I think it's really the steps I've written in comment 7, especially steps (2)
through (5).
If we don't teach authors of unit files to use it that way,... than no one will
and it's useless in the end.

-- 
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/0d119aaa/attachment.html>