Bennenung der NIC nach Kernelupgrade anders

[Colttt]

Hallo,

kurze frage, aktuell ist ja Debian Stretch mit Kernel 4.9, dort habe ich ein Netzwerinterface auf meinem Server Namens eno113, nach Upgrade auf den Backportkernel 4.19 heisst das ganze dann eno113np0. Warum ich dachte das bleibt bei eno113? Das ist schon echt kacke wenn der Server auf einmal nicht mehr erreichbar ist.

Vielen Dank für die Hilfe..

[MSfree]

Warum ich dachte das bleibt bei eno113?

(Un)Predictable Network Interface Names sind schon was feines

[guennid]

Frage: sollten udev-Aktionen nicht genau das seit jessie unterbinden?

[Colttt]

richtig, daher die frage warum das nicht so ist..

[DeletedUserReAsG]

Eigentlich ist der Name nach dem zweiten Schema Standard. Die Frage wäre eher, warum’s vorher nicht so war. Der Kernel hat damit übrigens nicht direkt etwas zu tun.

[MSfree]

Eigentlich ist der Name nach dem zweiten Schema Standard. Die Frage wäre eher, warum’s vorher nicht so war. Der Kernel hat damit übrigens nicht direkt etwas zu tun.

Dann schau mal hier:
https://www.freedesktop.org/wiki/Softwa ... faceNames/

The following different naming schemes for network interfaces are now supported by udev natively:

Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
Classic, unpredictable kernel-native ethX naming (example: eth0)

By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.

Mit anderen Worten, es ist ziemlich dem Zufall überlassen, ob da nun eno1, ens1, enp2s0, enx78e7d1ea46da oder eth0 rauskommt. So rosig, wie das in dem Artikel beschrieben ist "it simply works" ist es nämlich nicht.

Bis Jessie war es üblich, den Interfacename einfach an die Mac-Adresse zu koppeln, und das war wirklich stabil und hat nie zu irgendwelchen Problemen geführt, wenn man die Kiste rebootet. Ein Austausch eine (defekten) Netzwerkkarte hat naürlich einen neuen Namen für die neue Mac generiert, aber der war auch genauso schnell wieder auf den alten umgestellt. Erst durch das jetzige Namensschema ist es wirklich ein Zufallsgenerator geworden.

[TomL]

Mit anderen Worten, es ist ziemlich dem Zufall überlassen, ob da nun eno1, ens1, enp2s0, enx78e7d1ea46da oder eth0 rauskommt.

Ich glaube, dass diese Interpretation nicht das beschreibt, was wirklich systemisch dahinter steckt. Wirklich zufällig wärs nur dann, wenn ein NIC von Boot zu Boot jeweils einen anderen symbolischen Namen bekommen würde, aber genau das ist ja damit ausgeschlossen. Für mich ist aus diesem zitierten Text auch nicht zufällig ermittelt, woraus einmalig und initial der danach geltende Nic-Name abgeleitet wird. Ich lese das als von oben nach unten abgearbeitete Quellen, und die erste eindeutige (also die von der Firmware unterstützte) wird verwendet. Das hat m.M.n. gar nix mit Zufall zu tun, sondern ist imho einfach nur ein serielles Prüfen von Alternativen, wie das beispielsweise auch für jede andere Hardware gilt, deren Typ ermitteln werden muss. Insbesondere auch vor dem Hintergrund, dass bei jedem Boot konstant genau das gleiche ermittelt wird - deshalb, weil ja auch die Firmware der Hardware konstant bleibt.

Ändert sich allerdings die Firmware, sei es auch nur bei den Kernelmodulen nach einem Versionswechsel der Distribution, wäre es für mich jedenfalls nicht ungewöhjnlich, wenn sich auch das Ergebnis der obigen Prüfung ändert. Aber auch das bewerte ich als einmalige Angelegenheit, dessen Ergebnis danach konstant bleibt. Für mich ist das zunächst mal alles weit weg von 'zufällig'.

Kritischer empfinde ich nur den Umstand, dass USB-NICs möglicherweise durch wechseln eines Ports auf einmal anders benannt sind. In solchen Fällen würde ich die Hardware dann aber anhand ihrer Serial-ID identifizieren und selber eindeutig benennen. Das bliebe dann sogar konstant bei Portierung von Regel und Hardware auf andere Systeme. Aber auch diesen Schritt bezeichne ich nur als einen weiteren Schritt, als manuelle Ergänzung passend zu den gegebenen aus dem von Dir verlinkten Artikel-Zitat.

jm2c

[KBDCALLS]

Ich frage mich sowieso wer auf diesen hanebüchenen Unsinn gekommen ist. Bei einer Netzwerkarte mag das ja noch funktionieren. Was passiert bei mehrenen Netzwerkkarten und die dann noch verschieden Netzwerken zugeordnet sind , wenn dann auf einmal dem Kernel oder Udev einfällt die Devicenamen nach gutdünken zu vergeben. Sorry. Das kann doch eigentlich nur auf Potterings Mist gewachsen sein.

[MSfree]

Ich frage mich sowieso wer auf diesen hanebüchenen Unsinn gekommen ist.

Da hat jemand den Grundsatz: "Don't fix it, if it ain't broken!" grob verletzt. Wie gesagt, die Koppelung des Schnittstellennamens an die Mac hat früher mal absolut zuverlässig funktioniert.

Raspbian hat deshalb auch zurückgerudert und auf das alter Schema mit ethX zurückgestellt, schon, um alle Anleitungen, die sich mit der Netzkonfiguration auseinandersetzen, wieder einfach mit eth0 beschreiben zu können. Bei den jetzt unverhersagbaren Namen kann man eigentlich nichtmal mehr eine Anleitung schreiben, bei der man nicht erst die Dissertation über die Namensgenerierung vorweg schickt.

[KBDCALLS]

Ich hab das mal mit einer Sid Installation in einer Virtualbox ausprobiert.

You can disable these stable names and go back to the kernel-provided ones
(which don't have a stable order) in one of two ways:

- Put "net.ifnames=0" into the kernel command line (e. g. in
/etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT, then run "update-grub").

- Disable the default *.link rules with
"ln -s /dev/null /etc/systemd/network/99-default.link"
and rebuild the initrd with "update-initramfs -u".

Und siehe da ich hatte wieder eth0

Es kann nicht schaden sich mal durch die Readmes zu wühlen die bei den Programmen mitgeliefert werden.

• /usr/share/doc/udev/README.Debian.gz

[TomL]

Ich frage mich sowieso wer auf diesen hanebüchenen Unsinn gekommen ist.

Mich würde ja wirklich mal eine technische überprüfbare Begründung interessieren, die tatsächlich nachweist, dass das fehlerhaft funktioniert. Fakt ist, ich kann solche Probleme anhand unserer Systeme definitiv nicht bestätigen... das funktioniert beispiellos gut und vor allem dauerhaft konfliktfrei. Ist es nicht genau das, worauf es letztlich ankommt ...?... stabil und konfliktfrei? Ob das NIC einmalig als eno1 oder als eno08154711 benannt wird, empfinde ich als nebensächlich.... mir ist viel mehr wichtig, dass es nach der 'Taufe' wirklich konstant bei diesem Namen bleibt.

*hmmm*... wieso erkenne ich in den beiden folgenden Statements einen Widerspruch ...?... denn das obere Beispiel funktioniert unter der unteren Bedingung eben genau nicht... oder allenfalls nach dem zuvor bemängelten Zufallsprinzip:

Bei einer Netzwerkarte mag das ja noch funktionieren. Was passiert bei mehrenen Netzwerkkarten und die dann noch verschieden Netzwerken zugeordnet sind

Und siehe da ich hatte wieder eth0

Denn die predictable NIC-Names sind ja eigentlich genau für den Umstand mehrer Netzwerkkarten gemacht worden, damit sie eindeutig und wiederholt gleichbleibend benamt sind oder werden. Mir drängt sich bei solcher Kritik jedenfalls immer der Gedanke auf "ist primär sch***e, weil systemd", oder "ist sch***e, weil Units statt init.d", usw..... wirklich sachlich überprüfbare Aussagen fehlen mir allerdings .....

[KBDCALLS]

Anscheinend funktioniert das wohl nicht immer so wie gedacht, siehe Threadstart . Und wenn alles OK wäre , warum gibt es dann die Möglichkeit diesen Mechanismus rückgängig zu machen ?

[MSfree]

Denn die predictable NIC-Names sind ja eigentlich genau für den Umstand mehrer Netzwerkkarten gemacht worden, damit sie eindeutig und wiederholt gleichbleibend benamt sind oder werden.

Und was hat an der Kopplung der MAC an den Netzwerkname nicht funktioniert, daß man sich genötigt sah, das ehemals sehr gut und absolut zuverlässige System zu ändern? Hauptsache mal anders, weil das alte ja sooo veraltet ist?

Manche Designentscheidungen sollte man einfach auch mal als zweifelhaft akzeptieren und zurückrudern. Und diese Designentscheidung ist mehr als zweifelhaft.

[guennid]

Sorry. Das kann doch eigentlich nur auf Potterings Mist gewachsen sein.

Es fällt mir micht leicht zu sagen , aber das kann man ihm, glaube ich, nicht in die Schuhe schieben.

Ich habe den ganzen Zirkus von Anfang an nicht mitgemacht und mit der Benamung der Netzwerkschnittstellen noch nie Probleme gehabt. Das komplizierteste, was ich habe, sind aber auch nur zwei Ethernet-NICs am Debian-Router.

Grüße, Günther

[Colttt]

es _MUSS_ irgendwie am Kernel liegen.. grade wieder 4.9 gebootet und da habe ich wieder eno113

[guennid]

es _MUSS_ irgendwie am Kernel liegen

Glaub' ich nicht. Der numeriert, soweit ich weiß eth* und wlan* durch, wie sie ihm gerade unter die Finger kommen. Den Käse mit e*/weiß nicht was fabriziert erst udev.

[KP97]

...die Koppelung des Schnittstellennamens an die Mac hat früher mal absolut zuverlässig funktioniert.

Das kann man auch mit systemd problemlos einrichten.
Ich hatte das in einem anderen Zusammenhang schon mal beschrieben, aber ich wiederhole es noch mal:
Unter /etc/systemd/network eine Datei anlegen. Bei mir heißt diese 60-kabel.link und hat diesen Inhalt

[Match]
MACAddress=dc:fe:07:e1:77:22

[Link]
Name=eth0

Wichtig ist die Endung .link, der Name ist ansonsten frei wählbar.
Der 99-default.link kann unverändert bleiben, die MAC-Adresse muß natürlich mit der eigenen überschrieben werden.
Damit kann der Name eindeutig der MAC zugeordnet sein.

[novalix]

...die Koppelung des Schnittstellennamens an die Mac hat früher mal absolut zuverlässig funktioniert.

Das kann man auch mit systemd problemlos einrichten.

Wenn man die Störungsszenarien vergleicht, die zu einer Umbenennung der NIC führen, dann müsste man heute vorsichtshalber per se eine Regel für jede Netzwerkkarte erstellen (egal ob udev oder systemd), um der möglichen Umbenennung aus dem Weg zu gehen. Der Austausch einer Netzwerkkarte ist was anderes als ein Upgrade des Kernels (schon allein, was den Einsatz von Schraubendrehern betrifft).

Natürlich finden solche Ereignisse nach wie vor sehr, sehr selten statt.
Wäre das anders, gehörte die Einrichtung fest zugeordneter Namen zur NIC zum kanonischen Pflichtteil bei der Servereinrichtung. Ein Punkt mehr, der abzuarbeiten ist.

Ich vermute mal, dass der absolute Löwenanteil an Serverinstallationen da draußen ohne dezidierte Regeln in Betrieb ist. Gemessen an der Häufigkeit des Auftretens des Störungsfalls ist das vollkommen verständlich.
Auf der anderen Seite ist das Katastrophenpotential eines solchen Ereignisses doch recht erheblich.
Ich kann gut verstehen, dass man der Designentscheidung auch gerne mal mit dem Stinkefinger winkt, wenn man die möglichen Konsequenzen erfährt.

[DeletedUserReAsG]

Das große Geheimnis ist ja, dass man tatsächlich die Zuordnung anhand der MAC zu einem selbst ausgewählten Namen mittels udev-Regeln festschreiben kann. Das hätte das hier vorliegende Problem dann auch vermieden.

Früher™ war die Zuordung nicht fest – war das gleiche Spiel, wie mit den Blockdevices (für die dann ja die UUIDs erfunden wurden): was der Kernel zuerst sieht, bekommt den ersten Namen. In der Regel hat sich nix geändert, solange man nix an der HW geändert hat (und auch kein BIOS-Update fuhr, etc.). Hat man was geändert, konnte es durchaus passieren, dass die Reihenfolgen durcheinander gerieten. Unter Debian gibt’s allerdings bereits sehr lange eine udev-Regel für die Netzwerkinterfaces – viel länger schon, als es systemd und Co. gibt – vielleicht ist’s den Usern hier deswegen nicht aufgefallen, dass es eigentlich™ keine feste Zuordnung gab? Hatte allerdings auch seine Tücken – hat man ein Interface etwa wegen Defekt gewechselt hat, bekam das neue Teil dann eth1, obwohl’s das einzige Interface in der Maschine war. Das Löschen der Regel hat’s dann gefixt, aber einige Threads gab’s durchaus deswegen, wenn ich mich nicht falsch erinnere.

[TomL]

Anscheinend funktioniert das wohl nicht immer so wie gedacht, siehe Threadstart

Nach einem massiven Eingriff in das Betriebssystem durch manuellen Austausch eines Kernels? Und das Hardware dann möglicherweise anders gehandhabt wird, eben auch durch systemd, weil der Kernel möglicherweise andere Infos rausgibt....das wundert Dich? Für mich ist das ein handgemachtes Problem... fast (mal so sarkastisch umschrieben) auf gleicher Ebene wie "wieso sind meine Daten alle weg? ich habe doch nur format c: gemacht". Solcherart tiefen Eingriffe in das Betriebssystem haben eben Auswirkungen... die können zum guten sein, oder eben auch nicht, oder auch einfach nur Paradigmen ändern.... ich betrachte das als völlig normal und bewerte es als Ergebnis von Weiterentwicklung.

Und wenn alles OK wäre , warum gibt es dann die Möglichkeit diesen Mechanismus rückgängig zu machen ?

Ich vermute die gleichen Beweggründe, mit denen auch die net-tools trotz iproute2 überleben. Oder die fstab überlebt mithilfe autogenerierter Mount-Units. Oder sudo überlebt trotz Polkit. Oder init.d-Script wegen autogenerierter Service-Units. Vermutlich deshalb, damit auch die zufriedengestellt werden, die unbedingt an älteren Standards festhalten wollen.

Und was hat an der Kopplung der MAC an den Netzwerkname nicht funktioniert, daß man sich genötigt sah, das ehemals sehr gut und absolut zuverlässige System zu ändern?

Das funktioniert doch immer noch.... kp97 und niemand haben 2 Wege aufgezeigt.... network.link und udev....also gibts auch hier nicht wirklich eine Verschlechterung zum Früher.

[guennid]

nach Upgrade auf den Backportkernel 4.19

Nach einem massiven Eingriff in das Betriebssystem durch manuellen Austausch eines Kernels?

ohne Worte.

Das Debian-Kernel-Image ist nun mal, ich glaube seit squeeze, via initrd abhänigig von udev ergo redhat (ok, das kam dann erst mit jessie - nicht ungeschickt). Da muss man schon ein paar Klimmzüge veranstalten, wenn man das los werden will - es geht aber (immer noch) - ist dann halt kein „zeitgemäßes“ Rundum-sorglos-System mehr.

[MSfree]

Das funktioniert doch immer noch.... kp97 und niemand haben 2 Wege aufgezeigt.... network.link und udev....also gibts auch hier nicht wirklich eine Verschlechterung zum Früher.

Es funktioniert aber nicht mehr vollautomatisch, sondern bedingt manuelles Anlegen dieser Link-Dateien. Das würde ich dann doch als Verschlechterung sehen wollen.

[Colttt]

scheint wohl am Treiber/Kernel zu liegen..

https://bugs.debian.org/cgi-bin/bugrepo ... bug=929622

[guennid]

Ich lese das genau anders rum, bzw so, wie schon eingangs genannt: udev ist dafür verantwortlich (das systemd- können wir uns sparen, alldieweil's mittlerweile kein anderes udev als systemd-udev gibt):

Code: Alles auswählen

These names are generated by systemd-udevd, although they are based on
information from the kernel.

Looking at the system-udevd source code, it appears that the extra
"np0" is derived from a new "phys_port_name" attribute of the network
device, which the bnxt_en driver added support for in Linux 4.14.

It looks like this is required for switchdev functionality, so I don't
think this change is going to be reverted.

Bei mehreren NICs der gleichen Art würde ich niemands Rat folgen und in einer udev-Regel einen selbstgewählten Namen an die jeweilige MAC-Adresse des Gerätes binden.

[RobertS]

Die MAC Adresse ist ja per Software änderbar, um eine Karte in einen anderen Slot zu stecken brauch ich schon physischen Zugriff auf die Maschine. Von daher taugt die MAC, meiner Meinung nach, nicht zur eindeutigen, dauerhaften Kennzeichnug einer Schnittstelle.