4 ms·

>> Systemd has admittedly grown on me Not suggesting you are (were) a systemd hater, but all the systemd haters might find that systemd is actually damn awesom

>> Systemd has admittedly grown on me Not suggesting you are (were) a systemd hater, but all the systemd haters might find that systemd is actually damn awesome if they stopped their hating and learned about it. Here's an instant tasty systemd tip that I used yesterday ..... I had to prevent a forward proxy server from accessing local networks. How do you solve this without systemd? Well you have to start fiddling with iptables and descend into that level of hell wherein you are fundamentally fiddling with stuff you do not want to fiddle with, and beside that solution is going to be system wide. Or, you pull out systemd and get the job done by application IP address restrictions on a per application / service level: [Unit] Description=glider service After=multi-user.target [Install] WantedBy=multi-user.target [Service] IPAddressDeny=localhost IPAddressDeny=169.254.0.0/16 IPAddressDeny=192.168.0.0/16 IPAddressDeny=198.18.0.0/15 IPAddressDeny=172.16.0.0/12 IPAddressDeny=100.64.0.0/10 IPAddressDeny=10.0.0.0/8 ExecStart=<proxy command line goes here> systemd is chock full of super awesome stuff like this if you read the docs you'll find simple solutions to challenging problems everywhere. systemd is a beautiful, integrated work of art, and there's constant payoffs and benefits from the fact that it encompasses so much functionality previously split across a huge range of inconsistent small solutions to the various problems systemd solves. If the title GNU/Linux makes sense (which I don't think it does), then systemd/Linux makes much more sense. If Linux had started off with systemd and someone came along and said "better idea, lets tear systemd apart into a wide range of tiny applications all with different approaches, syntaxes, maintainers and functionality, with no overarching architecural approach and call it sysV", everyone would say "what a crazy idea, no thanks."

deleted 4y ago
[deleted]
thaumaturgy 4y ago
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?
saurik 4y ago
> Well you have to start fiddling with iptables and descend into that level of hell wherein you are fundamentally fiddling with stuff you do not want to fiddle with, and beside that solution is going to be system wide. This is just a really strange and depressing-to-hear stance, as you seem to simultaneously be claiming that it is worthwhile to read the documentation for systemd to learn about all of its one-off solutions but somehow NOT worthwhile to read the documentation for the actual Linux IP stack? > systemd is chock full of super awesome stuff like this if you read the docs you'll find simple solutions to challenging problems everywhere. Honestly, this just sounds horrible... this sounds like a project that has a million tiny one-off "simple solutions" to individual "challenging problems" instead of providing a generic tool that can be integrated with other generic tools to solve arbitrary problems in infinite combinations. > systemd is a beautiful, integrated work of art, and there's constant payoffs and benefits from the fact that it encompasses so much functionality previously split across a huge range of inconsistent small solutions to the various problems systemd solves. And so like, here is just where I guess there's a philosophy problem at play: those "inconsistent" solutions were just combinations of separate components. To me, that's beautiful... and it's beautiful, in no small part, because it was NOT "integrated", and was instead extensible and transparent. > If Linux had started off with systemd and someone came along and said "better idea, lets tear systemd apart into a wide range of tiny applications all with different approaches, syntaxes, maintainers and functionality, with no overarching architecural approach and call it sysV", everyone would say "what a crazy idea, no thanks." Really? You seriously don't see any benefit to taking a monolithic framework and breaking it apart into a ton of libraries? Yes: there are people out there who like the large monolithic opinionated frameworks... but there are also a lot of people who prefer having a toolkit of libraries. In particular, when we see this debate show up in other places, a big benefit of the "lots of libraries" approach is that it is an inclusive and extensible way of approaching a complex problem, where if you have an idea that you think makes the world better you can just work on that part. And so when someone is working on new network addressing or new ways of doing hypervisor-assisted sandboxing or new ways of managing user accounts, some of us would like to think that the mechanism for "run a bunch of stuff when the system boots" doesn't have to understand any of that. When you have a single program that has decided to form a giant knot in the space of solutions--where to solve anything you feel like you can't just add another library but you have to go modify the big central framework--you stifle a lot of participation and narrow the set of options. And that's where I feel like you are just going to say "that's great! I don't like options! I'd prefer someone else not only solve my problems but tell me what my problems are in the first place" and again: that's where this becomes a big philosophical argument instead of a technical one. So like, do I have technical issues with systemd? I mean, yes: I'm sick of being burned by this "journald" issue--one which has been open over a decade now and will probably never get fixed--because as far as I'm concerned if you build a logging system and you routinely lose log messages you probably aren't qualified to develop a logging system. https://github.com/systemd/systemd/issues/2913 https://github.com/systemd/systemd/issues/2913 https://bugs.freedesktop.org/show_bug.cgi?id=50184 https://bugs.freedesktop.org/show_bug.cgi?id=50184 But, at the end of the day, the reason that systemd makes me sad is because when I started doing system administration the entire community was firmly in the "we should strive to have a lot of separate tools that can be composed in fun ways" camp, and now it seems like the reins have been taken by the "you shouldn't know or care how things are put together: let me solve it for you" camp, and that makes me nigh-unto existentially sad about the state of computing. :( (And like, I want to be clear: normally, I just don't care that much?... I went into my past HN comments to find the link to that journald issue, and it seems like meekly asking after that specific bug is the only time I've ever even commented about systemd... I've always just figured it's yet another annoying change that maybe I'll have to get used to, from the ever-increasing essential complexity people like to foist on us every year; but then I see your comment here, and it is just SO SAD to see that it seems like you don't even consider it a depressing tradeoff but seem to actually WANT IT and I'm just like "ugh".)

deleted 4y ago

[deleted]

thaumaturgy 4y ago

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?

saurik 4y ago

> Well you have to start fiddling with iptables and descend into that level of hell wherein you are fundamentally fiddling with stuff you do not want to fiddle with, and beside that solution is going to be system wide. This is just a really strange and depressing-to-hear stance, as you seem to simultaneously be claiming that it is worthwhile to read the documentation for systemd to learn about all of its one-off solutions but somehow NOT worthwhile to read the documentation for the actual Linux IP stack? > systemd is chock full of super awesome stuff like this if you read the docs you'll find simple solutions to challenging problems everywhere. Honestly, this just sounds horrible... this sounds like a project that has a million tiny one-off "simple solutions" to individual "challenging problems" instead of providing a generic tool that can be integrated with other generic tools to solve arbitrary problems in infinite combinations. > systemd is a beautiful, integrated work of art, and there's constant payoffs and benefits from the fact that it encompasses so much functionality previously split across a huge range of inconsistent small solutions to the various problems systemd solves. And so like, here is just where I guess there's a philosophy problem at play: those "inconsistent" solutions were just combinations of separate components. To me, that's beautiful... and it's beautiful, in no small part, because it was NOT "integrated", and was instead extensible and transparent. > If Linux had started off with systemd and someone came along and said "better idea, lets tear systemd apart into a wide range of tiny applications all with different approaches, syntaxes, maintainers and functionality, with no overarching architecural approach and call it sysV", everyone would say "what a crazy idea, no thanks." Really? You seriously don't see any benefit to taking a monolithic framework and breaking it apart into a ton of libraries? Yes: there are people out there who like the large monolithic opinionated frameworks... but there are also a lot of people who prefer having a toolkit of libraries. In particular, when we see this debate show up in other places, a big benefit of the "lots of libraries" approach is that it is an inclusive and extensible way of approaching a complex problem, where if you have an idea that you think makes the world better you can just work on that part. And so when someone is working on new network addressing or new ways of doing hypervisor-assisted sandboxing or new ways of managing user accounts, some of us would like to think that the mechanism for "run a bunch of stuff when the system boots" doesn't have to understand any of that. When you have a single program that has decided to form a giant knot in the space of solutions--where to solve anything you feel like you can't just add another library but you have to go modify the big central framework--you stifle a lot of participation and narrow the set of options. And that's where I feel like you are just going to say "that's great! I don't like options! I'd prefer someone else not only solve my problems but tell me what my problems are in the first place" and again: that's where this becomes a big philosophical argument instead of a technical one. So like, do I have technical issues with systemd? I mean, yes: I'm sick of being burned by this "journald" issue--one which has been open over a decade now and will probably never get fixed--because as far as I'm concerned if you build a logging system and you routinely lose log messages you probably aren't qualified to develop a logging system. https://github.com/systemd/systemd/issues/2913 https://github.com/systemd/systemd/issues/2913 https://bugs.freedesktop.org/show_bug.cgi?id=50184 https://bugs.freedesktop.org/show_bug.cgi?id=50184 But, at the end of the day, the reason that systemd makes me sad is because when I started doing system administration the entire community was firmly in the "we should strive to have a lot of separate tools that can be composed in fun ways" camp, and now it seems like the reins have been taken by the "you shouldn't know or care how things are put together: let me solve it for you" camp, and that makes me nigh-unto existentially sad about the state of computing. :( (And like, I want to be clear: normally, I just don't care that much?... I went into my past HN comments to find the link to that journald issue, and it seems like meekly asking after that specific bug is the only time I've ever even commented about systemd... I've always just figured it's yet another annoying change that maybe I'll have to get used to, from the ever-increasing essential complexity people like to foist on us every year; but then I see your comment here, and it is just SO SAD to see that it seems like you don't even consider it a depressing tradeoff but seem to actually WANT IT and I'm just like "ugh".)