(gelöst) ip (iproute2), ifupdown(2) und Netzwerkkonfiguration.

[jessie]

Wer nichts Konkretes weiß oder nicht ewig lang recherchieren möchte, beruflich bedingt wenig Zeit für ein einziges, lapidares (Netzwerk-) Problem hat, sollte ein Frontend für die Netzwerkkonfiguration nutzen - und nicht ständig Frontends für Linux verteufeln.
https://access.redhat.com/documentation ... orkmanager
Spätestens bei ab und an zu wechselnden Netzwerkzugängen (einschließlich Tests derselben) werden Konfigs in mehreren Dateien und deren uneindeutige, mehrfach mögliche Aktualisierung im System nervig. Insbesondere bei mehr als 1 zu betreuendem (Rentner-) Rechner. Praxis versus Religion! Leicht vorhersehbare Verbalprügel und eventuelle Argumente interessieren mich weniger als stille Mitleser - da mein recht komplexes Netzwerk problemlos funktioniert.

Ünrigens: Wer kommt ohne Frontend so schnell darauf, wie MAC-Adressen wegen Tracking EINFACH zufällig gemacht oder gespooft werden können (weil manchmal müssen)? Wer auf Priorisierung mehrerer Netzwerkanschlüsse? Unterschiedliche Routen, Metriken? Alles in einem Tool, auch ohne GUI. Wenn das Tool nicht reicht, dann eben das Eingemachte.

[inne]

Was vlt. auch Grund ist warum noch ifupdown installiert und verwand wird.

Ich denke, dass es deshalb noch installiert ist, damit die Abwärtskompatibilität zu älteren Setups gewährleistet ist. Dieser Linie wird seit längerem konsequent gefolgt:

Ja! Aber ich wollte gunnid nur eine Antwort anbieten. Naiv gefragt: Spielt diese Kombatibilität denn auch bei einer Neuinstallation noch ein Rolle, damit der Benutzer seine ältere Konfiguration weiter nutzen kann?
Die restliche Software selbst ist davon doch nicht betroffen und setzt einfach ein eingerichtetes Netzwerk voraus?
Je nach Installationsumfang hat man auch war anderes am laufen. Bei einer Grundsystem/minimal Installation ifupdown und bei z.B. einer Installation mit GNOME den NetworkManager.

[TomL]

Naiv gefragt: Spielt diese Kombatibilität denn auch bei einer Neuinstallation noch ein Rolle, damit der Benutzer seine ältere Konfiguration weiter nutzen kann?

An eine solche ZIelsetzung glaube ich nicht. Ich denke eher an jene Setups, wo bei einem Releasewechsel zuerst nur die sources-list geändert und dann vollständig auf das neue Release upgraded wird... solche Setups müssen danach -auch mit alten Settings- einfach nur weiter laufen. Ich glaube, dass Debian nur sekundär ein einfaches Desktop-System ist... Debian ist viel mehr.... und in diesem 'mehr' ist eben nicht das üblich, was wir so allgemein als Desktop-Benutzer tun, also mal eben schnell alles in die Tonne kloppen und mit dem Installer fix ne neue Installation durchführen. Wir brauchen uns ja darüber keine Gedanken zu machen, weils keine vertraglichen Verpflichtungen gibt, keine Verfügbarkeitsgarantien, ist ja nur privat. Die Settings alter Installationen allerdings weiter zu unterstützen ist imho auch eine Form des Investitionsschutzes. Und nicht zu vergessen, es ist ja nach mehren Jahren immer noch so, dass sich bis heute eine Gruppe von Leute damit schwertun, die Vorteile von systemd zu akzeptieren, sich da einzuarbeiten und es dann auch in vollem Umfang zu nutzen.... obwohl systemd meiner Meinung nach eine grandiose Verbesserung im Vergleich zum Vorgänger sysv darstellt.

jm2c

[guennid]

Dann versuch' ich mal in der Sache meine bisherigen Erkenntnisse aus diesem Thread als These zusammenzufassen:

Das Paket iproute2 löst mindestens seit stretch das Paket net-tools ab und bedarf selber für die kabelgbundene Netzwerkkonfiguration weder des Paketes ifupdown noch der von ifupdown verwalteten Konfigurationsdatei /etc/network/interfaces. Man kann ausschließlich mit den Werkzeugen in iproute2 ein kabelgebundenes Netzwerk konfigurieren. Inwiefern andere Werkzeuge für diese Konfiguration sich weiterhin des Paketes ifupdown - und damit der /etc/network/interfaces - bedienen (müssen) bleibt offen. Ich bitte um Bestätigung/begründeten Widerspruch.

Da ich bisher noch keine Maschine mit Buster neu eingerichtet habe, interessierte mich weiterhin in diesem Zusammenhang: Installiert buster noch standardmäßig die net-tools neben iproute2? Anhand eines stretch-Buster-Upgrades kann man das wohl nicht erkennen, wie Thomas für mich recht plausibel dargelegt hat.

Grüße Günther

[TomL]

Hi Günther, ich stimme Deinen Schlußfolgerungen zu.... und nein, bei meinem Buster-Lite-Setup (*) waren die net-tools nicht installiert. Weil ich mich mit der Ausgabe-Form von ss im Vergleich zu netstat noch ein bisschen schwer tue, installiere ich das Paket noch. Aber tatsächlich nur wegen des Ausgabeformats von netstat


(*) "Lite" nenne ich einfach mein Debian-Setup ohne grafisches Environment, frei abgeleitet von raspbian-lite, bei dem auch kein GUI installiert ist. Ob net-tools bei einem vollständigen Buster-Setup (lxde, xfce, etc) dabei ist, weiss ich jetzt nicht... die nutze ich ja schon seit Jahren nicht mehr.

[JTH]

Man kann ausschließlich mit den Werkzeugen in iproute2 ein kabelgebundenes Netzwerk konfigurieren.

Richtig.

Das Paket iproute2 löst mindestens seit stretch das Paket net-tools ab […]

Bei Jessie war net-tools zumindest nach einer Standardinstallation ohne X noch installiert. Als obsolet angesehen wird’s aber anscheinend schon seit >>10–15 Jahren.


Um das nochmal anders zu beschreiben:

net-tools (ifconfig) und iproute2 (ip) sind Werkzeuge zur Kommunikation mit dem Kernel um ein Netzwerkinterface einzurichten. Mehr nicht. Die Konfiguration wird nirgendwo dauerhaft gespeichert.

ifupdown (und das nur dazu gehörige /etc/network/interfaces), NetworkManager (mit seiner Konfiguration in /etc/NetworkManager) und systemd-networkd (mit Konfiguration in /etc/systemd/network u.a.) sind weiterführende Werkzeuge, die dir das manuelle Einrichten des Netzwerks mit ifconfig oder ip bei jedem Booten abnehmen. Zwingend notwendig sind sie nicht. Man könnte das Ganze z.B. auch über ein eigenes Skript beim Booten lösen, wie Thomas es anscheinend macht.

ifupdown benutzt im Hintergrund die Werkzeuge aus iproute2, früher net-tools. NetworkManager und vermutlich auch systemd-networkd implementieren die Kommunikation mit dem Kernel selbst.

ifupdown, NetworkManager und systemd-networkd sind prinzipiell unabhängig voneinander, können aber auch nebeneinander benutzt werden. Es sind verschieden neue Wege, Netzwerkinterfaces nicht jedesmal von Hand aufsetzen zu müssen, mit unterschiedlicher „Zielgruppe“.

Als grobe Analogie: Du könntest auch bei jedem Booten deine Partitionen von Hand mit mount (äquivalent zu ifconfig/ip) einbinden. Da man das nicht möchte, listet man die Partitionen in /etc/fstab (äquivalent zu ifupdown + /etc/network/interfaces, NetworkManager + /etc/NetworkManager/* und systemd-networkd + /etc/systemd/network/*) und lässt sie automatisch einbinden.

Auch zur fstab gibt es seit systemd mit .mount-Units Alternativen. Das macht die fstab aber noch lange nicht komplett überflüssig oder obsolet.

(Ups, der Beitrag wurde länger als geplant.)

[MSfree]

ifupdown, NetworkManager und systemd-networkd sind prinzipiell unabhängig voneinander, können aber auch nebeneinander benutzt werden. Es sind verschieden neue Wege, Netzwerkinterfaces nicht jedesmal von Hand aufsetzen zu müssen, mit unterschiedlicher „Zielgruppe“.

Jein, so ganz unabhängig voneinander sind sie nicht. Zumindest der Networkmanager verwaltet nur diejenigen Netzwerkschnittstellen, die nicht durch ifupdown verwaltet werden. Meines Wissens liest der Networkmanager dazu sogar die interfaces, damit er nicht in Konflikt mit ifupdown gerät. Wie sich ifupdown und Networkmanager mit systemd-networkd vertragen, weiß ich nicht, vermute aber, daß Poettering da keine Rücksicht genommen hat.

Ich nutze nach wie vor ifupdown, wenn ich Rechner mit Kabel ans Netz bringen will. Auch für WLAN-Konfigurationen, die quasi statisch bleiben, weil die Rechner immer am selben Stadort bleiben, finde ich ich ifupdown sinnvoll.

Der Networkmanager ist nach meinem Empfinden vor allem für die WLAN-Konfiguration mit wechselnden Standorten sinnvoll, wenn es darum geht diverse ESSID/PSK-Kombinationen zu verwalten. Das geht zwar mit ifupdown auch, man muß dann aber manuell in der wpa_supplicant.conf rumfrickeln.

[guennid]

Danke für die Rückmeldungen!

Man könnte das Ganze z.B. auch über ein eigenes Skript beim Booten lösen, wie Thomas es anscheinend macht.

Me too! Ich mach's nicht mal beim Booten. Ich mach's dann, wenn ich's benötige (vom Debian-Router mal abgesehen). Und wenn ich unterwegs bin, habe ich gute Erfahrungen mit einem Nano-Router von TP-Link gemacht, nachdem ich vor drei- vier Jahren nicht fit genug war, mich händisch mit australischen öffentliche APs zu verbinden. Das bringt einen kleinen Sicherheitsgewinn und reduziert die Angelegenheit auf kabelgebundene Verbindung am privaten Rechner. Ich setz' das dann jetzt mal auf „gelöst“.

Grüße, Günther