[Pkg-systemd-maintainers] Bug#734951: Bug#734951: Bug#734951: systemd: somehow starts LSB stuff in the wrong order

[Michael Stapelberg]

Hi Christoph,

Christoph Anton Mitterer <calestyo at scientia.net> writes:
> Now... is there any clean way to do that with fail2ban/iptables
> persistent.. i.e. that when iptables-persistent is stopped/restarted,
> systemd automatically stops/restarts fail2ban as well?
> Especially since both are not yet converted to systemd.
You’ll have to convert them to native systemd service files to do
anything like that. I think using WantedBy= might lead to the desired
effect. I remember having done something like that for the bind9
package.

>>In general, if you want to make sure that a service cannot start unless
>>another has been successfully started, add the "Requires" or "Requisite"
>>field to the unit.
> But AFAIU, this would be like that every service for, which iptables
> rules MUST be in place due to e.g. the site's local security
> constraints, would need to Requires/Requisite iptables-persistent (or
> something similar).
> Realistically,.. it's not going to happen that all maintainers add
> something like this to their unit files (once they convert).
> Isn't there something like what we've had in sysvinit... e.g. that you
> reverse-depend on $networking?
Sure, you can use Before=networking.target, and there are even more
drastic ways to run a specific unit before most of the rest.

> I didn't imagine that systemd tries to be that smart, and also
> "converts" calls of /etc/init.d/xx stop to be queued.
>
> I haven't thought that through... but wouldn't the compatibility to
> legacy LSB script be better,... if it doesn't try to be that smart?
I don’t think so. With the current compatibility implementation, we get
a number of nice benefits, i.e. clean cgroup process termination when
calling the “stop” action.

> The question though is: are our units in Debian set up this way... and
> if not what's actually the best way do get that behaviour.
I doubt anyone has been paying a lot of attention to this specific
angle. As you know, we are not even sure whether systemd will become the
default init or not yet.

> For "services" like iptables-persistent or similar firewall programs,
> people would usually expect that the rules are in place before anything
> except perhaps the loopback network interface is brought up.
> […]
>> How about using pre-up iptables-restore < /etc/network/iptables in
>> /etc/network/interfaces then? :)
> I'm not sure whether that works with all rules... especially when you
> have rules that use ifaces which are then not yet up or perhaps not even
> existing.
Uh… so these two statements seem in conflict with each other. In the
first one you want to have it up before lo, in the second one you are
unsure whether it’s good enough to have it up before the actual
interfaces.

> Actually I think that this is at least partially also the responsibility
> of the systemd maintainers in Debian,... since you guys have probably
> the most experience how to do this kinds of things cleanly.
No, it’s not our responsibility. We are available for questions and
help, but we certainly are not responsible for how other people in
Debian write their units.

>> I do agree that network config is a bit unsatisfactory in general,
>> though. An effective and mostly parallel boot only highlights this
>> problem, but doesn’t create it, IMO.
> Well at least we need to eventually find some securely working solution
> for that,... cause this is really security critical.
I don’t agree that it’s security critical, but I agree that it’s
worthwhile to work on this. We seem to have different ways of thinking
about security :). In case you want to help out, any help is welcome,
but personally I won’t do much until the tech-ctte bug is resolved.

-- 
Best regards,
Michael