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

[jmar83]

​Name LAN-Adapter: enxb827eb...
​
​Name WLAN-Adpter: wlan0
​
​
​Weiss jemand, wie Raspbian das genau regelt? Ich möchte ein Debian (Intel)-System entsprechend angleichen, allerdings sehe ich immer nur den Tipp mit dem Kernel-Parameter "net.ifnames=0 biosdevname=0​", welche SÄMTLICHE Netzwerk-Gerät auf non-predictable-Namen umstellt. Dabei geht's mir drum, dass nur der LAN-Adapter-Name predictable sein soll.
​
​Also:
​
​LAN = predictable (enxb827eb......)
​
​WLAN = Nicht predictable (wlanX)
​
​
​Weiss jemand, wie Raspbian das genau macht (Konfiguration?), und/oder wie man das bei Debian (Intel) hinkriegt?

[MSfree]

​Weiss jemand, wie Raspbian das genau macht (Konfiguration?)

Bis Raspbian Stretch (für Buster weiß ich es nicht) ist der Kernelparameter net.ifnames=0 fest in den Kernel kompiliert und nicht änderbar.

und/oder wie man das bei Debian (Intel) hinkriegt?

net.ifnames=0

Lies mal diesen Thread hier:
viewtopic.php?t=173354

Es gibt aber auch noch die Möglichkeit, eine Regel für systemd zu setzen, mit der der NIC-Name festgelegt wird.

[jmar83]

Hallo

Vielen Dank fürs Feedback.

net.ifnames=0 stellt aber alles auf nicht-predictable, also wird auch aus dem LAN-Adapter wieder "ethX", was nicht sein sollte.

Benötigt wird:

LAN = predictable
WLAN = nicht-predictable


"Bis Raspbian Stretch (für Buster weiß ich es nicht) ist der Kernelparameter net.ifnames=0 fest in den Kernel kompiliert und nicht änderbar."

Nein, mann kann dies über "raspi-config" ändern. Allerdings gilt es dann, wie bereits erwähnt, nur für den LAN-Adapter (dieser heisst dann: enxb827eb......, "enx" ist das Präfix, der Rest ist die MAC). Der WLAN-Adapter heisst dabei weiterhin "wlan0", auch wenn man "Network" -> "Predictable Names" in "raspi-config" auf "enabled" schaltet. (Bei Stretch wohlverstanden)

Und zwecks Kompatibilität zu einer vorhandenen Software (Portierung von Rasbpian Stretch auf Debian Stretch amd64) sollte ich das bei Debian genauso hinkriegen wie bei Raspbian. Das geht dann wohl eher in Richtung udev/systemd...?

[debianoli]

Der Punkt in dem bereits erwähnten Thread dürfte für dich relevant sein: viewtopic.php?f=27&t=173354&start=15#p1206658

[MSfree]

Benötigt wird:

LAN = predictable
WLAN = nicht-predictable

OK, ich weiß was du willst. Aber bei "predictable" sträuben sich mir die Nackenhaare. Denn das, was die Entwickler als predictable bezeichnen, ist tatsächlich völlig unpredictable und der NIC-Name kann sich sogar von einer zur nächsten Kernelversion ändern. Bei der alten klassische Methode war der NIC-Name jedenfalls vorhersagbar, also predictable.

Wenn du also die neue Zufallsmethode für LAN haben möchtest und die alte verläßliche Methode für WLAN, dann mußt du das über systemd einrichten.

[jmar83]

Manchmal ist es nicht die MAC-Adresse, welche bei "predictable" angezeigt wird, sondern der Gerätepfad, an welchem Bus das Gerät halt ist.

enp = PCI(e)-Bus (?)
enx = Anderes Bus-System, da das Raspi über keinen PCI(e)-Bus verfügt.


...aber es stimmt schon was Du sagst, zumindest die MAC-Adresse sagt nicht viel zum Gerät aus. Damit weiss man auf Anhieb nicht, um welches Gerät es sich handelt.

(Gut, beim Raspi gibt's ja (normalerweise) nur 1 LAN-Anschluss - es sei denn man hantiert mit einem USB/LAN-Adapter)

[jmar83]

Im Moment haben wir es in der Software so gelöst, dass der Netzwerk-Adapter-Name ausgelesen wird (steht immer am Anfang des Strings -> Ausgabe des alten ifconfig-Befehls), und dann wird einfach auf 'e...' geparst.

Das deckt dann soweit alles ab:

- ethX
- enxMACAdresse
- enp....


...glücklicherweise fängt da alles mit einem "e" an!

[Teddybear]

Servus,

Vermutlich löst man das am einfachsten über udev, so wie man es halt zuvor schon immer gemacht hat.
/etc/udev/rules.d/70-persistent-net.rules

Code: Alles auswählen

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="wlan0"

[jmar83]

Und wie könnte man das lösen wenn man das auf jede x-beliebigen WLAN-Controller, also ohne konkrete MAC-Adresse? Sollte ein Image damit vorbereiten... GENAU das ist das Problem.

Deshalb habe ich, wie bereits erwähnt, mal die predictable-Geschichte über diesen Kernel-Parameter gelöst, und dabei das Glück (im Unglück) gehabt dass sämtliche LAN-Controller, ob nun predictable oder nicht, mit einem "e" anfangen... ethX, enxMACAdresse, enpVXYZ, etc.

Die Lösung wo man eine MAC-Adresse dazu braucht, scheidet also schon mal aus.

Grundsätzlich sollte die ganze Sache "predictable" sein, den WLAN-Controller sollte man aber davon ausnehmen, dieser soll weiterhin "wlan0" heissen, aber ohne die Angabe von irgendwelchen MAC-Adressen.

Wenn es z.B. einen Kernel-Parameter geben würde wie "net.ifnames", welcher sich aber NUR auf WLAN-Controller bezieht. Oder vielleicht auf Treiber-Ebene? Es handelt sich um ein USB-WLAN-Modul von Ralink, welches das Paket "firmware-ralink" benötigt. Erst dann erscheint es mit "ip" oder "ifconfig"..

[Teddybear]

Ja, dann nagel es doch per driver fest...

Code: Alles auswählen

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="rt73usb", NAME="wlan0"

Oder so in der Art könnte gehen.

[jmar83]

Vielen Dank, werde mal schauen. Allerdings stelle ich mir schon jetzt die Frage, was passiert wenn man mehrere von diesen USB-WLAN-Sticks einsetzen würde. (Die Frage ist rein theoretisch und keinesfalls praxisbezogen...)

[TomL]

Allerdings stelle ich mir schon jetzt die Frage, was passiert wenn man mehrere von diesen USB-WLAN-Sticks einsetzen würde. (Die Frage ist rein theoretisch und keinesfalls praxisbezogen...)

Via Udev auf Serial-ID matchen... das sollte zur Unterscheidung reichen.

BTW, Du solltest darauf hinweisen, dass das hier ein Crossposting ist und fairerweise die jeweiligen Ergebnisse/Erkenntnisse quer weitergeben, so das nicht unterschiedliche Leute mehrfach das gleiche Problem lösen müssen.

[guennid]

etwas, meinetwegen auch ziemlich OT :
Verwendung des Begriffs „predictable“ im Zusamenhang mit der Benamung von Netzwerkschnittstellen im Deutschen. Gehört jetzt die Glaskugel zum Grundbestandteil eines Debian-Systems?

Wenn ich recht sehe, dann geht's doch um die Zuweisung fester/dauerhafter Namen für „Dinge“, die der Linux-Kernel je nach Systemzustand anders benennt/benennen kann. Dafür ist seit ca. 2004 udev zuständig. Warum das nun, nachdem systemd-udev in diese dauerhafte Zuweisung auch die Namen für Netzwerkschnittstellen einbezogen hat, „predictable“ heißen soll, erschließt sich mir nicht. Mit „Vorhersage“ hat das nach meinem Verständnis wenig zu tun.

Grüße, Günther

[TomL]

Das ist imho falsch interpretiert. "Vorhersagbar" bedeutet, dass der Admin konkret vorhersagen kann, wie ein Device nach einem Boot des System vom Kernel bezeichnet ist, was ihm vorher ohne zusätzlichen Eingriff gar nicht möglich war. Er musste vorher zwangsläufig eine UDEV-Regel erstellen, um Eindeutigkeit herzustellen und genau das muss er nun nicht mehr. Und genau dieses Wissen eines vorhersagbaren Device-Namens kann er dann zuverlässig in eine Conf 'einbauen'. Wenn man sich darauf einlässt, wird man feststellen, dass das tatsächlich absolut zuverlässig funktioniert, weil ein Device mit dem Namen und einem Slot in Zusammenhang gebracht wird. Gerade bei statischen Systemen oder Server-Farmen ist das eine deutliche Reduzierung des Administrationsaufwandes. Natürlich gibt es Ausnahmen, wenn sich z.B. der Slot ändert... das liegt dann aber nicht am Konzept, sondern an der manipulativen Einwirkung eines "Technikers", der den Slot für ein Device gewechselt hat.... wie das bei USB-Ports halt passieren kann. Fummelt der Techniker nicht dran rum, ändert sich auch an der für den Admin verfügbaren Vorhersagbarkeit gar nichts. Aber speziell bei USB-Ports kann man das lösen, in dem man eine Regel über die SerialID des Devices match't. Dann brauche ich jedoch nur eine Regel, aber nicht mehrere, um für alles und jedes manuell mit hohem eigenem Arbeits-Aufwand eine Eindeutigkeit herzustellen.

Natürlich kann es auch passieren, dass sich eine Bezeichnung aufgrund einer Änderung im Hardware-Layer des Kernels ändert, wie das jetzt wohl passiert ist. Aber auch das hat nichts mit dem Konzept an sich zu tun, Name und Slot von einander abhängig zu machen, sondern ist entstanden durch eine gezielte Manipulation im Hardware-Layer des Kernels.

Ich bleibe dabei, dieses spezielle Konzept ist wie systemd selber absolut klasse, richtig gut durchdacht und funktioniert geradezu perfekt..... abgesehen davon, dass wie in jedem Software-Projekt die obligatorischen Fehler enthalten sind.... aber auch das hat nichts mit dem Konzept an sich zu tun. Perfekt funktioniert es nur da nicht, wo halt die Erwartungshaltung nicht kompatibel zum Konzept bzw. zur technischen Realisierung ist. Aber so ist es nun mal, wenn sich ein Projekt weiterentwickelt.... und dabei ist meine Meinung, hier hat es sich absolut positiv weiter entwickelt. Die Namensbildung an die Position in der Hardware zu binden finde ich jedenfalls eine geniale Idee. Wenn mir allerdings das Konzept an sich nicht passt, muss ich die Marke wechseln.... mach ich doch bei Autos auch so.... ist doch eigentlich ganz einfach....

jm2c

[MSfree]

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.

Ich bleibe dabei, dieses spezielle Konzept ist wie systemd selber absolut klasse, richtig gut durchdacht und funktioniert geradezu perfekt.....

Immer diese Jubelperser

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

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