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

[1] https://github.com/systemd/systemd/issues/18370

▲ wtallis 5 hours ago | parent [-]

> 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 4 hours ago | parent | next [-]

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 4 hours ago | parent [-]

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.

▲ godelski 24 minutes ago | parent | next [-]

  > 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

  >> You can always edit the service directly. There's nothing stopping you from doing that, and most people probably do it this way.

I'm lost. You're complaining that you'd be happy if you could do the thing I said you could do in my opening sentence as well as my closing? Sorry, but I think it is you who have

  > I think you missed the point entirely.

▲ ac29 2 hours ago | parent | prev [-]

> just developing their own workaround that requires users to learn another unnecessary custom way to edit a plain text file.

There's no need to use systemctl edit to make or edit an override file, its just a convenience shortcut

▲

wtallis an hour ago | parent [-]

> There's no need to use systemctl edit to make or edit an override file, its just a convenience shortcut

Do you think anyone who's reached this point in the thread has missed out on that? Yes, obviously those steps can be done manually. But that's not what's being recommended here, and it's more steps to learn and remember, and it doesn't really matter whether accomplishing this task requires one extra command or several when it either shouldn't need to be done at all, or should work the same for any config file that needs to be protected, not just systemd service definitions.

It's almost like one of the systemd developers looked at visudo and forgot that sudo should probably never be used as an example of the right way to do things.

	▲	godelski 18 minutes ago \| parent [-]
		Are you okay dude? I'm serious. This is obviously not about systemd, so what's up?

▲ em-bee an hour ago | parent | prev [-]

haven't debian and other systems been doing that long before systemd? i mean system config files that are controlled by the package manager and not supposed to be edited, but overridden by other files which are to be edited?

	▲	godelski 22 minutes ago \| parent [-]
		Yes. All systemctl edit does is provide a shortcut. It calls your $EDITOR variable (as you'd expect).