Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Hallo, ich versuche gerade die Arbeitsweise von netplan 🇬🇧 nachzuvollziehen. Zunächst dachte ich nach lesen der Dokumentation, dass die backend-Konfiguration im Konfigurations-Verzeichnis des Renderers angelegt würde, sobald man sudo netplan generate bzw. sudo netplan apply ausführt. Also z.B. für NetworkManager in /etc/NetworkManager/system-connections. Tatsächlich werden die Konfigurations-Dateien für NetworkManager aber in /run/NetworkManager/system-connections gespeichert, d.h. also netplan erzeugt diese Backend-Konfiguration bei jedem Neustart des Rechners zur Laufzeit anscheinend neu!? Jedenfalls habe ich diese Dateien an keiner anderen Stelle im System gefunden. Kann mir jemand erklären, warum die Backend-Konfiguration für NetworkManager von netplan nicht einfach einmalig in /etc/NetworkManager/sytem-connections angelegt wird? Vielen lieben Dank! LG, Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
Newubunti schrieb: […] Zunächst dachte ich nach lesen der Dokumentation, dass die backend-Konfiguration im Konfigurations-Verzeichnis des Renderers angelegt würde
Nein. Nicht „im“, sondern „in einem“. Es gibt mehrere Ablageorte, wie im Wiki beschrieben. Darunter auch temporäre wie …
[…] /run/NetworkManager/system-connections
… eben dieses.
d.h. also netplan erzeugt diese Backend-Konfiguration bei jedem Neustart des Rechners zur Laufzeit anscheinend neu!?
Ja.
[…] Kann mir jemand erklären, warum die Backend-Konfiguration für NetworkManager von netplan nicht einfach einmalig in /etc/NetworkManager/sytem-connections angelegt wird?
Es ist Design-Ziel für netplan. Es sollen nur temporäre Konfigurationsdateien für den Renderer erzeugt werden. Dahinter steckt wohl eine Weltanschauung, welche das gesamte Verzeichnis /etc/ als nur lesbares Dateisystem einbinden will. Ich persönlich halte dies für einen Irrweg und folglich auch netplan selbst für einen solchen. Das sehen offenbar auch viele andere so, denn bisher verwendet nur Ubuntu dieses netplan. Alle anderen Distributionen sehen wohl die direkte Konfiguration über systemd-networkd oder NetworkManager als einfachere Methode.
|
Newubunti
(Themenstarter)
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
@kB: Danke schon ein mal, für Deine Antwort! kB schrieb: Newubunti schrieb:
Es ist Design-Ziel für netplan. Es sollen nur temporäre Konfigurationsdateien für den Renderer erzeugt werden. Dahinter steckt wohl eine Weltanschauung, welche das gesamte Verzeichnis /etc/ als nur lesbares Dateisystem einbinden will. ...
Das ergibt aber für mich noch keinen richtigen Sinn, denn die *.yaml-Dateien erzeugt man ja auch in /etc/netplan/. Das ginge ja gar nicht, wenn man der von Dir beschriebenen "Weltanschauung" folgen und /etc/ nur lesend einbinden würde. Weißt Du, ob der Grund für das Verzichten auf Persistent-Konfigurationen alleine ein ideologischer ist? Oder gibt es noch andere technische Vorteile, die Konfiguration bei jedem Neustart neu zu generieren? Vielen Dank! LG, Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
Newubunti schrieb: […] Das ergibt aber für mich noch keinen richtigen Sinn, denn die *.yaml-Dateien erzeugt man ja auch in /etc/netplan/. Das ginge ja gar nicht, wenn man der von Dir beschriebenen "Weltanschauung" folgen und /etc/ nur lesend einbinden würde.
Ich empfinde das Konzept auch als widersprüchlich. Technisch lässt es sich aber durchaus umsetzen: Man muss ja nur in dem nur lesend eingebundenen Dateisystem für /etc/ im Ordner /etc/netplan/ ein weiteres Dateisystem beschreibbar oder zeitweise beschreibbar einbinden. Ob eine solche Konstruktion aber wirklich vorteilhafter als die herkömmliche Praxis ist oder eher als „im Wald der Möglichkeiten verirrt“ gelten müsste, lasse ich mal offen.
Weißt Du, ob der Grund für das Verzichten auf Persistent-Konfigurationen alleine ein ideologischer ist? Oder gibt es noch andere technische Vorteile, die Konfiguration bei jedem Neustart neu zu generieren?
Ich bezweifle, ob Ideologie hier die zutreffende Bezeichnung ist, und wenn sie es ist, ob das ein Vorteil in irgendeiner Art sein könnte. Ich sehe in Netplan keinerlei Vorteil, jedenfalls nicht für denjenigen, der einen Desktop oder einzelnen Server betreiben möchte. Das mag anders sein für Betreiber von Serverfarmen, bei denen hunderte von Rechnern mit demselben Betriebssystem-Image laufen sollen.
|
Newubunti
(Themenstarter)
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Hallo kB, siehst Du - unabhängig von der Frage, als wie sinnvoll man netplan einschätzt - eine technische Notwendigkeit für das Non-persistent-Konfigurations-Konzept von netplan? Ich kann eigentlich nur mutmaßen, dass netplan so sicher zu stellen versucht, dass aus der netplan front-end-Konfiguration stets eine auf etwaig anderem Weg erstellte back-end-Konfiguration für die gleiche Verbindung überschreibt. Allerdings sehe ich dabei noch nicht, dass sich das so auch wirklich sicherstellen ließe, oder? Danke! LG, Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
Newubunti schrieb: […] siehst Du […] eine technische Notwendigkeit für das Non-persistent-Konfigurations-Konzept von netplan?
Es kommt wie immer auf den Standpunkt an: Ein objektive Notwendigkeit für ein Non-persistent-Konfigurations-Konzept bei Linux besteht natürlich nicht, denn ohne ein solches funktioniert ja alles prächtig. Manche Leute wollen trotzdem so etwas haben. Frage bitte diese Leute, warum. Ich teile deren Ansichten nicht. Ein Notwendigkeit für ein Non-persistent-Konfigurations-Konzept bei Netplan besteht dagegen natürlich, denn ohne ein solches Design-Ziel wäre Netplan völlig überflüssig. Es macht selber keinerlei Netzwerk-Konfiguration und für den Anwender ist die indirekte Konfiguration der Backends über Netplan komplizierter als bei der direkten Verwendung der Backends (von Netplan Renderer genannt).
|
Newubunti
(Themenstarter)
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
kB schrieb: ...
Es macht selber keinerlei Netzwerk-Konfiguration und für den Anwender ist die indirekte Konfiguration der Backends über Netplan komplizierter als bei der direkten Verwendung der Backends (von Netplan Renderer genannt).
Stellt sich nicht eher ganz allgemein die Frage, ob Netplan den Endanwender überhaupt adressiert? Denn meine Vermutung ist (im Moment) eher, dass sich Netplan in erster Linie gar nicht an Endanwender sondern an Paket-Maintainer richtet. Denn die haben von Netplan - unabhängig von "persistent" oder "non-persistent" - den Vorteil, dass sie nur eine yaml-Konfiguration anstatt eine Konfiguration für NetworkManager und eine für networkd pflegen müssen. Ich kann nicht einschätzen, ob die Maintainer/Entwickler-Gemeinde auf so etwas dringend gewartet hat, aber objektiv lässt sich ein Nutzen von Netplan für dies Gruppierung doch wohl nicht abstreiten. Und dieser Nutzen ergibt sich ja nicht aus dem non-persistent-Design-Ziel, sondern aus der Fähigkeit von Netplan von einer einzelnen in mehrere andere Konfigurations-Sprachen übersetzen zu können. Oder übersehe ich da etwas? LG, Newubunti
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11181
Wohnort: München
|
Das ganze ist eher dafür gedacht, wenn man Ubuntu automatisiert ausrollen will (z.B. für VMs in einem Rechenzentrum) - da gibt es ja mit dem (s)ubiquity-Installer ein "modernes" Framework, das dann für die Netzwerkkonfiguration auf netplan zurückgreift und - falls der Use-Case dazu passt - ein bisschen eleganter sein kann als der klassische Debian-Installer mit seinen preseed-Dateien.
|
Newubunti
(Themenstarter)
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Danke!@seahawk1986, das hilft schon mal etwas weiter. Hast Du noch eine Einschätzung oder Wissen darüber, warum Netplan den Weg über das ewige Neu-Erstellen während des Systemstarts geht? LG, Newubunti
|