

It’s common with rootless docker/podman. Something needs to start up the services, and you’re not using a root enabled docker/podman socket, so systemd it is.
It’s common with rootless docker/podman. Something needs to start up the services, and you’re not using a root enabled docker/podman socket, so systemd it is.
Sounds like I won’t be using Vanilla because that (obsidian + synching + tailscale) is definitely my primary need.
The last time I played with it, I just remember thinking, cool - but why?
That’s what I was thinking, I know the pain of watching something run for ages, only to finally get past where it failed last time and run straight in to another stumbling block.
I don’t envy you having to work in an SELinux environment with less than stellar developer understanding of policies and contexts.
Is it not possible to run it in audit mode in dev and have it tell you what the would have blocked?
Username checks out
Sounds like you have reason to bump it up the list now - two birds with one stone.
I need to do this too. I know I have stuff deployed that has plaintext secrets in .env or even the compose. I’ll never get time to audit everything. So the more I make the baseline deployment safe, the better.