]] Christoph Anton Mitterer > On Wed, 2014-05-21 at 16:35 +0200, Tollef Fog Heen wrote: > > > By looking at that goal (which is a good goal of course) we "loose" > > > however that strict serialisation that we more or less had with > > > sysvinit. > > sysvinit isn't serialised today either. > Sure... I mean we have parallelism as well,... and I guess all what I'm > writing about is less about technical stuff (i.e. what would the > respective init dependency framework allow)... but rather about "how is > it done in practise with the respective scripts/units". > > And there I've had the impression that things in sysvinit are set up > more serialised (i.e. that there are things like $network, where de > facto any service depends upon, when it does networking).
$network is translated to network.target for LSB services, so it is in fact the same thing. You're pointing out that «the network is up» is ill-defined. That is a correct observation and technically never true in a dependency system, since it might change at any point. However, that's not a very useful definition and so systemd provides it for software that doesn't know how to deal with dynamic networks. > - it seems not really be well defined what it does Just the same as today, it's ill-defined. Does it mean you can bind to an interface? Other than localhost? Link is established? IP address set? You can bind to all the interfaces? You can talk to the default gateway? Your routing table has somewhat converged and you can speak to most of the internet? Something else? The answer to what it means is «it depends». For reference, the LSB definition is «$network: basic networking support is available. Example: a server program could listen on a socket.» So it does not say anything other than «you can listen on a socket», but that's not what applications treat it as. > - it's a passive unit, so AFAIU it's not to be pulled in by the services > consuming that functionallity (i.e. webserver) but rather the provider)? I don't know what you mean by passive unit. > - it's more about networking, less about netfilter,... so I think there > are services for which iptables need to be set up before they start > running, but where the interfaces, DNS, etc. don't need to work yet (or > at all, if there is just networking on the loopback) loopback works before any services are started, so that you don't have to worry about. There's nothing in the LSB definition that says «firewalls are up». If you want that, have a ferm.service (or iptables-persistent.service if you prefer that) that has Before=network.target and it will run before you have «useful networking». > - there seem to be only few services that do networking which actually > somehow depend on it... Services are hopefully rewritten to not having to rely on it. > So I guess one thing must be guaranteed... if one uses e.g. > iptables-persitent to load the iptables rules,.. than seervices that do > some networking must start after it,... and ONLY if iptables-persitent > was loaded successfully. No, you need the interface not to be brought up before you apply the iptables rules. That's completely orthogonal to when the service is started. > AFAIU systemd, than right now we have e.g. > network.target is before iptables-persistent... > But this doesn't guarantee at all that iptables-persistent is started, > does it? > Wouldn't one need some "Requires" for that? If iptables-persistent wants to run before network.target, it should declare that by doing WantedBy=network.target and Before=network.target > I think best would be if there were some more such special targets like > network-security or so... > All services that do some networking should Require=/After= that... and > that target in place should pull in those of the installed services like > iptables-persistent... Why should security be a bolt-on? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are _______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
