ich beschäftige mich seit 20 Jahren mit Linux (hauptsächlich Debian-basierte Distributionen) und stehe jedes Mal wie ein Idiot da, wenn ich größere Konfigurationsänderungen am Netzwerk vornehmen muss. Mal steht in der Anleitung Network Manager, mal networkd, mal ifupdown. Irgendwann bringt man alles durcheinander und hat kein gutes Gefühl dabei, auch wenn es funktioniert. Ich stelle mir dann immer vor, ich käme zum ersten Mal an das System und müsste mich erst einmal zurechtfinden, wie was wo eingestellt wurde.
Auch bei der Namensauflösung gibt es verschiedene Ansätze: /etc/resolv.conf, resolvconf und systemd-resolved. Was nun? Plötzlich sind vier Konfigurationsdateien involviert, wo vorher nur eine war. Nimmt man noch ifupdown hinzu, kommen noch ein paar weitere Dateien ins Spiel.
Ich habe gestern zwei Stunden gebraucht, um auf einem DHCP konfigurierten System einen anderen DNS-Server statisch so einzurichten, dass die Einstellung nach einer halben Stunde noch da war. Ich habe mit systemd-resolved herumgefummelt und irgendwann wusste ich, dass das so nicht richtig sein kann. Aber irgendwann musste ich das machen, was ich eigentlich machen wollte.
Daher meine Frage: Was ist heute Stand der Technik? Wie ändere ich heute bei einem aktuellen Debian- oder Ubuntu-Release die Netzwerkumgebung so, dass jeder, der weiß wie es geht, sich auf dem System zurechtfindet, ohne vorher in die Glaskugel schauen zu müssen, woher die Einstellungen eigentlich kommen?
Vielleicht zeigt mir jemand den roten Faden, dem ich folgen kann.
Welche Netzwerkkonfiguration verwendet wird, hängt von der Version und bei Verwendung von Images (z.B. für lxc, lxd, incus) ebenfalls nach Version sowie auch Vorlieben des Erstellers des Image und / oder erwartetem Verwendungszweck (Desktop oder Server).
Einen guten Überblick und eine Beschreibung aller Varianten unter Berücksichtigung der Versionen liefert https://wiki.debian.org/NetworkConfiguration
Ubuntu ist wieder andere Baustelle. Auf dem Server wird netplan zur Konfiguration verwendet, auf dem Desktop der Network-Manager (das ist wie bei Debian im Standard).
Bei neueren Systemen, wie z.B Ubuntu 22.04 macht das leider systemd. Bin ich auch kein Freund von. netplan ist die reinste pest. Damit konnte man anfangs nicht mal if-up benutzen ohne Umwege. Also um z.B scripts auszuführen bei einem boot.
Wenn die Rechner DHCP nutzen, warum gibst du den DNS nicht einfach via DHCP mit? Entweder nur für den Host, oder halt für das komplette Subnetz?
Aber selbst hier kannste Dir nicht sicher sein, ohne zu testen, ob nicht doch noch ein anderer DNS benutzt wird. z.B vom Browser… Wenn Du es genau haben willst, musste mit tcpdump/wireshark schauen.
Oder was Du auch machen kannst, Du biegst die DNS Anfragen so um, wie du sie haben willst mit firewalld, iptables oder nftables.
Ansonsten musst Du halt wissen, wie der DNS vergeben wird. Bei Systemen mit systemd, steht meistens in der resolv.conf, dass diese überschrieben wird.
Ja, wenn es ein dauerhaftes Setup wäre, würde ich das auch so oder so ähnlich machen. Allerdings läuft das Ganze in meiner VMware Fusion ausschließlich zum Testen, und ich wollte eine Dokumentation über BIND (DNS-Server) schreiben. Dafür hatte ich einen Client installiert, der diesen DNS-Server nutzen sollte. Statt mich auf die Doku zu konzentrieren, war ich dann jedoch mehr mit diesen Problemen beschäftigt.
Die Datei /etc/resolv.conf wird eigentlich nur bei ifupdown nicht automatisch befüllt, außer du hast einen DHCP am Laufen, dann setzt der dhclient alles wieder zurück. Selbst wenn du in der /etc/network/interfaces statische Einstellungen vornimmst, jedoch das Interface grundsätzlich auf DHCP eingestellt bleibt. Das war letztlich auch die Ursache für mein Chaos am Samstag. Mein Fehler.
Ich weiß nicht, ob die Warnung in der /etc/resolv.conf auch aufzeigt, was die Datei überschreibt, aber ich glaube nicht. Das wäre jedenfalls hilfreich.
Mit Netplan habe ich auf Ubuntu auch schon herumexperimentiert. Da habe ich direkt einen Online-Syntax-Checker verwenden müssen, der mir die Leerzeichen und Einrückungen überprüft hat. YAML ist in dieser Hinsicht extrem empfindlich.
Die wird automatisch befüllt, bzw überschrieben z.B von systemd-resolve. Zum brechen.
Letzlich bleibt Dir nur dich mit der jeweiligen aktuellen Distri auseinander zu setzen. Nur weil es bei XYZ so war, muss es bei v XYZ-1 nicht mehr so ein.
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details
Es ist gut, sich mit der aktuellen Distri zu beschäftigen, aber ich fange jetzt in einem neuen Team an und muss mich mit einem Haufen unbekannter Systeme auseinandersetzen. Was ich jetzt sehr hilfreich fände, wären Indikatoren, die mir zeigen, welchen Weg der Admin bisher gegangen ist.
Aus welcher Datei stammen die Kommentare, die du da gepostet hast? Ist das dein System? Was geben die folgenden Kommandos zurück?
was netplan betrifft, so habe ich jetzt herausgefunden, dass damit nur die Konfigurationsdateien entweder für systemd-networkd oder NetworkManager erstellt werden. Welcher der beiden Systemdienste verwendet wird sollte mit o.g. Kommandos ermittelt werden können. Aber das einer dieser active ist, sagt leider noch nichts darüber aus, ob er auch mit netplan konfiguriert wird. Ein Alptraum…
Ich denke bei meinen Systemen bleibe ich bei ifupdown und gehe die Konfiguration zu Fuß durch. Die Frage ist nur, wie lange das gut geht, bis irgendein Default eines neueren Releases meint, es jetzt anders machen zu müssen. Womit wir wieder am Anfang dieses Beitrags wären. In Debian 12 scheint keiner der Systemdienste standardmäßig beteiligt zu sein. Mir hat nur dhclient in die Suppe gespuckt, aber das ist ein anderes Thema. Ich schaue mir jetzt noch Ubuntu 24.04 an, wie es da out of the box aussieht und dann hoffe ich genug gelernt zu haben, dass ich zumindest weiß, dass ich vorsichtig sein muss.
