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

[TomL]

Er musste vorher zwangsläufig eine UDEV-Regel erstellen, um Eindeutigkeit herzustellen und genau das muss er nun nicht mehr.

Entweder du bist noch nicht lange genug bei Linux dabei oder dein Erinnerungsvermögen ist arg getrübt. Die UDEV-Regel mußte man nicht erstellen, das ging vollautomatisch.

Ja, mag sein, dass ich das vergessen habe... weil ich keinen Sinn darin sehe, mir unnützes merken zu müssen. Ich halte jedenfalls "keine Regel notwendig" für besser, als unnötige vorhandene Regeln, auch wenn sie automatisch erstellt wurden. Insgesamt reduziert das jedenfalls meinen Admin-Aufwand.... gerade auch bei der Fehlerdiagnose.

Immer diese Jubelperser

Das ist unsachlich, unnötig, persönlich und hat überhaupt nichts mit meiner Realität zu tun. Ich nutze einfach nur die aktuell gegebenen Möglichkeiten zu meinem Vorteil aus....und die Vorteile sind absolut unbestreitbar. Außerdem habe ich versucht, meine Sichtweise technisch zu begründen.... das hat mir Jubeln wahrlich nix zu tun. Widerlege einfach meine Aussage zur Sinnhaftigkeit der Bindung "Name" und "Slot" bei der Vergabe einer Bezeichnung.

Seit systemd haben die Anwender Probleme, die vorher nie auftraten.

Ja, aber ich glaube, ich kann das einschätzen. Wer alles auf sysv reduziert und alles neue mit einer geradezu statischen sysv-Erwartungshaltung vergeicht, wird solcherart Mauern nie überwinden. Ich persönlich, wo ich mittlerweile alles eliminiere und auf systemd umstelle, was auch nur ansatzweise an sysv erinnert, habe noch nie ein stabileres und faktisch problemloseres Debian erlebt, wie jetzt mit systemd.... so unterschiedlich sind also die Erfahrungen... ... und ich bin mir ziemlich sicher, dass Du weisst, dass ich einiges mehr als nur ein normales Desktop-Debian betreibe.

[guennid]

Ich habe doch noch gar nichts gegen das „Konzept“ an sich gesagt. Im Gegenteil, ich hab's als sinnvoll bezeichnet - wenn man's nutzen will/muss. Mir ging's nur um die Bezeichnung. Und die hat mit Voraussage nichts zu tun, ob du nun den Admin oder wen auch immer ins Spiel bringst. udev ändert/legt fest im Nachhinein eine Kernel-Bezeichnung, ob nun automatisch oder vom „User“ angestoßen.

Wer alles auf sysv reduziert

Und das war jetzt sachlich?

[TomL]

Und das war jetzt sachlich?

Ja, natürlich, weil sich das Vorposting auf die Vergangenheit bezog.... und die lautete nun mal sysv. Aber sysv ist tot, und es bringt nichts, mit Komastation, Herz-Lungen-Maschine und Zwangsernährung daran festzuhalten - der Patient ist tot. Es gibt jetzt neue Spielregeln... die muss ich akzeptieren und kann versuchen, diese zu meinem Vorteil zu nutzen. Mir ist das wirklich gut gelungen. Dagegen anzukämpfen halte ich jedenfalls für sinnlose Energieverschwendung.

[guennid]

Tut mir leid, ich halte das für unsachlich und aggressiv. Und ich finde mich da in keiner Weise wieder.

[TomL]

Das ist aber nur so, weil Du das so interpretieren möchtest. In meiner Stimmungslage ist nichts davon enthalten.... ganz im Gegenteil....

[MSfree]

Das ist unsachlich, unnötig,

....und die Vorteile sind absolut unbestreitbar.

Oha, du beantwortest etwas mit einer unsachlichen Redefloskel. Na dann...

[TomL]

Oha, du beantwortest etwas mit einer unsachlichen Redefloskel. Na dann...

Auch das ist unwahr und rein konflikt-provozierend motiviert.

Das hatte ich geschrieben:
"...eindeutige Vorhersagbarkeit ... bei statischen Systemen ist das eine deutliche Reduzierung des Administrationsaufwandes. ...keine Regeln sind besser als unnötige Regeln... reduziert das jedenfalls meinen Admin-Aufwand.... gerade auch bei der Fehlerdiagnose.... stabileres und faktisch problemloseres Debian erlebt, wie jetzt mit systemd...."

Wenn ich das alles als unbestreitbare Vorteile für mich bezeichne, sind das also unsachliche Redefloskeln...?... aha.... was müsste man denn Deiner Meinung nach für andere, ebenso technisch nachprüfbare Fakten anführen, damit das keine unsachlichen Floskeln sind?

Seit systemd haben die Anwender Probleme, die vorher nie auftraten.

Wenn das mehr als ne inhaltsleere Floskel ist, wegen völligem Verzicht auf irgendwas nachgewiesenes und allgemeingültiges, dann haben wir völlig unterschiedliche Vorstellungen, was Floskeln sind.

Sorry... hier gehts jetzt nicht mehr um technische Fakten, die man versucht nachprüfbar zu widerlegen, sondern um persönlich Attacken... ich bin raus.

[guennid]

"Vorhersagbar" bedeutet, dass der Admin konkret vorhersagen kann, wie ein Device nach einem Boot des System vom Kernel bezeichnet ist

„Das ist imho falsch interpretiert.“
Der Admin sagt gar nichts vorher. Der Admin legt via udev fest (ob nun automatisch und wie gut/schlecht interessiert mich im gegebenen Zusammenhang überhaupt nicht), wie ein device angesprochen werden soll, und zwar unabhängig davon, wie der Kernel (je nach variablem Systemzustand) meint, dass es angesprochen werden soll. Das ist doch der eigentliche Sinn der Aktion bzw. von udev. Mit systemd hat das meiner Meinung nach nur insofern etwas zu tun, als dieses (für mich sinnfreie) „predictable“ nach meiner Wahrnehmung erst verwendet wird, seit die systemd-Leute udev machen. Ob sie das aktuell nun besonders gut machen (TomL) oder eher nicht so gut (MSfree), darüber maße ich mir hier kein Urteil an. Und insbesondere hat es für mich nun absolut gar nichts mit sysvinit zu tun!

Grüße, Günther

edit:

Ja, natürlich, weil sich das Vorposting auf die Vergangenheit bezog.... und die lautete nun mal sysv.

Ich habe mir den gesamten Thread vor meinem 1. Beitrag noch mal durchgelesen. Ich finde kein Vorposting in dem auf sysv Bezug genommen würde. Habe ich was überlesen?

[jmar83]

Vielen Dank für die Feedbacks!

[TomL]

„Das ist imho falsch interpretiert.“ ....Der Admin sagt gar nichts vorher. Der Admin legt via udev fest

Manchmal ist es wirklich besser, weniger nur eine Meinung zu haben und sich stattdessen mehr auf Fakten zu berufen. Da steht nämlich wortwörtlich...
"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."

Die Formulierung "will automatically assign predictable" bedeutet in sinngemäßer Übersetzung, es wird so zugewiesen, damit es vorhersagbar ist. Was denkst Du, an wen diese Botschaft "Du kannst das zweifelsfrei vorhersagen" gerichtet ist, vor dem Hintergrund, dass es vorher für den Admin ein Glückspiel war und er deshalb zu UDEV-Rules geradezu gezwungen wurde ... egal ob automatisch angelegt oder manuell? Dabei gehts auch gar nicht um eine orakelnde Vorhersage, sondern um den wahren Bedeutungsinhalt "Du weisst vorher zweifelsfrei, wie das NIC nach dem nächsten Systemstart heissen wird, auch ohne UDEV-Regel!". Das ist doch im Vergleich zu vorher eine wirklich greifbare und unzweifelhafte Verbesserung. 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... außer vielleicht den Verzicht auf nicht mehr so flüssig lesbare und leicht erinnerbare Namen wie "eth0", "eth1", "eth2". Ganz zum Schluss empfinde ich "but should fix real problems" als eine absolut zutreffende Feststellung.

Außerdem ist in dem Text die genannte Versions-Nr. V197 interessant. Fakt ist, diese o.g. Regel wäre eigentlich schon unter Jessie aktiv gewesen, wodurch zwangsläufig alle Formulierungen wie "früher" , "ging mal" oder "vorher" automatisch auf sysv deuten, ohne dass das explizit erwähnt wurde, weils bei wheezy eben noch sysv war.... auch wenn diese Funktion in Jessie noch mal vorübergehend mit einer auf wheezy/sysv rückwärts orientierten Sichtweise rausgepatcht wurde... ab Stretch war es jedenfalls aktiv. An UDEV selber hat sich nach meinem Verständnis in seiner Funktionalität doch gar nichts großartig geändert. Es wurde meiner Einschätzung nach lediglich besser in den system-manager integriert, was ich wiederum im Sinne der Systemstabilität für richtig halte. Aber es tut alles wie zuvor... insofern ist es müßig, darüber nachzudenken, ob udev jetzt systemd-udev heisst oder nicht.

Ich habe jedenfalls diese predictable NIC-Name nie deaktiviert und das von Anfang an immer als Vorteil verstanden. Nun gut... ist auch egal.... und vor allem, es ist nicht wirklich wichtig. Und um das noch mal deutlich zu sagen, ich kritisiere nicht, was andere tun oder deren Entscheidungen, ich bewerte das auch nicht, das steht mir nicht zu und es interessiert mich auch nicht. Ich versuche mich in meiner Argumentation nach Möglichkeit an Fakten zu orientieren und wenn ich denke, irgendeine Äußerung widerspricht den Fakten, dann empfinde ich es nicht als schlecht, unter Bezugnahme auf diese Fakten darauf hinzuweisen.

[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!!