staging.inyokaproject.org

Hallo,

IMHO ist der Artikel immer noch an diversen Stellen ziemlich unverständlich, wenn man das selber noch nie gemacht hat.

Was mir gerade so aufgefallen ist:

"Bei Systemen ab 17.10 muss systemd-resolved manuell deaktiviert werden, damit keine Störungen auftreten." → wie denn? Link auf eine Wiki-Artikel, der das beschreibt?

"Der NetworkManager muss zudem so konfiguriert werden, dass dieser resolvconf nutzt." → wie denn? Wo steht, wie das geht?

"Hier erfolgen die Angaben in den Verbindungsdateien im Verzeichnis /etc/NetworkManager/system-connections/" → welche denn? Es scheint ja mehrere zu geben, da in der Mehrzahl geredet wird. Alles Verbindungsdateien? Nur selektierte?

Und der allerletzte Link unter Links ist ein Deadlink.

Gruß, noisefloor

systemctl disable systemdresolved

Den Teil zum NetworkManager suche ich noch raus.

noisefloor schrieb:

[…] "Bei Systemen ab 17.10 muss systemd-resolved manuell deaktiviert werden, damit keine Störungen auftreten." → wie denn?

systemd-resolved läuft als Systemdienst, welcher vom Init-System gestartet wird. Standard dafür ist systemd. Jedenfalls muss man im Init-System den Start von systemd-resolved verbieten.

[…] "Der NetworkManager muss zudem so konfiguriert werden, dass dieser resolvconf nutzt." → wie denn?

Hier geht es um die Konfigurationsoption dns= des NetworkManager, welche bei Ubuntu üblicherweise in der Datei /usr/lib/NetworkManager/conf.d/10-dns-resolved.conf gesetzt wird. Ich würde diese Datei nicht direkt verändern, sondern durch eine gleichnamige Datei in /etc/Networking/conf.d/ übersteuern. Zulässige Werte für die Option dns= sind dnsmask, unbound, systemd-resolved, none. Der Wert darf leer sein (unspezifiziert), dann gilt als Vorgabe systemd-resolved. Diese Informationen gehören aber wohl nicht in diesen Wiki-Artikel. Welchen Manager NetworkManager zum Setzen der DNS-Informationen benutzt, wenn er systemd-resolved nicht benutzen soll, und wie man das konfiguriert, ist mir unklar und wohl nur durch umfangreiche Tests zu ermitteln. Auf jeden Fall muss man ihm sagen, systemd-resolved nicht zu verwenden.

[…] "Hier erfolgen die Angaben in den Verbindungsdateien im Verzeichnis /etc/NetworkManager/system-connections/" → welche denn? Es scheint ja mehrere zu geben, da in der Mehrzahl geredet wird. Alles Verbindungsdateien? Nur selektierte?

Gemeint ist das Profil, welches man zum Herstellen der Verbindung tatsächlich benutzen will. In dieses kann man die Einstellungen für den DNS-Resolver wie DNS-Server, Suchpfad usw. packen. Man kann diese Angaben wohl auch in einer grundlegenden Konfigurationsdatei in /etc/Networking/conf.d/ machen. Dann gelten sie für alle Profile.

Und der allerletzte Link unter Links ist ein Deadlink.

Ja. Das ist ein fehlender Artikel, den ich schreiben wollte und den ich für viel wichtiger halte als den hier diskutierten. Schließlich ist systemd-resolved aktuelle Realität und resolvconf bei Ubuntu Historie.

Baustelle gelöscht

Hallo,

Baustelle gelöscht

Warum? Ich hatte die Diskussion bis dato nicht so verstanden, dass das Ding nicht doch zu Ende gebracht wird...

Gruß, noisefloor

Das kann aus meiner Sicht eigentlich den Status der Baustelle verlassen.

Ein Test für 18.04 oder neuere Versionen erübrigt sich, da eben resolvconf standardmäßig nur noch von 16.04 LTS benutzt wird. Nach April 2021 darf das dann ohne Schmerz ins Archiv.

Persönlich hätte ich kein Problem damit, die Prozedur des Live-schalten zu machen. Ich frage mich nur, ob das Sinn macht, wenn er in gut vier Monaten eh hinfällig wird. Was meinen die anderen?

Hi!

Wenn ich es richtig sehe, ist der Artikel nie aus der Baustelle rausgekommen - insofern muss er auch nicht archiviert, sondern kann gelöscht werden.

so long
hank

Ich sehe keinen Grund, den Artikel nicht jetzt (d.h. effektiv wohl im Januar 2021) in normalen Verfahren aus der Baustelle zu entlassen, denn

• er ist fertig und

• er ist für ein momentan unterstütztes Betriebssystem getestet.

Auch wenn seine Lebensdauer vermutlich nur kurz sein wird, ist das kein Grund für eine Sonderbehandlung.

Außerdem wird ja nach meiner Kenntnis erst nach einer Karenzzeit von 6 Monaten archiviert, also in diesem Fall wohl im November 2021.

Hi!

OK, hatte deinen Post oben anders interpretiert, da der Artikel schon seit längerem den Status "Baustelle/Verlassen" hatte - und wir sind derzeit schon dabei, xenial rauszuschmeißen, wenn Artikel aktualisiert werden.

Sehe gerade:: noisefloor hat ihn gerade verschoben.

Ansonsten gilt: Baustellen, die nicht veröffentlicht waren, werden in der Regel nicht archiviert.

so long
hank

Hallo,

es ist zwar ein bisschen ungewöhnlich, jetzt noch einen "Xenial only" Artikel zu veröffentlichen - aber formell spricht nichts dagegen.

Artikel ist im Wiki, Danke für's Erstellen! Bitte noch an geeigneter Stelle verlinken.

Gruß, noisefloor

Bitte diesen Artikel jetzt archivieren und sofort wieder als Baustelle eröffnen!

Zur Begründung siehe den gerade von mir im Artikel angebrachten Hinweis.

Könnte man den Artikel dann im Archiv z.B. als „resolvconf (eigenständiges Programm)“ benennen?

Hi!

Hm, etwas schwierig - ein Artikel kann sinnnvollerweise nicht gleichzeitig im Archiv und in der Baustelle sein (geht auch wg. Versionshistorie nicht wirklich)... Entweder du legst eine eigen Baustelle an, oder ich schiebe dir den Artikel in die Baustelle, und wir sehen zu, dass nach Fertigstellen der Baustelle der "alte" entsprechend behandelt wird, (mit Hinweis auf Historie, Umbenennung etc).

so long
hank

Hallo,

Bitte diesen Artikel jetzt archivieren und sofort wieder als Baustelle eröffnen!

Das macht keinen Sinn und ist nicht Sinn der Sache - siehe Ausführungen von Heinrich_Schwietering.

Was ist den das _Ziel_? Wenn es nur um den Alias "resolvconf" geht, dann wäre das richtige Vorgehen:

• du legst eine Baustelle zu resolvctl an

• bestehenden Artikel mit dem EOL von Xenial ins Archiv

• dann kann ein Redirect resolvconf → resolvctl angelegt werden

Gruß, noisefloor

Das Ziel ist dieses Chaos zu ordnen, was ich durch mehrere Wiki-Seiten erreichen möchte:

1. Es gibt außerhalb des systemd-Universiums das Paket/Programm resolvconf, welches früher bei Ubuntu standardmäßig installiert und zur Verwaltung der Datei /etc/resolv.conf verwendet wurde. Dies ist im momentan real existierenden Artikel resolvconf beschrieben, welcher gerne sofort ins Archiv darf.

2. Das Programm systemd-resolve/resolvectl/resolvconf aus dem systemd-Clan ist schizophren. Das sind nicht nur mehrere Namen, sondern völlig unterschiedliche Verhaltensweisen. Nur die Persönlichkeit resolvconf soll in einem neuen Artikel beschrieben werden, der keine Historie zum alten Artikel resolveconf haben darf. Mir geht es nur um diesen Punkt.

3. Das echte Programm resolvconf ist nach wie vor installierbar. (Was aber wahrscheinlich keine gute Idee wäre.) Wenn das jemand machen und im Wiki beschreiben wollte, wäre eine Kontinuität zum jetzigen Artikel sinnvoll.

Ich versuche mal für den 2. Punkt eine Baustelle anzulegen. → Baustelle/systemd/resolvconf