Unbound - Could not open /etc/unbound/unbound.conf: No such file or

wjavixxassuj

Benutzer
Mitglied seit
19. Sep 2021
Beiträge
101
Punkte für Reaktionen
10
Punkte
68
Hallo Zusammen,

nachdem ich unbound deployed habe erhalte ich über die Logfiles folgende Meldung

[1695837036] unbound[1:0] error: Could not open /etc/unbound/unbound.conf: No such file or directory

Das ist mein docker run Befehl:
Code:
docker run --name=unbound --network=host \
--volume=/var/lib/docker/unbound:/opt/unbound/etc/unbound/ \
--restart=unless-stopped \
--detach=true \
alpinelinux/unbound:latest


root@DietPi:/etc/unbound# ls
unbound.conf

root@DietPi:/var/lib/docker/unbound# ls
root.hints unbound.conf

ich habe an beiden Orten zum testen die unbound.conf abgelegt. CHMOD 777 besteht auf der Datei und dem unbound Ordner.

Ich verstehe nicht, warum der Ordner nicht gefunden werden kann.
 

synfor

Benutzer
Sehr erfahren
Mitglied seit
22. Dez 2017
Beiträge
9.027
Punkte für Reaktionen
1.614
Punkte
308
Code:
--volume=/var/lib/docker/unbound:/opt/unbound/etc/unbound/
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^
Ob das so richtig ist?
 

wjavixxassuj

Benutzer
Mitglied seit
19. Sep 2021
Beiträge
101
Punkte für Reaktionen
10
Punkte
68

synfor

Benutzer
Sehr erfahren
Mitglied seit
22. Dez 2017
Beiträge
9.027
Punkte für Reaktionen
1.614
Punkte
308
Tja manchmal steht auch in Anleitungen Unfug.

Laut deiner Fehlermeldung muss das wohl /etc/unbound heißen. Wobei, wenn du den Container gerade erstellt hast, muss die Config eh erst einmal erstellt werden.
 

wjavixxassuj

Benutzer
Mitglied seit
19. Sep 2021
Beiträge
101
Punkte für Reaktionen
10
Punkte
68
Die unbound.conf habe ich bereits

Code:
server:
    # If no logfile is specified, syslog is used
    # logfile: „/var/log/unbound/unbound.log“
    verbosity: 0

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # 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

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it  automatically
    #root-hints: „/var/lib/unbound/root.hints“

    # 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.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS – Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # 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 >
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # 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

Das Volume Mapping habe ich angepasst. Er scheint das jetzt erstmal zu nehmen
--volume=/var/lib/docker/unbound:/etc/unbound/

Aktuell noch ein Folgefehler vorhanden
[1695841584] unbound[1:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.

EDIT: ok, der letzte Fehler ist auch weg. Lösung gibt es hier
https://github.com/chriscrowe/docker-pihole-unbound/issues/45#issuecomment-823544989

"Comment / Remove the line so-rcvbuf: 1m in unbound conf file to resolve the issue."
 
Zuletzt bearbeitet:

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.519
Punkte für Reaktionen
404
Punkte
103
Hier wird ja schon wieder wild spekuliert.... Hat irgendeiner von euch schon mal ins Dockerfile und ins Entrypoint Skript geschaut?

https://github.com/MatthewVance/unbound-docker/blob/master/1.18.0/data/unbound.sh#L374


Update:
Ich hab gerade erst gesehen, dass in Post 3 ein Repo zu einem anderen Image angegeben ist, als das was in Post 1 verwendet wurde.
Natürlich passt die Doku von mvance/unbound nicht zum alpinelinux/unbound. Wie kommt man den auf die Idee das die Beschreibung von irgendeinem unbound Image auch für ein anderes unbound Image gilt?
 
Zuletzt bearbeitet:

wjavixxassuj

Benutzer
Mitglied seit
19. Sep 2021
Beiträge
101
Punkte für Reaktionen
10
Punkte
68
Das mvance/unbound kann ich nicht nutzen weil es sich nicht auf dem RapsberryPi deployn lässt. Das Image ist für linux/amd64 sind. Deswegen auch das Image von alpinelinux/unbound
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.519
Punkte für Reaktionen
404
Punkte
103
Die Frage des Warums bezog sich auf "Wie kommt man auf die Idee das die Beschreibung eines Images zu einem anderen passt?".

Probier mal ob klutchell/unbound auf dem Pi funktioniert. Mit 10M+ Downloads und 66 Sternen kann es nicht ganz so verkehrt sein.
 

wjavixxassuj

Benutzer
Mitglied seit
19. Sep 2021
Beiträge
101
Punkte für Reaktionen
10
Punkte
68
Ja, funktioniert problemlos.

Die Frage des Warums bezog sich auf "Wie kommt man auf die Idee das die Beschreibung eines Images zu einem anderen passt?".
Wieso kommt man den auch auf die Idee die interne Struktur im Container zu ändern?
Ist hier aber auch tatsächlich anders gemappt.

Code:
docker run --name unbound \
  -p 53:53/tcp -p 53:53/udp \
  -v /path/to/config:/etc/unbound/custom.conf.d \
  klutchell/unbound

Merke ich mir für das nächste Mal. Danke für die Unterstützung.
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: haydibe

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
Wieso kommt man den auch auf die Idee die interne Struktur im Container zu ändern?
Wieso ändern? Es wird einfach eine andere Struktur verwendet. Gibt doch keinen Standard oder Pflicht es so zu machen. Bestes Beispiel sind da auch die Images von Linuxserver. Die haben alle eine andere Struktur vorgegeben, als die anderen. Vergleich mal Nextcloud und LinuxServer Nextcloud. Das hängt einfach damit zusammen wie derjenige das Image erstellt. Daher ist es wichtig sich die Settings von jedem Image anzugucken.
 
  • Like
Reaktionen: haydibe

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.519
Punkte für Reaktionen
404
Punkte
103
Dazu kommt, dass Images einer Anwendung im Zweifel auch nicht denselben Funktionsumfang haben, bspw. was die Parametrisierung über environment Variablen angeht: mach erlauben UID:GID mitzugeben oder per TZ die Zeitzone zu setzen, oder ob ein ausgebufftes Init-System wie s6-Overlay verwendet wird, das erlaubt multiple-Prozesse in einem Container zu managen, wie es bei Linuxserver.io Images der Fall ist.

Nicht jedes Image besteht nur aus OS-Paket Installationen. Gerade wenn beim Image-Bau etwas heruntergeladen oder gebaut wird, dann landet das im Zweifel sonstwo.
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat