noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29045
Wohnort: WW
|
Hallo,
Ich stelle mir zunehmend die Frage, ob das Deaktiviern von Netplan überhaupt notwendig ist.
Ich werfe mal folgenden subjektive Behauptung in den Raum: Der Artikel stammt aus der Zeit, als Netplan sehr neu war. Linux-Nutzer sind ja gerne konservativ und lehnen Änderungen am System erst Mal ab, weswegen so Artikel wie "besser beim alten bleiben und dem neuen keine Chance geben" entstehen. Dazu kommt vielleicht noch
... sondern höchst wahrscheinlich an einem Mangel an Wissen des Anwenders ...
Kann natürlich sein, dass es real world use cases gibt (real world = kein konstruierter Nischenfall, der nur bei einem von 1 Mio System notwendig ist), wo Netplan weg muss. Ist mir aber selber noch nie unter gekommen. Gruß, noisefloor
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Newubunti schrieb: […] Ich stelle mir zunehmend die Frage, ob das Deaktiviern von Netplan überhaupt notwendig ist.
Die von mir präferierte Strategie, welche ich auch im Artikel erwähnt habe, ist einfach Netplan zu ignorieren. Wenn man es nicht benutzen möchte, benutzt man es eben nicht und schreibt keine YAML-Dateien.
Denn trotz vorhandenen Netplan-Konfigurationen sollte es IMO stets möglich sein, diese bei Bedarf durch eigene Konfigurationen aus /etc/... heraus zu überschreiben, oder?
Möglich ist es, sofern man die Dateinamen kennt, welche Netplan für seine Arbeitsergebnisse verendet.
[…] Also das Problem liegt hier IMO weniger an den von Netplan erzeugten Konfigurationen an sich, sondern höchst wahrscheinlich an einem Mangel an Wissen des Anwenders, wie man Konfigurationen niederer Priorität mittels Konfiguration höherer Priorität überschreibt.
Das habe ich allerdings im Artikel zu systemd-networkd beschrieben, zu dem der hier diskutierte Artikel ja veweist.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
kB schrieb: Die von mir präferierte Strategie, welche ich auch im Artikel ...
Wäre es nicht sinnvoll, diese Methode auch im Artikel als präferierte Methode klar herauszustellen und zu begründen warum? Eine Begründung könnte sein: "Wenn man Netplan vollständig deaktiviert, besteht die Gefahr, dass man künftig Netzwerkkonfiguration stets händisch nachtragen muss, anstatt dass dies von einem Paket, dass man nachinstalliert, automatisch über eine Netplan-Konfiguration erledigt wird." Hinweis: Das ist jetzt eine Begründung, die ich für realistisch halte, aber nicht sagen kann, in wie weit das in der Praxis schon eine Rolle spielt. Mir geht es nur um das Aufzeigen etwaiger Nachteile im Verhältnis zu (eventuell) fraglichen Vorteilen. Oder spinne ich mir da einen Nachteil zurecht, den Ihr für absolut unrealistisch haltet? LG, Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Newubunti schrieb: […] Wäre es nicht sinnvoll, diese Methode auch im Artikel als präferierte Methode klar herauszustellen und zu begründen warum?
Nein. Meine persönliche Präferenz sollte im Wiki-Artikel gerade nicht zum Ausdruck kommen. Vielmehr sollte ein Wiki-Artikel die Möglichkeiten beschreiben und dem Leser die Wahl überlassen. Meine Begründung für meine persönliche Präferenz des Ignorierens ist: Diese Methode benötigt von allen vorgestellten Möglichkeiten den geringsten Eingriff in die Struktur der Distribution und hat damit wahrscheinlich auch in der Zukunft die geringsten Nebenwirkungen. Andere können aber in anderen Situationen als ich oder aus mir unbekannten Gründen zu ebenso berechtigten, aber anderen Ergebnissen kommen.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
kB schrieb: Nein. Meine persönliche Präferenz sollte im Wiki-Artikel gerade nicht zum Ausdruck kommen.
Ich sehe es in dem Fall nicht als Frage persönlicher Präferenz, sondern eher als Best-Practice im Sinne des Distributors mit dessen ausgerollten Mitteln. Hier geht es ja um die Frage, ob ich etwas aus der Distribution entferne/dekativiere, bei dem sich der Distributor etwas gedacht hat. Eine Frage persönlicher Präferenz wäre für mich z.B. der Fall, dass ich einen Artikel über Editoren schreibe und dann z.B. Geany als den besten Editor küre. Das wäre für mich ein echter Fall persönlicher Präferenz - die ich in der Tat dann auch für unangebracht halte. Oder ich behaupte, dass man NetworkManager stets mit nmcli anstatt mit GUI konfigurieren muss, obwohl tatsächlich in den allermeisten Fällen gleichberechtigte Alternativen. Verstehst Du, auf welchen Unterschied ich hinaus will? Sollten hier jetzt natürlich zig weitere Leute posten, die der Ansicht wären, man könne das nicht als Best-Practice empfehlen, dann lasse ich mich da auch gerne überstimmen.
Meine Begründung für meine persönliche Präferenz des Ignorierens ist: Diese Methode benötigt von allen vorgestellten Möglichkeiten den geringsten Eingriff in die Struktur der Distribution und hat damit wahrscheinlich auch in der Zukunft die geringsten Nebenwirkungen.
Aber man sollte dann wenigstens diesen Nachteil im Artikel erwähnen, soweit man sich meiner Meinung bezüglich "Best-Practice" nicht anschließen mag.
Andere können aber in anderen Situationen als ich oder aus mir unbekannten Gründen zu ebenso berechtigten, aber anderen Ergebnissen kommen.
Das steht aber jedem auch frei, selbst wenn man eine Best-Practice vorgibt. Das muss ja nicht in der Form geschehen, dass man den Leser auf Gedeih und Verderb die Best-Practice aufzwingt, sondern sie schlicht nur mit Begründung darlegt. Und natürlich darf der Leser dann immer noch selbst anders entscheiden. Wäre das nicht auch im Sinne des Supports?: Denn nehmen wir mal an ich liege mit meiner Begründung im vorigen Post richtig, dann handelt man sich doch hier nur zusätzliche Probleme ein, wenn man in einem solchen Artikel nicht wenigstens auch vor (etwaigen) Nachteilen warnt bzw. darauf hinweist, dass Netplan im Grunde nicht sonderlich stört. Und wäre nicht auch ein aktives Netplan für einen Netzwerk-Supporter von Vorteil? Denn Du kannst Konfigurationen dann immer als yaml-Format posten und weißt, dass sie sowohl für NetworkManager als auch für systemd-network funktionieren. LG, Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Newubunti schrieb: […] Verstehst Du, auf welchen Unterschied ich hinaus will?
Nein, ich verstehe nicht, worauf Du hinaus willst. Wenn Du den Wiki-Artikel verbessern willst und kannst, dann mache es. Es ist ein Wiki. Ich halte allerdings die von Dir vorgeschlagenen Ergänzungen für nicht erforderlich, sonst hätte ich solche bei meiner Überarbeitung und Umgestaltung des Artikels ja schon eingefügt. Ich traue aber dem Leser grundsätzlich auch immer zu, selbst das Gelesene für seine eigene Situation beurteilen zu können und will ihm das auch nicht durch Aufzählung von offensichtlichen Fakten abnehmen.
[…] Und wäre nicht auch ein aktives Netplan für einen Netzwerk-Supporter von Vorteil?
Ich sehe da keinen Vorteil.
Denn Du kannst Konfigurationen dann immer als yaml-Format posten und weißt, dass sie sowohl für NetworkManager als auch für systemd-network funktionieren.
Das YAML-Format ist beim Support im Forum eher problematisch, weil es ja Whitespace als Syntaxelement verwendet und Whitespace bei der textlichen Kommunikation oft nicht originalgetreu übertragen wird. Bei vielen, nach meiner Wahrnehmung der Mehrheit aller im Forum diskutierten Probleme mit Netplan spielt dieser Umstand eine Rolle.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
Mal gerade zur Kerneloption zum Deaktivieren:
Ich habe hier gerade in einer VM (libvirt) aufgesetzten Ubuntu Server 20.04. Dort hat GRUB_CMDLINE_LINUX="netcfg/do_not_use_netplan=true" keine Funktion, d.h. trotz setzen der Option in /etc/default/grub, wird trotzdem aus der yaml-Datei eine Datei in /run/systemd/network generiert. Ich kann in dmesg sehen, dass die Kerneloption gelesen wird, ob die allerdings irgendwie verarbeitet wird, ergibt sich aus den Logs erst mal nicht. In /etc/systemd/network befinden sich selbstverständlich keine Konfigurationen. Und sobald ich der yaml-Datei ein .unused anhänge, erhalte ich das erwartete Ergebnis - nämlich erst mal kein funktionsfähige Netzwerkverbindung. Dazu nur eine Frage: Hast Du das bzw. sonst jemand unter 20.04 Server in letzter Zeit schon mal getestet? Mein Vorgehen war wie folgt: Ubuntu Server mittels ubuntu-20.04.2-live-server-amd64.iso in libvirt VM unter Ubuntu 20.04 Host - Einrichtung eines virtuellen Netzwerkadapters Während es subiquity setup alles auf Standard gelassen, also Netzwerk per DHCP, kein Proxy oder ähnliches. Nach Abschluss des Setups Updates installieren → ergo funktionsfähige Netzwerkverbindung Vorhandensein von entsprechender yaml-Datei und /run/systemd/network geprüft - beides erwartungsgemäß vorhanden. ip a Ausgabe überprüft
Bearbeitung der /etc/default/grub mit setzen von GRUB_CMDLINE_LINUX="netcfg/do_not_use_netplan=true" sudo update-grub
reboot ip a erneut geprüft, noch immer wie unter 5. Netzwerkfunktionalität auch immer noch vorhanden.
ping -c4 google.com läuft ohne Paketverluste durch
dmesg zeigt die Kerneloption an, allerdings gibt es zu Netplan bzw. Net kaum Informationen, übrigens auch nicht wenn Kerneloption nicht gesetzt.
journalctl -b0 zeigt auch keine Informationen diesbezüglich an
yaml-Datei nun umbenannt - also .unused angehängt. reboot ip a zeigt nur noch das Gerät aber keine Verbindung (keine IP-Adressen) mehr → wie erwartet!
ping -c4 google.com kann nicht aufgelöst werden → wie erwartet
Gegenprobe: yaml-Datei wieder umbenennen - also .unused wieder weg. reboot ip a zeigt wieder ein verbundenes Interface nebst IPs.
ping -c4 google.com geht wieder ohne Paket-Verlust durch.
Testweise noch ifupdown installiert - /etc/network/interfaces ist leer! reboot Verbindung immer noch trotz Kerneloption vorhanden.
Ich frage, weil ich auch das hier gefunden habe - zwar für 17.10:
https://askubuntu.com/questions/977243/ubuntu-17-10-disable-netplan (siehe dort den Kommentar zur 1. Antwort): Answer from @chili555 was not enough for me. I had to remove every yaml file from netplan directories ( {/run , /lib, /etc }/netplan/*.yaml ). Then, reboot and the network should works back with /etc/network/interfaces (guess this is a normal fallback). – remyd1 Jan 19 '18 at 11:00 Nicht dass ich mir hier den Wolf debugge. LG, Newubunti EDIT: Nach setzen von debug in GRUB_CMDLINE_LINUX= - also insgesamt GRUB_CMDLINE_LINUX="debug netcfg/do_not_use_netplan=true" - kann ich aus dmesg entnehmen: [ 3.273792] systemd[354]: /usr/lib/systemd/system-generators/netplan succeeded.
[ 3.315494] systemd[1]: unit_file_build_name_map: normal unit file: /run/systemd/system/netplan-ovs-cleanup.service Also wird Netplan wohl noch ausgeführt. Das würde ich jetzt aufgrund von netcfg/do_not_use_netplan=true nicht erwarten. Oder soll diese Option auf einer anderen Ebene wirken - also naheliegend wäre hier ja netcfg ? EDIT2: Also ein Workaround wäre jetzt: sudo chmod a-x /usr/lib/systemd/system-generators/netplan Daraus resultiert dann folgender log-Eintrag in dmesg :
[ 2.878324] systemd[345]: Ignoring '/usr/lib/systemd/system-generators/netplan', as it is not marked executable.
Damit könnte ich jetzt gut leben! Was ich mich frage, woher weiß ich, welche Bootoptionen von der aktuellen Distribution unterstützt werden? Die Inhalte in den verlinkten Quellen aus Bootoptionen am Ende scheinen mir hinsichtlich Ubuntu veraltet. Und warum in einer aktuellen Distribution noch netcfg ? netcfg ist doch eher initd statt systemd zuzuordnen, oder? LG, Newubunti EDIT3: netcfg/do_not_use_netplan=true hat bei mir auch bei Desktop-Systemen keinerlei erkennbare Funktion. Nachdem ich noch mal How to go back to ifupdown gelesen habe, dachte ich die Bootoption sei vielleicht ausschließlich bei der Installations-DVD anwendbar und würde dort dann dazu führen, dass ifupdown statt netplan während der Ubuntu-Installation installiert würde. So lese und verstehe ich den verlinkten Abschnitt zumindest.
Aber auch das funktioniert so nicht. Getestet habe ich das jetzt mehrere Male mit der Ubuntu-20.04-Desktop-DVD. Ich deaktiviere Netplan jetzt so: sudo rm /usr/lib/systemd/system-generators/netplan Aktivieren kann man dann bei Bedarf wieder mittels: sudo ln -s /usr/lib/netplan/generate /usr/lib/systemd/system-generators/netplan Das ist im Prinzip so ähnlich, wie systemctl {enable|disable} . LG, Newubunti
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
Da nun dankenswerterweise ausgelagert, habe ich den Abschnitt "ifupdown" auf Verlinkung nach interfaces reduziert. Begründung: Dieser Artikel bleibt damit für die Zukunft leichter testbar, weil hier nicht überprüft werden muss, ob ifupdown erfolgreich aktiviert und konfiguriert werden kann. LG, Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Abschnitte zu do_not_use_netplan=true überarbeitet und Link ergänzt.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
Hallo kb, es bleibt für mich unklar, ob Du das selbst jetzt mal getestet hast und zu dem gleichen oder einem anderen Ergebnis kommst wie ich bzw. andere im Internet ja auch. Ich habe übrigens hier bei mir schon eine überarbeitete Version von Netplan/Deaktivieren bereit liegen, bei der ich die von mir gefundene Lösung eingebaut habe. Ich warte nur darauf, dass einerseits ein Rückmeldung kommt, ob das von "mir" geschilderte Problem nachvollzogen werden kann - wobei ich stark davon ausgehe, dass das so ist - und andererseits, dass der Artikel Netplan die Baustelle wieder verlässt. LG, Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Newubunti schrieb: […]
Ich deaktiviere Netplan jetzt so: sudo rm /usr/lib/systemd/system-generators/netplan Aktivieren kann man dann bei Bedarf wieder mittels: sudo ln -s /usr/lib/netplan/generate /usr/lib/systemd/system-generators/netplan
Das kannst Du gerne so machen. Ich halte das aber nicht für eine empfehlenswerte Methode, weil man dann in den installierten Paketen des Systems herum pfuscht und beim nächsten Update des Paketes sicherlich Probleme bekommt. Dann fände ich schon eher empfehlenswert, das Paket netplan.io zu entfernen (was bereits als Versuch beachtenswerte Fehlermeldungen erzeugt). Aus meiner Sicht ist Deine Methode nicht Wiki-tauglich. Wenn man Netplan nicht benutzen möchte, ist nach wie vor die einfachste, sicherste und am wenigsten invasive Methode, es einfach zu ignorieren.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
Hallo kb, da war mein voriger Beitrage wohl missverständlich. Ich wollte in erster Linie wissen, ob Du do_not_use_netplan=true mal selbst mittels Installations-DVD getestet hast? Danke! LG, Newubunti EDIT: Ich habe nun mal noch unter Ubuntu 18.04.05 Server/Desktop getestet. Installiert wurde jeweils ein mal mit netcfg/do_not_use_netplan=True und ein mal ohne - also insgesamt vier Varianten. Dabei habe ich immer direkt die Option "Ubuntu installieren" gewählt, so dass unmittelbar (s)ubiquity gestartet wird. Nach Abschluss der Installation und Neustart wurden anschließend bei allen Varianten zunächst alle Updates eingespielt und noch mal ein Neustart ausgeführt. Bei der Server-Variante geht das Einspielen der Updates bei do_not_use_netplan=Ture nicht (siehe dazu unten). Aus diesem Versuch kann ich nun ableiten, dass netcfg/do_not_use_netplan=Ture im Prinzip genau das macht bzw. machen soll, was es ausdrückt: Während der Installation wird für die Konfiguration des Netzwerks keine yaml-Datei erzeugt - also keine, die eine tatsächliche Funktion hat. Die Null-Konfiguration "NetworkManager" wird im Falle der Desktop-Version immer erzeugt. Eine Konfiguration der Netzwerkschnittstelle für die /etc/network/interfaces wird nicht generiert. Das macht ja bei der Desktop-Version auch Sinn, weil hier stets NetworkManager der Standard Netzwerk-Dienst ist. Bei der Server-Version wird im Falle von netcfg/do_not_use_netplan=Ture eine solche Null-Konfiguration auch für networkd erstellt. Allerdings ist die Null-Konfiguration noch sinnloser, als bei den Desktop-Versionen, denn gleichzeitig wird systemd-networkd sowieso noch auf disable gestellt. Allerdings wird hier erwartungsgemäß eine /etc/network/interfaces -Datei generiert, die auch funktionieren würde, wenn da nicht - nach meiner Meinung - ein Bug wäre: Denn es wird bei der Server-Variante kein ifupdown installiert, was dazu führt, dass man erst mal keine Netzwerkfunktionalität nach dem Neustart hat. Da systemd-networkd erst mal nicht läuft, reicht es alleine nicht aus eine Konfiguration zu erzeugen, sondern der Service muss natürlich erst mal wieder gestartet werden. Danach kann man dann erst ifupdown installieren. Da hat man im Installer-Team wohl vergessen, dass ifupdown bei 18.04 in der Desktop-Version noch mit in der Grundinstallation vorhanden ist - dort also auch nicht durch do_not_use_netplan=True nachinstalliert werden muss - bei der Server-Variante ist dies aber anders. Dort ist ifupdown nicht mehr in der Grundinstallation vorhanden und hätte nach installiert werden müssen. Bei keiner der vier Varianten, wird netplan deaktiviert. Legt man eine yaml-Konfiguration in /etc/netplan ab, so erzeugt die dann die entsprechende Back-End-Konfiguration. Es gibt also gar keinen "offiziellen" Weg, Netplan zu deaktivieren. Richtig durchdacht ist dieses do_not_use_netplan=True -Konzept in meine Augen - zumindest für Server-Systeme - nicht, denn hier kann nicht ausgeschlossen werden, dass eine Paket-Installation eine yaml-Datei mitliefert und diese im Rahmen der Installation auch anwendet - also ein netplan apply ausführt. Das kann dann dazu führen, dass der Server im schlimmsten Fall die Netzwerk-Konektivität verliert und unter Umständen neu gestartet werden muss. Das will man so auf einem Server sicher nicht haben. Die Tage werde ich mal noch die unterschiedlichen Service-States der vier Varianten hier posten, die sind nämlich IMO ganz hilfreich, um zu wissen, was eigentlich die Standards nach der Installation sind. LG, Newubunti EDIT2: Was ich beim vorherigen EDIT vergessen habe: Genau genommen würde ich von einer Option netcfg/do_not_use_netplan=True eigentlich erwarten, dass sie schlicht und einfach das Verzeichnis /etc/netplan leer lässt und stattdessen für den in der Distribution standardmäßig genutzten Netzwerkdienst eine Konfiguration erzeugt. Das würde insbesondere für Server bedeuten, dass in /etc/systemd/network eine entsprechende Konfigurations-Datei erzeugt wird. Das ist aber bei den Server-Versionen nicht der Fall. Bei den Dekstop-Versionen ist dies quasi "von-hinten-durch-die-Brust-ins-Auge" der Fall, weil dort unabhängig von netcfg/do_not_use_netplan=True sowieso immer NetworkManager der Standard-Dienst ist und Netplan - zumindest was die Grundinstallation anbelangt - gar keine praktische Rolle spielt.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
Bitte den Artikel zwecks Bearbeitung in die Baustelle verschieben. Gleiches Spiel wie bei Netplan auch, die Überarbeitung habe ich schon fertig. Dementsprechend die Bearbeitungszeit nur wenige Tage. Danke! LG, Newubunti
|
tuxifreund
Projektleitung
Anmeldungsdatum: 7. November 2020
Beiträge: 1162
|
Newubunti schrieb: Bitte den Artikel zwecks Bearbeitung in die Baustelle verschieben.
Done. LG tuxifreund
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
Vielen lieben Dank! Artikel ist überarbeitet. Kritik willkommen! Die Abschnitte mit dem Aktivieren eines alternativen Konfigurations-Programms habe ich herausgenommen, weil das bei Ubuntu-Standard-Installationen nicht notwendig und zudem verwirrend ist. Die Thematik hat mit dem Deaktivieren von Netplan an sich erst mal nichts zu tun bzw. ist nicht Netplan-spezifisch, sondern tritt dann auf, wenn es konkurrierende genutzte Netzwerkdienste auf dem System gibt. Das ist soweit ich das beim Überfliegen der anderen Artikel - also systemd-networkd und NetworkManager - gelesen habe, dort auch schon mehr oder weniger enthalten. Jedenfalls verusacht das Deativieren von Netplan an sich keine Konflikte. kB schrieb: Das kannst Du gerne so machen. Ich halte das aber nicht für eine empfehlenswerte Methode, weil man dann in den installierten Paketen des Systems herum pfuscht und beim nächsten Update des Paketes sicherlich Probleme bekommt. Dann fände ich schon eher empfehlenswert, das Paket netplan.io zu entfernen (was bereits als Versuch beachtenswerte Fehlermeldungen erzeugt).
"in den installierten Paketen herumpfuscht" halte ich doch für übertrieben. Dass man unter Linux im allgemeinen und systemd im speziellen symbolische Verknüpfungen setzt und löscht um etwas zu aktivieren/deaktivieren ist gängige Praxis. Nebenwirkungen kann ich natürlich nicht vollends ausschließen, aber ich habe ja darauf hingewiesen. Darüber hinaus kann ich mir eigentlich keine tiefer gehenden Probleme vorstellen. kB schrieb: Aus meiner Sicht ist Deine Methode nicht Wiki-tauglich.
Weil? IMO ist das hier ein Community-Wiki und kein Wiki, das sich strickt immer nur an das Distributions-Design hält. Ich sehe da auch überhaupt kein Problem, sofern darauf hingewiesen wird. Im übrigen ist auch beim Umbenennen der Dateien nicht auszuschließen, dass es nicht zu "Problemen" kommt. Auch darauf wird aber am Anfang des Artikels hingewiesen. Der Artikel heißt zudem Netplan-Deaktivieren und sollte dementsprechenden Inhalt liefern. Ob man das dann anwendet oder nicht bleibt jedem selbst überlassen. Das vollständige Deaktivieren - so man sich zum Deaktivieren überhaupt entschließt - kann z.B. bei Server durchaus sinnvoll sein, um zu verhindern, dass ein netplan apply verursacht durch Paket-Installation, die Netzwerkverbindung unterbricht. LG, Newubunti
|