4 ms·

> Why exactly does systemd need to mess with the networking services? It doesn't. All this stuff is opt-in. If you don't want to use it, don't. What's a bit u

> Why exactly does systemd need to mess with the networking services? It doesn't. All this stuff is opt-in. If you don't want to use it, don't. What's a bit unfair though is that you imply that the various technologies where equivalent in behaviour and would be different only in performance. That's really not the case. The eBPF stuff allows configuration of per-cgroup, i.e. per-service or per-container access control. And that's a massive advantage. Classic Netfilter doesn't allow that: you can't tell it to permit all traffic to bittorrentd.service, because service/container/cgroup information is not available to it. Yes, people have tried to make that work, and there was some support for it in the kernel, but only for egress, and that made it pretty useless ultimately. You know, if iptables would allow us to configure tables per-service, we'd happily hook that up. Such a design is in fact where we started from originally. But the fact is that such a scheme isn't really compatible with Netfilter's design and thus didn't happen. And that that's the case is really not systemd's fault, but a technical decision of the kernel community. I know it is fashionable to blame systemd for everything, but seriously, eBPF+cgroups and all that kind of stuff is the result of the kernel's development scheme, and systemd only follows that and exposes what they came up with. If you don't like where kernel development goes, please complain about and to the kernel community, but systemd is just a consumer of what they do, and I couldn't care less if per-service firewalling is ultimately implemented based on netfilter, on nftables or on ebpf/cgroup. As it turns out only the latter ended up being capable enough to make this possible. And I accept that, and then made use of this. Do note that the port forward hookups in nspawn (i.e. --port=) are actually implemented using netfilter, not cgroups/ebpf. I hope that illustrates a bit that we use what works and is provided by the kernel community, and don't really follow an evil scheme here. Lennart

binaryapparatus 9y ago
> It doesn't. All this stuff is opt-in. If you don't want to use it, don't. This sentence is getting rather long in a tooth. Cgroups? Kdbus? udev? Same mantra that is used over and over again turned out to be at least deceptive if not outright lie, each time it was used.
- binaryapparatus 9y ago
  One of the examples of 'pants on fire' syndrome I mentioned is udev. Other examples are equally easy to search and examine. "After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time" http://article.gmane.org/gmane.linux.hotplug.devel/17392 http://article.gmane.org/gmane.linux.hotplug.devel/17392 "...this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call." http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html http://lists.freedesktop.org/archives/systemd-devel/2014-May... So when Lennart or somebody in the systemd team claims something to be optional you can bet everything it is not or soon won't be.
marios 9y ago
Firstly, thank you for taking the time to answer. Some comments: > It doesn't. All this stuff is opt-in. If you don't want to use it, don't. I said I feared a package used it, because it made sense at packaging time. Let's be honest, upstream often has less than sane defaults. In that case, there will most likely be some hair-pulling on the user/sysadmin side before he figures what what's wrong. And then, he will definitely blame systemd (even though it's not really systemd's fault). > What's a bit unfair though is that you imply that the various technologies where equivalent in behaviour and would be different only in performance. That's really not the case. The eBPF stuff allows configuration of per-cgroup, i.e. per-service or per-container access control. And that's a massive advantage. Classic Netfilter doesn't allow that: you can't tell it to permit all traffic to bittorrentd.service, because service/container/cgroup information is not available to it. Yes, people have tried to make that work, and there was some support for it in the kernel, but only for egress, and that made it pretty useless ultimately. My bad. I mentioned the performance aspect because AFAIK, that's the main problem solved in the big players' case. I'm fully aware of Netfilter's limits. It is very powerful, no doubt about that, but it operates at the network level. Therefore, it has limited knowledge regarding the software running (unlike, say, the firewall integrated in Windows that can permit/deny depending on the process that attempts to contact the network). eBPF/XDP bridges that gap, which is an interesting feature for the user (as you rightly mentioned). > I know it is fashionable to blame systemd for everything, but seriously, eBPF+cgroups and all that kind of stuff is the result of the kernel's development scheme, and systemd only follows that and exposes what they came up with. If you don't like where kernel development goes, please complain about and to the kernel community, but systemd is just a consumer of what they do, and I couldn't care less if per-service firewalling is ultimately implemented based on netfilter, on nftables or on ebpf/cgroup. I didn't blame systemd for eBPF :-). I'm fully aware that the kernel community often has different concerns that what us user-peasants would like. I am bothered by the overlap between eBPF/XDP and Netfilter and more importantly, that the tooling seems to be lacking. Using it in systemd is opt-in, sure. However, a user that opts into this feature is not aware of the technology used underneath. When debugging time comes, he will be wondering what this magic is. > As it turns out only the latter ended up being capable enough to make this possible. And I accept that, and then made use of this. Why does systemd need to expose it ? As you said, it's fashionable to blame systemd for everything but I feel you're just making it easier by adding knobs for everything. What is the scope of systemd ? Where exactly does it stop ?

binaryapparatus 9y ago

> It doesn't. All this stuff is opt-in. If you don't want to use it, don't. This sentence is getting rather long in a tooth. Cgroups? Kdbus? udev? Same mantra that is used over and over again turned out to be at least deceptive if not outright lie, each time it was used.

binaryapparatus 9y ago
One of the examples of 'pants on fire' syndrome I mentioned is udev. Other examples are equally easy to search and examine. "After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time" http://article.gmane.org/gmane.linux.hotplug.devel/17392 http://article.gmane.org/gmane.linux.hotplug.devel/17392 "...this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call." http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html http://lists.freedesktop.org/archives/systemd-devel/2014-May... So when Lennart or somebody in the systemd team claims something to be optional you can bet everything it is not or soon won't be.

marios 9y ago

Firstly, thank you for taking the time to answer. Some comments: > It doesn't. All this stuff is opt-in. If you don't want to use it, don't. I said I feared a package used it, because it made sense at packaging time. Let's be honest, upstream often has less than sane defaults. In that case, there will most likely be some hair-pulling on the user/sysadmin side before he figures what what's wrong. And then, he will definitely blame systemd (even though it's not really systemd's fault). > What's a bit unfair though is that you imply that the various technologies where equivalent in behaviour and would be different only in performance. That's really not the case. The eBPF stuff allows configuration of per-cgroup, i.e. per-service or per-container access control. And that's a massive advantage. Classic Netfilter doesn't allow that: you can't tell it to permit all traffic to bittorrentd.service, because service/container/cgroup information is not available to it. Yes, people have tried to make that work, and there was some support for it in the kernel, but only for egress, and that made it pretty useless ultimately. My bad. I mentioned the performance aspect because AFAIK, that's the main problem solved in the big players' case. I'm fully aware of Netfilter's limits. It is very powerful, no doubt about that, but it operates at the network level. Therefore, it has limited knowledge regarding the software running (unlike, say, the firewall integrated in Windows that can permit/deny depending on the process that attempts to contact the network). eBPF/XDP bridges that gap, which is an interesting feature for the user (as you rightly mentioned). > I know it is fashionable to blame systemd for everything, but seriously, eBPF+cgroups and all that kind of stuff is the result of the kernel's development scheme, and systemd only follows that and exposes what they came up with. If you don't like where kernel development goes, please complain about and to the kernel community, but systemd is just a consumer of what they do, and I couldn't care less if per-service firewalling is ultimately implemented based on netfilter, on nftables or on ebpf/cgroup. I didn't blame systemd for eBPF :-). I'm fully aware that the kernel community often has different concerns that what us user-peasants would like. I am bothered by the overlap between eBPF/XDP and Netfilter and more importantly, that the tooling seems to be lacking. Using it in systemd is opt-in, sure. However, a user that opts into this feature is not aware of the technology used underneath. When debugging time comes, he will be wondering what this magic is. > As it turns out only the latter ended up being capable enough to make this possible. And I accept that, and then made use of this. Why does systemd need to expose it ? As you said, it's fashionable to blame systemd for everything but I feel you're just making it easier by adding knobs for everything. What is the scope of systemd ? Where exactly does it stop ?