Pouvez-vous expliquer : je ne saisis pas l'erreur.
Ces alias dans le fichier /etc/modules.conf permettent, quand une application (ici typiquement ifconfig) fait appel à l'interface eth0 ou eth1, de charger automatiquement le module correspondant à la carte réseau si celui-ci n'a pas déjà été chargé. Ce mécanisme, du temps où il n'y avait aucun chargement automatique des modules (via hotplug ou via les fichiers /etc/modules ou /etc/rc.d/rc.modules) durant la phase de démarrage du système, fonctionnait alors très bien pour attacher le nom de telle ou telle interface à telle ou telle carte réseau.
Mais il ne garantit aucunement que l'interface réseau associée au module aura le nom de l'alias ! C'est le gros défaut de la méthode. Ainsi, si on fait "ifconfig eth1" en premier, l'alias charge le module 8139too qui crée l'interface eth0 et la commande échoue parce que l'interface eth1 n'existe pas.
Aujourd'hui, avec les systèmes hotplug et udev, il en est autrement. Les modules des cartes réseaux sont (en principe) déjà chargés avant toute opération possible sur elles. Il existe des solutions pour empêcher le chargement automatique au démarrage, mais ça s'apparente souvent à du bricolage.
Bah, pourquoi du bricolage ?
alias eth0 tulip
alias eth1 8139too
Rhâa non, pas toi ! :-(
Pouvez-vous expliquer : je ne saisis pas l'erreur.
Ces alias dans le fichier /etc/modules.conf permettent, quand une
application (ici typiquement ifconfig) fait appel à l'interface eth0 ou
eth1, de charger automatiquement le module correspondant à la carte
réseau si celui-ci n'a pas déjà été chargé.
Ce mécanisme, du temps où il n'y avait aucun chargement automatique des
modules (via hotplug ou via les fichiers /etc/modules ou
/etc/rc.d/rc.modules) durant la phase de démarrage du système,
fonctionnait alors très bien pour attacher le nom de telle ou telle
interface à telle ou telle carte réseau.
Mais il ne garantit aucunement que l'interface réseau associée au module
aura le nom de l'alias ! C'est le gros défaut de la méthode.
Ainsi, si on fait "ifconfig eth1" en premier, l'alias charge le module
8139too qui crée l'interface eth0 et la commande échoue parce que
l'interface eth1 n'existe pas.
Aujourd'hui, avec les systèmes hotplug et udev, il en est autrement. Les
modules des cartes réseaux sont (en principe) déjà chargés avant toute
opération possible sur elles.
Il existe des solutions pour empêcher le chargement automatique au
démarrage, mais ça s'apparente souvent à du bricolage.
Pouvez-vous expliquer : je ne saisis pas l'erreur.
Ces alias dans le fichier /etc/modules.conf permettent, quand une application (ici typiquement ifconfig) fait appel à l'interface eth0 ou eth1, de charger automatiquement le module correspondant à la carte réseau si celui-ci n'a pas déjà été chargé. Ce mécanisme, du temps où il n'y avait aucun chargement automatique des modules (via hotplug ou via les fichiers /etc/modules ou /etc/rc.d/rc.modules) durant la phase de démarrage du système, fonctionnait alors très bien pour attacher le nom de telle ou telle interface à telle ou telle carte réseau.
Mais il ne garantit aucunement que l'interface réseau associée au module aura le nom de l'alias ! C'est le gros défaut de la méthode. Ainsi, si on fait "ifconfig eth1" en premier, l'alias charge le module 8139too qui crée l'interface eth0 et la commande échoue parce que l'interface eth1 n'existe pas.
Aujourd'hui, avec les systèmes hotplug et udev, il en est autrement. Les modules des cartes réseaux sont (en principe) déjà chargés avant toute opération possible sur elles. Il existe des solutions pour empêcher le chargement automatique au démarrage, mais ça s'apparente souvent à du bricolage.
Bah, pourquoi du bricolage ?
Sébastien Monbrun aka TiChou
Dans le message <news:eg10l1$166d$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
Mais il ne garantit aucunement que l'interface réseau associée au module aura le nom de l'alias ! C'est le gros défaut de la méthode. Ainsi, si on fait "ifconfig eth1" en premier, l'alias charge le module 8139too qui crée l'interface eth0 et la commande échoue parce que l'interface eth1 n'existe pas.
Certes mais sauf qu'en général, si on veut associer eth0 à la bonne carte, c'est qu'on commence par configurer en premier celle-ci. ;-)
Aujourd'hui, avec les systèmes hotplug et udev, il en est autrement. Les modules des cartes réseaux sont (en principe) déjà chargés avant toute opération possible sur elles. Il existe des solutions pour empêcher le chargement automatique au démarrage, mais ça s'apparente souvent à du bricolage.
Bah, pourquoi du bricolage ?
Parce que selon les distributions ou même selon les versions de celles ci, on est obligé de modifier le comportement et/ou l'ordre d'exécution des scripts d'initialisation.
-- Sébastien Monbrun aka TiChou
Dans le message <news:eg10l1$166d$1@biggoron.nerim.net>,
*Pascal Hambourg* tapota sur f.c.o.l.configuration :
Mais il ne garantit aucunement que l'interface réseau associée au module
aura le nom de l'alias ! C'est le gros défaut de la méthode.
Ainsi, si on fait "ifconfig eth1" en premier, l'alias charge le module
8139too qui crée l'interface eth0 et la commande échoue parce que
l'interface eth1 n'existe pas.
Certes mais sauf qu'en général, si on veut associer eth0 à la bonne carte,
c'est qu'on commence par configurer en premier celle-ci. ;-)
Aujourd'hui, avec les systèmes hotplug et udev, il en est autrement. Les
modules des cartes réseaux sont (en principe) déjà chargés avant toute
opération possible sur elles.
Il existe des solutions pour empêcher le chargement automatique au
démarrage, mais ça s'apparente souvent à du bricolage.
Bah, pourquoi du bricolage ?
Parce que selon les distributions ou même selon les versions de celles ci,
on est obligé de modifier le comportement et/ou l'ordre d'exécution des
scripts d'initialisation.
Dans le message <news:eg10l1$166d$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
Mais il ne garantit aucunement que l'interface réseau associée au module aura le nom de l'alias ! C'est le gros défaut de la méthode. Ainsi, si on fait "ifconfig eth1" en premier, l'alias charge le module 8139too qui crée l'interface eth0 et la commande échoue parce que l'interface eth1 n'existe pas.
Certes mais sauf qu'en général, si on veut associer eth0 à la bonne carte, c'est qu'on commence par configurer en premier celle-ci. ;-)
Aujourd'hui, avec les systèmes hotplug et udev, il en est autrement. Les modules des cartes réseaux sont (en principe) déjà chargés avant toute opération possible sur elles. Il existe des solutions pour empêcher le chargement automatique au démarrage, mais ça s'apparente souvent à du bricolage.
Bah, pourquoi du bricolage ?
Parce que selon les distributions ou même selon les versions de celles ci, on est obligé de modifier le comportement et/ou l'ordre d'exécution des scripts d'initialisation.
-- Sébastien Monbrun aka TiChou
Pascal Hambourg
Certes mais sauf qu'en général, si on veut associer eth0 à la bonne carte, c'est qu'on commence par configurer en premier celle-ci. ;-)
Pure spéculation ! :-p
Aujourd'hui, avec les systèmes hotplug et udev, il en est autrement. Les modules des cartes réseaux sont (en principe) déjà chargés avant toute opération possible sur elles. Il existe des solutions pour empêcher le chargement automatique au démarrage, mais ça s'apparente souvent à du bricolage.
Bah, pourquoi du bricolage ?
Parce que selon les distributions ou même selon les versions de celles ci, on est obligé de modifier le comportement et/ou l'ordre d'exécution des scripts d'initialisation.
/etc/hotplug/blacklist, ce n'est pas standardisé ?
Certes mais sauf qu'en général, si on veut associer eth0 à la bonne
carte, c'est qu'on commence par configurer en premier celle-ci. ;-)
Pure spéculation ! :-p
Aujourd'hui, avec les systèmes hotplug et udev, il en est autrement.
Les modules des cartes réseaux sont (en principe) déjà chargés avant
toute opération possible sur elles.
Il existe des solutions pour empêcher le chargement automatique au
démarrage, mais ça s'apparente souvent à du bricolage.
Bah, pourquoi du bricolage ?
Parce que selon les distributions ou même selon les versions de celles
ci, on est obligé de modifier le comportement et/ou l'ordre d'exécution
des scripts d'initialisation.
/etc/hotplug/blacklist, ce n'est pas standardisé ?
Certes mais sauf qu'en général, si on veut associer eth0 à la bonne carte, c'est qu'on commence par configurer en premier celle-ci. ;-)
Pure spéculation ! :-p
Aujourd'hui, avec les systèmes hotplug et udev, il en est autrement. Les modules des cartes réseaux sont (en principe) déjà chargés avant toute opération possible sur elles. Il existe des solutions pour empêcher le chargement automatique au démarrage, mais ça s'apparente souvent à du bricolage.
Bah, pourquoi du bricolage ?
Parce que selon les distributions ou même selon les versions de celles ci, on est obligé de modifier le comportement et/ou l'ordre d'exécution des scripts d'initialisation.
/etc/hotplug/blacklist, ce n'est pas standardisé ?
Sébastien Monbrun aka TiChou
Dans le message <news:eg162o$18me$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
selon les distributions ou même selon les versions de celles ci, on est obligé de modifier le comportement et/ou l'ordre d'exécution des scripts d'initialisation.
/etc/hotplug/blacklist, ce n'est pas standardisé ?
C'est l'orde du chargement de hotplug qui n'est pas standardisé.
-- Sébastien Monbrun aka TiChou
Dans le message <news:eg162o$18me$1@biggoron.nerim.net>,
*Pascal Hambourg* tapota sur f.c.o.l.configuration :
selon les distributions ou même selon les versions de celles ci, on est
obligé de modifier le comportement et/ou l'ordre d'exécution des scripts
d'initialisation.
/etc/hotplug/blacklist, ce n'est pas standardisé ?
C'est l'orde du chargement de hotplug qui n'est pas standardisé.
Dans le message <news:eg162o$18me$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
selon les distributions ou même selon les versions de celles ci, on est obligé de modifier le comportement et/ou l'ordre d'exécution des scripts d'initialisation.
/etc/hotplug/blacklist, ce n'est pas standardisé ?
C'est l'orde du chargement de hotplug qui n'est pas standardisé.
-- Sébastien Monbrun aka TiChou
Nicolas George
Sébastien Monbrun aka TiChou wrote in message :
C'est l'orde du chargement de hotplug qui n'est pas standardisé.
J'aurais tendance à dire qu'une configuration qui dépend pour son bon fonctionnement de l'ordre dans lequel les modules sont chargés (au delà de l'ordre de dépendance, évidemment) est fondamentalement cassée.
Sébastien Monbrun aka TiChou wrote in message
<gniii.20061004225138@florizarre.tichou.org>:
C'est l'orde du chargement de hotplug qui n'est pas standardisé.
J'aurais tendance à dire qu'une configuration qui dépend pour son bon
fonctionnement de l'ordre dans lequel les modules sont chargés (au delà de
l'ordre de dépendance, évidemment) est fondamentalement cassée.
C'est l'orde du chargement de hotplug qui n'est pas standardisé.
J'aurais tendance à dire qu'une configuration qui dépend pour son bon fonctionnement de l'ordre dans lequel les modules sont chargés (au delà de l'ordre de dépendance, évidemment) est fondamentalement cassée.
Sébastien Monbrun aka TiChou
Dans le message <news:, *Sébastien Monbrun aka TiChou* tapota sur f.c.o.l.configuration :
/etc/hotplug/blacklist, ce n'est pas standardisé ?
C'est l'orde du chargement de hotplug qui n'est pas standardisé.
s/chargement/lancement au démarrage/
-- Sébastien Monbrun aka TiChou
Dans le message <news:gniii.20061004225138@florizarre.tichou.org>,
*Sébastien Monbrun aka TiChou* tapota sur f.c.o.l.configuration :
/etc/hotplug/blacklist, ce n'est pas standardisé ?
C'est l'orde du chargement de hotplug qui n'est pas standardisé.
Dans le message <news:, *Sébastien Monbrun aka TiChou* tapota sur f.c.o.l.configuration :
/etc/hotplug/blacklist, ce n'est pas standardisé ?
C'est l'orde du chargement de hotplug qui n'est pas standardisé.
s/chargement/lancement au démarrage/
-- Sébastien Monbrun aka TiChou
Pascal Hambourg
J'aurais tendance à dire qu'une configuration qui dépend pour son bon fonctionnement de l'ordre dans lequel les modules sont chargés (au delà de l'ordre de dépendance, évidemment) est fondamentalement cassée.
Ah. Et donc, tu fais comment pour t'assurer par exemple que eth0 est la carte Realtek, eth1 la 3Com et eth2 l'Intel si ce n'est pas en chargeant d'abord 8139too, puis 3c59x, et enfin e100 ?
J'aurais tendance à dire qu'une configuration qui dépend pour son bon
fonctionnement de l'ordre dans lequel les modules sont chargés (au delà de
l'ordre de dépendance, évidemment) est fondamentalement cassée.
Ah. Et donc, tu fais comment pour t'assurer par exemple que eth0 est la
carte Realtek, eth1 la 3Com et eth2 l'Intel si ce n'est pas en chargeant
d'abord 8139too, puis 3c59x, et enfin e100 ?
J'aurais tendance à dire qu'une configuration qui dépend pour son bon fonctionnement de l'ordre dans lequel les modules sont chargés (au delà de l'ordre de dépendance, évidemment) est fondamentalement cassée.
Ah. Et donc, tu fais comment pour t'assurer par exemple que eth0 est la carte Realtek, eth1 la 3Com et eth2 l'Intel si ce n'est pas en chargeant d'abord 8139too, puis 3c59x, et enfin e100 ?
Sébastien Monbrun aka TiChou
Dans le message <news:eg2ltc$1r52$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
Ah. Et donc, tu fais comment pour t'assurer par exemple que eth0 est la carte Realtek, eth1 la 3Com et eth2 l'Intel si ce n'est pas en chargeant d'abord 8139too, puis 3c59x, et enfin e100 ?
On leur donne un autre nom (plus parlant par la même occasion) avec nameif ou on les renomme en deux temps avec nameif et/ou les règles udev adéquates. Oui, ça reste aussi du bricolage, mais là pas besoin de toucher aux scripts d'initialisation de la distribution pour celles où c'était nécessaire.
-- Sébastien Monbrun aka TiChou
Dans le message <news:eg2ltc$1r52$1@biggoron.nerim.net>,
*Pascal Hambourg* tapota sur f.c.o.l.configuration :
Ah. Et donc, tu fais comment pour t'assurer par exemple que eth0 est la
carte Realtek, eth1 la 3Com et eth2 l'Intel si ce n'est pas en chargeant
d'abord 8139too, puis 3c59x, et enfin e100 ?
On leur donne un autre nom (plus parlant par la même occasion) avec nameif
ou on les renomme en deux temps avec nameif et/ou les règles udev adéquates.
Oui, ça reste aussi du bricolage, mais là pas besoin de toucher aux scripts
d'initialisation de la distribution pour celles où c'était nécessaire.
Dans le message <news:eg2ltc$1r52$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
Ah. Et donc, tu fais comment pour t'assurer par exemple que eth0 est la carte Realtek, eth1 la 3Com et eth2 l'Intel si ce n'est pas en chargeant d'abord 8139too, puis 3c59x, et enfin e100 ?
On leur donne un autre nom (plus parlant par la même occasion) avec nameif ou on les renomme en deux temps avec nameif et/ou les règles udev adéquates. Oui, ça reste aussi du bricolage, mais là pas besoin de toucher aux scripts d'initialisation de la distribution pour celles où c'était nécessaire.
-- Sébastien Monbrun aka TiChou
Pascal Hambourg
Ah. Et donc, tu fais comment pour t'assurer par exemple que eth0 est la carte Realtek, eth1 la 3Com et eth2 l'Intel si ce n'est pas en chargeant d'abord 8139too, puis 3c59x, et enfin e100 ?
On leur donne un autre nom (plus parlant par la même occasion) avec nameif ou on les renomme en deux temps avec nameif et/ou les règles udev adéquates.
udev permet de (re)nommer les interfaces réseau sans bidouillage basé sur l'adresse MAC ? Comment ça marche ? En fait je veux pouvoir remplacer une carte réseau par une autre du même modèle et que tout continue à marcher comme avant sans avoir à modifier quoi que ce soit dans les fichiers de configuration.
Oui, ça reste aussi du bricolage, mais là pas besoin de toucher aux scripts d'initialisation de la distribution pour celles où c'était nécessaire.
Mais je n'ai eu besoin de toucher à rien, moi. Les modules sont listés dans l'ordre qui va bien dans /etc/modules, et ils sont chargés dans le même ordre avant que hotplug se mette en branle (et râle parce que les modules sont déjà chargés).
Ah. Et donc, tu fais comment pour t'assurer par exemple que eth0 est
la carte Realtek, eth1 la 3Com et eth2 l'Intel si ce n'est pas en
chargeant d'abord 8139too, puis 3c59x, et enfin e100 ?
On leur donne un autre nom (plus parlant par la même occasion) avec
nameif ou on les renomme en deux temps avec nameif et/ou les règles udev
adéquates.
udev permet de (re)nommer les interfaces réseau sans bidouillage basé
sur l'adresse MAC ? Comment ça marche ? En fait je veux pouvoir
remplacer une carte réseau par une autre du même modèle et que tout
continue à marcher comme avant sans avoir à modifier quoi que ce soit
dans les fichiers de configuration.
Oui, ça reste aussi du bricolage, mais là pas besoin de toucher aux
scripts d'initialisation de la distribution pour celles où c'était
nécessaire.
Mais je n'ai eu besoin de toucher à rien, moi. Les modules sont listés
dans l'ordre qui va bien dans /etc/modules, et ils sont chargés dans le
même ordre avant que hotplug se mette en branle (et râle parce que les
modules sont déjà chargés).
Ah. Et donc, tu fais comment pour t'assurer par exemple que eth0 est la carte Realtek, eth1 la 3Com et eth2 l'Intel si ce n'est pas en chargeant d'abord 8139too, puis 3c59x, et enfin e100 ?
On leur donne un autre nom (plus parlant par la même occasion) avec nameif ou on les renomme en deux temps avec nameif et/ou les règles udev adéquates.
udev permet de (re)nommer les interfaces réseau sans bidouillage basé sur l'adresse MAC ? Comment ça marche ? En fait je veux pouvoir remplacer une carte réseau par une autre du même modèle et que tout continue à marcher comme avant sans avoir à modifier quoi que ce soit dans les fichiers de configuration.
Oui, ça reste aussi du bricolage, mais là pas besoin de toucher aux scripts d'initialisation de la distribution pour celles où c'était nécessaire.
Mais je n'ai eu besoin de toucher à rien, moi. Les modules sont listés dans l'ordre qui va bien dans /etc/modules, et ils sont chargés dans le même ordre avant que hotplug se mette en branle (et râle parce que les modules sont déjà chargés).
Sébastien Monbrun aka TiChou
Dans le message <news:eg39gh$22tb$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
udev permet de (re)nommer les interfaces réseau sans bidouillage basé sur l'adresse MAC ?
Oui. D'une manière générale, on peut (re)nommer les périphériques en fonction de la position du périphérique sur le bus PCI (variable ID), en fonction de son constructeur (variable SYSFS{vendor}), en fonction du modèle (SYSFS{device}), etc.
Comment ça marche ?
Il suffit de placer une règle dans /etc/udev/rules.d. Par exemple, pour renommer une carte réseau Realtek :
Dans le message <news:eg39gh$22tb$1@biggoron.nerim.net>,
*Pascal Hambourg* tapota sur f.c.o.l.configuration :
udev permet de (re)nommer les interfaces réseau sans bidouillage basé sur
l'adresse MAC ?
Oui. D'une manière générale, on peut (re)nommer les périphériques en
fonction de la position du périphérique sur le bus PCI (variable ID), en
fonction de son constructeur (variable SYSFS{vendor}), en fonction du modèle
(SYSFS{device}), etc.
Comment ça marche ?
Il suffit de placer une règle dans /etc/udev/rules.d. Par exemple, pour
renommer une carte réseau Realtek :
Dans le message <news:eg39gh$22tb$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
udev permet de (re)nommer les interfaces réseau sans bidouillage basé sur l'adresse MAC ?
Oui. D'une manière générale, on peut (re)nommer les périphériques en fonction de la position du périphérique sur le bus PCI (variable ID), en fonction de son constructeur (variable SYSFS{vendor}), en fonction du modèle (SYSFS{device}), etc.
Comment ça marche ?
Il suffit de placer une règle dans /etc/udev/rules.d. Par exemple, pour renommer une carte réseau Realtek :
