LAN-Adapter-Name ist "predictable", WLAN-Adapter-Name nicht...? [Gelöst]

[guennid]

Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme ("eth0", "eth1", "wlan0", ...), but should fix real problems."

Ich sehe nicht, wo ich jemals etwas anderes gesagt hätte und die Aussage ändert sich meiner Meinung nach um keinen Jota, wenn ich das sinnlose predicatble weglasse. Es geht um „stable“, also stabile, feste Namen. Vielleicht wäre „verlässlich“ der am besten geignete deutsche Ausdruck für das Gemeinte. Und die Frage, inwiefern „systemd/udev“ diesem Anspruch gerecht wird, habe ich gar nicht angesprochen.

Ich vermute stark, dass wir hier entweder aneinander vorbei reden oder aber du (und nicht nur du) dich unsterblich in das Wort „predictable“ verliebt hast.

Grüße, Günther

edit:

Mal abgesehen davon dass im Inhalt deines Links ganz oben dick steht: "This page has been obsoleted and replaced by a man page: systemd.net-naming-scheme(7)." ist vielleicht die entscheidende Wendung:
"with v197 systemd/udev will automatically assign ..." Ich weiß nicht, wann die udev-Version 197 erschienen ist/in Debian implementiert wurde. In jessie war's bereits 215, wenn ich packages.debian.org richtig interpretiere. Aber ich vermute mal in dieser Info ging es den Autoren schlicht darum, anzukündigen, dass, was udev vorher (seit etwa etwa 2004, sag ich mal) bereits mit den Gerätedateien unter /dev gemacht hat, mit Version 197 nunmehr auch auf Netzwerkschnittstellen ausdehnt wird.

Ich sagte ja eingangs schon, dass mein Beitrag wohl etwas OT ist. Hätte ich geahnt, welch weitgehend aneinandervorbeiredende Diskussion dadurch entsteht, hätte ich gleich einen eigenen Thread, vielleicht unter dem Titel: Sinnhaftigkeit/Angemessenheit des udev-Ausdrucks „predictable“, in Smalltalk eröffnet. Vielleicht kann ein Moderator das nachholen.

[TomL]

Ich vermute stark, dass wir hier entweder aneinander vorbei reden

Das glaube ich mittlerweile auch... deswegen ist es für mich selbstverständlich, dass diese Möglichkeit unbedingt ein Missverständnis als Grundlage für eine emotionale Schieflage ausschließen sollte

oder aber du (und nicht nur du) dich unsterblich in das Wort „predictable“ verliebt hast.

Nee, ich denke nicht, dass es mir um das Wort "predictable" oder "vorhersagbar" geht ... eigentlich überhaupt nicht.... das kann eigentlich benannt werden oder sein, wie es will... die Benennung hat keine Bewandtnis für mich. Mir geht es vielmehr um die tatsächliche Intention dieses Konzeptes, und zwar das ein NIC immer den gleichen Namen haben soll und hat und den auch behält... das gilt sogar dann, wenn ich andere NICs zusätzlich einbaue oder andere bereits vorhandene NICs ausbaue. Genau das hat ja vorher zufällige Effekte ausgelöst, denen man deshalb erzwungenermaßen mit udev begegnen musste.... was jetzt aber nicht mehr notwendig ist. Solange jetzt das betroffenen NIC seinen Steckplatz behält, solange bleibt die Bezeichnung immer gleich. Diese Lösung finde ich gut... ganz unabhängig davon, dass irgendwer das "predictable" benannt hat… er hätts auch "systemd-type-and-slot-dependent-name-assignment-modul" nennen können, auch das ist für mich nur ne Bezeichnung für ein dahinterstehendes Verfahren.... macht für mich aber keinen Unterschied ... ich finde nur das Verfahren gut.

Mal abgesehen davon dass im Inhalt deines Links ganz oben dick steht: "This page has been obsoleted and replaced by a man page: systemd.net-...

Jau, hab ich tatsächlich übersehen... .... aber objektiv betrachtet hat auch das imho keinen Einfluss auf die eigentliche Intention dieses Verfahrens und die aktuelle Umsetzung.

Ich sagte ja eingangs schon, dass mein Beitrag wohl etwas OT ist.

Nöö, ich denke, dass auch so eine grundsatzbezogene Erörterung zum Thema gehört und das das gar nicht soooo OT ist. Und solange das einfach nur sachlich bleibt, ist das jedenfalls für mich eine Bereicherung... vor allem lerne ich selber immer dann am effektivsten, wenn ich mich in der Diskussion mit den Gegenargumenten befassen muss und versuche, die zu widerlegen.

[guennid]

zu Thomas:
Mir ging's tatsächlich nur um diese Bezeichnung, die ich extrem unpassend, um nicht zu sagen albern finde. Deswegen auch die OT-Vermutung. Aber ich meine, nicht nur, aber gerade auch in der IT sollte man sich um möglichst aussagekräftige Bezeichnungen bemühen.

objektiv betrachtet hat auch das imho keinen Einfluss auf die eigentliche Intention dieses Verfahrens und die aktuelle Umsetzung.

Wenn du dich da mal nicht ein wenig täuschst: Wenn ich recht sehe, dann gab es drei Änderungen bei der Behandlung von Netzwerkschnittstellen durch udev: vor v197: gar keine Behandlung. Danach: automatische Erstellung einer udev-Regel unter Verwendung der NIC-MAC. Letztens: automatische Umbenennung, aber nicht mehr gebunden an die NIC-MAC und auch nicht nachvollziehbar anhand einer bestimmten udev-Regel. Die letzte Änderung führte dazu, dass u.U. genau das Gegenteil dessen bewirkt wurde, was udev seit seinen Anfängen eigentlich vermeiden wollte: sich ändernde Bezeichnungen, statt fester, stabiler und damit verlässlicher. Ein Beispiel dazu findet sich hier (1). Der Link ist nicht mein Verdienst, auf ihn wurde auch schon in mindestens einem anderen einschlägigen DF-Thread verwiesen. Nun lässt sich das alles mit udev- und/oder systemd-Mitteln wieder gerade biegen, dazu gibt es im Link, hier und auch in anderen einschägigen Threads genügend Anregungen. Aber es muss einem 1. auffallen (nachdem man sich nach v197 daran gewöhnt hatte, dass udev die automatische Zuweisung verlässlicher Bezeichnungen zuverlässig erledigt) und 2. muss man es händisch tun. Ich vermute, dass das der Kern von MSfrees Kritik ist.

(1) https://fryboyter.de/wlan-stick-und-pre ... sso-thread

Grüße, Günther

[jmar83]

..irgendwie meine ich bei Debian 9 schon beides gesehen zu haben ohne dass ich speziell was angepasst hätte (?), enp0sX wie auch ethX. Der "enp"-Präfix bezieht sich meines Wissens auf den PCIe-Bus, ethX ist ganz klar generell. ("Ethernet")

Gibt es Situationen, wo sich Debian "selbst" entscheidet, anstelle von einem "predictable"-Name das gute, alte "ethX" zu verwenden? Soviel ich weiss habe ich diesbezüglich nichts angepasst/verändert - einmal ist's "predictable", das andere mal nicht...?

[smutbert]

Gibt es Situationen, wo sich Debian "selbst" entscheidet, anstelle von einem "predictable"-Name das gute, alte "ethX" zu verwenden?

Ja, auch wenn ich da kein System erkennen kann. Ich habe beispielsweise ein normales Debian auf dem Cubietruck installiert und die onboard-Schnittstellen (wlan+lan) erhalten die Namen eth0 und wlan0, während ein USB-Wlan-Stick einen „vorhersagbaren“ Namen bekommt.

[jmar83]

Vielen Dank, dann bin ich immerhin nicht der Einzige, der das feststellen konnte!!

Bei mir war's sogar bei VirtualBox, kam aber evtl. davon dass ich

a.) Wie wild zwischen verschiedenen VirtualBox-LAN-Adptern hin- und hergewechselt habe

oder

b.) Die damalige Installation eine ältere Version (9.6, 9.7?) war. Seit der letzten Zeit ist mir aber nur noch "ethX" aufgefallen.

(Hoch subtil, das Ganze!! )

Da hat man mit dem Raspi schon seine Vorteile, zumindest in dieser Hinsicht. Dort ist seit Version 9 ständig "enxb827eb......" der Fall - gut, das hat ja auch grundsätzlich nur eine Art von NIC drin, es sei denn man macht da was mit USB...


Was könnte man machen, um alles wieder in einer Art "Initialzustand" zurückzuversetzen (oder in einem Zustand, der dem Verhalten der neueren Debian-Version (wie nach "apt-get upgrade") entspricht?)

Die dafür zuständigen Pakete mit "apt-get purge" (statt remove) entfernen und wieder einspielen?

[jmar83]

Das ganze Zeugs ist recht verwirrend: viewtopic.php?f=27&t=174770

Ferner ein Problem, welches daraus resultieren könnte: viewtopic.php?f=27&t=174768

[wanne]

Die Bezeichnung predictible ist einfach die einzig korrekte. Stabiel waren sie vorher:
Es wurde per UDV eine regel angelegt und danach behielt das gleiche device immer den selben Namen. – Das ist stabil.
Völlig anders jetzt: Jedes BIOS-Update killt dir erst mal die Banamung weil es die PCIe-Nummerirung ändern und jedes zweite Kernel Update ändert sie auch, weil der Treiberherautor sich ein anderes Namensschema ausgedacht hat. Das ist eben ganz und gar nicht mehr stabiel, aber wenn man alle äußeren umstände kennt, vorhersehbar.

Und ich sehe da halt schon ganz dick den systemd Einfluss: Früher Konfigurationsdatei um auf individuelle Bedürfnisse reagieren zu können, heute Bevormundung durch Systemd. Um das nochmal zu verdeutlichen:

Und ja, der Admin kann auch heute natürlich via UDEV bestimmen, so wie du sagst, wie die NICs heissen sollen .... die Besonderheit dabei ist, "er kann", und nicht "er muss'. Mit den predictable NIC-Names muss er das nämlich nicht mehr und hat deshalb trotzdem keine Nachteile...

Nein. eben genau anders herum wird ein Schuh draus: Früher konnte ich auch genau das in udev-Regeln gießen was heute die predictable Names machen. Weitestgehend ist das auch das was die meisten RZs gemacht haben aber halt an die individuellen Bedürftnise angepasst: eth0 immer die GbE-Karte zur Providionierung – Erkennbar daran, dass sie die einzige GbE-Karte ist. int erkennbar daran, dass es Mellanox-Karten sind immer das interne netz ext immer der 40GbE-Uplink.... Schön predictable UND stabiel. – Aber halt etwas Handarbeit erforderlich. Schaltest du jetzt prdictable names an, heißen die Schnittstellen trotz explizit anders lautender UDEV-Regel anders – Und alle Scripte müssten für eine unnötige Autokonfiguration geändert werden. – Und zwar bei jedem Update. Und genau deswegen sind die predictable Names auch in fast allen größeren RZs aus. Nette Idee aber viel zu starr für den Gebrauch im RZ.
PS: Ja ich weiß, dass man es mit systemd-networkd wieder hinbiegen könnte. Aber warum soll ich funktionierende udev-Einzeiler in 20 Zeilen Systemd-Konfig umschreiben, nur damit wieder alles so funktioniert wie vorher.

Das ist halt allgemein der Grund, warum systemd so fett da scheitert wo es am meisten benötigt würde: Die Philosophie unkonfigurierbar ist besser passt halt nur für den 0815-User. Und das hat in UDEV genau so Einzug gefunden wie überall sonst in Systemd-Projekten.

[jmar83]

Vielen vielen Dank für die hoch kompetente Antwort!!