Ist unbound Pi-hole überhaupt im Docker möglich?

Hallo,

ich bin gerade viel am probieren um meine perfekte Konfiguration zu finden.

Ich versuche gerade Pi-hole im buanet Docker zu installieren und es läuft auch alles. Ich schaffe es aber nicht ,unbound zu installieren. Ist das überhaupt möglich?

Da ich mir diese Kombi am Wochenende gebaut habe: Nimm Pihole und unbound jeweils in eigenen Contrainern und packe sie in ein gemeinsames Netz, ich nutze dafür eine Bridge. Die (feste) IP (für unbound) aus dem Netz ist dann Dein custom upstream DNS.

Der klare Vorteil ist: Ich habe 3 Container (stable, dev, nightly) und kann diese jeweils starten. Sie teilen sich die volumes und sprechen alle den gleichen unbound an.

@photobix

Danke für den Anstoß. Ich hatte da auch schon dran gedacht aber es gibt so viele unbound Docker, dass ich das wieder verworfen hatte. Ich kann nicht sehen kann welcher für Pi-hole geeignet ist. Welchen hast du denn genommen (ich habe eine QNAP)?

Der Docker Grundsatz ist ja, ein Container pro Aufgabe.
Als unbound läuft: klutchell/unbound:latest

Meine Config ist:

server:
    # Enable or disable whether the unbound server forks into the background
    # as a daemon. Default is yes.
    do-daemonize: no

    # If given, after binding the port the user privileges are dropped.
    # Default is "unbound". If you give username: "" no user change is performed.
    username: "unbound"

    # No need to chroot as this container has been stripped of all other binaries.
    chroot: ""

    # If "" is given, logging goes to stderr, or nowhere once daemonized.
    logfile: ""

    # The process id is written to the file. Not required since we are running
    # in a container with one process.
    pidfile: ""

    # The verbosity number, level 0 means no verbosity, only errors.
    # Level 1 gives operational information.
    # Level 2 gives detailed operational information.
    # Level 3 gives query level information, output per query.
    # Level 4 gives algorithm level information.
    # Level 5 logs client identification for cache misses.
    # Default is level 1. The verbosity can also be increased from the commandline.
    verbosity: 1

    # Listen on all ipv4 interfaces, answer queries from the local subnet.
    interface: 0.0.0.0
    interface: ::0

    # The port number, default 53, on which the server responds to queries.
    port: 53

    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    do-ip6: yes

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1472

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines.
    # In reality for most users running on small networks or on a single machine,
    # it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    # (requires CAP_NET_ADMIN or privileged)
    # so-rcvbuf: 1m

    # The netblock is given as an IP4 or IP6 address with /size appended for a
    # classless network block. The action can be deny, refuse, allow or allow_snoop.
    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
    access-control: fd00::/8 allow

    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

    # Read  the  root  hints from this file. Default is nothing, using built in
    # hints for the IN class. The file has the format of  zone files,  with  root
    # nameserver  names  and  addresses  only. The default may become outdated,
    # when servers change,  therefore  it is good practice to use a root-hints
    # file.  get one from https://www.internic.net/domain/named.root
    #root-hints: /etc/unbound/root.hints

    # File with trust anchor for one zone, which is tracked with RFC5011 probes.
    # The probes are several times per month, thus the machine must be online frequently.
    # The initial file can be one with contents as described in trust-anchor-file.
    # The file is written to when the anchor is updated, so the unbound user must
    # have write permission.
    auto-trust-anchor-file: /etc/unbound/root.key

    include: /etc/unbound/a-records.conf

Wenn ich klutchell/unbound installiere mit Mount Point /etc/unbound bekomme ich folgende Meldungen.

[1641827262] unbound[1:0] error: Could not open /etc/unbound/unbound.conf: No such file or directory
[1641827262] unbound[1:0] warning: Continuing with default config settings
[1641827262] unbound[1:0] error: can't bind socket: Address not available for ::1 port 53
[1641827262] unbound[1:0] fatal error: could not open ports

Der Container wird dann auch nicht gestartet, um irgendetwas machen zu können.

photobix hat mir versucht per PN zu helfen aber er nutzt unbound leider nicht auf einem QNAP als Docker.

Im unbound Verzeichnis container/unbound /etc/unbound sollen die nachfolgenden Datei enthalten sein:

a-records.conf
root.hints
root.key
unbound.conf

Wo bekomme ich diese her?

Gibt es niemanden der unbound Docker auf einem (QNAP) NAS nutzt und helfen kann?

Die Dateien werdem beim erstmaligen Start des Containers automatisch erstellt, wenn das Volume korrekt eingebunden ist

Trage ich bei Volume from Host folgende Daten ein:

unbound (vorher den Ordner angelegt) und dann Mount Point /etc/unbound

kommt die Fehlermeldung wie oben dargestellt.

Trage ich aber New Volume die Daten ein wird unbound installiert. Ich kann es aber nicht überprüfen, da ich, warum auch immer, in das Containerverzeichnis nicht reinsehen kann.

Hast Du mal in der linken Seitenleiste versucht, ein neues Volume anzulegen?
Das soltle nur irgendeinen sprechenden Namen bekommen, z.B. "unbound".
Wenn Du dann ein Container anlegst, solltest Du auf dieses Volume referenzieren können


Ja, das funktioniert. Ich habe mir selbst eine Pi-hole/Unbound/Watchtower-Kombi gebaut.

Grüße, madnuttah

Das klingt vernünftig.
Ich habe mir ein bridged Netz gebaut, dadurch muss ich die unbound Ports nicht freigeben, Pihole kann über die festen IPs (v4, v6) zugreifen.
Die Trennung zwischen unbound und pihole hat (auch) den Vorteil, dass ich zwischen stable, dev und nightly wechseln kann (jeweils ein eigener Container mit geteilten Volumes).

1 Like

Hatte in meinem letzten Post nicht gesehen, dass du schon ein Stückchen weiter warst, daher wollte ich ihn editieren und habe ihn dann versehentlich komplett gelöscht.

Erstelle bitte einen neuen, freigegebenen Ordner und nenne ihn "docker". In diesem Ordner bitte einen Ordner namens "unbound" anlegen. Auf diesen Ordner musst du den Ordner des Containers (/etc/unbound) referenzieren. Falls das immer noch nicht starten will, leg bitte die vom Container benötigten Dateien manuell in diesem Ordner ab und versuche dann nochmal den Container zu starten.

Ansonsten kannst du es auch mal mit einer docker compose Datei versuchen. Dies wäre meiner Meinung nach ohnehin der bessere Weg. Dazu benötigst du allerdings ssh Zugriff auf die NAS und etwas Erfahrung mit der Linux-Konsole.

Das mit dem eigenen Verzeichnis Docker habe ich auch probiert aber es ändert sich leider nichts daran. Ich werde deinen Vorschlag probiere. Danke

@madnuttah

Es geht leider nicht siehe Bild.

Ich habe das heute morgen noch einmal durchgespielt:
Beim Erstellen des Containers werden die Dateien automatisch erzeugt. Solltest Du sie zuvor manuell in das Volume kopiert haben, startet unbound nicht.
Also: Volume löschen und neu anlegen.
Container neu erstellen lassen (aus dem Image).
Veränderungen im Nachgang vornehmen, falls notwendig

Ansonsten versuche das mit einem anderen Image, ich hatte bevor ich mein eigenes erstellt habe das von Matthew Vance benutzt.

Ich kann für eine neue Installation nicht mal mehr das Verzeichnis unbound löschen.
NAS wurde neu gestartet aber auch danach ist es nicht möglich.
Es muss irgendetwas in Verbindung mit dem QNAP NAS sein, was bei mir diese Probleme mit unbound verursacht.

pihole, iobroker, unifi und watchtower laufen

Ich habe keine QNAP, daher kann ich nicht wirklich etwas dazu sagen.

Dir bleibt noch ein anderes Image mit anderen Pfaden zu probieren.

Sorry und alles Gute weiterhin.

Obwohl ich Admin bin musst ich zum Löschen des Ordners sudo nutzen, grrrrr

Habe mehrer andere Docker genutzt ,keiner läuft.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.