kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
Das erscheint mir inhaltlich reif für die Entlassung aus der Baustelle. Natürlich ist der Artikel gemessen an den Möglichkeiten von systemd-networkd noch unvollständig bzgl. LLMNR, MulticastDNS, DNSSEC usw. Wie man das aus- und einschaltet ist aber trivial und die nicht-trivialen Anwendungsbeispiele dazu mögen später gerne fleißige Wiki-Autoren z.B. in passenden Unterseiten hinzufügen, ich werde das jetzt nicht übernehmen. Dagegen wäre ich dankbar für Hinweise auf übersehene Fehler und welche Dinge beim alltäglichen Umgang mit dem DNS-Cache noch erwähnt werden sollten.
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Sieht auf die Schnelle betrachtet gut aus - nur dass etwa 5 selbstreferenzielle Links auf systemd-resolved drin sind... Gibt es eine Projektseite, wohin der erste in der Einleitung verweisen könnte? Bei den anderen könnte wohl schlicht das [:...:] rausgenommen werden. so long hank
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Ich finde den Artikel super! Freue mich schon auf deine Überarbeitung von networkd 😉 Offensichtliche Fehler kann ich keine entdecken. Im Zeitalter von pihole & Co könnte man noch kurz den Konflikt zwischen anderen DNS-Diensten (dnsmasq,bind9…) und systemd-resolved erwähnen. Ich kann dazu allerdings nicht all zu viel sagen, da ich den faulen Weg gegangen bin und systemd-resolved einfach nicht zusammen mit dnsmasq nutze 😉 Eventuell könntest du noch glibc erklären oder verlinken, ich vermute, dass das nicht jedem Einsteiger ein Begriff ist.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Prima. Ein, zwei Details:
Die Hauptkonfigurationsdatei /etc/systemd/resolved.conf dokumentiert die bei der Übersetzung des Programms definierte Voreinstellung. Man kann diese Datei abändern; dies sollte man aber vermeiden, da man sonst keine Dokumentation über die Voreinstellung mehr hat und nutzt besser die hier folgend beschriebenen weiteren Konfigurationsdateien.
Die Datei dokumentiert klingt ein wenig merkwürdig für mich, als sei die Datei evtl. nur zur Dokumentation gedacht. Der folgende Satz klärt es mehr oder weniger auf, aber ich kenne das Vorgehen auch schon von einigen anderen Programmen, dass Konfigurationsdateien die Einstellungen auflisten, die ohnehin gelten. Wäre:
Die Hauptkonfigurationsdatei /etc/systemd/resolved.conf listet die ohnehin für das Programm definierten Voreinstellungen auf und eignet sich daher auch als Dokumentation.
vielleicht besser? Ich würde auch nicht vom Ändern abraten. Persönlich halte ich es so, dass ich bei minimalen Änderungen den Urzustand als Kommentar drinlasse, und eine Kommentarzeile dazusetze mit einem Kürzel (mod uu/ins uu/del uu) für modifiziert, insert, delete, immer nach Schema F, um leicht danach greppen zu können, oder bei größeren Änderungen lege ich eine xy.conf.orig an. Solche Methoden sind in dem Artikel natürlich off-topic, aber im Ernstfall findet man ja auch hier im Forum jmd., der einem eine Kopie der Orginaldatei schickt (wenn man dann noch ins Netz kommt). Oder auf einer Live-DVD oder in einer VM.
Nach der Hauptkonfigurationsdatei werden noch alle auf .conf endenden Dateien in diesen Verzeichnissen berücksichtigt: /usr/lib/systemd/resolved.conf.d/ (vorgesehen für Distributionen) /usr/local/lib/systemd/resolved.conf.d/ (vorgesehen für Distributionen) /run/systemd/resolved.conf.d/ (temporär) /etc/systemd/resolved.conf.d/ (vorgesehen für den Verwalter des Rechners)
Punkt 1 gilt für 20.04, auf 18.04 nicht:
| l -d /usr/lib/systemd/resolv*
ls: Zugriff auf '/usr/lib/systemd/resolv*' nicht möglich: Datei oder Verzeichnis nicht gefunden
|
Seit wann das so ist (18.10, 19.04, ...?) kann ich nicht sagen. Sonst würde ich einfach "(seit 1899)" dazu setzen. Vielleicht "(nicht: 18.04)" zufügen? Punkt 2:
| l -d /usr/local/lib/systemd/resolv*
ls: Zugriff auf '/usr/local/lib/systemd/resolv*' nicht möglich: Datei oder Verzeichnis nicht gefunden
|
finde ich weder auf 18.04, noch auf 20.04. Vielleicht "(verwendet von manch anderen Distributionen)" schreiben, dass die Leute erst gar nicht suchen, bzw. nur die richtigen Leute? Bei Punkt 3 finde ich das "temporär" nicht aussagekräftig genug. Das könnte auch heißen, dass es mit 20.10 kam aber in 21.04 wieder verschwinden wird. Vielleicht "temporär zur Laufzeit" schreiben?
|
kB
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
Heinrich_Schwietering schrieb: […] etwa 5 selbstreferenzielle Links auf systemd-resolved
Es sind 12!
[…] Projektseite
Ist jetzt unter Links aufgeführt. Die 12 selbst referenziellen Links auf systemd-resolved ändere ich noch per Massenbearbeitung und lade morgen eine neue Version hoch.
|
kB
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
ChickenLipsRfun2eat schrieb: Ich finde den Artikel super! Freue mich schon auf deine Überarbeitung von networkd 😉
Danke.
[…] Konflikt zwischen anderen DNS-Diensten (dnsmasq,bind9…) und systemd-resolved erwähnen.
Ein wichtiger Punkt! Habe ich Warnhinweis aufgenommen und einen Diagnosebefehl hinzugefügt.
Eventuell könntest du noch glibc erklären oder verlinken
glibc erklären wäre an dieser Stelle heftig OT und an anderer Stelle für mich eine Überforderung. Ein Verweis auf die Quelle muss ausreichen.
|
kB
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
user_unknown schrieb: Prima.
Danke.
[…] Die Datei dokumentiert klingt ein wenig merkwürdig für mich, als sei die Datei evtl. nur zur Dokumentation gedacht.
Das ist lt. Programmdokumentation tatsächlich der primäre Zweck dieser Datei. Hier stehen die Voreinstellungen, welche für das hier eingesetzte Kompilat gelten, d.h. bei anderen Distributionen können andere Voreinstellungen gelten.
Der folgende Satz klärt es mehr oder weniger auf
Genau. Man kann (und darf auch) diese Datei zur Konfiguration verwenden. Wenn man dabei in unvorsichtiger Weise Informationen vernichtet, ist man selber schuld.
[…]
Wäre:
Die Hauptkonfigurationsdatei /etc/systemd/resolved.conf listet die ohnehin für das Programm definierten Voreinstellungen auf und eignet sich daher auch als Dokumentation.
vielleicht besser?
Nein. Aber ich werde über die Formulierung nachdenken und bei der nächsten Version ggf. ändern.
Ich würde auch nicht vom Ändern abraten.
Ich verbiete das Ändern nicht. Ich zeige nur einen Weg auf, wie man das Ändern in dieser Dokumentationsdatei vermeiden kann.
[…] Nach der Hauptkonfigurationsdatei werden noch alle auf .conf endenden Dateien in diesen Verzeichnissen berücksichtigt: […]
systemd-resolved durchsucht lt. Programmdokumentation die genannten Verzeichnisse. Natürlich nur, wenn sie existieren. Es ist kein Fehler, wenn sie nicht existieren. Bei Ubuntu existieren in der Tat die meisten nicht, aber root darf sie anlegen. Das erscheint mir aber alles trivial und nebensächlich.
Bei Punkt 3 finde ich das "temporär" nicht aussagekräftig genug. Das könnte auch heißen, dass es mit 20.10 kam aber in 21.04 wieder verschwinden wird. Vielleicht "temporär zur Laufzeit" schreiben?
Das Verzeichnis /run/ selbst (und natürlich alles, was darin aufbewahrt wird) ist temporär in dem Sinne, dass es mit dem Abschalten des Rechners aus der Welt verschwindet und beim Start des Systems neu erschaffen wird.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
kB schrieb: […] Die Datei dokumentiert klingt ein wenig merkwürdig für mich, als sei die Datei evtl. nur zur Dokumentation gedacht.
Das ist lt. Programmdokumentation tatsächlich der primäre Zweck dieser Datei. Hier stehen die Voreinstellungen, welche für das hier eingesetzte Kompilat gelten, d.h. bei anderen Distributionen können andere Voreinstellungen gelten.
Der folgende Satz klärt es mehr oder weniger auf
Genau. Man kann (und darf auch) diese Datei zur Konfiguration verwenden. Wenn man dabei in unvorsichtiger Weise Informationen vernichtet, ist man selber schuld.
[…]
Wäre:
Die Hauptkonfigurationsdatei /etc/systemd/resolved.conf listet die ohnehin für das Programm definierten Voreinstellungen auf und eignet sich daher auch als Dokumentation.
vielleicht besser?
Nein. Aber ich werde über die Formulierung nachdenken und bei der nächsten Version ggf. ändern.
Ich würde auch nicht vom Ändern abraten.
Ich verbiete das Ändern nicht. Ich zeige nur einen Weg auf, wie man das Ändern in dieser Dokumentationsdatei vermeiden kann.
Und ich habe nicht behauptet, dass Du es verbietest. ☺ Ich habe ein wenig Erfahrung mit den Konfigurationskonventionen unter Ubuntu/Linux - mir musst Du es nicht erklären. Ich überlege wie es auf jemanden wirkt, der sehr wenig Erfahrung damit hat.
[…] Nach der Hauptkonfigurationsdatei werden noch alle auf .conf endenden Dateien in diesen Verzeichnissen berücksichtigt: […]
systemd-resolved durchsucht lt. Programmdokumentation die genannten Verzeichnisse. Natürlich nur, wenn sie existieren. Es ist kein Fehler, wenn sie nicht existieren. Bei Ubuntu existieren in der Tat die meisten nicht, aber root darf sie anlegen. Das erscheint mir aber alles trivial und nebensächlich.
Bei Punkt 3 finde ich das "temporär" nicht aussagekräftig genug. Das könnte auch heißen, dass es mit 20.10 kam aber in 21.04 wieder verschwinden wird. Vielleicht "temporär zur Laufzeit" schreiben?
Das Verzeichnis /run/ selbst (und natürlich alles, was darin aufbewahrt wird) ist temporär in dem Sinne, dass es mit dem Abschalten des Rechners aus der Welt verschwindet und beim Start des Systems neu erschaffen wird.
Das ist mir bekannt, aber nicht jedem, der den Artikel liest.
|
kB
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
user_unknown schrieb: […] Ich überlege wie es auf jemanden wirkt, der sehr wenig Erfahrung damit hat.
Das sehe ich als sehr löblichen Absatz und wertvollen Beitrag. Ich habe aber den Artikel als „erfordert Erfahrung, richtet sich an Fortgeschrittene“ klassifiziert. Die Anregungen von Heinrich_Schwietering, ChickenLipsRfun2eat und user_unknown habe ich nun berücksichtigt. Vielen Dank für die Mitarbeit.
|
kB
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
Da es seit dem 05.02.2021 keine Rückmeldungen mehr gab und mir auch nichts mehr dazu einfällt, bitte die Baustelle auflösen!
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo, kannst du bitte noch die Linkflut entfernen? Es reicht, wenn man das 1. Vorkommen eines Wort / Programmnamens verlinkt - und nicht jedes. Sehr auffällig ist das bei [#Links systemd-resolved] , trifft aber wahrscheinlich noch auf andere Worte / Programmnamen zu. Ansonsten passt der Artikel. Gruß, noisefloor
|
dirkolus
Anmeldungsdatum: 17. Mai 2011
Beiträge: 2003
Wohnort: dahoam
|
Hallo kB, Vielen Dank für diesen hilfreichen Artikel. Ich habe dazu tatsächlich gleich ein paar inhaltliche Fragen, weil das m.E. in dem Artikel nicht klar herauskommt:
systemd-networkd ohne systemd-resolved geht wohl nicht (dachte ich bislang zumindest), aber kann man andersherum systemd-resolved ohne systemd-networkd betreiben? In der Achtung-box wird zwar die (fehlende) Zusammenarbeit mit NetworkManager etwas beschrieben, aber es wird nicht klar, ob man in NetworkManager nur den DNS-cache abschalten kann (auf der NM-Seite hab ich auf die Schnelle keinen Hinweis gefunden) oder den NM damit komplett abschalten muss? Die üblichen Tools dig, host, nslookup funktionieren offenbar mit Methode B - wie sieht es hier mit Methode A aus? Ich frage mich das auch vor dem Hintergrund, dass Methode A die (seitens des Projektes) präferierte Variante ist - wo ist bei A der Vorteil?
Dirk
|
kB
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
noisefloor schrieb: […] kannst du bitte noch die Linkflut entfernen? Es reicht, wenn man das 1. Vorkommen eines Wort / Programmnamens verlinkt - und nicht jedes.
Ich empfinde gerade dies wegen der unterschiedlichen Schreibweisen als chic. Schade, dass es nicht auf Gegenliebe trifft. Ich werde also eine neue Version hochladen und mich dann wieder melden. Sollen in dieser die Programmnamen normal oder fett (weil es ja Dateien sind) geschrieben werden?
|
kB
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
dirkolus schrieb: […]
systemd-networkd ohne systemd-resolved geht wohl nicht
Doch, das geht. Es sind zwei Programme mit unterschiedlichen Aufgaben. Man kann jedes ohne das andere verwenden und umgekehrt.
[…] kann man andersherum systemd-resolved ohne systemd-networkd betreiben?
Ja. NetworkManager in seiner Voreinstellung macht das beispielsweise.
In der Achtung-box wird zwar die (fehlende) Zusammenarbeit mit NetworkManager etwas beschrieben,
Von fehlender Zusammenarbeit steht da nichts. Im Gegenteil: NetworkManager benutzt systemd-resolved und setzt natürlich voraus, dass er diese Ressource exklusiv nutzen kann. Dies trifft normalerweise auch zu. Konfliktpotential entsteht erst dann, wenn auch der Administrator des Rechners am NetworkManager vorbei an systemd-resolved herum konfiguriert.
aber es wird nicht klar, ob man in NetworkManager nur den DNS-cache abschalten kann (auf der NM-Seite hab ich auf die Schnelle keinen Hinweis gefunden) oder den NM damit komplett abschalten muss?
Zur Auflösung des Konflikts hat der Administrator (nur bei diesem, nicht beim NetworkManager, besteht die Hoffnung, dass er schlau genug dafür ist) die in der Box genannte 3-fache Alternative: Nimm dem NetworkManager sein Spielzeug systemd-resolved weg. Wie man das macht, ist zwar durchaus nicht trivial, wäre aber in diesem Artikel sachfremd. Schlag den NetworkManager tot. Akzeptiere, dass es Fehlfunktionen geben kann. (Und sei vorsichtig.)
Jede Wahlmöglichkeit hat Nachteile, löst aber bereits einzeln angewendet den Konflikt auf.
Die üblichen Tools dig, host, nslookup funktionieren offenbar mit Methode B - wie sieht es hier mit Methode A aus? Ich frage mich das auch vor dem Hintergrund, dass Methode A die (seitens des Projektes) präferierte Variante ist - wo ist bei A der Vorteil?
Methode A und B sind unterschiedliche Wege zur Konfiguration des DNS-Resolvers in der glibc. Alle Programme, welchen diesen Resolver benutzen, sollten von diesen Details unbeeinflusst sein. Es ist aber unklug, beide Methoden zu mischen, da sonst z.B. wegen unnötiger Mehrfachanfragen an die DNS-Server sich das Zeitverhalten verschlechtern kann. Wer etwas doppelt macht, braucht dafür meist halt länger. Was besser ist? Das hat die gleiche Qualität wie die Kaufentscheidung zwischen einem Maserati und einem Ferrari.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo,
Sollen in dieser die Programmnamen normal oder fett (weil es ja Dateien sind) geschrieben werden?
Konvention ist wenn nur das 1. Vorkommen fett (wenn es kein Link ist). Im restlichen Text kann dann ganz normal so system-resolved stehen. Ist auch für's Lesen besser als wenn immer wieder Fettschrift kommt. Gruß, noisefloor
|