pihole + unbound in Portainer auf Raspberry Pi (RasPiOS bookworm)

Stationary

Well-known member
Kann mir eventuell jemand weiterhelfen? Bisher laufen pihole und unbound bei mir als direkte Installation of RasPiOS (bullseye, bzw. bookworm; wie in der Forumsanleitung beschrieben).
Nun versuche ich seit einigen Tagen, sowohl pihole als auch unbound mittles Portainer als Dockercontainer laufen zu lassen. Pihole allein habe ich auch bereits einmal so zum laufen bekommen, daß es die Anfragen aus meinem Netzwerk annimmt und die erlaubten Webseiten aufgerufen werden.
Was ich bisher nicht hinbekommen habe, ist, die Anfragen von pihole an unbound, das in einem weiteren Container liegt, weiterzureichen. Auf der Pihole-Oberfläche sehe ich die eingehenden Anfragen, die Statusmeldung, daß die Anfrage an den unbound-Container weitergricht wurde, es komt aber keine Antwort zurück und ich kann keine Webseiten öffnen.
Hat jemand eine Idee, was ich bei meinem Stack falsch gemacht habe? Oder hat jemand einen funktionsfähigen Stack für pihole und unbound basierend auf zwei getrennten Containern, den er mir überlassen könnte?

Code:
version: '1.0'
services:
  pihole:
    container_name: pihole-stack
    image: pihole/pihole:latest
    hostname: pihole-portainer.local
    depends_on:
      - unbound
    restart: unless-stopped
    ports:
      - "8093:80/tcp" # web ui -> http://<IP-Pi5>:8093/admin/
      - "443:443/tcp"
      - "53:53/tcp"
      - "53:53/udp"
# portainer volumes to be mapped
    volumes:
      - "/var/lib/docker/volumes/pi-hole/_data:/etc/pihole/"
      - "/var/lib/docker/volumes/pi-hole/dnsmasq.d:/etc/dnsmasq.d/"
    environment:
      WEBPASSWORD: <password here>
      FTLCONF_LOCAL_IPV4: 192.168.143.100 # <IP-Pi5> = address of RasPi5
      TZ: Europe/Berlin
      PIHOLE_DNS_: 172.168.133.3#5335 # forward request to unbound
      DNSSEC: true
      WEBTHEME: default-dark
    networks:
      pihole_dns_network:
        ipv4_address: 172.168.133.2 # address in pihole_dns_network
  unbound:
    container_name: unbound-stack
    image: mvance/unbound-rpi:latest
    hostname: unbound-portainer.local
    restart: unless-stopped
    networks:
      pihole_dns_network:
        ipv4_address: 172.168.133.3 # address to be used by pihole as upstream DNS

networks:
  # Custom subnet for pihole, unbound upstream DNS on port 53
  pihole_dns_network:
    name: "pihole_dns_network"
    ipam:
      driver: default
      config:
        - subnet: 172.168.133.0/24
          gateway: 172.168.133.1
          ip_range: 172.168.133.0/24

Time Type Domain Client Status Reply
2024-05-25 19:40:05Agateway.icloud.comiPad.fritz.boxOK (sent to unbound-stack.pihole_dns_network#5335)N/A
2024-05-25 19:40:05HTTPSgateway.icloud.comiPad.fritz.boxOK (sent to unbound-stack.pihole_dns_network#5335)N/A
 
Es ist immer wieder eine Freude mit Images arbeiten zu wollen, für die keine Beschreibung existiert :)

Laut der Image History für das latest Tag, wird hier Port 53 udp/tcp exposed. Es sollte also ausreichen als Upstream einfach nur den Service-Namen unbound mit dem Default-Port 53 zu verwenden.

Code:
      PIHOLE_DNS_: unbound # forward request to unbound

Interessante Nutzung im Stack:
- Das Bridge Netzwerk hat IPAM konfiguriert, und die Container haben fest ips. Würde ich niemals verwenden, außer ich würde mit einer Anwendung arbeiten, die keine Domainnamen auflösen kann. Ansonsten hat es keinen Vorteil, da im Netzwerk die Servicenamen eh als DNS-Eintrag aufgelöst werden.
- Es werden binds in das Host-Verzeichnis gelegt, in dem Docker selbst seine Named Volumes hinlegt. Letztere werden mit docker volume ls gelistet.

Während erstes Geschmackssache ist (abgesehen davon das es unnötig ist), würde ich stark davon abraten irgendetwas selbst im Docker Root-Verzeichnis anzulegen, zu editieren, oder zu löschen.
 
beim PIHOLE_DNS_ nur unbound einzutragen, hilft leider auch nicht, es kommt auch damit keine Antwort zurück und Webseiten können auch so leider nicht aufgerufen werden. Irgendwie fehlt immer noch etwas für den Weg zurück.

2024-05-25 21:37:31 HTTPSwww.faz.netiPad.fritz.boxOK (sent to 172.168.133.3#53)N/A
 
Ich verstehe "es kommt auch damit keine Antwort zurück" noch nicht so richtig.

Wenn im Client Pihole als DNS-Server eingetragen ist, dann kommuniziert der Client doch nur mit PIhole. Pihole selbst kommuniziert mit Unbound als Upstream Server ungehindert über das gemeinsame Containernetzwerk. Natürlich muss Unbound selbst die Anfragen, die es noch nicht zwischengespeichert hat an seinen Upstream (Default: CloudFlare, siehe hier) weiterreichen.

Was sagen den die Logs vom Unbound-Container? Was passiert, wenn man PiHole testweise aus der Gleich herausnimmt und Unbound direkt als DNS-Server im Client einträgt?

Update:
Und hier erkennt man, dass die unbound.conf als here-doc string im entrypoint geschrieben wird, sofern man keine eigene als Volume reinmapped:

https://github.com/MatthewVance/unbound-docker-rpi/blob/master/1.19.2/data/unbound.sh#L40
 
Zuletzt bearbeitet:
Ich denke, ich habe das Problem gefunden:
- subnet: 172.168.133.0/24
ist in der default unbound.conf kein akzeptiertes Subnet für Anfragen:
https://github.com/MatthewVance/unbound-docker-rpi/blob/master/1.19.2/data/unbound.sh#L153C1-L156C37 schrieb:
access-control: 127.0.0.1/32 allow
access-control: 192.168.0.0/16 allow
access-control: 172.16.0.0/12 allow
access-control: 10.0.0.0/8 allow
 
Well spotted!

Ohne die IPAM Konfiguration und die statischen IPs, hätte Pihole eine IP aus den erlaubten Ranges gehabt :D
 
Immer wieder lese ich das Leute PiHole in einen Container packen. Du packst auch noch Unbound in einen weiteren Container. Soweit - so gut. Dafuer sind Container ja auch gedacht.

Ich weiss jetzt nicht wie wichtig es bei Dir ist dass die DNS Aufloesung per PiHole 7/24 verfuegbar ist. Ich habe bei mir ein RPi2B mit genau derselben Konfig in Betrieb - kein Container - alles plain im OS.

Wenn der ausfaellt ziehe ich meinen anderen 2B aus der Schublade sofern es ein HW Problem ist und ziehe ein aktuelles Backup aus der Schublade wenn es ein SW Problem ist.

Ein System mit vielen Containern im Failurefall wieder zum Laufen zu bringen denke ich ist da schon schwieriger und aufwaendiger. Jedenfalls ist das der Grund warum ich mein PiHole und unbound native auf einer Rasperry laufen lasse. JM2C
 
Nennen wir es einerseits ein Experiment zum Kennenlernen von Portainer. Andererseits läuft in meiner bisherigen Installation direkt auf dem OS auch noch eine ebenfalls direkte Installation von Homebridge. Läuft bisher auch seit Jahren problemlos. Die Erwartung ist einfach, daß sich mit Containern die Updates vereinfachen und sich nicht gegenseitig in die Quere kommen.
 
So scheint es jetzt zu funktionieren. Lasse ich den network/ipam-Teil weg und automatisch IP-Adressen vergeben, geht es nicht.
Außerdem habe ich noch ein paar Vorgaben für die Installation eingefügt.
Gemappte Volumes brauche ich, weil sonst die zuätzlichen Blocklisten bei jedem redeploy des Stacks verloren gehen. Die verlege ich aber vielleicht am Ende der Testphase noch in die User-Home.

Code:
version: '1.0'
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    hostname: pihole-portainer
    depends_on:
      - unbound
    restart: unless-stopped
    ports:
      - "8093:80/tcp" # web ui -> http://<IP-Pi5>:8093/admin/
      - "53:53/tcp"
      - "53:53/udp"
# portainer volumes to be mapped
    volumes:
      - "/var/lib/docker/volumes/pi-hole/_data:/etc/pihole/"
      - "/var/lib/docker/volumes/pi-hole/dnsmasq.d:/etc/dnsmasq.d/"
    environment:
      WEBPASSWORD: xxxxxxxx
      DNS1: 172.16.133.3#53 # forward request to unbound
      FTLCONF_LOCAL_IPV4: 192.168.xxx.xxx # <IP-Pi5> = address of RasPi5
      TZ: Europe/Berlin
      DNSSEC: true
      DNSMASQ_LISTENING: single
      INTERFACE: eth0
      REV_SERVER: true
      REV_SERVER_DOMAIN: fritz.box
      REV_SERVER_TARGET: 192.168.xxx.1
      REV_SERVER_CIDR: 192.168.xxx.0/24
      WEBTHEME: default-dark
    networks:
      pihole_network:
         ipv4_address: 172.16.133.2 # address in pihole_dns_network
 
  unbound:
    container_name: unbound
    image: mvance/unbound-rpi:latest #  exposes port 53
    hostname: unbound-portainer.local
    restart: unless-stopped
    networks:
      pihole_network:
        ipv4_address: 172.16.133.3 # address to be used by pihole as upstream DNS

networks:
  # Custom subnet for pihole, unbound upstream DNS on port 53
  pihole_network:
    name: "pihole"
    ipam:
      driver: default
      config:
        - subnet: 172.16.133.0/24
          gateway: 172.16.133.1
#         ip_range: 172.16.133.0/24 # 172.16.133.1 - 172.16.133.254
 
Ich hab es testweise mal ausgedünnt:
Code:
version: '2.4'

services:
  pihole:
    image: pihole/pihole:latest
    depends_on:
      - unbound
    restart: unless-stopped
    ports:
      - "8093:80/tcp"
      - "53:53/tcp"
      - "53:53/udp"
    volumes:
      - "./config:/etc/pihole/"
      - "./nsmasq.d:/etc/dnsmasq.d/"
    environment:
      DNS1: unbound
      FTLCONF_LOCAL_IPV4: 192.168.xxx.xxx
      TZ: Europe/Berlin
  unbound:
    image: mvance/unbound-rpi:latest
    restart: unless-stopped

networks:
  default:
    name: "pihole"

Läuft auf Anhieb.
 
Geht auch ohne die Deklarationen im Top-Level network Element, da jeder Service von Haus aus dem default Netzwerk zugeordnet ist, solange kein anderer definiert wurde.

Ich hab es nur drin gelassen, um den Default Namen {projekt-name}_default mit pihole zu ersetzen.

Man kann sich die resultierende compose Konfiguration übrigens mit docker compose config validieren und anzeigen lassen.
 
Ich habe es jetzt mal danke Deiner Hilfe @Confluencer auf folgenden Stack reduziert:
YAML:
version: '1.2'

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    hostname: pihole-portainer
    depends_on:
      - unbound
    restart: unless-stopped
    ports:
      - "8093:80/tcp"
      - "53:53/tcp"
      - "53:53/udp"
    volumes:
      - "/var/lib/docker/volumes/pi-hole/_data:/etc/pihole/"
      - "/var/lib/docker/volumes/pi-hole/_data/dnsmasq.d:/etc/dnsmasq.d/"
    environment:
      WEBPASSWORD: x
      DNS1: unbound
      FTLCONF_LOCAL_IPV4: 192.168.xxx.yyy
      TZ: Europe/Berlin
      DNSSEC: true
      DNSMASQ_LISTENING: single
      INTERFACE: eth0
      REV_SERVER: true
      REV_SERVER_DOMAIN: fritz.box
      REV_SERVER_TARGET: 192.168.xxx.1
      REV_SERVER_CIDR: 192.168.xxx.0/24
      WEBTHEME: default-darker
  unbound:
    container_name: unbound
    image: mvance/unbound-rpi:latest
    restart: unless-stopped

networks:
  default:
    name: "pihole"

Noch eine Frage zu den gemappten Volumes, Du hattest geschrieben, Du würdest sie nicht dort mappen, wo ich es getan habe. "/var/lib/docker/volumes/pi-hole/_data" ist der Mountpoint, der in Portainer angegeben wird, wenn man Volumes definiert. Lege ich keine Volumes an, so sind mir nach einem redeploy die bereits angelegten Blocklisten verschwunden, ich mußte sie also neu hinzufügen, und ich vermute, daß das dann auch bei jedem Update der Fall wäre. In der Portainer-"Volumes"-Liste wird das pihole-Volume allerdings als "unused" deklariert. Sehe ich mir das Verzeichnis allerdings im Terminal an, so liegen dort die .conf-Dateien und die ganzen Blocklisten. Wenn mir also Portainer die Volumes in das Docker-Verzeichnis mappt, kann es doch so falsch nicht sein?
 
@framp

Pi4/8GB mit homebridge, pihole und unbound direkt auf RasPiOS: noch 6.88 GB frei, 1% CPU load, T 42 °C, 15W Netzteil.
Pi5/8GB mit homebridge, pihole und unbound mit Portainer in Docker auf RasPiOS: noch 4.74 GB frei, 9% CPU load, T 49°C, 27W Netzteil

Die Zahlen sprechen also eigentlich für den ersten Ansatz...
 
Das sieht aber nicht nach "Volumes" aus, sondern nach "mount binds". Volume wäre in diese Richtung: data:/opt/data, wobei so ein Volume dann in seinem Default-Pfad angelegt wird. Vielleicht hilft dieser Artikel ja noch ein bisschen beim Thema Volumes: https://docs.docker.com/compose/compose-file/07-volumes/.

Wenn Du einfach nur Ordner mappst, haben die im eigentlichen Volume-Ordner eher nix verloren, ich nutze da meist "/opt/<projekt-name>/" und mappe dann entweder direkt diesen Ordner, oder ggf. auch Unterordner (je nachdem halt).
Lege ich keine Volumes an, so sind mir nach einem redeploy die bereits angelegten Blocklisten verschwunden
Klar, ist ja auch kein persistenter Speicher angegeben, irgendwo müssen die Dinge ja "dauerhaft" abgelegt werden.

In der Portainer-"Volumes"-Liste wird das pihole-Volume allerdings als "unused" deklariert.
Versuch es doch mal mit folgendem Ansatz: https://docs.docker.com/storage/volumes/#use-a-volume-with-docker-compose. Alternativ bleib bei den bind-mounts, aber dann halt eher woanders (bei mir wie oben erwähnt immer unter /opt/) :)
 
Portainer nennt das, was ich gemacht habe "Volumes"... auf den dort angegebenen Mountpoint habe ich dann den "bind" gesetzt. Ist also eher der falsche Ansatz.
D.h. Du legst manuell irgendwo ein Verzeichnis an und setzt den bind darauf?
Wenn ich das jetzt mache, müßte es doch möglich sein, aus /var/lib/docker/volumes/pi-hole/_data alles in das neue Verzeichnis zu kopieren und den mount bind auf das neue Verzeichnis zu legen. Dann sollte ja auch alles erhalten bleiben, oder? (Antwort: ja, tut es, gerade ausprobiert).

Also eher so:
YAML:
 volumes:
   - "/opt/pihole:/etc/pihole/"
   - "/opt/pihole/dnsmasq.d:/etc/dnsmasq.d/"
 
Zuletzt bearbeitet:
So mache ich es oftmals, genau.

Variante a) volume-name:/pfad/im/container
Variante b) /pfad/auf/dem/host:/pfad/im/container

Ein normales Volume kannst Du vorher auch anlegen und in Deinem Compose-File dann darauf verweisen. Das findet Docker dann schon alles (halt Default-Verzeichnis + eigens benanntes Volume)
- "/opt/pihole:/etc/pihole/"
- "/opt/pihole/dnsmasq.d:/etc/dnsmasq.d/"
Bei mir wäre das übrigens eher etwas in diese Richtung geworden:
/opt/pihole/etc/pihole + /opt/pihole/etc/dnsmasq.d
oder
/opt/pihole/config + /opt/pihole/dnsmasq

Problem bei Deiner Konstellation ist dann ja, dass dnsmasq auch schon in der Definition darüber (eben als Unterordner) vorhanden ist, weswegen ich die beiden etwas strikter trennen würde :)
 

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
4.796
Beiträge
48.630
Mitglieder
4.456
Neuestes Mitglied
Fahren
Zurück
Oben