DNS-Resolver funktioniert nach einiger Zeit nicht mehr

thiasaef

@nonick nein, aber daran lag es leider auch nicht.

thiasaef

Ich bekomm keinen dieser Commits via System / Patches nachinstalliert. Dann bleibt wohl wirklich nur ein Downgrade auf 2.5.2.

JeGr

@thiasaef Man soll auch nicht einfach random irgendeinen Commit installieren.

Die Frage ist ja ob die aktuelle SystemPatches Version mit dem o.g. Commit funktioniert und die Felder ausfüllt nach einem Fetch oder nicht. Das Apply ist ja nochmal nen anderer Punkt.

thiasaef

@jegr said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:

Man soll auch nicht einfach random irgendeinen Commit installieren.

Schon klar, es ging ja erst mal nur darum herauszufinden, ob es sich um einen simplen Merge Conflict handelt, oder ob der Hund wo anders begraben ist.

Die Frage ist ja ob die aktuelle SystemPatches Version mit dem o.g. Commit funktioniert und die Felder ausfüllt nach einem Fetch

Klares nein.

JeGr

@thiasaef OK also hast du Probleme mit dem neuen SysPatch Update 2.x

Dann geh bitte mal so vor:

wie oben anlegen
Fetch drücken
ID sollte sich jetzt zu voller URL geupdated haben, aber das Textfeld ist leer (?)
URL in einem Browser aufmachen
Strg+A, Strg+C (alles kopieren was angezeigt wird, sollte nur Text sein und von "From ec7... bis ?> gehen"
den ganzen Schmodder bei "Patch Contents" einfügen
Rest so lassen (Strip Count 2, Base /, Ignore Whitespaces)
speichern

Jetzt sollte Apply/Revert und Test auftauchen. Testen, Apply drücken, gegenprüfen :)

Edit: Patch wohl in Vorbereitung um das zu reparieren: https://forum.netgate.com/topic/170300/new-system-patches-v2-0/16

thiasaef

@jegr mit System_Patches 2.0_4 hat es jetzt ohne Umweg über "Patch Contents" funktioniert.

Edit: Der DNS Resolver funktioniert jetzt wieder, aber sauber gelöst ist das Problem damit leider nicht, denn Unbound legt jetzt einen kompletten Neustart hin, sobald ein direkt an der Firewall angeschlossenes Gerät ein oder ausgeschaltet wird.

JeGr

@thiasaef said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:

Edit: Der DNS Resolver funktioniert jetzt wieder, aber sauber gelöst ist das Problem damit leider nicht, denn Unbound legt jetzt einen kompletten Neustart hin, sobald ein direkt an der Firewall angeschlossenes Gerät ein oder ausgeschaltet wird.

a) was ist daran nicht sauber wenn es funktioniert?
b) was ist ein "an der FW angeschlossenes Gerät"? Normalerweise hängt ne Firewall am Switch und daran ein Gerät.
c) Unbound hatte schon immer ein paar Macken, bei soft-reloads warum man ja lange bei per DHCP-hinzugefügten Namen nen Neustart getriggert hatte um sicher zu sein dass es sauber geladen wird.

Aber dass man nen Dienst durchtritt, wenn es ein Interface Event gibt ist jetzt nichts abartig neues. Es gibt eben Dienste die mehr oder weniger gut drauf klarkommen, dass ihr Binding an ein Interface nicht mehr existiert und die dann damit nicht gut umgehen können. Und wenn unbound auf "Interface any" gebunden ist und eines wird runtergefahren (weil Gerät direkt an FW hängt) dann muss ich eben den Service durchtreten damit er das mitbekommt, dass er nicht mehr am Interface hängt. Verstehe da nicht was unsauber daran ist. Natürlich wäre es besser nen online reload schicken zu können, aber es wird ja einen Grund haben, dass ein restart statt einem reload gemacht wird?

thiasaef

@jegr said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:

a) was ist daran nicht sauber wenn es funktioniert?

Unbound ist temporär nicht erreichbar und der DNS Cache geht ebenfalls jedes Mal komplett verloren, ansonsten siehe: https://redmine.pfsense.org/issues/5413

was ist ein "an der FW angeschlossenes Gerät"? Normalerweise hängt ne Firewall am Switch und daran ein Gerät.

In meinem Fall drei Endgeräte, die alle mehrmals am Tag ein- bzw. ausgeschaltet werden.

c) Unbound hatte schon immer ein paar Macken, bei soft-reloads

Wenn es am Zusammenspiel zwischen Unbound und FreeBSD läge, müsste OPNsense genauso betroffen sein. Ist es das?

Aber dass man nen Dienst durchtritt, wenn es ein Interface Event gibt ist jetzt nichts abartig neues.

Ja, wenn es einen Grund dafür gäbe, der nicht "der Weg des geringsten Widerstandes" lautet und außerdem war der Neustart in 2.4.5-p1 ja offenbar auch nicht nötig.

aber es wird ja einen Grund haben, dass ein restart statt einem reload gemacht wird?

Kurz und knapp Faulheit.

JeGr

@thiasaef said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:

Wenn es am Zusammenspiel zwischen Unbound und FreeBSD läge, müsste OPNsense genauso betroffen sein. Ist es das?

Jetzt neuerdings - ja/jein, vorher nicht, nein. OPNsense hatte nicht FreeBSD als BaseOS drunter, sondern einen "Spezialfork" den sie jetzt im letzten Release rausgenommen haben, weil der Sinn und Nutzen kaum noch gegeben war und die Nachteile wie Warten auf Pakete und Commits zu groß.

@thiasaef said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:

Unbound ist temporär nicht erreichbar und der DNS Cache geht ebenfalls jedes Mal komplett verloren, ansonsten siehe: https://redmine.pfsense.org/issues/5413

Das stimmt natürlich.

@thiasaef said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:

Ja, wenn es einen Grund dafür gäbe, der nicht "der Weg des geringsten Widerstandes" lautet und außerdem war der Neustart in 2.4.5-p1 ja offenbar auch nicht nötig.

Doch, war er bereits da schon. Die Implementierung war schon seit 2.4.x mit restart und beim Resolver, dass man keine DHCP Leases hinzufügen sollte da sonst die Neustarts zu häufig laufen.

@thiasaef said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:

Kurz und knapp Faulheit.

Das ist schlicht ne Unterstellung die niemand was bringt.

thiasaef

@jegr said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:

Die Implementierung war schon seit 2.4.x mit restart

Da muss ich widersprechen. Bei 2.4.5-p1 wurde Unbound definitiv nicht bei jedem rc.newwanip Event neu gestartet.

Das ist schlicht ne Unterstellung die niemand was bringt.

Stimmt, aber solange mir niemand einen besseren Grund nennt, bleibt das meine Arbeitshypothese.

bytegetter

Note: Kurz danach kam ein Update der das Problem behob.