Best Practice: AdGuard Home & unbound als DNS-Server

[Janüscht]

@mj084,

Ich musste jetzt wirklich noch einmal das Issue (147) von @update-freak auf GitHub suchen. Wenn ich das richtig sehe, warst du bei der Diskussion auch dabei? In den Issue findest du weiter unten auch eine kleine Anleitung, wie Unbound schnell einzurichten geht. Das soll auch bei älteren DS funktionieren. In den Issue wird sogar von einem 13er-Modell berichtet, was funktioniert. Entsprechende Files wurden dafür bereitgestellt, wobei es sich aber scheinbar „nur“ um die Standard-Config handelt. Bei meiner 218+ mit DSM 7.2 funktioniert es ohne Probleme.

Nur weil die Anleitung hier im Forum nicht ganz richtig ist bzw. User sich nicht na die Anleitung des Entwicklers halten, ist das der Container ja nicht unbedingt schlecht! Hast du das überhaupt einmal ausprobiert oder behauptest du nur deine Aussagen? Es mag noch andere Container geben, wo es auch noch funktioniert. Das Image von Matthew Vance ist aber einer der verbreiteten.

Matthew Vance macht das aber schon lange und es ist vorgestern/gestern wieder ein Update erschienen. Von dir seine Arbeit schlechtzureden, ist nicht fair. Probleme sind da, um gelöst zu werden. Wenn man einfach etwas anderes nutzt, bleibt das Problem ja bestehen. Wenn ich in den Kuketz-Link von @update-freak sehe, beschwert sich selbst der Entwickler über die schlechte Wartung seines Containers – ohne anzugeben, um welchen es sich handelt. Der hier im Thread genannte Container hat aber innerhalb der letzten 2 Jahre mehrfache Updates bekommen und kann somit nicht gemeint sein! Ich kann nur für dich hoffen, dass Madnuttah sein Container auch so pflegt wie Matthew, nicht, dass du wieder wechseln musst…

Ps.: Wenn ich beide Anhänge (hier & GitHub) vergleiche, ist die Frage: warum @plang.pl. leere Dateien nutzt und nicht die Config dazu anpasst? Auch dazu steht etwas auf GitHub!

 

[mj084]

@Janüscht

Sorry, wo rede ich das Image von Matthew Vance schlecht, und welche welche Aussagen behaupte ich denn?

Scheinbar hast du den Beitrag von Madnuttah im Kuketz-Forum nicht richtig gelesen oder interpretiert (den Link hat @update-freak übrigens von mir) - er hatte vor Jahren mal ein fremdes Unbound Image genutzt und sich über die schlechte Wartung und Aufgeblähtheit des Images geärgert - daher hat er dann selbst ein Image auf die Beine gestellt, welches automatisch via Bot aktualisiert wird - steht auch alles so im Thread dort.

Den Change mit "Updated to OpenSSL 3.3.0" gabs bei Madnuttah schon etwas eher dank Bot:

https://github.com/madnuttah/unbound-docker/releases/tag/v1.19.3-2

Natürlich könnte die man die Lösung mit der direkten Angabe der unbound.conf:

-v /volume1/docker/unbound/unbound.conf:/opt/unbound/etc/unbound/unbound.conf \

Der Container mit dem Image von Madnuttah läuft auch nicht anders mit den Mounts, von daher sollte es mit dem Image von Matthew auch keine Probleme mehr auf "alten" Systemen geben.

Momentan werde ich trotzdem nicht wechseln, da ich mit dem anderen schlankeren Image mehr als zufrieden bin und mit dem Entwickler in Kontakt stehe. - das ist auch kein Schlechtreden vom anderen Image in meinen Augen.

Warum @plang.pl hier leere Dateien (die werden beim Start von unbound im Image von Matthew scheinbar benötigt) nutzt, weiss ich nicht.

Im Image von Madnuttah sind die configs ein wenig gesplittet und hier gibt es ein schönes Beispiel:

https://www.xfelix.com/2020/09/pihole-unbound-docker-setup-on-raspberry-pi/

Wer das Image von Madnuttah nutzen möchte und die Logs weiterhin im Container-Manager/Docker sehen möchte, trägt in der logging.conf im Ordner conf.d folgendes ein:

logfile: ""

 

[Janüscht]

Und warum funktioniert es dann bei Usern mit nem alten Kernel nicht?

Zu deiner Behauptung schreibst du in der letzten Antwort nichts mehr. Hast du das Image mit den genannten Einstellung im Nachhinein probiert oder nicht? Ich kann das Problem nicht bestätigen.

Wir sind uns ja wenig, dass die Anleitung hier nicht optimal ist und nachgearbeitet werden sollte.

Mir ist es auch egal, welches Image du nutzt, nur falsche Aussagen aufgrund einer fehlerhaften/schlechten Anleitung sollte man nicht tätigen!

 

[plang.pl]

die werden beim Start von unbound im Image von Matthew scheinbar benötigt

Genau das ist der Grund.
Aber fehlen in #279 nicht die Foldermappings?

 

[mj084]

Korrekt, die Filemappings fehlen - so schaut es bei mir aus

 

[update-freak]

Korrekt, die Filemappings fehlen - so schaut es bei mir aus

habe diese nun ergänzt:

version: "3"
services:
  unbound:
    container_name: Unbound
    image: madnuttah/unbound:latest
    ports:
      - 5335:5335/tcp
      - 5335:5335/udp
    volumes:
      - /volume1/docker/unbound/unbound.conf:/usr/local/unbound/unbound.conf:rw
      - /volume1/docker/unbound/conf.d/:/usr/local/unbound/conf.d/:rw
      - /volume1/docker/unbound/iana.d/:/usr/local/unbound/iana.d/:rw
      - /volume1/docker/unbound/log.d/unbound.log:/usr/local/unbound/log.d/unbound.log:rw
      - /volume1/docker/unbound/zones.d/:/usr/local/unbound/zones.d/:rw
    network_mode: host
    environment:
      - UNBOUND_UID=1026
      - UNBOUND_GID=100
      - TZ=Europe/Berlin
    restart: always
    healthcheck:
      test: /usr/local/unbound/sbin/healthcheck.sh
      interval: 60s
      retries: 5
      start_period: 15s
      timeout: 30s

 

[plang.pl]

Ok. Schau ich mir demnächst mal an auf der Testmaschine. Mir ist noch nicht so ganz klar, was sich hinter den einzelnen Ordnern verbirgt, aber das sehe ich ja dann. Ob das letzten Endes als Workaround in die Anleitung kommt, kann ich noch nicht sagen. Vielleicht nur als Hinweis, denn da noch die Installation eines komplett anderen Containers mit reinzupacken, würde denke ich den Rahmen sprengen.
Und verstehe ich das richtig: Der "Kernel-Fehler" tritt nur dann auf, wenn man im mvance Image den gesamten Ordner mappt? D.h. wenn ich einzeln die benötigten Daten reinmappe, dann geht es einwandfrei? In dem Falle würde ich das eher als Lösung präferieren. Denn da kann ich einfach grundsätzlich die Installationsroutine anpassen und von dem Bug würde keiner mehr was mitbekommen.

 

[Janüscht]

Ich verstehe das Problem ja irgendwie nicht. Matthews Vans hat in einem Beitrag geschrieben, dass es besser ist nicht den unbound-Ordner zu mounten, sondern lieber die Files. Wenn man das beachtet, funktioniert der Container auf den älteren DS ohne Problem. Kann es sein, dass ihr Äpfel mit Birnen vergleicht oder warum mountet ihr die Files in den Madnuttah-Container aber nicht in den mvance?

 

[mj084]

Und verstehe ich das richtig: Der "Kernel-Fehler" tritt nur dann auf, wenn man im mvance Image den gesamten Ordner mappt? D.h. wenn ich einzeln die benötigten Daten reinmappe, dann geht es einwandfrei?

So wie ich es verstanden habe, ja.
Der Test wäre ja schnell gemacht
Ich bleibe trotzdem wie aus bereits genannten Gründen beim anderen Image

 

[plang.pl]

Vielleicht kannst du das mal testen. Ich kann es nicht. Ich habe keine DS mit so altem Kernel.

 

[mj084]

@update-freak darf gerne ran

 

[mj084]

Ich verstehe das Problem ja irgendwie nicht. Matthews Vans hat in einem Beitrag geschrieben, dass es besser ist nicht den unbound-Ordner zu mounten, sondern lieber die Files. Wenn man das beachtet, funktioniert der Container auf den älteren DS ohne Problem. Kann es sein, dass ihr Äpfel mit Birnen vergleicht oder warum mountet ihr die Files in den Madnuttah-Container aber nicht in den mvance?

Wo hat er das genau geschrieben?

Ich habe lediglich aus seinem Repo gelesen, wenn ich die unbound.conf nutzen möchte, den ganzen Ordner mounten soll - dies hat @plang.pl hier auch so in der Anleitung angegeben.

Use a customized Unbound configuration

Wo habe ich jetzt also was falsch behauptet?

Wenn man den Ordner nach der Doku im GitHub, mountet, kommt es eben auf alten Systemen zu Problemen.

Das ist weder die Schuld von Matthew noch von uns, und ist auch kein Schlechtmachen vom besagten Image.

Ich könnte auch mit beiden Images einen direkten Foldermount testen - habe so eine Vorahnung wie es aussieht...

 

[Janüscht]

Wo hat er das genau geschrieben?

Wenn man einmal die Issues durchgeht, findet man so einiges: https://github.com/MatthewVance/unbound-docker/issues/159#issuecomment-1919686845

Grundsätzlich schaue ich immer etwa "tiefer", was indirekt mit einem Problem zu tun haben könnte. Eine Überschrift muss dafür nicht zielführend sein! Auch wenn ich das nebenbei schon vor einiger Zeit gelesen habe, konnte ich es in 2 Minuten wieder finden.

Deine anderen Fragen habe sich damit aus meiner Sicht auch geklärt. Gerne kann jeder User die Readme anpassen, um spätere Fehler zu vermeiden. Jeder ist sich aber meist selbst der Nächste.

Wenn man den Ordner nach der Doku im GitHub, mountet, kommt es eben auf alten Systemen zu Problemen.

Und warum mountest du den unbound-Ordner nicht direkt= Hier im Forum sowie auch auf GitHub sind alle Compose -Files auch nur als Files gemountet - nicht in den unbound-Ordner. Also doch ein ungleiches vergleichen. Also doch Äpfel & Birnen.

Ich könnte auch mit beiden Images einen direkten Foldermount testen - habe so eine Vorahnung wie es aussieht...

Das ist ja schön für dich. Es war deine Aussage: Das hier angeben Image von Matthew Vance auf älteren Modellen nicht läuft. Das habe ich einfach widerlegt. Wenn du so viel genest, hättest, wie du die letzten Seiten schreibst zzgl. deiner Erfahrung hättest du auch darauf kommen können. Du hast das Problem nicht lösen können und einfach ein anderes Image genommen, mit der Hoffnung es passt.

Es geht darum, dass die Aussagen einfach nicht stimmen, welche in #275 und #280 getätigt wurden. Es muss ja nicht alles auf den Silbertablett präsentiert werden, wobei die Lösung auf GitHub liegt.

Wenn du beide Version ausprobiert und ausgiebig getestet hast, kannst du ja sicherlich sagen, ob sich das Ergebnis unterschiedlich ist? Somit wären es ja 2 unterschiedlich Herangehensweisen, welch zum gleichen Ziel führen. Bei mir klappt es jedenfalls. Ich persönlich finde die mit einer Config übersichtlicher, anstatt alles auseinander zu bröseln. Aber jeder wie er es mag.

Ich würde die Anleitung als TE komplett überarbeiten, nachdem sich doch paar Fehler eingeschlichen haben. Am besten einen neuen sauberen Thread! So sieht doch kein Anfänger damit durch. Selbst für Erfahrene ist das schon grenzwertig!

 

[plang.pl]

Nunja, also lasse ich mich doch wieder darauf ein.
Wieso ein neuer Thread? Ich kann doch hier alles bearbeiten. Und was für Fehler sind das für dich abseits der "falschen" Foldermappings? Und die DNS-Records mit in die Config zu packen halte ich für unsinnig, wenn nicht sogar nicht vorgesehen!

 

[mj084]

Also irgendwer hat nen Denkfehler oder?

In seinem Repo steht unter "Use a customized Unbound configuration"


Daraufhin gibt es bekannten Fehler mit entsprechender Meldung und Issue.

Wenn er da woanders was schreibt, wo die Fehlermeldung ne ganz andere ist - wer sucht da schon?
Du natürlich

Und wenn er im Januar in dem andere Issue empfiehlt lieber einzelene Dateien zu mounten anstatt ganze Ordner, warum steht es noch so im Readme und warum hat keiner, auch du nicht auf den Issue reagiert und den Tip gegeben?

Weiterhin hast du nicht wirklich was widerlegt, wenn man mit älteren Systemen eben den Ordner wie aus dem Readme lädt, gibt es Probleme, fertig.

Du kannst auch gerne bei deinem Äpfel & Birnen Thema bleiben, ist mir egal

Du hast das Problem nicht lösen können und einfach ein anderes Image genommen, mit der Hoffnung es passt.

Schon interessant wo du dein Wissen so hernimmst!

Ich hatte es mit dieser Config (nach Readme) mit der 1.18 und dem gemounteten Folder am Laufen (was auch deine angebliche Widerlegung widerlegt) - das war für mich aber nur eine temporäre Lösung.

Auf das andere Image bin ich durch Zufall gestoßen und war hellhörig aufgrund der anderen Vorteile - wenn es dann für mich passt, so what - ich bin nicht verpflichtet ein Image zu nehmen was hier im Thread als Beispiel dient.

Unabhängig von der Thematik könnte man natürlich einen sauberen Thread hochziehen

 

[Janüscht]

Mein letzter Beitrag zu diesem Thema:

@mj084

1. Alle Beispiel für die Nutzung der Modifizierten Files sind immer it den Mount der Files angegeben, nicht mir den Unbound. Ordner. Dazu musst du dir nur einmal die blauen "drocker run/compose"- Befehle in der Readme ansehen.
2. Sollte jeder User bei Problemen zuerst die Issues durchsuchen und nicht nur warten, bis das Ergebnis geliefert wird
3. also hast du es nicht mit der aktuellen Version und den Config(s) ausprobiert, aber behauptest hier wild, dass es nicht geht? Deine getestete Version 1.18 ist ja schon elfter und ist somit über den Fehler, den du beschreibst aussagekräftig.
4. anstatt anderen die schuld zu geben solltest du selbst erst einmal die Readme-richtig studieren
5. Ich ändere, bearbeite, fixe sehr viel auf Github. Leider kann ich nicht jedes Projekt gleich in Angriff nehmen. mvance ist aber bei mir bereits auf der To-do-Liste. Solche Aussage wie dein sind der Grund, warum man aber keine Lust hat so etwas zu machen. Eventuell hast du schon von der einen oder anderen Veränderung meinerseits etwas gehabt, ohne es zu wissen. Die fähigen User wissen, wie es geht und nicht anderen schreien nach Lösung und Hilfe. "Madnuttha" schreibt noch viel weniger in der Readme und verweist nur auf die Compose-Files. Also doch ein bisschen Äpfel & Birnen.
6. Wie viele Änderungen hast du denn auf Github überhaupt eingereicht? Wenn du schon auf andere zeigst, solltest du vorangehen!
7. Wenn ich was weiß und herausfinde und du nicht, liegt es bestimmt nicht an mir. Mein Wissen beziehe ich aus lesen und breit gefächertes suchen, manchmal auch ohne Grund - nur aus Interesse. Dadurch wusste ich, dass Matthew Vance dazu schon etwas geschrieben hat. Ich hoffe, du bist zufrieden mit der Antwort.

@plang.pl
Ich würde die nicht benötigte "leere" Configs lieber in der unbound.conf auskommentieren. Das gilt auch für nicht angelegte, welche Hinweismeldungen beim Start machen könnten. Auch würde ich, wenn möglich, die Container immer in einem Bridge-Netzwerk laufen lassen und so wenig wie möglich im Host-Netzwerk. Beides ist mit AdGuard und Unbound möglich. Das starten der Container über die Syno-API hast du auch sehr spät erkannt. Berechtigungen für "Jedermann" habe ich natürlich auch nicht gesetzt, dieses könnte zu einem Sicherheitsproblem führen! Dazu kommt noch das Springen zwischen AdGuard ohne und mit Fritz!Box. Was die User durcheinander bringen könnten. Mit deinem letzten Satz, was du für unsinnig hältst, muss ich auch widersprechen. Du übernimmst einfach irgendwelche Werte aus irgendwelchen Anleitung und verbastelt die ganze Config. Dann bekommst du nicht einmal mit, wenn andere User dich auf Fehler aufmerksam machen und bestreitest das. Du erstellst lieber leere Dateien, anstatt diese in der Config zu bearbeiten. Scheinbar hast du deine Anleitung selbst nicht genug getestet und kannst Logs auswerten. Problematisch finde ich, auch wenn du das ganze nicht direkt auf eine DS probierst, sondern oft/meist nur in Promox oder VDSM. Ob man dann noch von "best practice" sprechen kann, bezweifle ich.

Mehr habe ich zum Thema nicht zu sagen und verabschiede mich. Sollen sich die User selbst eine Meinung bilden.

 

[madnuttah]

Hi ich bin madnuttah, der Maintainer des besagten Unbound Docker images.

Zunächst ein herzliches Dankeschön, dass einige mein Image nutzen und wohl zufrieden damit sind. Matthew's Image ist in der Tat weit verbreitet und schlecht kann es ja nicht sein. Ich sehe kein Problem damit dieses Image zu verwenden, es kommt schließlich immer auf die eigenen Ansprüche an.

Ich verstehe nicht warum man sagt ich hätte keine Doku. Die Readme wurde unübersichtlich und ich habe die Anleitung nur ausgelagert: https://github.com/madnuttah/unbound-docker/blob/main/doc/DETAILS.md. Falls euch was fehlt, ergänze ich das gerne. In den Beispielen habe ich so ziemlich jedes Anwendungsszenario berücksichtigt, schaut euch einfach die yaml Dateien an.

Falls ihr Wünsche oder Fragen habt bin ich gerne da.

 

[mj084]

@Janüscht

Alle Beispiel für die Nutzung der Modifizierten Files sind immer it den Mount der Files angegeben, nicht mir den Unbound. Ordner. Dazu musst du dir nur einmal die blauen "drocker run/compose"- Befehle in der Readme ansehen

docker run --name=my-unbound \
--detach=true \
--publish=53:53/tcp \
--publish=53:53/udp \
--restart=unless-stopped \
--volume=/my-directory/unbound:/opt/unbound/etc/unbound/ \
mvance/unbound:latest

Wurde hier also nicht der Ordner angegeben?

Was willst du immer mit deinem Äpfel & Birnen Vergleich, hast du noch was anderes?

Wie viele Änderungen hast du denn auf Github überhaupt eingereicht? Wenn du schon auf andere zeigst, solltest du vorangehen!

Was hat das eine mit dem anderen zu tun?

Auf deine weiteren komischen Aussagen und komischen Fragen gehe ich nicht weiter ein - alleine an deinem Schreibstil und deiner generellen Einstellung, dass jemand ein anderes Image bevorzugt spricht Bände...

Und danke, dass du dich so bei Github betätigst, wohin darf ich spenden?

 

[plang.pl]

Das mit der Bridge erachte ich nicht für sinnvoll. Auf der DS sieht man sonst als Anfrage m.W. immer das Gateway des Docker-Netzwerks und nicht die anfragenden Clients.
Das mit den leeren Dateien auskommentieren ist grundsätzlich sinnvoll. Einige möchten aber vielleicht in die Dateien was eintragen und dann sind sie immerhin schon mal da.

 

[update-freak]

@madnuttah

Wenn ich die Filemappings ergänze bekomme ich diesen Fehler; ohne läuft es jedoch Problemlos. Weißt du wie sich die root.key Datei erstellen lässt?

could not write builtin anchor, to file /usr/local/unbound/iana.d/root.key: Permission denied
[1714068106] libunbound[7:0] error: unable to open /usr/local/unbound/iana.d/root.key for reading: No such file or directory
[1714068106] libunbound[7:0] error: error reading auto-trust-anchor-file: /usr/local/unbound/iana.d/root.key
[1714068106] libunbound[7:0] error: validator: error in trustanchors config
[1714068106] libunbound[7:0] error: validator: could not apply configuration settings.
[1714068106] libunbound[7:0] error: module init for module validator failed
Apr 25 20:01:46 unbound[1:0] notice: init module 0: validator
Apr 25 20:01:46 unbound[1:0] notice: init module 1: iterator
Apr 25 20:01:47 unbound[1:0] info: start of service (unbound 1.19.3).