# Device Name für Ethernet und WLAN etwas wirr ...

## alexander_ro

Hi Mädels ... Jungs ...  :Smile: 

Bin etwas verwirrt wegen der neuen Geräte Namen des Linux Kernels. Bisher also bei mir mit Debian war die erste Ethernet Schnittstelle eth0 soweit so praktisch weil man sich darauf verlassen konnte und eine Linux Installation ohne Veränderung von einem Rechner auf den anderen umziehen kann. Das gleiche für WLAN mit wlan0 ... es gibt in allen Systemen nur eine einzige Ethernet Schnittstelle.

Ich habe jetzt Gentoo auf einem Asus 901 auf einem Server in einer KVM VM und auf einem Alien M14 installiert. 

Wer will raten wie viele verschiedene Namen jetzt eth0 hat?

...

drei: enp4s0, enp7s0, enp1s0

gleicher Käse für das WLAN

Das ist Total blöd weil ich jede Installation manuell bearbeiten muss und in den Konfig Dateien die Device Namen ändern. Vermutlich gibt das auch Probleme wenn man eine Installation von einem Rechner auf einen anderen umzieht was bei mir öfter mal vorkommt.

Kann man das irgendwie vereinheitlichen das die erste Ethernet Schnittstelle immer z.B. enp1s0 benannt wird?

Grüße

Alexander

----------

## schmidicom

Die neue Namensgebung hat nichts mit dem Kernel zu tun sondern kommt von udev und macht bei genauerer Betrachtung durch aus Sinn:

http://en.wikipedia.org/wiki/Consistent_Network_Device_Naming

Es gibt einen Parameter den man dem Kernel übergeben kann und im späteren bootvorgang dann udev dazu veranlasst das alte Schema zu benutzen aber den habe ich gerade nicht im Kopf.

----------

## cryptosteve

Hi,

```
net.ifnames=0
```

gemäß Gentoo Wiki zu Udev/upgrade

----------

## alexander_ro

Ich kann da keinen Sinn erkennen auch nicht in dem Wiki Text. Multihomedhosts hab ich hier. Probleme macht da der Device Namen nicht völlig unrelevant in dem Zusammenhang. Ausserdem was ist daran konsistent wenn auf jeder Maschine die Schnittstellen anders benannt werden?

Das hat ja keinerlei Zusammenhang und erfolgt völlig willkürlich.

Hat das schon mal jemand gemacht mit dem umschalten auf die alten Namen?

Ich habe da den verdacht das es dann halt wieder irgendwo anders klemmt wenn man das macht.

----------

## cryptosteve

 *alexander_ro wrote:*   

> Hat das schon mal jemand gemacht mit dem umschalten auf die alten Namen?
> 
> 

 

Ich zumindestens nicht. Nachdem ich mich anfänglich zunächst ein wenig "geärgert" habe, dass man mir mein altes eth0 weggenommen hat, habe ich mich mittlerweile daran gewöhnt, dass es hier jetzt enp6s0 ist. Das ist zum Schreiben war etwas holpriger, aber sooo oft, als das es eine echte Auswirkung hat, muss ich an den Devicenamen nun auch nicht.

----------

## schmidicom

Und wenn man anstelle von Scripts einen intelligenten Hintergrunddienst (wie "net-misc/networkmanager" oder "net-misc/wicd") verwendet spielt die Namensgebung sowieso keine Rolle mehr weil die dort gepeicherten Profile, wenn überhaupt, an der MAC-Adresse festgenagelt werden.

----------

## mv

Die neue Namensgebung ist in der Tat fragwürdig, aber die alte war unhaltbar, weil sie zu Race-Conditions geführt hat.

Ich empfehle, selber udev-Regeln zu erstellen und z.B. Namen wie "lan0", "lan1", ... für Ethernet, "wifi0", "wifi1", ... für Wifi, "wan0", "ieee" o.ä. für andere Schnittstellen zu vergeben. Natürlich musst Du in den Regeln selbst darauf achten, dass im Fall von z.B. mehreren Ethernet-Karten die korrekte Numerierung gesichert ist. Da Du aber Deine Hardware kennst, kannst Du das selbst am besten tun (z.B. weißt Du, ob Du die Mac-Adresse abfragen musst, oder ob der Test auf den Treiber oder den Vendor genügt, oder ob Du gar überhaupt nur eine entsprechende Karte hast und gar keinen Test brauchst.)

----------

## mv

 *schmidicom wrote:*   

> (wie "net-misc/networkmanager" oder "net-misc/wicd")

 

Das klaffende Sicherheitsloch "policykit" will man sich sicher nicht installieren - also scheidet networkmanager aus. wicd ist veraltet und benutzt Schnittstellen des Kernels, die bald entfernt werden. Der neue wicked von SuSE klingt interessant, aber dazu gibt es noch kein Ebuild, und mir ist anhand der Beschreibung nicht ganz klar, ob es nicht doch üble Abhängigkeiten hat.

----------

## schmidicom

Ich bin auch kein Fan von policykit, hauptsächlich wegen diesem XML-Graffel in den Konfigurationsdateien, aber da man daran inzwischen kaum noch vorbeikommt [1] habe ich gelernt damit zu leben.

```
 * These packages depend on polkit:

app-admin/system-config-printer-common-1.4.3 (policykit ? >=sys-auth/polkit-0.104-r1)

gnome-base/gconf-3.2.6-r3 (policykit ? sys-auth/polkit)

net-misc/networkmanager-1.0.0 (>=sys-auth/polkit-0.106)

net-print/hplip-3.14.10 (policykit ? sys-auth/polkit)

sys-apps/accountsservice-0.6.40 (sys-auth/polkit)

sys-apps/systemd-216-r3 (policykit ? sys-auth/polkit)

sys-auth/polkit-qt-0.112.0-r1 (>=sys-auth/polkit-0.103)

sys-fs/udisks-2.1.3 (>=sys-auth/polkit-0.110)

sys-power/upower-pm-utils-0.9.23-r2 (>=sys-auth/polkit-0.110)
```

----------

## mv

 *schmidicom wrote:*   

> Ich bin auch kein Fan von policykit, hauptsächlich wegen diesem XML-Graffel in den Konfigurationsdateien

 

Das ist noch die Geringste der Fehlentscheidungen von policykit gewesen. Die Schlimmste ist die Grundsatzentscheidung, das gesamte Unix-Rechtesystem durch einen Daemon ad absurdum zu führen und damit potentielle privilege-escalation-Möglichkeiten über dbus u.ä. zu eröffnen. Dass dbus und policykit dann auch noch so komplex geraten sind, dass Sicherheitlöcher an der Tagesordnung sind und wohl nie alle gefunden werden, ist einfach der Sicherheits-GAU.

Bei den meisten Sachen, die Du angeführt hast, ist ja policykit glücklicherweise auch nur optional (wer Gnome benutzt, ist selber schuld); für udisks und upower gibt es sichere Alternativen. Das Problem ist nur die Software, die von dem unsicheren udisks und upower-Gesocks abhängt. Bei mir war das glücklicherweise nur k3b (und damit zusammen mit dem semantik-desktop-Quatsch der Hauptgrund, KDE endgültig zu entsorgen).

----------

## SkaaliaN

 *mv wrote:*   

> ..... Bei mir war das glücklicherweise nur k3b (und damit zusammen mit dem semantik-desktop-Quatsch der Hauptgrund, KDE endgültig zu entsorgen).

 

Was setzt du stattdessen ein, wenn man fragen darf?

LG

----------

## alexander_ro

 *mv wrote:*   

>  aber die alte war unhaltbar, weil sie zu Race-Conditions geführt hat.

 

In welcher Art waren die?

Wie kann ich denn den Zusammenhang zwischen MAC Adresse und Device Namen herstellen. Also so das eine MAC immer den gleichen Namen bekommt. Die MAC Adressen müsste ich halt dann von allen Rechnern in dem System-Image konfigurieren. Das sind zwar einige aber die Zahl ist endlich.

Eigentlich will ich diese Manager nicht ein Stück Software mehr das Probleme machen kann. Viel wichtiger ist aber gehen die Netzwerk Manager auch ohne Desktop?

Zwei der oben genannten Beispiele haben nur Kommandozeile.

 *schmidicom wrote:*   

> Die neue Namensgebung hat nichts mit dem Kernel zu tun

 

Bei mir steht da die folgende Meldung im Log:

```

kernel[2016] renamed network interface wlan0 to wlp13s0

```

deshalb habe ich vermutet das der Kernel das macht.

----------

## mv

 *metal1ty wrote:*   

> Was setzt du stattdessen ein, wenn man fragen darf?

 

Für k3b: xfburn. Ich hätte lieber einen Wrapper für die Schilling-Tools, weil die Brennergebnisse von diesen Tools aufgrund der großen Erfahrung von Schilling vermutlich besser sind, aber vielleicht spielt das bei modernen Brennern und schnellen Rechnern ohnehin keine entscheidende Rolle mehr.

Für KDE: kmail hatte ich ohnehin schon lange durch claws-mail ersetzt (für die Familie; für meine eigene Benutzung bin ich ohnehin immer noch bei alpine), und für kdepim-Bloat bestand somit ohnehin nie Bedarf. xterm war seit jeher besser als kterm. Das Einzige, was ich etwas vermisste, war kdm, aber mit slim kann ich bislang auch leben.

Als Fenstermanager hatte ich zunächst meine uralte fvwm-Konfiguration wieder aufgetaut. Inzwischen benutze ich fvwm-crystal-3.3.2 mit einigen Patches, das so insgesamt meiner ursprünglichen fvwm-Konfiguration sehr nahe kommt, aber etwas mehr am "mainstream" ist.

----------

## schmidicom

Und was benutzt du anstelle von udisks? pmount, autofs oder gehörst du zu denen die bei jedem Wechselmedium ein root-terminal aufmachen?

----------

## mv

 *alexander_ro wrote:*   

>  *mv wrote:*    aber die alte war unhaltbar, weil sie zu Race-Conditions geführt hat. 
> 
> In welcher Art waren die?

 

Kernel und udev bastelten beide (möglicherweise zeitgleich) am selben Namespace (z.B. eth* und wlan*) herum...

 *Quote:*   

> Wie kann ich denn den Zusammenhang zwischen MAC Adresse und Device Namen herstellen.

 

Mit udev-Regeln. Schau Dir als Beispiel die alten Regeln an, die udev früher in /etc/udev/rules.d erstellt hatte.

Ich habe hier beispielsweise so etwas  */etc/udev/rules.d/30-my-net.rules wrote:*   

> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="MAC Hexstring entfernt", NAME="ieee", OPTIONS="last_rule"
> 
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEMS=="pci", KERNEL=="eth*", NAME="lan0", OPTIONS="last_rule"
> 
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEMS=="usb", KERNEL=="wlan*", NAME="wifi0", OPTIONS="last_rule"

 

Das funktioniert natürlich nur so einfach, weil ich weiß, dass es außer dem spezifierten ieee höchstens ein weiteres eth* und/oder wlan* geben wird.

Die Daten, auf die Du testen kannst, holst Du Dir z.B. mit 

```
udevadm info --path=/sys/class/net/lan0 --query=all --attribute-walk
```

----------

## mv

 *schmidicom wrote:*   

> Und was benutzt du anstelle von udisks? pmount, autofs oder gehörst du zu denen die bei jedem Wechselmedium ein root-terminal aufmachen?

 

Wenn ich "generelle" Benutzung bräuchte, würde ich entweder pmount oder sudo-Regeln nehmen. autofs ist aber auch in Betrieb, aber derzeit noch nicht für die Sticks.

Da es aber ein Privat-PC ist und ich die eingesteckten Sticks und Platten alle kenne, habe ich allen Sticks/Platten feste Device-Namen (mit udev) und diesen feste Mount-Punkte zugeordnet - derzeit ohne automount sondern mit mount-Option "usermount", weil ich "sicheres" umount bevorzuge.

Falls ja mal ein "Fremd-Stick" rein muss, kennt jeder Benutzer das root-Passwort. Wie gesagt: Ein Privat-PC.

----------

## Josef.95

alexander_ro,

schau dazu am besten auch noch mal in der damaligen News

/usr/portage/metadata/news/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt

Dort sind auch schon ein paar udev-rules Beispielkonfigurationen mit genannt usw.

----------

## alexander_ro

Was mich noch immer stört ist das man so nie ein System automatisch konfigurieren kann. Weil man nicht vorhersehen kann wie die Schnittstellen heißen werden. Die Lösung über die MAC Adresse ist zwar eine Lösung aber geht nur wenn man die Adresse kennt. Bei neuer Hardware steht die selten drauf da muss ich erst ein Betriebssystem installieren um nach der Adresse zu sehen und dann kann ich die Regel von Hand einbauen. Klingt wie IT Kreidezeit ...

Auf dieser freedesktop Seite habe ich eine Beschreibung gefunden was die Vorteile des neuen Systems sind. Wenn ich nicht falsch übersetzt habe dann stand da Hardware unabhängige Gerätenamen. Das war dann ja wohl nix ...

----------

## py-ro

Vorher konntest das auch nicht wirklich voraussehen, zumindest sobald mehr als ein Device vorhanden war, das hat dann auch gerne mal per Boot alterniert.

Bye

Py

----------

## alexander_ro

Bei mir ging das immer gut und die Server haben die meisten zwei mal Ethernet.

Das wichtigste weil häufigste Problem geht ja mit den udev Regeln zu lösen. Neue Hardware kommt schon seltener da kann man dann leichter auch von Hand machen.

----------

## py-ro

Dann hast du Glück gehabt oder eben schon udev mit dem alten System gehabt.

Wir haben auch alle Interfaces jetzt sinnvoll benannt, z.B. ifext, ifint, ifmgmt usw..

Bye

Py

----------

## mv

 *alexander_ro wrote:*   

> Was mich noch immer stört ist das man so nie ein System automatisch konfigurieren kann

 

Das ist ein Dilemma, das sich prinzipiell nicht mehr lösen lässt, seit die Treiber parallel - also in potentiell zufälliger Reihenfolge - initialisiert werden:

Man muss sich immer entscheiden, ob man ein System will, bei dem die Karten garantiert die selben Namen haben, wie beim letzten Booten ("Persistenz"), oder ob man flexibel bei jedem Booten auf die aktuelle Hardware reagiert ("Automatismus") - beides zusammen geht offensichtlich nicht, außer man baut eine so komplexe Logik ein, die versucht, die Wünsche des Benutzers zu erraten, dass auch da Probleme vorprogrammiert wären...

Die Persistenz war früher schon eine Vorgabe, die viel Unmut ausgelöst hatte: Beispielweise wurde bei ausgetauschter Netzwerkkarte die neue Karte als eth1 gemeldet, weil eth0 ja für die alte per fester Regel vergeben war... insofern wäre die Lösung mit den Busnummern gar nicht so dumm, wenn - ja, wenn - vor Entwickeln und Durchdrücken dieser Idee auf alle Nutzerrechner, die Sache erst mal erst mal getestet worden wäre: So wurde nämlich berichtet, dass etliche Geräte die Busnummern verändern, wenn man irgendeine Karte zieht oder hinzusteckt, so dass der derzeitige udev-Default alle Nachteile in sich vereint: Weder ist er flexibel noch ist er persistent.

----------

## Jean-Paul

 *schmidicom wrote:*   

> Und was benutzt du anstelle von udisks? 

 

 *Quote:*   

> [I] sys-apps/uam
> 
>      Available versions:  0.3 (~)0.3.1 0.3.2 (**)9999
> 
>      Installed versions:  9999(17:42:00 30.06.2014)
> ...

  Für Für Sticks, USB-Platte und CD/DVD völlig ausreichend

----------

## mv

 *Jean-Paul wrote:*   

>  *Quote:*   [I] sys-apps/uam
> 
>      Available versions:  0.3 (~)0.3.1 0.3.2 (**)9999
> 
>      Installed versions:  9999(17:42:00 30.06.2014)
> ...

 

Das greift aber letztlich wieder auf pmount zurück. Deswegen sagte ich ja: Für eine "generelle" Lösung: pmount (oder eigene sudo-Skripte)

----------

## Jean-Paul

 *mv wrote:*   

> Das greift aber letztlich wieder auf pmount zurück.

  Hm, pmount habe ich nicht installiert. Ich schicke ein "sync" bevor ich den Stick abziehe, aber vielleicht geht das mit pmount bequemer.

----------

## mv

 *Jean-Paul wrote:*   

> Ich schicke ein "sync" bevor ich den Stick abziehe

 

Damit ist es ziemliche Glückssache, ob Du das gewünschte Verhalten erhälst:

 *sync(3P) wrote:*   

> The writing, although scheduled, is not necessarily complete upon return from sync().

 

Gerade die ext*-Filesysteme puffern gerne minutenlang und können auch durch einen "sync" nicht zum Schreiben bewegt werden; außer einem umount oder speziellen selbstgeschriebenen Kernel-Hacks gibt es auch nichts, was sie dazu zwingt: Ich hatte vor Jahren wegen eines Hardwareproblems Möglichkeiten gesucht, das zu erreichen und auch hier in den Foren nachgefragt, hatte aber nichts gefunden und keine Hilfe erhalten können.

----------

