Neue Version hochgeladen. Inhalt unverändert, aber Links wunschgemäß reduziert.
Kann aus meiner Sicht von der Baustelle ins Wiki verschoben werden.
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: Beiträge: 9387 Wohnort: Münster |
Neue Version hochgeladen. Inhalt unverändert, aber Links wunschgemäß reduziert. Kann aus meiner Sicht von der Baustelle ins Wiki verschoben werden. |
||||
Anmeldungsdatum: Beiträge: 29567 |
Hallo, der Artikel ist im Wiki, Danke für's Erstellen ☺ Verlinkt ist er bis jetzt nur auf der systemd Seite. Weitere Verlinkungen auf anderen Seiten bei Bedarf bei noch vornehmen. Gruß, noisefloor |
||||
Anmeldungsdatum: Beiträge: Zähle... |
Warum heißt es im Artikel, man solle nicht gleichzeitig Methode A und B verwenden? Methode A und B können problemlos kombiniert werden, und das ist auch die Standardkonfiguration z.B. in Fedora. Die Idee dahinter ist (wie auch in obigem Link erklärt), daß Applikationen, die den DNS-Resolver der glibc verwenden, direkt mit systemd-resolved kommunizieren und nicht über den Stub-DNS-Server (Methode B), während Applikationen, die das DNS-Protokoll selbst implementieren, also den DNS-Resolver der glibc umgehen (z.B. nslookup) den Stub-DNS-Server in /etc/resolv.conf finden (Methode A). Gegenüber nur Methode A hat es den Vorteil, daß die meisten Applikationen effizienter sind, weil sie den Stub-DNS-Server nicht brauchen, gegenüber nur Methode B, daß die restlichen Applikationen auch systemd-resolved verwenden. Ich würde also (entgegen dem derzeitigen Wiki-Text) auf jeden Fall die kombinierte Methode A+B empfehlen. Ich kann auch bestätigen, daß das auf Ubuntu auch funktioniert, zumindest auf 20.04 LTS "Focal Fossa" (aber ich wüßte nicht, warum es auf anderen Versionen nicht funktionieren sollte). |
||||
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: Beiträge: 9387 Wohnort: Münster |
Es macht keinen Sinn, gleichzeitig beide Methoden zu aktivieren, weil – selbst wenn es dann funktionieren sollte – man dann die Arbeit doppelt tun lässt. Davon abgesehen, kann es auch nicht zuverlässig funktionieren, weil die Aktivierung von Methode A oder B eben auf der unterschiedlichen Natur der Datei /etc/resolv.conf beruht: Sie ist entweder ein symbolischer Link oder nicht und kann nicht beides gleichzeitig sein. Die Art der Datei ist in diesem Falle funktionsrelevant! Ob übrigens die Datei /etc/resolv.conf ein symbolischer Link ist oder nicht, ist auch für den NetworkManager relevant, der beim Mischen der Methoden A und B Probleme bekommt. Wenn Fedora das anders macht, hat dies keinerlei Relevanz für das UbuntuUsers.de-Wiki. Hier wird beschrieben, wie es bei Ubuntu funktioniert oder auch nicht funktioniert. Die schließlich und am wichtigsten: Die Warnhinweise stehen da, weil es beim ausführlichen Test zu funktionalen Problemen gekommen ist. Und weil es diese Beobachtungen gibt, die durchaus nicht in allen denkbaren Konstellationen zwangsläufig auftreten müssen, aber eben manchmal aufgetreten sind, kann ich die Kombination beider Methoden keinesfalls empfehlen. Gerade, weil die Probleme nur manchmal auftreten, muss man seriöser Weise davor warnen. Aber jeder Leser darf Warnungen ignorieren. |
||||
Anmeldungsdatum: Beiträge: 6 |
Ich habe doch gerade erklärt, warum ich beides brauche! Nicht jede Applikation geht für das DNS-Resolving über den Resolver der glibc, deshalb funktioniert nsswitch.conf nicht für alle Applikationen. Für die restlichen muß resolv.conf auf den Stub-Resolver umgestellt werden. Probiere mal, mit einer Split-DNS-Konfiguration (nur) Methode B anzuwenden und dann mit nslookup ein paar Domains innerhalb und außerhalb der Zuständigkeit des VPNs aufzulösen, du wirst überrascht sein!
Die Datei /etc/resolv.conf wird unter Methode B vom glibc-DNS-Resolver komplett ignoriert (!), daher ist es für Applikationen, die den verwenden, völlig irrelevant, ob die Datei eine einfache Datei oder ein symbolischer Link ist oder sogar überhaupt nicht existiert. Der symbolische Link auf die stub-resolv.conf wird nur für die Applikationen benötigt, die den Resolver der glibc umgehen.
Was für Probleme? Der NetworkManager erkennt den symbolischen Link und weiß daher, daß systemd-resolved verwendet wird und er daher seine DNS-Informationen nicht in /etc/resolv.conf hineinschreiben soll, sondern an eine Stelle, wo sie systemd-resolved auch finden kann. Das verhindert keinesfalls, systemd-resolved auch direkt über nsswitch.conf (also ohne den Stub-Resolver, für den der symbolische Link gesetzt wird) aufzurufen. Wie genau mit systemd-resolved kommuniziert wird, dafür ist der NetworkManager ja gar nicht zuständig. Ich sehe also nicht, wo es da zu Problemen kommen könnte. Bei mir hat es jedenfalls keine gegeben.
Wie gesagt, ich habe die kombinierte Methode A+B auf einem Ubuntu Focal Server getestet und sie funktioniert einwandfrei.
Und was waren diese Probleme? Könnte es sich um längst behobene Bugs in alten Versionen handeln? Das riecht für mich stark nach "cargo culting", das die optimale Lösung aufgrund längst obsoleter schlechter Erfahrungen verhindert.
Ich möchte diese unsinnigen Warnungen aber aus dem Wiki entfernt sehen, weil sie Benutzern von der optimalen, von systemd-Entwicklern empfohlenen (die von mir verlinkte Fedora-Change-Seite wurde von Zbigniew Jędrzejewski-Szmek mitgeschrieben, der auf https://github.com/systemd/systemd gleich an zweiter Stelle nach Lennart Poettering steht, letzterer kommt übrigens auch von Fedora / Red Hat) Methode abraten. |
||||
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: Beiträge: 9387 Wohnort: Münster |
Ubuntu Server 20.04 alleine ist nicht repräsentativ für die die Gesamtheit aller aktuellen Ubuntu-Systeme. Ich habe es seinerzeit unter Ubuntu 18.04 Desktop und Server sowie 20.04 Desktop und Server getestet und Probleme mit der DNS-Auflösung und der Netzwerk-Konfiguration durch NetworkManager beobachtet, wenn gleichzeitig beide Methoden angewendet wurden. Beim Server gab es weniger Probleme, weil hier eben kein NetworkManager eingesetzt wird.
Was Du im Trotz als unsinnig ansiehst, sehen andere (auch ich) anders. Fedora und Ubuntu sind unterschiedliche Betriebssysteme und was bei dem einen gut funktioniert kann beim anderen Ärger verursachen. Wie gesagt: Bei Ubuntu ist generell eine gleichzeitige Anwendung nicht sinnvoll, weil für aktuelle Systeme negative Erfahrungen vorliegen. Vielleicht ist es für 22.04 anders, das bleibt abzuwarten und zu testen. Und wenn es für einen speziellen Anwendungsfall gut funktioniert, gilt es noch lange nicht generell. Und wenn Du es für einen sehr speziellen Anwendungsfall sogar benötigst, ist das auch kein Anlass für eine generelle Empfehlung. Im Übrigen weist sogar die von Dir verlinkte Seite im Fedora-Wiki darauf hin, dass es zu Wechselwirkungen mit NetworkManager kommen kann! |
||||
Anmeldungsdatum: Beiträge: 6 |
Fedora verwendet jedenfalls auch NetworkManager, also daran alleine kann es nicht liegen.
Gibt es zu den nicht-LTS-Zwischenversionen keine Erfahrungswerte?
Eine Interaktion ist noch nicht automatisch ein Konflikt. Es ist schade, denn diese sonst sehr übersichtliche Wikiseite wird durch die für mich nicht nachvollziehbaren Warnungen so weit unbrauchbar gemacht, daß ich sie nicht guten Gewissens verlinken kann. Es lesen übrigens auch Nutzer*innen anderer Distributionen eure Wikiseiten, der Cargo-Cult könnte sich also auch noch deutlich weiter verbreiten, als du es vermuten würdest. |
||||
Anmeldungsdatum: Beiträge: 6 |
Was ich jedenfalls sicher sagen kann, ist, daß die "doppelte" Konfiguration auf Ubuntu 20.04 LTS Focal Fossa (Server), Fedora 33 (KDE Plasma) und Fedora 35 (KDE Plasma) mit einem split-DNS-VPN (das auf dem erwähnten Ubuntu-Focal-Server läuft, mittels dnsmasq) problemlos funktioniert. Übrigens: dnsmasq und systemd-resolved kommen sich nicht in die Quere, wenn dnsmasq mit |
||||
Anmeldungsdatum: Beiträge: 6 |
Wobei die systemd-resolved-Konfiguration auf dem Server keine Split-DNS-Konfiguration ist, weil der Server ja kein VPN-Client, sondern "nur" ein VPN-Server ist, und dnsmasq Abfragen an systemd-resolved schickt und nicht umgekehrt. Nur auf den (Fedora-)Clients wird Split-DNS verwendet. Der Server verwendet eigentlich nur deshalb systemd-resolved, weil es in Ubuntu Focal Standard ist. |
||||
Anmeldungsdatum: Beiträge: 29567 |
Hallo,
Es ist schon klar, dass sich das Wiki auch bei Nutzern anderer Distribution, sich einer gewissen Beliebtheit erfreut. Und sicherlich ist auch viele ohne größere Probleme auf andere Distros übertragbar. Nichts desto trotz ist das Wiki nur (und nur) relevant, was auf einem *buntu getestet wurde und läuft. Ob etwas auf Mint oder Debian oder ... läuft und darum auch auf Ubuntu laufen müsste hat keine Relevanz. Es ist halt ein Ubuntu-Wiki (=Ubuntu und offizielle Derivate) und es gibt auch z.Zt. null Bestrebungen, daran was zu ändern.
In Bezug auf den Wikiartikel hier: scheinbar nicht. Die Erfahrung ist her auch eher so, dass je "tiefer" ("low level") das Thema ist - was IMHO bei systemd-resolvd gegeben ist - desto weniger testen das bzw. interessieren sich für die STS Releases von *buntu. Was nicht heißt, dass das nicht alles 1:1 übertragbar ist. Hat halt nur entweder keiner wirklich getestet oder der, der es getestet hat, hat es nicht im Wiki manifestiert. Zum Ausgangspunkt: wenn es ein (reproduzierbares) Problem gibt, dann darf und soll das im Wikiartikel erwähnt werden. Normalerweise am Ende im Abschnitt "Problembehebung". Im gegebenen Fall macht es aber schon Sinn, dass nach vorne zu packen, weil das ja quasi den ganzen Artikel betrifft. In wie fern das ganze alle *buntus betrifft oder ggf. nur ein Problem für einen (kleinen) Teil der *buntus ist kann ich nicht beurteilen, weil ich systemd-resolvd selber nicht nutzen. Dass sich darüber bisher noch keiner beschert hat kann halt zwei Gründe haben: a) ist es ein reales Problem und alles ist 1:1 richtig, wie es im Wiki steht oder b) das Thema interessiert eigentlich niemanden, deswegen fallen auch mögliche Fehler im Artikel nicht auf. Gruß, noisefloor |
||||
Anmeldungsdatum: Beiträge: 6 |
Das entweder-oder verursacht auch Probleme, z.B. https://github.com/calamares/calamares/issues/1942. |
||||
Wikiteam
Anmeldungsdatum: Beiträge: 1480 Wohnort: Bad Oeynhausen |
Ich habe diesen Artikel getestet und auf meinem Noble funktioniert Methode B nicht, sondern es wird verlangt, dass /etc/resolv.conf ein symbolischer Link auf /run/systemd/resolve/stub-resolv.conf ist, wie mittlerweile auch bereits bei Systeminstallation eingerichtet (eine leere Datei funktioniert auch nicht); andernfalls funktioniert die Namensauflösung überhaupt nicht mehr. Es brachte auch nichts, den Namen des Moduls
|
||||
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: Beiträge: 9387 Wohnort: Münster |
Methode B ist aus heutiger Sicht zu knapp beschrieben. Wenn man die Datei /etc/resolv.conf selbst verwalten möchte, muss man die Verwaltung vorher sowohl systemd-resolved als auch NetworkManager entziehen. Die Methoden dazu (leere Dateien, Symlinks) sind wohl versionsabhängig. Das Abhängigkeitsgestrüpp zwischen den Konfigurationsprogrammen (und zusätzlich Netplan) ist unerfreulich unübersichtlich (jedenfalls für mich) und variabel. Ich schlage vor, Methode B als fehlerhaft ab noble zu markieren. |
||||
Wikiteam
Anmeldungsdatum: Beiträge: 1480 Wohnort: Bad Oeynhausen |