4 ms·

I have been pretty vocally opposed to systemd's gradual takeover of core Linux systems that I was previously familiar with, but it's clearly not going away and

I have been pretty vocally opposed to systemd's gradual takeover of core Linux systems that I was previously familiar with, but it's clearly not going away and I'm gradually getting up to speed on it. In your example, I'm super comfortable with iptables and it would probably take me less time to solve it there than it would to discover that a systemd service could have ip address filters added to its unit file. When people say "just read its documentation" ... that seems really dismissive of both the volume and the inconsistent quality of it. I spent hours about a week ago working on a single service file for an encfs mount (not a mount unit, which is a different thing, which I also spent hours reading documentation on!). Ultimately it was only through trial-and-error that I discovered that it would only work with "Type=forking". The systemd docs do a fine job of describing the different "Type" values and how they matter to systemd, but don't fill in the blanks that certain things require certain Type values. Most of my interactions with systemd have required time with its documentation. It's fiddly and quirky and not a big improvement over historical tooling in that respect. But I recognize that it is capable of doing some things better than the old tooling could, and it's not gonna go away, so it'll just be another volume of arcana to memorize and I should get to it.

andrewstuart 4y ago
You are correct. Systemd is not necessarily easy, but that because it is surfacing the power of linux and many of the concepts take some learning. Or you probably already know the concepts but do not yet know how or where systemd brings them out. It’s worth reading as much as you can stomach of the systemd documentation. Even if you’re just skimming over it, you’ll pick up useful things for the future. Like socket activation, file change activation, timers, nspawn and lots of other good stuff. You might even come to like it. Or at least forgive its sins.
traverseda 4y ago
As a systemd hater, I have to say that I like the systemd approach here better than messing with iptables. The locality of behavior is nice.
- andrewstuart 4y ago
  systemd has a bunch of other application/service level resource control stuff you might like, besides IPAddressDeny, listed here: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html https://www.freedesktop.org/software/systemd/man/systemd.res... Also you might like nspawn it's a pretty cool alternative to chroot: https://wiki.archlinux.org/title/systemd-nspawn https://wiki.archlinux.org/title/systemd-nspawn https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html https://www.freedesktop.org/software/systemd/man/systemd-nsp...
  - traverseda 4y ago
    Nah, I'm still passed off about nspawn. Broke chroots for me in some embedded linux contexts, well the fact that you have to use nspawn in order to launch systemd services.
- throw0101c 4y ago
  > As a systemd hater, I have to say that I like the systemd approach here better than messing with iptables. The locality of behavior is nice. Until someone new comes along and is not aware of this seemingly obscure feature and can't figure why traffic is not getting to the app: nothing in iptables, tcpdump shows the packets getting to the system… WTF? Looking at a service's systemd unit file would be the last place I would think for network filtering configuration. Or does systemd place the appropriate lines into iptables (or nftables nowadays) on your behalf?

andrewstuart 4y ago

You are correct. Systemd is not necessarily easy, but that because it is surfacing the power of linux and many of the concepts take some learning. Or you probably already know the concepts but do not yet know how or where systemd brings them out. It’s worth reading as much as you can stomach of the systemd documentation. Even if you’re just skimming over it, you’ll pick up useful things for the future. Like socket activation, file change activation, timers, nspawn and lots of other good stuff. You might even come to like it. Or at least forgive its sins.

traverseda 4y ago

As a systemd hater, I have to say that I like the systemd approach here better than messing with iptables. The locality of behavior is nice.

andrewstuart 4y ago
systemd has a bunch of other application/service level resource control stuff you might like, besides IPAddressDeny, listed here: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html https://www.freedesktop.org/software/systemd/man/systemd.res... Also you might like nspawn it's a pretty cool alternative to chroot: https://wiki.archlinux.org/title/systemd-nspawn https://wiki.archlinux.org/title/systemd-nspawn https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html https://www.freedesktop.org/software/systemd/man/systemd-nsp...
- traverseda 4y ago
  Nah, I'm still passed off about nspawn. Broke chroots for me in some embedded linux contexts, well the fact that you have to use nspawn in order to launch systemd services.
throw0101c 4y ago
> As a systemd hater, I have to say that I like the systemd approach here better than messing with iptables. The locality of behavior is nice. Until someone new comes along and is not aware of this seemingly obscure feature and can't figure why traffic is not getting to the app: nothing in iptables, tcpdump shows the packets getting to the system… WTF? Looking at a service's systemd unit file would be the last place I would think for network filtering configuration. Or does systemd place the appropriate lines into iptables (or nftables nowadays) on your behalf?