5 ms·

Make sure to do systemctl edit foo.service The reason for this is that it creates an override file rather than edits the systemd file directly. This means y

Make sure to do systemctl edit foo.service The reason for this is that it creates an override file rather than edits the systemd file directly. This means you'll keep your changes even if the systemd file changes in an upgrade. Obviously also helps you roll back and make sure you got things right. Another side benefit is that you can place these on github. Also, pretty much every service should use `PrivateTmp=yes` and this is surprisingly uncommon. Then run systemd-analyze security foo.service It'll give you a nice little rundown of what is restricted and what isn't. There's a short description of what each of the capabilities are, but I also like this gist[0]. The docs kinda suck (across systemd) but play around and it starts to make sense. This stuff is surprisingly quite powerful and it's caused me to go on a systemd binge for the last year. You can restrict access to basically anything, effectively giving you near container like restrictions. You can restrict paths (and permissions to those paths), executables, what conditions will cause the service to start/stop, how much CPU and memory usage a service can grab, and all sorts of things. That last one can be really helpful when you have a service that is being too greedy, giving you effectively an extremely lightweight container. If you want to go further, then look into systemd-nspawn and systemd-vmspawn. This will give you a "chroot on steroids" (lightweight container, which can be used in place of things like docker) and a full fledged VM, respectively. Both of these have two complementary commands: machinectl and importctl. `machinectl` will allow you to make these things act just like services, even allowing you to define conditions in which they can autoactivate. `importctl` gives you the ability to download, import, and export these machines as images. You can use importctl to get an image from an arbitrary url, so if a project decided to provide this in addition to (or as a replacement to) a docker image, you could have a pretty similar streamlined process. I'm no expert, but I've not run across a case where you can't use systemd as a full on replacement for docker. While it's more annoying to make these images I've found that I can get better control over them and feel a lot less like I'm fighting the system. A big advantage too is that these can run with fewer resources than docker, but this really depends on tuning. The more locked down the slower it will be, so this is only a "can" not "will" (IIRC defaults on vmspawn are slower[1]) Finally, note that all these have a `--user` flag, so you don't always need to use sudo. That itself gives a big advantage because you're automatically limiting capabilities by running it as a user service. No more fucking around with groups and all that. Honestly, the biggest downside of systemd is the lack of documentation and the lack of wider adoption and examples to pull from. But that's a solvable problem and the exact kinda thing HN can help solve (this comment is even doing some of that as well as some others in this thread). Systemd is far from perfect and there's without a doubt a good learning curve (i.e. lack of docs), but IME it's been worth the effort. [0] https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db04 https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db... [1] https://github.com/systemd/systemd/issues/18370 https://github.com/systemd/systemd/issues/18370

wtallis 1y ago
> systemctl edit foo.service That seems like an unnecessary foot-gun. Needing a special command to safely edit what appears to be an ordinary config file indicates some other part of the system is trying to be too clever. In this case, I think it's a combination of filling /etc with symlinks to stuff in /usr, and package managers casually overwriting stuff in /usr without the careful handling that stuff in /etc deserves.
- godelski 1y ago
  You can always edit the service directly. There's nothing stopping you from doing that, and most people probably do it this way. Doing that would make it just like any other application with a config file. BUT have you ever had configs overwritten by an update? Have you ever found an update to break your config? These are really quite annoying problems to deal with. Having the override file basically means you can keep the maintainer's config as your "gold standard" and then edit it without worrying of fucking things up. This is the difference to me: systemctl edit: It is clearly defined what you changed. Your changes will not be overwritten by an update. directly editing config: File may change with update. You won't be notified of said change. If you didn't write down what you're changes were, you need to redo that work and figure it out all over again. The pros outweigh the cons IMO. I had to get myself into the habit of doing `systemctl edit foo` instead of `sudo vim /etc/systemd/system/foo.service`, but that's provided more benefits than the annoyance of building this habit.
  - wtallis 1y ago
    I think you missed the point entirely. I'm not complaining at all that there's a way to make override files. I'm pointing out that the need for making override files (even with the affordance of a special command to handle editing them) is itself a symptom of a bad system design and a deeper problem that deserves a broader solution than what systemd offers. I run gentoo on most of my linux machines. I don't have a problem with files in /etc being silently overwritten by the package manager. Gentoo's solution isn't perfect, but at least it gets at the heart of the real problem. I think perhaps systemd should use its clout to demand a sane solution to this problem, instead of just developing their own workaround that requires users to learn another unnecessary custom way to edit a plain text file.

wtallis 1y ago

> systemctl edit foo.service That seems like an unnecessary foot-gun. Needing a special command to safely edit what appears to be an ordinary config file indicates some other part of the system is trying to be too clever. In this case, I think it's a combination of filling /etc with symlinks to stuff in /usr, and package managers casually overwriting stuff in /usr without the careful handling that stuff in /etc deserves.

godelski 1y ago
You can always edit the service directly. There's nothing stopping you from doing that, and most people probably do it this way. Doing that would make it just like any other application with a config file. BUT have you ever had configs overwritten by an update? Have you ever found an update to break your config? These are really quite annoying problems to deal with. Having the override file basically means you can keep the maintainer's config as your "gold standard" and then edit it without worrying of fucking things up. This is the difference to me: systemctl edit: It is clearly defined what you changed. Your changes will not be overwritten by an update. directly editing config: File may change with update. You won't be notified of said change. If you didn't write down what you're changes were, you need to redo that work and figure it out all over again. The pros outweigh the cons IMO. I had to get myself into the habit of doing `systemctl edit foo` instead of `sudo vim /etc/systemd/system/foo.service`, but that's provided more benefits than the annoyance of building this habit.
- wtallis 1y ago
  I think you missed the point entirely. I'm not complaining at all that there's a way to make override files. I'm pointing out that the need for making override files (even with the affordance of a special command to handle editing them) is itself a symptom of a bad system design and a deeper problem that deserves a broader solution than what systemd offers. I run gentoo on most of my linux machines. I don't have a problem with files in /etc being silently overwritten by the package manager. Gentoo's solution isn't perfect, but at least it gets at the heart of the real problem. I think perhaps systemd should use its clout to demand a sane solution to this problem, instead of just developing their own workaround that requires users to learn another unnecessary custom way to edit a plain text file.