ubuntuusers.de

ok, danke für die Antwort.

Hallo,

so, allerletzte Chance: wenn bis Mitte Januar 2019 hier nichts entscheidendes mehr passiert, wird die Baustelle leider wieder zurück gesetzt.

Gruß, noisefloor

Mitte Januar ist in ziemlich genau 3 Tagen.

hab das mal umgesetzt.

Gruß BillMaier

trusty aus dem Artikel entfernt. Ich hoffe, ich hab alles erwischt. An wenigen Stellen, an denen ich es sinnvoll fand, habe ich die Info 16.04 drin gelassen. Ansonsten auch das entfernt.

Gruß BillMaier

Einleitung dem Status von ifupdown bei Ubuntu entsprechend überarbeitet und Hinweise auf erforderliche Vorarbeiten für die Verwendung von ifupdown bei aktuellen Ubuntu-Versionen als Links hinzugefügt.

Die eigentliche Beschreibung der Datei bleibt unverändert und ist weiterhin gültig. Ich habe darauf verzichtet, Weiterentwicklungen von ifupdown einzupflegen, da alle gängigen Aufgaben bereits beschrieben sind und mir weitere Details für Insider entbehrlich erscheinen.

Bei den Anwendungsbeispielen habe ich im Abschnitt VPN auf WireGuard verwiesen. Das Beispiel mit vpnc habe ich nicht getestet, weil mir momentan dafür keine Testmöglichkeit zur Verfügung steht. Ich erwarte aber, dass es nach wie vor wie beschrieben funktioniert.

Verweise auf auf das Python 2 Programm Wicd wurden entfernt, weil dieses unter 20.04 nicht mehr funktioniert.

Getestet für 20.04.

IMO sollte in diesem Artikel - Wiki-konform und wie in fast jedem anderen Artikel auch - anno 2021 der Punkt "Insallation" stehen. Das gehört seit nicht mehr vorinstalliert in diesen Artikel. Ebenso gehört in diesen Artikel, wie man etwaige Konflikte mit systemd/networkd bzw. NetworkManager auflöst in diesen Artikel.

Im Artikel Netplan/Deaktivieren ist beides dagegen fehl platziert. systemd/networkd und NetworkManager lassen sich auch nach Deaktivieren von Netplan noch konfigurieren und nutzen. Netplan Deaktivieren heißt nicht zwangsläufig auch ifupdown nutzen.

Es ist auch aus Wiki-taktischen Gründen gerechter bzw. geschickter, das hier zu platzieren. Denn: Ob der Artikel Netplan/Deaktivieren das Getetst-Tag erhält, kann man an sich sehr schnell testen. Bürdet man dem Tester aber noch auf, auch Wechselwirkungen und das Funktionieren von ifupdown zu testen, dann stellt dies eine nicht unerhebliche Test-Hürde da.

Wer ifupdown anno 2021 noch nutzen möchte, muss sich dagegen ohnehin mit Wechselwirkungen auseinandersetzen und ist für einen Artikel-Test eher Zielgruppe, als derjenige der Netplan nur deaktivieren will.

Den Punkt "Installation" würde ich hier noch einpflegen.

Den Punkt "Konflikte/Wechselwirkungen" dagegen nicht. Da fehlt mir die Zeit und ehrlich gesagt auch die Lust. Ich habe es aber erwähnt, damit der Punkt nicht vollends unter den Tisch fällt.

LG, Newubunti

Hallo,

man könnte in einem nächsten Schritt relativ einfach den Abschnitt zu ifupdown aus Netplan/Deaktivieren hierher umziehen. Newubunti schrieb:

Wer ifupdown anno 2021 noch nutzen möchte, muss sich dagegen ohnehin mit Wechselwirkungen auseinandersetzen und ist für einen Artikel-Test eher Zielgruppe, als derjenige der Netplan nur deaktivieren will.

+1

Daher ist auch die Frage, ob das jemand hier dokumentieren will. Sowas macht man ja nicht "mal eben" - das muss man schon wollen ☺

Gruß BillMaier

BillMaier schrieb:

man könnte in einem nächsten Schritt relativ einfach den Abschnitt zu ifupdown aus Netplan/Deaktivieren hierher umziehen.

Ich überlege gerade auch, ob ein Unterartikel "Wechselwirkungen..." nicht vielleicht geschickter wäre? Dann muss interfaces nicht alleine deswegen aus dem Wiki fallen, falls die Wechselwirkungen nicht getestet sind.

Der Inhalt des Unter-Artikels wäre zwar nach jetzigem Stand ziemlich überschaubar, aber da muss IMO - wenn da wirklich jemand Interesse dran hat - mit hoher Wahrscheinlichkeit eh noch mal nachgebessert werden.

LG, Newubunti

EDIT: Ich habe mal eine entsprechende Baustelle, Ubuntu System-Dienste zwecks Rückkehr zu ifupdown konfigurieren angelegt.

Bevor man hier Chaos anrichtet, sollte man sich über die tatsächlichen Verhältnisse klar werden:

Bei Ubuntu ist ab Version 17.10 Netplan die führende Komponente zur Konfiguration des Netzwerks und ifupdown mit der Datei /etc/network/interfaces ist nicht mehr Standard bei Ubuntu. Man mag das gut oder schlecht finden (Ich persönlich empfinde es nicht als gute Entscheidung.), aber man muss es als Design-Entscheidung der Distribution akzeptieren. Dementsprechend muss auch im Wiki Netplan und nicht mehr wie früher interfaces der führende Artikel sein. Jeder, der Ubuntu installiert, hat Netplan.

Wer Netplan nicht benutzen oder nicht in der vorgesehenen Form benutzen möchte, findet im Artikel Netplan/Deaktivierung eine Handreichung. Hier wird beschrieben, wie man auf eine Alternative umstellt. Welche der leicht erreichbaren (es gibt natürlich noch viele weitere ungenannte) alternativen Konfigurationstechniken man persönlich auswählt, bleibt natürlich dem Leser überlassen.

Eine dieser Möglichkeiten ist ifupdown, welches natürlich installiert werden muss. Natürlich kann man die Installation dieses Paketes im Artikel interfaces selbst statt im Artikel Netplan/Deinstallieren beschreiben. Das ist aber auch alles, was ich als sinnvolle Änderung ansehe und daher bereits vollzogen habe.

Hallo,

sehe ich grundsätzlich auch so. Netplan ist nun mal der Standard. Man (=das Wiki) kann auf Optionen / Alternativen hinweisen und das reicht dann auch. Das Wiki muss da nicht in die Untiefe der mannigfaltigen Konfigurationsmöglichkeiten abtauchen. Zumal das ja auch, wie BillMaier nicht trivial ist und IMHO für min 99% der Leser des Wikis nicht wirklich relevant. Bzw. die Leute, für die es relevant ist, kennen sich wahrscheinlich / hoffentlich so gut damit aus, das sie das Wiki sowie so nicht (mehr) dafür brauchen.

Gruß, noisefloor

Ich finde folgenden Abschnitt unter NetworkManager deaktivieren unklar und verstehe nicht genau, was der Autor damit sagen wollte:

• NM für alle in interfaces genannten Schnittstellen deaktivieren: Dies ist durch die Standardeinstellung des NM vorgeben: NM wertet die Datei /etc/network/interfaces aus und verwaltet die dort genannten Schnittstellen nicht. Man sollte allerdings beachten, dass man durchaus Netzwerk-Schnittstellen über die Datei /etc/network/interfaces konfigurieren kann, obwohl der Name der Schnittstelle nicht in der Datei auftaucht!

Der erste nicht markierte Teil ist noch klar und ergibt sich aus der Standard-Einstellung in /etc/NetworkManager/NetworkManager.conf:

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

...

Aber der markierte Satz liest sich für mich:

Man sollte allerdings beachten, dass man durchaus Netzwerk-Schnittstellen über die Datei /etc/network/interfaces konfigurieren kann, obwohl der Name der Schnittstelle nicht in der Datei (/etc/network/interfaces ?) auftaucht!

Wie konfiguriere ich etwas in der Datei /etc/network/interfaces ohne dass es dort gleichzeitig auftaucht?

Zielt das auf etwaige Skripte in /etc/network/interfaces/... ab?

Danke!

LG, Newubunti

Newubunti schrieb:

[…] Wie konfiguriere ich etwas in der Datei /etc/network/interfaces ohne dass es dort gleichzeitig auftaucht?

Natürlich über ein mapping, so wie ich es ja auch im Wiki-Artikel beschrieben habe. Die in der Datei vorhandenen Definitionen "iface NAME …" verwenden willkürliche Namen zur Unterscheidung der Konfigurationen; d.h. NAME ist syntaktisch nicht der Name einer Netzwerkschnittstelle, darf aber gleichlautend zu einem Namen einer Netzwerkschnittstelle sein. Welche (logische) Konfiguration tatsächlich zur Konfiguration einer physischen Schnittstelle angewendet wird, wird

1. entweder beim Aufruf von ifup angegeben (ifup eth0=DHCP)

2. oder durch ein mapping berechnet

3. oder, wenn das alles nichts ergeben hat, in einem letzten Schritt durch das triviale mapping per echo bestimmt.

D.h. im letzten Schritt wird für den physischen Namen der Schnittstelle eine Konfiguration mit dem gleichlautenden Namen gesucht und sofern es eine solche gibt auch angewendet.

Das alles ist im Artikel beschrieben.

NetworkManager kann diesen komplizierten Algorithmus nicht durchschauen und beschränkt sich daher bei seiner Analyse der Datei auf den letzten Schritt.

In einem Artikel über eine bestimmte Datei (i.d.F. /etc/network/interfaces) bezieht sich die Formulierung „die Datei“ natürlich immer auf die im Thema gemeinte und i.d.F. sogar im Titel des Artikels genannte Datei.

kB schrieb:

Natürlich über ein mapping, so wie ich es ja auch im Wiki-Artikel beschrieben habe.

Danke, für die Erklärung!

Ich habe jetzt einfach einen Link auf den Abschnitt mapping ergänzt. Damit kann man als Leser nun direkt nachvollziehen, was gemeint ist.

In einem Artikel über eine bestimmte Datei (i.d.F. /etc/network/interfaces) bezieht sich die Formulierung „die Datei“ natürlich immer auf die im Thema gemeinte und i.d.F. sogar im Titel des Artikels genannte Datei.

Ähm, nein. Bezüge ergeben sich in der Sprache zunächst mal durch entsprechenden Satzbau! Und der ist in dem genannten Fall nicht gerade besonders verständlich. Und das sage ich als jemand, dem es durchaus häufig auch schwer fällt, gefälligen Satzbau ins Wiki zu bringen bzw. sich verständlich auszudrücken!

Du solltest bedenken, dass es einen Unterschied gibt zwischen der Art und Weise wie du als Autor und/oder Fachmann den Artikel liest- wobei Du für den hier zur Diskussion stehende Abschnitt ja GAR NICHT die Verantwortung trägst - und der Art und Weise wie ein unbedarfter Leser den Artikel versteht.

Wenn man einen Artikel schreibt, ist man IMO nicht die geeignete Person, um die Verständlichkeit zu beurteilen, weil man - ob man will oder nicht - Sachen beim Lesen mitdenken wird, die ein unbedarfter Leser gar nicht kennt.

Das ist nicht zwangsläufig Schuld des Autors, sondern ergibt sich aus der Natur der Sache. Nicht umsonst arbeiten auch die renommiertesten Autoren mit Lektoren zusammen.

Außerdem mangelt es beim Erstellen von Wiki-Artikeln an genug Leuten, die auch die Verständlichkeit beurteilen können. Und das sollte eben eher von Laien der Materie beurteilt werden. Diese trauen sich die Mitarbeit am Wiki häufig aber nicht zu.

Ich finde man sollte daher immer dankbar sein, wenn man auf missverständliche oder schwer verständliche Sachverhalte aufmerksam gemacht wird. Das ist ja nie persönlich gemeint und ist IMO auch eine Anerkennung der vom Autor geleisteten Arbeit.

LG, Newubunti