• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Umbenennung der Netzwerk-Karten bei OpenSUSE 13.1 (eth0 weg)

gehrke

Administrator
Teammitglied
Moin *,

ist jetzt etwas peinlich, aber egal:

Ich habe tatsächlich einen guten Monat gebraucht, um festzustellen, dass mit OpenSUSE 13.1 scheinbar eine Umbenennung der Netzwerk-Karten einher gegangen ist. Seitdem habe ich kein eth0 mehr auf meinem System, sondern stattdessen ein 'enp3s0':
Code:
j2:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether f1:01:12:00:60:e0 brd ff:ff:ff:ff:ff:ff
    inet 172.16.11.6/24 brd 172.16.11.255 scope global enp3s0
       valid_lft forever preferred_lft forever
    inet6 fe80::fad1:11ff:fe00:50e0/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s25: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 01:10:09:7c:82:54 brd ff:ff:ff:ff:ff:ff

Eine Recherche brachte als Begründung, dass die verlässliche Vorhersagbarkeit der Benennung ein Security-Feature sei. Näheres hierzu findet sich beispielsweise hier: http://wrohr.eu/anleitungen-howto/10211-neu-an-opensuse-13-1

Ein echtes Problem habe ich damit bislang nicht. Es ist mir erst aufgefallen, als ich einen tcpdump brauchte und das Interface nicht da war. Ich könnte mir aber vorstellen, dass es irgendwo Scripten gibt, die Probleme bekommen, weil sie mit 'eth0' arbeiten.

Nur so als Information (auch wenn es die meisten schon wissen werden)...
 

soyo

Hacker
Hi
Ich bin froh , das es so ist.
Hab meine Betriebssysteme auf Wechselplatten.
Wenn ich meine SUSE in einen anderen Rechner geschoben hab , mußte ich immer händisch , die Netzwerkkarte (Hardware) für eth0 ändern und dann den Rechner neu starten.
Um ins Internet zu kommen. Das hat mich an Suse doch später schon gestört .
Das ist nun vorbei :thumbs:

Bei mir sind aber nach der installation von Suse 13.1 Beide (das Neue und eth0) da , hab halt eth0 unkonfiguriert gelassen.
MfG soyo
 

BdMdesigN

Member
Bei mir ist nur eth0 vorhanden.
Das kommt warscheinlich daher, das es ein Update von 12.3 -> 13.1 war und ich eine Bridge für KVM installiert ist.

Oder mir ist es nicht aufgefallen.

MfG

Peter
 

josef-wien

Ultimate Guru
gehrke schrieb:
einen guten Monat gebraucht, um festzustellen
soyo schrieb:
Bei mir sind aber nach der installation von Suse 13.1 Beide (das Neue und eth0) da
Ich frage mich immer wieder, warum es so viele "release notes lesen-Verweigerer" gibt.

BdMdesigN schrieb:
Das kommt warscheinlich daher, das es ein Update von 12.3 -> 13.1 war
Noch ein (lautloser) Schuß ins Blaue: Du hast noch eine Datei /etc/udev/rules.d/70-persistent-net.rules, durch deren Inhalt eine der Bedingungen in /usr/lib/udev/rules.d/80-net-name-slot.rules nicht erfüllt ist.
 

BdMdesigN

Member
josef-wien schrieb:
gehrke schrieb:
....
Noch ein (lautloser) Schuß ins Blaue: Du hast noch eine Datei /etc/udev/rules.d/70-persistent-net.rules, durch deren Inhalt eine der Bedingungen in /usr/lib/udev/rules.d/80-net-name-slot.rules nicht erfüllt ist.

Ahh ok, dann werde ich das mal ändern.
Danke für den Hinweisss.

Obwohl mich das mit eth0 nicht sonderlich stört.
Aber wenn es der Sicherheit dient, wird es geändert.

Mit den Update von Version auf Version (12.1 -> 12.3 -> 13.1) lag ich aber richtig, sonst würde es die Datei "70-persistent-net.rules" ja nicht geben.

MfG

Peter
 

josef-wien

Ultimate Guru
BdMdesigN schrieb:
Aber wenn es der Sicherheit dient
Irgendeine Begründung muß man schließlich schreiben, wenn man etwas Neues unter die Leute bringen will.

Ich schließe nicht aus, daß die erzeugten udev-Umgebungsvariablen (in dieser Reihenfolge) ID_NET_NAME_ONBOARD, ID_NET_NAME_SLOT und ID_NET_NAME_PATH ein bißchen gefinkelter sind als die Lösung durch den Kernel, aber ich warte schon auf den ersten Beitrag, in dem beklagt wird, daß zwei der neuen Begriffe plötzlich vertauscht sind. Mir erschließt sich jedenfalls nicht, was gegenüber eth0, eth1 usw. sicherer sein soll, und ich stimme der Aussage von robi durchaus zu. Was davon zu halten ist, daß die Erfinder gleich vier Varianten anbieten, um die Neuerung nicht zu verwenden, und daß die wirklich eindeutige Zuordnung per MAC-Adresse (zu weder vom Kernel noch jetzt von udev verwendeten Identifizierungsmerkmalen) so wie bisher selber gemacht werden muß, darf jede(r) selbst beurteilen.
 
Oben