staging.inyokaproject.org

Hallo,

vielen Dank für den Artikel. Sehr gut lesbar und gut strukturiert wie ich finde. 👍

Hier wie gewünscht ein paar Anmerkungen/Fragen:

1. Ich habe systemd-resolved auf den bestehenden Artikel(Abschnitt) im Wiki verlinkt, dann ist der Artikel erstmal unabhängig von deiner anderen Baustelle.

2. Abschnitt "Installation": "Bei Ubuntu-Server-Systemen benötigt man dieses Paket" suggeriert für mich, dass man das Paket installieren muss. Werkelt nicht bereits bei 16.04 der systemd-resolved ? Siehe auch https://wiki.ubuntuusers.de/systemd/networkd/#systemd-resolved und http://manpages.ubuntu.com/manpages/xenial/en/man8/systemd-resolved.service.8.html .

3. Der Abschnitt beginnend mit "Alternativ kann man, wenn man ohnehin die Datei /etc/resolv.conf händisch pflegen möchte, das Paket /etc/resolv.conf deinstallieren" kann IMHO ganz aus dem Artikel raus. Aus Sicht des Admins wird die Komplexität damit auch nicht reduziert, sondern erhöht, da man sich um mehr Details selbst kümmern muss.

1. "Ubuntu-Desktops konfigurieren standardmäßig einen lokalen DNS-Server als Cache; dieser wird realisiert durch dnsmasq (vor 17.10)". Der ist aber ja nicht vorinstalliert (zumindest nicht unter Xenial Server) - warum wird er also konfiguriert? Und als Cache kann er ja dann auch nicht dienen? Das verstehe ich nicht.

Viele Grüße BillMaier

edited: Punkt 4. Wer lesen kann ist klar im Vorteil.

Noch was: Das Beispiel mit den beiden DNS-Servern finde ich nicht gut gewählt: Es ist ein typischer Fehler aus der Praxis, zwei DNS-Server zu konfigurieren, die unterschiedliche Antworten zurück geben (müsste auch im Forum schon aufgeschlagen sein). Da es keine definierte Reihenfolge in der Abfrage der Server gibt, führt dies schnell zu Fehlern, insbesondere wenn der interne Server mal weg ist (dann wird nämlich nur noch der externe angefragt, auch wenn der interne wieder kommt)

Sauberer ist die Konfiguration

Client → interner DNS ––-Weiterleitung-für-extene-Adressen-an-–→ externen DNS

Gruß BillMaier

BillMaier schrieb:

[…]

1. Ich habe systemd-resolved auf den bestehenden Artikel(Abschnitt) im Wiki verlinkt, dann ist der Artikel erstmal unabhängig von deiner anderen Baustelle.

Danke. Baustelle/systemd/resolved kast Du gefunden?

2. Abschnitt "Installation": "Bei Ubuntu-Server-Systemen benötigt man dieses Paket" suggeriert für mich, dass man das Paket installieren muss. Werkelt nicht bereits bei 16.04 der systemd-resolved ? Siehe auch https://wiki.ubuntuusers.de/systemd/networkd/#systemd-resolved und http://manpages.ubuntu.com/manpages/xenial/en/man8/systemd-resolved.service.8.html .

Bei 16.04 ist systemd-networkd und systemd-resolved (?) voristalliert, wird aber standardmäßig nicht aktiviert. Aktiv beim Desktop sind resolvconf und NetworkManager, ifupdown lauert funktionsfähig. Beim Server ist es m.W. genauso, nur ohne NetworkManager. Ich werde das aber nochmal auf frischen Installationen überprüfen.

3. Der Abschnitt beginnend mit "Alternativ kann man, wenn man ohnehin die Datei /etc/resolv.conf händisch pflegen möchte, das Paket /etc/resolv.conf deinstallieren" kann IMHO ganz aus dem Artikel raus. Aus Sicht des Admins wird die Komplexität damit auch nicht reduziert, sondern erhöht, da man sich um mehr Details selbst kümmern muss.

Wenn man händisch pflegen will, dann will man die Komplexität auch selber beherrschen. Automatismen im Hintergrund stören dann. Deaktiviern durch Deinstallation ist eine sehr sinnvolle Maßnahme. Ich werde über die Formulierung nachdenken, halte den Hinweis aber inhaltlich für gerechtfertgt.

BillMaier schrieb:

Noch was: Das Beispiel mit den beiden DNS-Servern finde ich nicht gut gewählt: […] zwei DNS-Server zu konfigurieren, die unterschiedliche Antworten zurück geben […]

Ja, dem stimme ich zu. Auch wenn es in dem Artikel nur um den Konfigurationsvorgang geht, sollte man kein inhaltlich schlechtes Beispiel verwenden.

Sauberer ist die Konfiguration

Client → interner DNS ––-Weiterleitung-für-extene-Adressen-an-–→ externen DNS

Jetzt stehe ich auf dem Schlauch. Kannst Du bitte konkreter werden?

kB schrieb:

BillMaier schrieb:

[…]

1. Ich habe systemd-resolved auf den bestehenden Artikel(Abschnitt) im Wiki verlinkt, dann ist der Artikel erstmal unabhängig von deiner anderen Baustelle.

Danke. Baustelle/systemd/resolved kast Du gefunden?

Ja, genau, das meinte ich.

2. Abschnitt "Installation": "Bei Ubuntu-Server-Systemen benötigt man dieses Paket" suggeriert für mich, dass man das Paket installieren muss. Werkelt nicht bereits bei 16.04 der systemd-resolved ? Siehe auch https://wiki.ubuntuusers.de/systemd/networkd/#systemd-resolved und http://manpages.ubuntu.com/manpages/xenial/en/man8/systemd-resolved.service.8.html .

Bei 16.04 ist systemd-networkd und systemd-resolved (?) voristalliert, wird aber standardmäßig nicht aktiviert. Aktiv beim Desktop sind resolvconf und NetworkManager, ifupdown lauert funktionsfähig. Beim Server ist es m.W. genauso, nur ohne NetworkManager. Ich werde das aber nochmal auf frischen Installationen überprüfen.

Stimmt, dann hatte ich das falsch im Kopf. Xenial-Server

# systemctl status systemd-resolved.service 
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-resolved.service.d
           └─resolvconf.conf
   Active: inactive (dead)
     Docs: man:systemd-resolved.service(8)

# cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)                                                       
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN                                                              
nameserver 10.139.0.10                                                                                                               
search k1.rdx-dev.com 

3. Der Abschnitt beginnend mit "Alternativ kann man, wenn man ohnehin die Datei /etc/resolv.conf händisch pflegen möchte, das Paket /etc/resolv.conf deinstallieren" kann IMHO ganz aus dem Artikel raus. Aus Sicht des Admins wird die Komplexität damit auch nicht reduziert, sondern erhöht, da man sich um mehr Details selbst kümmern muss.

Wenn man händisch pflegen will, dann will man die Komplexität auch selber beherrschen. Automatismen im Hintergrund stören dann. Deaktiviern durch Deinstallation ist eine sehr sinnvolle Maßnahme. Ich werde über die Formulierung nachdenken, halte den Hinweis aber inhaltlich für gerechtfertgt.

Wie wäre es mit einem extra Abschnitt (analog zu anderen Wiki-Artikeln) "resolvconf deinstallieren"?

Gruß BillMaier

kB schrieb:

BillMaier schrieb:

Sauberer ist die Konfiguration

Client → interner DNS ––-Weiterleitung-für-extene-Adressen-an-–→ externen DNS

Jetzt stehe ich auf dem Schlauch. Kannst Du bitte konkreter werden?

Ich meinte nur, dass man den externen DNS-Server nicht am Client eintragen soll, sondern am internen DNS-Server als Weiterleitung (das was man bei dnsmasq in der .conf einträgt). (Nur zur Vollständigkeit, ist für diesen Artikel hier irrelevant).

Gruß BillMaier

Seit Ubuntu 17.10 wird statt resolvconf der Manager systemd-resolved verwendet.

Laut diversen Seiten schon ab 17.04, was im Artikel fehlt.

Hallo,

Stand der Dinge hier?

Gruß, noisefloor

Der Cache in den Desktopsystemen wird meines Wissens durch dnsmasq-base bereitgestellt.

das Paket /etc/resolv.conf deinstallieren

halte ich für falsch. Das Paket heißt resolvconf. Stimmt das so?

DJKUhpisse schrieb: [...]

das Paket /etc/resolv.conf deinstallieren

halte ich für falsch. Das Paket heißt resolvconf. Stimmt das so?

Ja, klar. /etc/resolv.conf ist eine Konfigurationsdatei, kein Paket ☺ Habs direkt mal korrigiert.

Passiert hier noch etwas?

-push-

Hallo

hab's schon mal auf "Verlassen" gesetzt.

Gruß, noisefloor

Was fehlt denn hier noch? Meines Erachtens ist alles über resolvconf gesagt.