There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

Rootless podman adguard home failing [SEMI-SOLVED]

[Semi-solved edit]: To answer my question, I was not able to figure out podman. There’s just too little community explanations about it for me to pull myself up by my own bootstraps.

So I went for Incus, which has a lot of community explanations (also via searching LXD) and made an Incus container with a macvlan and put the adguard home docker in that. Ran the docker as “root” and used docker compose since I can rely on the docker community directly, but the Incus container is not root-privileged so my goal of avoiding rootful is solved.

Anyone finding this via search, the magic sauce I needed to achieve a technically rootless adguardhome docker setup was:


<span style="color:#323232;">sudo incus create gooner # For networking, it doesn't need to be named gooner
</span><span style="color:#323232;">sudo incus profile device add gooner eth0 nic nictype=macvlan parent=enp0s10 # Get your version of 'enp0s10' via 'ip addr', macvlan thing won't work with wifi
</span><span style="color:#323232;">sudo incus profile set gooner security.nesting=true
</span><span style="color:#323232;">sudo incus profile set gooner security.syscalls.intercept.mknod=true
</span><span style="color:#323232;">sudo incus profile set gooner security.syscalls.intercept.setxattr=true
</span><span style="color:#323232;"># Pause here and make adguardhome instance in the Incus web UI (incus-ui-canonical) with the "gooner" profile
</span><span style="color:#323232;"># Make sure all network stuff from docker-compose.yml is deleted
</span><span style="color:#323232;"># Put docker-compose.yml in /home/${USER}/server/admin/compose/adguardhome
</span><span style="color:#323232;">printf "uid $(id -u) 0ngid $(id -g) 0" | sudo incus config set adguardhome raw.idmap - # user id -> 0 (root), user group id -> 0 (root) since debian cloud default user is root
</span><span style="color:#323232;">sudo incus config device add adguardhome config disk source=/home/${USER}/server/admin/config/adguardhome path=/server/admin/config/adguardhome # These link adguard stuff to the real drive
</span><span style="color:#323232;">sudo incus config device add adguardhome compose disk source=/home/${USER}/server/admin/compose/adguardhome path=/server/admin/compose/adguardhome
</span><span style="color:#323232;"># !! note that the adguardhome docker-compose.yml must say "/server/configs/adguardhome/work" instead of "/home/${USER}/server/configs/adguardhome/work"
</span><span style="color:#323232;"># Install docker
</span><span style="color:#323232;">sudo incus exec adguardhome -- bash -c "sudo apt install -y ca-certificates curl"
</span><span style="color:#323232;">sudo incus exec adguardhome -- bash -c "sudo install -m 0755 -d /etc/apt/keyrings"
</span><span style="color:#323232;">sudo incus exec adguardhome -- bash -c "sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc"
</span><span style="color:#323232;">sudo incus exec adguardhome -- bash -c "sudo chmod a+r /etc/apt/keyrings/docker.asc"
</span><span style="color:#323232;">sudo incus exec adguardhome -- bash -c 'echo 
</span><span style="color:#323232;">  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian 
</span><span style="color:#323232;">  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | 
</span><span style="color:#323232;">  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null'
</span><span style="color:#323232;">sudo incus exec adguardhome -- bash -c "sudo apt update"
</span><span style="color:#323232;">sudo incus exec adguardhome -- bash -c "sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin"
</span><span style="color:#323232;"># Disable port 53 binding
</span><span style="color:#323232;">sudo incus exec adguardhome -- bash -c "[ -d /etc/systemd/resolved.conf.d ] || mkdir -p /etc/systemd/resolved.conf.d"
</span><span style="color:#323232;">sudo incus exec adguardhome -- bash -c "printf "%sn%sn" '[Resolve]' 'DNSStubListener=no' | sudo tee /etc/systemd/resolved.conf.d/10-make-dns-work.conf"
</span><span style="color:#323232;">sudo incus exec adguardhome -- bash -c "sudo systemctl restart systemd-resolved"
</span><span style="color:#323232;"># Run the docker
</span><span style="color:#323232;">sudo incus exec adguardhome -- bash -c "docker compose -f /server/admin/compose/adguardhome/docker-compose.yml up -d"
</span>

I’m trying to get rootless podman to run adguard home on Debian 12. I run the docker-compose.yml file via podman-compose up -d.

I get errors that I cannot google successfully, sadly. I do occasionally see shards of people saying things like “I have adguard running with rootless podman” but never any guides. So tantalizing.

I have applied this change so rootless can yoink port 53:

sudo nano /etc/sysctl.conf

net.ipv4.ip_unprivileged_port_start=53 # at end, required for rootless podman to be able to do 53

(Do I even need that change with a macvlan?)

The sticking point seems to be the macvlan. I want a macvlan so I can host a PiHole as a redundant fallback on the same server. I error with:

Error: netavark: Netlink error: No such device (os error 19) and that error really gets me no where searching for it. I am berry sure the ethernet connection is named enp0s10 and spelled right in the docker-compose file, cause I copied and pasted it in.

I tried forcing the backend to “CNI” but probably did it wrong, it complained about:


<span style="color:#323232;">WARN[0000] Failed to load cached network config: network dockervlan not found in CNI cache, falling back to loading network dockervlan from disk
</span><span style="color:#323232;">WARN[0000] 1 error occurred:
</span><span style="color:#323232;">        * plugin type="macvlan" failed (delete): cni plugin macvlan failed: Link not found
</span>

(I also made a /etc/cni/net.d/90-dockervlan.conflist file for cni but it didn’t seem to see it and I couldn’t muster how to get it to see it)

Both still occur if I pre-make the dockervlan with:

podman network create -d macvlan -o parent=enp0s10 --subnet 10.69.69.0/24 --gateway 10.69.69.1 --ip-range 10.69.69.69/32 dockervlan

And adjust the compose file’s networks: call to:


<span style="color:#323232;">networks:
</span><span style="color:#323232;">    dockervlan:
</span><span style="color:#323232;">        external: true
</span><span style="color:#323232;">        name: dockervlan
</span>

Has anyone succeeded at this or done something similar?

docker-compose.yml:


<span style="color:#323232;">version: '3.9'
</span><span style="color:#323232;"># --- NETWORKS ---
</span><span style="color:#323232;">networks:
</span><span style="color:#323232;">    dockervlan:
</span><span style="color:#323232;">        name: dockervlan
</span><span style="color:#323232;">        driver: macvlan
</span><span style="color:#323232;">        driver_opts:
</span><span style="color:#323232;">            parent: enp0s10
</span><span style="color:#323232;">        ipam:
</span><span style="color:#323232;">            config:
</span><span style="color:#323232;">              - type: "host-local"
</span><span style="color:#323232;">              - dst: "0.0.0.0/0"
</span><span style="color:#323232;">              - subnet: "10.69.69.0/24"
</span><span style="color:#323232;">                rangeStart: "10.69.69.69/32" # This range should include the ipv4_address: in services:
</span><span style="color:#323232;">                rangeEnd: "10.69.69.79/32"
</span><span style="color:#323232;">                gateway: "10.69.69.1"
</span><span style="color:#323232;"># --- SERVICES ---
</span><span style="color:#323232;">services:
</span><span style="color:#323232;">    adguardhome:
</span><span style="color:#323232;">        container_name: adguardhome
</span><span style="color:#323232;">        image: docker.io/adguard/adguardhome
</span><span style="color:#323232;">        hostname: adguardhome
</span><span style="color:#323232;">        restart: unless-stopped
</span><span style="color:#323232;">        networks:
</span><span style="color:#323232;">            dockervlan:
</span><span style="color:#323232;">                ipv4_address: 10.69.69.69# IP address inside the defined dockervlan range
</span><span style="color:#323232;">        volumes:
</span><span style="color:#323232;">            - '/home/${USER}/server/configs/adguardhome/work:/opt/adguardhome/work'
</span><span style="color:#323232;">            - '/home/${USER}/server/configs/adguardhome/conf:/opt/adguardhome/conf'
</span><span style="color:#323232;">            #- '/home/${USER}/server/certs/example.com:/certs # optional: if you have your own SSL certs
</span><span style="color:#323232;">        ports:
</span><span style="color:#323232;">            - '53:53/tcp'
</span><span style="color:#323232;">            - '53:53/udp'
</span><span style="color:#323232;">            - '80:80/tcp'
</span><span style="color:#323232;">            - '443:443/tcp'
</span><span style="color:#323232;">            - '443:443/udp'
</span><span style="color:#323232;">            - '3000:3000/tcp'
</span>

podman 4.3.1

podman-compose 1.0.6

Getting a newer podman-compose is pretty easy peasy, idk about newer podman if that’s needed to fix this.

markstos ,

You can get similar security in rootful mode, by making sure within the container the adguard binary is not running as root.

glizzyguzzler OP ,
@glizzyguzzler@lemmy.blahaj.zone avatar

I see, I’ll check that out and also check out how to ascertain that lol

Does that “similar security” still count if the image is hacked? Since the capability for “real” root is there.

markstos ,

In both cases of rootless and rootful-with-non-root process your process is running as a non-root user with respect to the host.

To break out the container will require two steps. First, adguard itself must be exploited. A second exploit is then required elevate privileges from the adguard user to root.

If your attacker successfully gets that far, then having a rootless container would matter, because in a rootful container, root in the container equals root on the host. In a rootless container, “root” only gives you the abilities of the user running the rootless container.

But as you’ve found, rootless containers can be a pain.

Making sure your container is running as non-root user in a rootful container is better than giving up.

glizzyguzzler OP ,
@glizzyguzzler@lemmy.blahaj.zone avatar

Thank you for the in-depth explanation!! I’ll keep this in mind as I try to club my way through podman!

kylian0087 ,

Ports below 1000 or something are reserved for root by default.

glizzyguzzler OP ,
@glizzyguzzler@lemmy.blahaj.zone avatar

I’ve made it so the host OS doesn’t require root, are you saying I’d need to make the image also do that?

kylian0087 ,

Shouldn’t be necessary. What you can try is run it with sudo just to see if it works then.

k_rol ,

Ive started using podman too but I am not comfortable with it yet. So just an idea, could you use a higher port number on the pod then use iptable to redirect from port 53 to the new port #?

serverfault.com/…/how-to-do-port-forwarding-redir…

glizzyguzzler OP ,
@glizzyguzzler@lemmy.blahaj.zone avatar

Love the idea, but theoretically with this “macvlan” it will have its own IP address and thus have free reign of all of its ports and not have any conflicts

coffee_chum ,

That’s… not how that works. Just because they’re getting separate IP addresses doesn’t mean you can all of the sudden have “full control” and start using privileged ports without granting that sys capability to docker. I fear you are overcomplicating what should be a fairly straightforward process and likely weakening security because you don’t fully grok the implications of the security measures you’re attempting to put in place. Just use traefik or caddy and be done with it.

glizzyguzzler OP , (edited )
@glizzyguzzler@lemmy.blahaj.zone avatar

Yea I likely don’t have a full understanding, just getting into this and all. That’s why I decided a hard req was to force the images to run in a non-root context. (I did succeed, prolly)

But the macvlan does have its own IP with the associated ports free and that will let the adguard home image bind 53 while the host can squat on it with dns listener stub or whatever the fuck it does by default. The macvlans is a recommended thing by the Docker adguard home guides to bypass the host or other processes already binding 53, I didn’t cook it up myself.

Anyway, this is the first I’m hearing of traffic or caddy in this context - googling those is not ez pz so it’ll take me a bit to know what you’re implying I should do!

Edit: I’m not gonna understand traffic or caddy beyond the surface level, the main pages are enterprise-focused so I’m not sure how they apply. I’ll have to wait to run into an organic use case (with wordy guide) to truly understand them, I think. (Other than traffic could redirect but it’s called a reverse proxy but I think, at least in this context, that’s a fancy word for redirect. So use it somehow instead of forwarding specific ports?)

oakcroissant ,

I thought macvlans were only available to rootful Podman?

glizzyguzzler OP ,
@glizzyguzzler@lemmy.blahaj.zone avatar

Huh you’d think macvlans would have an error telling me to kick rocks for trying to use it in a rootless state. I guess that’s why it can’t see anything?

Weird though, like why can’t I make the macvlans network interface as root and then let rootless containers connect to it? If I sudo make the macvlans network thing it lives in the sudo podman zone. Hm

somethingsomethingidk ,

Have you tried taking the metwork config out of the compose file and just letting podman handle it?

glizzyguzzler OP ,
@glizzyguzzler@lemmy.blahaj.zone avatar

I have tried pre-making the network in podman directly beforehand, but because I want a second docker image binding to port 53 I was under the impression that I had to use macvlans

  • All
  • Subscribed
  • Moderated
  • Favorites
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines