One thing the author probably hasn’t done yet or just doesn’t mention is that you can configure .container services with systemd-podman units (often called quadlets), e.g. a simple MariaDB container would look like this:
This is superb, because it means your containers finally feel well-integrated with the rest of the OS and you can use systemctl, journalctl, etc. just like you would with other services.
Personally, I use this as an alternative to Podman/Docker compose and have been very happy with it running rootless containers from Nextcloud, Pufferpanel, Forgejo, Authentik, etc. (ask me for .container files if you need any help, I’m currently working on a small repo with a collection)
Excuse me, peasant crontab enjoyer here, but what?! I could write a (mostly) declarative system without having to learn Nix?! I should probably be learning systemd anyway, it’s looking more and more like the present, let alone the future.
I run a bunch of remote reverse proxies that are functionally identical, but for having a different Cloudflare key and calling for a different static IP
Could I write the entire config to a self hosted Git > pull that repo > change those two variables and have a running machine?
Remote updates have been kicking my ass, I either can’t wrap my head around Screen or it isn’t fit for my need. Being able to pull the new config from Git over Tailscale and then run it would be game changing for me.
Most compiled output of NixOS configuration (besides packages, perhaps) is just systemd units anyway. I found out quickly when learning nix that my lack of systemd prowess was going to cap how well I could understand NixOS.
Your distrust is kind of reasonable: I’ve been using this a lot for the past year and there definitely were two or three moments where it was a bit annoying, too little transparent on what commands will be run, etc.
You can if you want to. But I don’t think that is best practice. The idea of quadlets is the bring Linux norms to containers. You contain and manage all permissions for that container in that user.
I personally have completely separated users and selinux mls contexts for each container group (formerly docker compose file) and I manage them thusly. It’s more annoying but it substantially more secure.
This being said I think you can do it as root. I think this might work but I am not certain sudo systemctl --user -M theuser@ status myunit.service
One thing the author probably hasn’t done yet or just doesn’t mention is that you can configure
.containerservices with systemd-podman units (often called quadlets), e.g. a simple MariaDB container would look like this:[Unit] Description=MariaDB container [Container] Image=docker.io/mariadb:latest Environment=MYSQL_ROOT_PASSWORD=rootpassword Environment=MYSQL_USER=testuser Environment=MYSQL_PASSWORD=testpassword Environment=MYSQL_DATABASE=testdb [Install] WantedBy=multi-user.targetShort intro Full reference
This is superb, because it means your containers finally feel well-integrated with the rest of the OS and you can use systemctl, journalctl, etc. just like you would with other services.
Personally, I use this as an alternative to Podman/Docker compose and have been very happy with it running rootless containers from Nextcloud, Pufferpanel, Forgejo, Authentik, etc. (ask me for .container files if you need any help, I’m currently working on a small repo with a collection)
Excuse me, peasant crontab enjoyer here, but what?! I could write a (mostly) declarative system without having to learn Nix?! I should probably be learning systemd anyway, it’s looking more and more like the present, let alone the future.
I run a bunch of remote reverse proxies that are functionally identical, but for having a different Cloudflare key and calling for a different static IP
Could I write the entire config to a self hosted Git > pull that repo > change those two variables and have a running machine?
Remote updates have been kicking my ass, I either can’t wrap my head around Screen or it isn’t fit for my need. Being able to pull the new config from Git over Tailscale and then run it would be game changing for me.
Most compiled output of NixOS configuration (besides packages, perhaps) is just systemd units anyway. I found out quickly when learning nix that my lack of systemd prowess was going to cap how well I could understand NixOS.
If you need a half step on your journey, convert your crontab to systemd timers first.
In fact, I do need a half step. Legend, thank you.
awesome!
TIL. That’s pretty useful!
That’s neat! There’s so many advanced features of systemd I swear I learn something new every time it comes up.
This is due to systems generators allowing Podman to plug in to that system
That idea feels very useful but I also distrust it and it makes me angry for reasons I can’t articulate.
Do the reasons include gate keeping?
Your distrust is kind of reasonable: I’ve been using this a lot for the past year and there definitely were two or three moments where it was a bit annoying, too little transparent on what commands will be run, etc.
It’s amazing, the gitea container supports this. Autostarts on machine restart, etc.
Yeah, it’s great that Gitea/Forgejo has a copy-paste snippet in the docs, but you can actually use that with pretty much every container.
There is this useful tool to convert containers, podman commands or even compose files to podman-systemd units: https://github.com/containers/podlet
I like this, but even though pod man runs perfect rootless, quadlets can only run as root for now :-(
Not true. I run them rootless on my server as we speak. :)
How do you do that? Please link a description. This has been a major stumbling block for me
Are you placing your service files in
~/.config/containers/systemdof the home dir of the user you want them to run as?Here is a link: https://linuxconfig.org/how-to-run-podman-containers-under-systemd-with-quadlet
Yeah, that works, but it means the services cannot be managed by systemctl as root anymore. Or am I missing something?
You can if you want to. But I don’t think that is best practice. The idea of quadlets is the bring Linux norms to containers. You contain and manage all permissions for that container in that user.
I personally have completely separated users and selinux mls contexts for each container group (formerly docker compose file) and I manage them thusly. It’s more annoying but it substantially more secure.
This being said I think you can do it as root. I think this might work but I am not certain
sudo systemctl --user -M theuser@ status myunit.serviceSame here; Rootless Podman Quadlets gang unite (there is two of us in total)
Make that 3!
Just place your Quadlets in the $HOME/.config/containers/systemd/ directory for this ;)
The reference I linked to earlier also contains more information on rootless.
While that is true, that is not how I would run services normally with SystemD. Those would be defined globally, but run as a user.
Definitiv then in the user home, means that I dint see them with
systemctlwhich is very annoying.