[Eisfair] [e1] Netzwerk-Namen mit udev

[Hans-Georg Kiefer]

Hallo, Marcus.

Am 19.12.2016 um 10:48 schrieb Marcus Roeckrath:
> Hallo Tanne, hallo Holger,
>
> Marcus Roeckrath schrieb am Mo, 19 Dezember 2016 06:35
>> Stört halt nur, dass sich die BusID ändern kann.
>>
>>>  Das ist ja auch eigentlich alles völlig Wurscht. Gibt's denn
>>> keine
>>>  Möglichkeit, die Netzwerkschnittstelle an ihrer MAC
>>> festzumachen und den
>>>  Namensraum schlicht nach der aufsteigenden MAC zu nummerieren?
>>>
>>>  Damit wäre das Ganze absolut nur noch vom Netzwerk-Geraffel
>>> abhängig.
>>
>> Verwendung von Phantasienamen (möglichst ohne ethX, oder mit
>> ausreichend
>> hohem X).
>>
>> Aber da würden wir im Vergleich zu allen anderen auch wieder ein
>> eigenes
>> Süppchen kochen.
>
Joa, entweder ich maches es wie alle Anderen, oder ich mache es 
besser... :-)

Das eisfair-Projekt hat sich 'easy' auf die Fahnen geschrieben und 
begnüpgt sich mit der Nutzung in kleineren, semi-professionellen 
Netzwerken. Somit ist auch eine Nutzzung durch weniger fachkundige User 
sehr wahrscheinlich. Ein solcher mag erstmal merkwürdig aus der Wäsche 
schauen, wenn er in seinen Homeentertainment-Server eine Soundkarte 
steckt und anschlissend das Netzwerk nicht mehr funktioniert.

>
> Hier - Link hatte Holger IMHO auch schonmal gepostet - wird das ganze
> erläutert, auch die Reihenfolge (Policy) mit der udev versucht den
> eindeutigen Namen festzulegen:
>
>
> 1. Names incorporating Firmware/BIOS provided index numbers for on-board
> devices (example: eno1)
> 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot
> index numbers (example: ens1)
> 3. Names incorporating physical/geographical location of the connector
> of the hardware (example: enp2s0)
> 4. Names incorporating the interfaces's MAC address (example:
> enx78e7d1ea46da)
> 5. 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.
> [/Zitat]
>
Hab ich doch geahnt, dass es sowas gibt!

> Um die Policy zu ändern - insbesondere 4. zu aktivieren und eventuell
> als primäre Regel festzulegen - wäre eine
> /etc/udev/rules.d/80-net-setup-link.rules zu erstellen
> (https://lists.debian.org/debian-user-german/2015/05/msg00045.html).
>
> Die könnte bei uns auch /lib/udev/rules.d/80-net-names-slot.rules
> heißen.
>
> Wenn man in dieser festlegt, dass die Devices primar nach der MAC
> (ID_NET_NAME_MAC) benannt werden soll, wären wir aus dem ganzen Dilemma
> raus.
>
Man müsste auch keine Unterschiede mehr machen, ob nur eine oder mehrere 
Netzwerkkarten verbaut sind oder im Verlauf der Zeit verbaut werden.

> Ich denke, da sollten wir mal ernsthaft drüber nachdenken.
>
Da muss ich mich geschlossen halten.

> Interessant die Aussage in der ersten Quelle:
>
> "Stable interface names even when hardware is added or removed, i.e. no
> re-enumeration takes place (to the level the firmware permits this)"
>
> da wir gerade andere Erfahrungen machen.
>
Der Teil in Klammern relativiert das ganze gleich wieder.

> Ich denke, dass BIOS/UEFI eine nicht unerhebliche Rolle spielen.
> Onboard-Karten sollten sich bei udev eher als eno-Devices finden lassen,
> aber wir finden sie dennoch als enp-Devices (PCI) vor.
>
UEFI wird noch getestet, BIOS Award und Phoenix können das schonaml.

> Fazit: Es gibt einen Weg, eindeutige Namen aufgrund der MAC zu nutzen;
> bleibt die Frage, wollen wir das so?
>
>
Das musst du beantworten.

Tanne
-- 
--------------------------
Es grüsst hochachtungsvoll
******* T A N N E ********

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus