Handbook:MIPS/Networking/Advanced/fr
Configuration avancée
La variable config_eth0 est le cœur de la configuration d'une interface. C'est une liste d'instructions de haut niveau pour la configuration de l'interface (eth0 dans ce cas). Chaque commande de la liste d'instructions est exécutée de manière séquentielle. L'interface est considérée comme OK si au moins une commande fonctionne.
Voici une liste d'instructions intégrées :
| Valeur | Description |
|---|---|
null
|
Ne fait rien. |
noop
|
Si l'interface est active et qu'il y a une adresse, abandonner la configuration avec succès. |
| Une adresse IPv4 ou IPv6 | Ajouter l'adresse à l'interface. |
dhcp, adsl, ou apipa (ou une valeur personnalisée d'un module tiers)
|
Exécuter le module qui fournit la commande. Par exemple, dhcp exécutera un module qui fournit le protocole DHCP qui peut être servi par dhcpcd, dhclient, ou pump.
|
Si une commande échoue, spécifier une valeur de remplacement. Le repli doit correspondre exactement à la structure de configuration.
Il est possible d'enchaîner ces valeurs. Voici quelques exemples :
/etc/conf.d/netExemples de configuration# Ajouter trois adresses IPv4
config_eth0="192.168.0.2/24
192.168.0.3/24
192.168.0.4/24"
# Ajouter une adresse IPv4 et 2 adresses IPv6
config_eth0="192.168.0.2/24
4321:0:1:2:3:4:567:89ab
4321:0:1:2:3:4:567:89ac"
# Garde l'adresse assignée par le noyau. Si l'interface
# devient inactive, assigner une adresse par DHCP.
# Si DHCP échoue, ajouter une adresse IP statique déterminée par APIPA.
config_eth0="noop
dhcp"
fallback_eth0="null
apipa"
Quand le module
ifconfig est utilisé et que plus d'une adresse est ajoutée, des alias d'interface sont créés pour chaque adresse supplémentaire. Ainsi, en suivant les exemples précédents, l'utilisateur obtiendra les interfaces eth0, eth0:1 et eth0:2. Il est impossible d'effectuer quelque chose de spécial avec ces interfaces car le noyau et autres programmes considéreront eth0:1 et eth0:2 comme étant eth0.L'ordre de repli est important ! Si l'option
null n'était pas spécifiée alors apipa ne sera exécuté que si noop a échoué.Dépendances réseau
Les scripts d'initialisation dans /etc/init.d/ peuvent dépendre d'une interface réseau spécifique ou simplement de "net". Toutes les interfaces réseau du système d'initialisation de Gentoo fournissent ce qu'on appelle "net".
Si, dans /etc/rc.conf, la variable rc_depend_strict est définie sur YES, alors toutes les interfaces réseau fournissant "net" doivent être actives avant qu'une dépendance sur "net" soit supposée être satisfaite. En d'autres termes, si un système a un net.eth0 et un net.eth1 et un script d'initialisation dépend de "net", alors les deux doivent être activés.
D'un autre côté, si rc_depend_strict="NO" est défini, alors la dépendance "net" est marquée comme résolue du moment qu'au moins une interface réseau est activée.
Mais que faire si net.br0 dépend de net.eth0 et net.eth1 ? net.eth1 peut être un périphérique sans fil ou PPP qui nécessite une configuration avant de pouvoir être ajouté au pont. Cela ne peut pas être fait dans /etc/init.d/net.br0 car c'est un lien symbolique vers net.lo.
La solution est de définir un paramètre rc_net_{interface}_need dans /etc/conf.d/net :
/etc/conf.d/netAjouter un dépendance de net.br0rc_net_br0_need="net.eth0 net.eth1"
Cela seul, cependant, n'est pas suffisant. Les scripts d'initialisation de mise en réseau de Gentoo utilisent une dépendance virtuelle appelée "net" pour informer le système lorsque le réseau est disponible. Clairement, dans le cas ci-dessus, la mise en réseau ne doit être marquée comme disponible que lorsque net.br0 est actif, et non lorsque les autres le sont. Nous devons donc aussi le signaler dans /etc/conf.d/net :
/etc/conf.d/netMise à jour des dépendances virtuelles et des dispositions pour la mise en réseaurc_net_eth0_provide="!net"
rc_net_eth1_provide="!net"
Pour une discussion plus détaillée sur la dépendance, consulter la section sur la rédaction des scripts d'initialisation dans le manuel Gentoo. Plus d'informations sur /etc/rc.conf sont disponibles sous forme de commentaires dans le fichier.
Noms de variables et valeurs
Les noms de variables sont dynamiques. Ils suivent normalement la structure de la variable _${interface|mac|essid|apmac}. Par exemple, la variable dhcpcd_eth0 contient la valeur des options dhcpcd pour eth0 et dhcpcd_essid contient la valeur des options dhcpcd lorsqu'une interface se connecte à l'ESSID (Extended Service Set Identifier - "nom du réseau") appelé "essid".
Cependant, il n'y a pas de règle absolue que les noms d'interface des états doivent être ethx. En fait, de nombreuses interfaces sans fil ont des noms comme wlanx, rax ou même ethx. En outre, certaines interfaces définies par l'utilisateur, telles que les ponts, peuvent recevoir n'importe quel nom. Pour rendre la vie plus intéressante, les points d'accès sans fil peuvent avoir des noms avec des caractères non alphanumériques - c'est important car les utilisateurs peuvent configurer les paramètres réseau pour chaque ESSID.
L'inconvénient de tout cela est que Gentoo utilise des variables bash pour la mise en réseau - et bash ne peut pas utiliser quoi que ce soit en dehors de l'alphanumérique anglais. Pour contourner cette limitation, nous changeons chaque caractère qui n'est pas un alphanumérique anglais en _ (Tiret bas).
Un autre inconvénient de bash est le contenu des variables - certains caractères doivent être échappés. Cela peut être réalisé en plaçant le caractère \ (barre oblique inverse) devant le caractère qui doit être échappé. Les caractères suivants doivent être échappés de cette façon: ", ' et \.
Dans cet exemple, nous utilisons un ESSID sans fil car ils peuvent contenir le plus large éventail de caractères. Nous utiliserons l'ESSID Mon "\ RESEAU' ' :
/etc/conf.d/netNoms de variables# Cela fonctionne mais le nom de domaine est invalide
dns_domain_Mon____RESEAU="Mon \"\\ RESEAU"
L'exemple précédent définit le domaine DNS sur Mon "\ RESEAU lorsqu'une carte sans fil se connecte à un point d'accès dont l'ESSID est Mon "\ RESEAU.
Nommage de l'interface réseau
Fonctionnement
Les noms d'interface réseau ne sont pas choisis arbitrairement : le noyau Linux et le gestionnaire de périphériques (la plupart des systèmes ont udev comme gestionnaire de périphériques bien que d'autres soient également disponibles) choisissent le nom de l'interface via un ensemble de règles fixes.
Lorsqu'une carte d'interface est détectée sur un système, le noyau Linux rassemble les données nécessaires à propos de la carte. Cela inclue :
- Le nom enregistré de la carte réseau (sur l'interface elle-même), qui est ensuite visualisé via la valeur ID_NET_NAME_ONBOARD.
- L'emplacement dans lequel la carte réseau est connectée, qui est ensuite visible via la valeur ID_NET_NAME_SLOT</ var>.
- Le chemin d'accès au périphérique de la carte réseau, qui est ensuite visible via la valeur ID_NET_NAME_PATH.
- L'adresse MAC (fournie par le fabriquant) de la carte, qui est ensuite visualisée via la valeur ID_NET_NAME_MAC.
A partir de ces informations, le gestionnaire de périphériques décide comment nommer l'interface sur le système. Par défaut, il utilise le premier résultat des trois premières variables ci-dessus (ID_NET_NAME_ONBOARD, _SLOT ou _PATH). Par exemple, si ID_NET_NAME_ONBOARD est trouvé et défini sur eno1, l'interface s'appellera eno1.
Étant donné un nom d'interface active, les valeurs des variables fournies peuvent être affichées en utilisant udevadm :
root #udevadm test-builtin net_id /sys/class/net/enp3s0 2>/dev/nullID_NET_NAME_MAC=enxc80aa9429d76 ID_OUI_FROM_DATABASE=Quanta Computer Inc. ID_NET_NAME_PATH=enp3s0
Comme le premier (et le seul) résultat des trois premières variables est ID_NET_NAME_PATH, sa valeur est utilisée comme nom d'interface. Si aucune des variables ne contient de valeurs, le système revient à la dénomination fournie par le noyau (eth0, eth1, etc.)
Utiliser l'ancien système de nommage du noyau
Avant cette modification, les cartes d'interface réseau étaient nommées par le noyau Linux lui-même, en fonction de l'ordre de chargement des pilotes (entre autres, probablement pour des raison plus obscures). Ce comportement peut toujours être activé en définissant le paramètre de démarrage net.ifnames=0 dans le chargeur d'amorçage.
Utiliser des noms personnalisés
L'idée derrière le changement du système de nommage n'est pas de confondre les gens, mais de faciliter le changement de nom. Supposons qu'un système possède deux interfaces appelées eth0 et eth1. L'une est destiné à accéder au réseau via un cable, l'autre est pour un accès sans fil. Avec la prise en charge du nommage d'interface, les utilisateurs peuvent utiliser les noms lan0 (filaire) et wifi0 (sans fil - il est préférable d'éviter d'utiliser les noms précédemment connus comme eth* et wlan* car ils peuvent toujours entrer en collision avec les noms suggérés).
Trouver les paramètres des cartes, puis utiliser ces informations pour définir une règle de nommage personnalisée :
root #udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/nullID_NET_NAME_MAC=enxc80aa9429d76 ID_OUI_FROM_DATABASE=Quanta Computer Inc.
root #vim /etc/udev/rules.d/70-net-name-use-custom.rules# La première utilise les informations MAC et le nombre 70- devant le nom du fichier pour être lue avant les autres règles net
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="c8:0a:a9:42:9d:76", NAME="lan0"
root #vim /etc/udev/rules.d/76-net-name-use-custom.rules# La deuxième utilise l'information ID_NET_NAME_PATH et le nombre 75-
# pour se situer entre les règles 75-net-*.rules et 80-net-*.rules
SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_PATH}=="enp3s0", NAME="wifi0"
Comme les règles sont déclenchées avant celle par défaut (les règles sont déclenchées dans l'ordre alphanumérique, donc 70 vient avant 80), les noms fournis dans le fichier de règles seront utilisés à la place des noms par défaut. Le nombre accordé au fichier doit être compris entre 76 et 79 (les variables d'environnement sont définies par un début de règle commençant par 75 et le nommage de solution de repli est effectué dans une règle numérotée 80).