4 ms·

On the one hand, the user facing aspect of this feature as presented in this article seems really nice. On the other hand, it's another abstraction over rather

by marios 9y ago

On the one hand, the user facing aspect of this feature as presented in this article seems really nice. On the other hand, it's another abstraction over rather new kernel APIs. Your average user may know of NetFilter kernel component, and the iptables userland counterpart. Some may even have heard of nftables. How many users know about eBPF/XDP ? More importantly, how many sysadmins know how to debug this when something goes wrong ? I'm aware there's a lot of development around eBPF and a number of players (Facebook, CloudFlare, ...) are already using XDP because of the ridiculous performance gain it provides for their use-cases. There's a myriad of frontends to iptables and yet they all suck. Each of them fail in mysterious ways and at that point the only way to debug what's wrong is to look at the ruleset with ... iptables. A package could ship with IP filtering in its service file, which may not match what the user expected. The symptom "service does not respond to TCP connections" is well known. In that case, it's common to check the process is alive (using ps), it has setup listening sockets (using netstat) and that the system firewall is not blocking it (using iptables/nftables or some frontend). Figuring out it's a eBPF/XDP misconfiguration is going to be painful IMHO. systemd attempts to cooperate with the system firewall. The subtlety is that there are now two facilities in the kernel that provide firewalling, and both can be on at the same time. To be honest, I don't even know which one has precedence. Why exactly does systemd need to mess with the networking services ? AFAIK, its primary function is that of a service manager; i.e: reliably bring services up and down. I feel all the rest should not be systemd's concern. After using systemd for quite some time, I've come to the conclusion that it works rather well when it sticks to starting/stopping services, assuming your service fits the systemd model. If it doesn't, debugging is extremely difficult and you often have to resort to dirty hacks to end up with a functionning system -- which is ironic considering one of systemd's motivations was to get rid of the dirty hacks in initscripts. An example of a buggy use case is when you need to pass environment variables to your executable and there's escaping involved. The systemd documentation suggests you can pass pretty much anything in the ExecStart lines. However, the reality is that it does not behave as other environments. The solution is to store the variables in a separate file, and not involve systemd at all. My takeaway is: why does systemd involve so many features ? It increases failure cases as well as the cognitive load required when dealing with it.

deleted 9y ago
[deleted]
poettering 9y ago
> 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.

by marios 9y ago

deleted 9y ago

[deleted]

poettering 9y ago

> 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.