ChickenLipsRfun2eat
(Themenstarter)
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Damals bei der Erstellung war es das auch - experimentell. Ich kann aktuell noch nicht sagen, wie weit Ubuntu da nun ist mit dem systemd-networkd, aber mir scheint der resolved-Service ist immer noch nicht richtig aktiv oder eingerichtet? Habe leider kein unverbasteltes Ubuntu parat, nur einen Server und der läuft schon seit 16.04 auf systemd-networkd. Den NetworkManager muss man natürlich nicht deinstallieren, allerdings kann man nur einen Dienst zur Verwaltung nutzen. Wie das aktuell aufeinander abgestimmt ist, weiß ich leider nicht. Ich muss mich da erst neu einarbeiten und mir eine VM erstellen ☺ Falls du den Artikel gerne überarbeiten wollen würdest, kannst du ihn dir in eine Baustelle verschieben lassen. Ich helfe dir gerne bei Fragen dazu, wenn du welche hast.
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6472
|
ChickenLipsRfun2eat schrieb: aber mir scheint der resolved-Service ist immer noch nicht richtig aktiv oder eingerichtet?
Wie meinst du das? Unter 17.04: $ 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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
Der 127.0.0.53 verweist auf den resolved. $ service systemd-resolved status
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-resolved.service.d
└─resolvconf.conf
Active: active (running) since Mon 2017-11-06 18:32:30 CET; 5h 50min ago
Docs: man:systemd-resolved.service(8)
http://www.freedesktop.org/wiki/Software/systemd/resolved
http://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
http://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 1002 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 4915)
CGroup: /system.slice/systemd-resolved.service
└─1002 /lib/systemd/systemd-resolved
Nov 06 19:28:37 josua systemd-resolved[1002]: Using degraded feature set (UDP+EDNS0+DO) for DNS server 8.8.8.8.
Nov 06 19:28:42 josua systemd-resolved[1002]: Switching to DNS server 172.21.0.254 for interface enp5s0.
Nov 06 19:28:43 josua systemd-resolved[1002]: Switching to DNS server 8.8.8.8 for interface enp5s0.
Nov 06 19:28:48 josua systemd-resolved[1002]: Switching to DNS server 172.21.0.254 for interface enp5s0.
Nov 06 19:54:41 josua systemd-resolved[1002]: Switching to DNS server 8.8.8.8 for interface enp5s0.
Nov 06 20:10:07 josua systemd-resolved[1002]: Grace period over, resuming full feature set (UDP+EDNS0+DO+LARGE) for DNS server 8.8.8.8.
Nov 06 22:29:09 josua systemd-resolved[1002]: Switching to DNS server 172.21.0.254 for interface enp5s0.
Nov 06 22:29:11 josua systemd-resolved[1002]: Switching to DNS server 8.8.8.8 for interface enp5s0.
Nov 06 22:29:18 josua systemd-resolved[1002]: Switching to DNS server 172.21.0.254 for interface enp5s0.
Nov 06 22:35:14 josua systemd-resolved[1002]: Switching to DNS server 8.8.8.8 for interface enp5s0.
Falls du den Artikel gerne überarbeiten wollen würdest, kannst du ihn dir in eine Baustelle verschieben lassen. Ich helfe dir gerne bei Fragen dazu, wenn du welche hast.
Dazu reicht mein KnowHow noch nicht. Ich beobachte das aber hier aber mal. Bis dahin stelle ich solche Fragen... 😉
|
ChickenLipsRfun2eat
(Themenstarter)
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Ah, gut. Danke. Bis ich wieder up to date bin schweige ich dann mal diesbezüglich ☺
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28958
Wohnort: WW
|
Hallo,
also auch für spätestens 18.04
Warten, bis das Final Beta draussen ist, den Stand der Dinge checken und dann den Artikel ggf. umbauen. Gruß, noisefloor
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12802
|
Ich beschäftige mich gerade mit diesem Artikel, weil ich verstehen will, wie Netzwerkeinrichtung mit systemd funktioniert. Dabei ist mir aufgefallen, dass der Artikel Konfigurationsdateien in /usr/lib/systemd/network erwähnt, während die Manpage von 16.04 dieses nicht, dafür aber /lib/systemd/network erwähnt. Auf meinem System (16.04.3) gibt es ein leeres /usr/lib/systemd/network und die einzigen *.network-Dateien liegen in /lib/systemd/network. Ist also die Pfadangabe /usr/lib/systemd/network im Artikel falsch? Edit: Name des leeren Verzeichnisses korrigiert.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17442
|
Eventuell hat Debian/Ubuntu, mal wieder, etwas abweichend vom Standard gemacht. Zumindest auf CentOS, RHEL, Fedora und Arch Linux wird /usr/lib/systemd/network verwendet. Dort gibt es aber auch kein /lib mehr, auf Ubuntu gibt es zusätzlich zum /usr/lib auch noch /lib und dort liegt die Konfiguration. Effektiv sollte man aus den Buildfiles vom Paket den richtigen Pfad finden können, ich gehe aber von /lib als Standardpfad auf der wie üblich durch /etc und final /run überschrieben wird von der Priorität. mfg Stefan
|
ChickenLipsRfun2eat
(Themenstarter)
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Ist gut möglich. Als ich den Artikel damals erstellt habe, war networkd ja noch nicht richtig implementiert. Ich habe die Dateien da manuell angelegt, da es imho keinen default gab. Da systemd mittlerweile Standard ist, wäre eine Überarbeitung der Pfade gut. Der Rest sollte nach wie vor passen, da systemd die Pfade ja intern regelt. In meinem arch sind die Dateien in beiden Pfaden zu finden.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17442
|
ChickenLipsRfun2eat schrieb: In meinem arch sind die Dateien in beiden Pfaden zu finden.
Mach mal ein ls -l -h / , dann wirst du feststellen das es bei Arch nur ein Symlink ist. mfg Stefan
|
ChickenLipsRfun2eat
(Themenstarter)
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6472
|
Bin bei dem systemd-resolver noch nicht durch gestiegen. Bei 17.10 ist dieser ja standardmäßig aktiviert. Desweiteren gibt es auch keinen Symlink von /var/run/systemd/resolve/resolv.conf nach /etc/resolv.conf . diff -y --suppress-common-lines /var/run/systemd/resolve/resolv.conf /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edi | # Dynamic resolv.conf(5) file for glibc resolver(3) generated
# | # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE O
# This is a dynamic resolv.conf file for connecting local cli | # 127.0.0.53 is the systemd-resolved stub resolver.
# all known DNS servers. | # run "systemd-resolve --status" to see details about the act
# <
# Third party programs must not access this file directly, bu <
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) i <
# replace this symlink by a static file or a different symlin <
# <
# See man:systemd-resolved.service(8) for details about the s <
# operation for /etc/resolv.conf. <
nameserver 192.168.178.1 | nameserver 127.0.0.53
nameserver fd00::a96:d7ff:fe5d:4a < Dies nur zur Vollständigkeit, falls hier jemand weiter machen will/kann. Bzgl. Support werde ich ggf. ein neues Thema eröffnen.
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6472
|
Hallo, tendenziell bin ich dafür, dem resolved einen separaten Artikel zu spendieren. Was meint ihr? Gruß BillMaier
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28958
Wohnort: WW
|
|
kletterbuxe
Anmeldungsdatum: 17. Juni 2009
Beiträge: 113
|
Hallo in die Runde! Ich habe den Artikel / die Anleitung für eoan getestet und 2 Unterschiede festgestellt, die ich aber nicht so auf die Schnelle einpflegen kann. 1. systemd/networkd (Abschnitt „systemd-resolved“) Zumindest unter eoan hat sich der Pfad geändert. Hier wird die resolv.conf von systemd nach /var/run/systemd/resolve/resolv.conf erzeugt. Ab wann das so ist konnte ich nicht herausfinden, weshalb ich mich da mal mit Eintragungen im Artikel zurückgehalten habe - nachher bekomme ich nur wieder einen auf den Deckel. Der Pfad ist auch nochmal in dem Skript entscheidend: systemd/networkd (Abschnitt „Standardkonfiguration-Kabel“). Hier für jede (kurzlebige) Version ein eigenes Skript anzulegen ist ja auch quatsch, zumal zumindest mir das Skript erst aufgefallen ist, als ich mit allem durch war. 2. systemd/networkd (Abschnitt „Namensaufloesung-funktioniert-nicht“) hat mir nicht geholfen. Ich habe auf askubuntu.com eine Antwort gefunden, wo in der Datei /etc/nsswitch.conf "hosts: files dns" eingetragen wurde, statt "files mdns4_minimal [NOTFOUND=return] resolve", wie es die Problembehandlung nennt - das hat bei mir funktioniert. Ich hätte auch hier gerne meine Antwort zur Problembehandlung beigetragen, jedoch habe ich keinerlei Ahnung, was da passiert, bzw. was die Optionen tun bzw. "anrichten" können.
Eine kleine Erklärung liefert dort die erste Antwort nach Votes (von Caesium) - die ist allerdings von 2011, weshalb wahrscheinlich kein systemd-Problem zugrunde liegt. Gruß kletterbuxe
|
ChickenLipsRfun2eat
(Themenstarter)
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! kletterbuxe schrieb: 1. systemd/networkd (Abschnitt „systemd-resolved“)
Mit systemd-resolved kann der Symlink von /etc/resolv.conf sogar auf /var/run/systemd/resolve/stub-resolv.conf oder /usr/lib/systemd/resolv.conf zeigen. Welcher Link nun von Ubuntu bei welcher Konfiguration automatisch genutzt wird, kann ich auch gerade nicht sagen. Funktionieren tun sie alle. Den Artikel hatte ich damals unter 16.04 erstellt, da war systemd noch sehr stiefkindlich in Ubuntu integriert. Da der NetworkManager mittlerweile aber auch mit systemd arbeitet, kannst du deine Änderungen ruhig in den Artikel eintragen.
2. systemd/networkd (Abschnitt „Namensaufloesung-funktioniert-nicht“) hat mir nicht geholfen. Ich habe auf askubuntu.com eine Antwort gefunden, wo in der Datei /etc/nsswitch.conf "hosts: files dns" eingetragen wurde, statt "files mdns4_minimal [NOTFOUND=return] resolve", wie es die Problembehandlung nennt - das hat bei mir funktioniert.
Das ist nur die Reihenfolge, in der die Namensauflösung versucht wird. Also zuerst files (Dateien), wie /etc/hosts, dann dns, usw. Falls du das alte, nicht-funktionierende Szenario noch mal einrichten kannst und systemd-resolved verwendet wird, prüfe mal mit systemd-resolve status und systemd-resolve ubuntuusers.de die Ausgabe. Meistens kommt eine solche Problematik aber von sich in die Quere kommenden Diensten wie Parallelbetrieb von dnsmasq und systemd-resolved. Für eine Aktualisierung des Artikels wäre auf jeden Fall die Standardeinrichtung von Ubuntu interessant → siehe Netplan.
|