Add support for rootless Podman

[ghost]

Description

There is an Nix module called virtualisation.oci-containers allowing creating OCI (Podman, Docker, …) containers on NixOS. Podman does support rootless containers, but home-manager has no module for declarative configuring containers like the virtualisation.oci-containers allows.

Consider adding such feature as not all software has its nix derivation.

[rycee]

Yeah, I've thought about this and would like podman support. But haven't had time to look into it and it is unlikely that I'll find time going forward. If anybody would like to work on it then I would definitely be interested and willing to assist to some degree.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[n-hass]

Bump. Nixpkgs maintainers have said they will not implement rootless containers as user services as it should be left to home manager.

I would be very willing to implement this, but I would appreciate a chat with maintainers to get some input and guidance first as I don’t think this is a trivial task.

[n-hass]

I have something which gives you an interface to describe your container in home-manager -> gets parsed as a podman quadlet file (which is actually very close to an ideal declarative interface) -> gets built by the bundled podman-systemd user generator because, well, why reinvent the wheel -> links systemd units into user's ~/.config/systemd/user directory.

I'll open a PR soon.

[bamhm182]

I've been using NixOS and rootless podman in a hacked together fashion for about a year. That has finally come to bite me due to nixos-rebuild using systemd-run within 23.11. I found your comments when trying to resolve my issues and slowly coming to the realization that what I'm trying to do would be better handled in home-manager.

I don't have any experience with home-manager aside from throwing together some configs for my user, but if there's any way I can assist you, I'd be happy to. I looked for the work you've completed already, but was unable to find it. 

[n-hass]

Hi, I’ve just forked and have a branch. It’s available here. PR #4801

My aim was to mimic the oci-containers.containers interface from NixOS. So there are two option trees provided, services.podman.networks and services.podman.containers.

Here is example usage:

    services.podman.networks = {
      caddy_routing = {
        driver = "bridge";
        subnet = "172.21.1.0/24";
      };
    };

    services.podman.containers.caddy = {
      image = "ghcr.io/n-hass/caddy-cloudflare:latest";
      description = "Caddy web server";
      environmentFile = "${homeDir}/caddy/.env";
      networks = [ "caddy_routing" ];
      networkAlias = "caddy";
      ports = [
        “8080:80"
        “8443:443"
      ];
      volumes = [
        "${homeDir}/caddy/Caddyfile:/etc/caddy/Caddyfile:ro"
        "${homeDir}/caddy/config:/etc/caddy/config"
        "${homeDir}/caddy/data:/data"
        "${homeDir}/caddy/static:/static"
        "/etc/timezone:/etc/timezone:ro"
        "/etc/localtime:/etc/localtime:ro"
      ];
      autoupdate = "registry";
      addCapabilities = [ "NET_RAW" ];
    };

    services.podman.containers.vaultwarden = {
      image = "docker.io/vaultwarden/server:latest";
      description = "Vaultwarden server";
      environmentFile = "${homeDir}/vw/.env";
      networks = [ "caddy_routing" ];
      networkAlias = "vaultwarden";
      volumes = [
        "${homeDir}/vw/data:/data:rw"
        "/etc/timezone:/etc/timezone:ro"
        "/etc/localtime:/etc/localtime:ro"
      ];
      autoupdate = "registry";
      service.timeoutStopSec = 60;
    };

there’s also a third service, services.podman.auto-update, which only has one bool option: enable. It’s just the standard podman auto-update user service.

I wrote this before realising that I should contribute this, and hence also before reading contributing guidelines… I’ll have the draft PR open soon, but I suspect the interface to this module may change. It provides many options which is not in the spirit of the “minimise provided options” guidelines :)

I also wonder if this work is in the shadow of this ongoing PR. It’s a darwin+linux approach which is nice and I am sure is better pieced together than my code, but frankly I prefer the method of using Podman’s already built, already compliant systemd generator. It keeps a cap on the scope of this module as the Podman Quadlet interface is already very close to what you would be writing in a Nix configuration, and it adds a user-friendly layer of validation as the generator errors will be displayed to stdout when doing a home-manager or nixos rebuild.

[bamhm182]

Thanks for sharing! It does say that you should minimize provided options, but at the same time, it isn't like you've got extraneous options for no reason, they're all options that you'd configure normally with podman. I'll also say that I'm new to podman from docker, so I simply brought compose over and kept on going how I was. The quadlet idea is pretty neat and something I'll have to look into more, however, in the interest of increasing darwin compatibility, it does seem like it may be a bit better to shy away from the systemd-focused approach into something that would work on either.

I somehow missed that PR. It looks like they've made some pretty good headway on it, but it has been stagnant for 3 months.

[n-hass]

My thoughts exactly - that PR seems to have gone (or going) stagnant and I really wanted something working for Linux so just built it. I’m new to Nix as well as NixOS and home-manager, but here to stay now :)

I doubt doing away with the quadlet method altogether would be necessary for Darwin compatibility though. Running podman on a Darwin system requires a Linux virtual machine anyway. It might be too much jank to be acceptable, I don’t know, but I will admit my personal prioirty has been Linux support and so would appreciate help on the Darwin side of things if it’s not okay to just lock this behind a Linux platform assertion.

[fursman]

You guys are awesome. I was running up against this exact same problem this week, and now this weekend your exchange was extremely clarifying. Thanks for all your hard work.

[bamhm182]

That's a fair point. I would rather have something than nothing, and Darwin probably isn't the priority for a majority of the people. If someone decides they do want it, they should be able to get it working on top of what you've built.

@fursman, I had to do a lot of digging, but my issue was that users.users.name.linger was added, which broke old ways of lingering. Might be worth checking out as a stopgap until this gets added.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.