Artisan Numérique

/système/réseau/udev/ Renommer des interfaces réseau

Depuis quelques années, un classique enquiquinement avec les interfaces réseau consiste à comprendre pourquoi telle interface s'appelle eth1 plutôt qu'eth0. Problème récurrent avec VmWare, ou lorsque l'on déplace l'installation d'une configuration physique à une autre. Et il n'est pas rare de se retrouver avec un eth6 ou mieux, eth0_renamed, sans arriver à remettre les compteurs à zéros.

L'ère pré-udev

Dans un temps pas si ancien, pour qu'une carte réseau soit reconnue, il fallait d'abord créer un alias entre son pilote et le nom de l'interface dans /etc/modprobe.conf. Cela donnait quelque chose comme cela

alias eth0 e1000
/etc/modprobe.conf

Ensuite il fallait créer un fichier de configuration /etc/sysconfig/network-script/ifcfg-eth0 avec un champ device faisant référence à cet alias :

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
...
/etc/sysconfig/network-script/ifcfg-eth0

Du coup au redémarrage le module était chargé automatiquement (via modprobe.conf) puis l'interface réseau étant instancié plus lié au pilote grâce à l'alias et à ifcfg-eth0.

Avec udev

Avec udev les choses ont quelque peu changées, rendant sans objet l'utilisation de modprobe.conf. En effet udev va, au démarrage, passer en revue tout le matériel présent, et donc la carte réseau. Une fois la carte détectée, c'est lui qui va charger son module. Ce dernier va en premier lieu créer son alias par défaut (ex. ath0 pour une carte atheros, ou eth0 pour une carte réseau classique). Mais, et c'est là que cela se corse, udev va pour diverse raisons passer derrière le module et renommer cet alias. C'est comme cela qu'une carte qui aurait du s'appeler eth0 se retrouve nommé eth1 ou plus exotiquement eth0_renamed.

La raison de ce renommage tient à un mécanisme interne à udev, la génération automatiques de règles. En effet, udev lors d'une première détection va chercher à écrire une règle permettant de pérenniser sa découverte. Pour Mandriva la règle en question est stockée dans le fichier /etc/udev/rules.d/70-persistent-net.rules, ce qui pour mon cas problématique donne l'exemple suivant :

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.


# PCI device 0x1234:0x5658 (pc32net)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:12:34:52", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"


# PCI device 0x8086:0x100f (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:85:23:5c", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0_renamed"
exemple de /etc/udev/rules.d/70-persistent-net.rules

Là du coup nous comprenons mieux le problème. Nous aurons beau détruire l'interface, chaque réinstallation de la carte et1000 rentrera de toute façon en conflit de nommage avec la carte pc32net, carte qui n'existe plus dans la configuration existante. Elle ne sera donc jamais nommée eth0 comme il devrait.

Et ce problème est en plus doublé sur certaines distribution (comme Mandriva) par un chargement du module même si la carte n'existe pas, car le configurateur automatique (à l'installation ou via harddrake) aura aussi ajouté sa référence dans /etc/modprobe.conf.

Remise à zéro des compteurs

Ma procédure pour remettre tout cela en place est la suivante :

  1. Arrêt du réseau par un /etc/init.d/network stop.
  2. Décharger tous les modules liés à une carte réseau existante ou pas. ex rmmod e1000 pc32net.
  3. Aller dans /etc/modprobe.conf et supprimer les références aux modules cités à l'étape précédente.
  4. Aller dans /etc/sysconfig/network-scritps, renommer la configuration mal nommée en ifcfg-eth0 et l'éditer pour que le champ device soit bien positionné à eth0.
  5. Supprimer les configurations sans objet. Dans mon cas il ne reste plus que ifcfg-eth0 et ifcfg-lo.
  6. Supprimer (ou mettre à l'abri) le fichier /etc/udev/rules.d/70-persistent-net.rules.
  7. Charger le module de la carte réseau. ex modprobe et1000.
  8. Vérifier qu'une nouvelle règle, avec le bon nommage, a bien été ajoutée dans /etc/udev/rules.d/70-persistent-net.rules.
  9. Redémarrer le réseau par un /etc/init.d/network start.
  10. Vérifier que tout est en place par un ifconfig, relancer la machine et vérifier à nouveau.

Conclusion

udev est globalement une excellente chose, mais tellement mal documenté qu'il laisse parfois cette désagréable impression que la machine ne vous obéit plus, ce qui pour certains, dont je suis, à été l'une dés raisons clefs de la rupture avec Windows. Heureusement, à chaque fois que l'on comprend mieux le fonctionnement de cette couche aujourd'hui aussi vitale que X11, cela éloigne un peu plus ce mauvais oeil. Il n'y a donc pour l'instant pas (encore) de fantôme dans GNU/Linux :-)