[Banc d'essai] Un portable, plusieurs reseaux (probleme classique)
Bonjour,
Suite à ma question et aux réponses que j'ai alors reçues, je me suis
attelé à l'évaluation des différentes alternatives. J'ai tâché d'être
exhaustif (installer tous les paquets, voir ce qu'ils fournissent,
lire leur documentation respective et deviner ce qu'ils font et ne
font pas. En revanche, je ne les ai pas tous configurés et testés
grandeur nature). Relectures et avis contraires ou complémentaires
sont les bienvenus, d'autant qu'on pourrait envisager ajouter une
version relue de ce courriel à la FAQ DUF.
Question : j'ai un ordinateur (typiquement un ordinateur portable)
avec une ou plusieurs interfaces réseau, se déplacant d'un endroit à
un autre, où ces interfaces doivent être configurées différemment.
Comment faire pour passer le plus automatiquement possible d'une
configuration à une autre ?
Analyse : il y a plusieurs sous-problèmes. J'ai noté :
- la détection d'un changement potentiel. On pense à la suspension et
à la reprise de l'ordinateur (APM/ACPI), au branchement d'un cable
réseau, au branchement sur le secteur ou à une station de dockage,
et à l'ajout d'une carte réseau PCMCIA. La succession des outils qui
suivent ne sera déclenchée que lorsque l'un de ces évènements a eu
lieu. [tâche 1]
- l'indentification de l'état actuel/du réseau actuel. À cette phase,
on essaie de contacter des équipements « permanents » du réseau qui
permettraient d'identifier où l'on se trouve, ou de détecter que
l'on n'est plus connecté à eux. [tâche 2]
- la reconfiguration du système, tâche que l'on peut à son tour
diviser en deux aspects :
- la reconfiguration de l'interface réseau proprement dite. A
minima, fixer ou obtenir une adresse IP, adapter /etc/resolv.conf
et les routes. [tâche 3.a]
- la reconfiguration des services voire des applications, ou comment
signifier à son agent de transport de courriels (MTA ;-) ou à son
navigateur d'utiliser un autre mandataire, etc. [tâche 3.b]
Les approches : certains outils se cantonnent à résoudre un de ces
sous-problèmes, d'autres tentent d'en cumuler plusieurs, le plus
souvent l'identification du réseau et la reconfiguration adéquate.
Une approche Debian ? Debian, par l'intermédiaire de son paquet
« ifupdown » (priorité : importante), propose un mécanisme de
« mapping » (appelons-ça « schéma ») qui permet, lorsque l'on souhaite
configurer une interface (eth0, par exemple) par « ifup eth0 »,
d'appeler un script qui va détecter où l'on se trouve. C'est en
fonction du résultat de ce script que ifup va configurer correctement
l'interface (IP fixe ou DHCP, passerelle mais pas /etc/resolv.conf).
De plus, il est possible de préciser des actions à exécuter une fois
qu'un schéma particulier a été mis en place. ifupdown permet donc de
réaliser la tâche 3.a et fournit le minimum pour nous permettre de
faire ce que l'on veut pour la tâche 3.b.
Je viens de découvrir (et d'installer) resolvconf, (qui paraît très
compliqué et) qui résoud le problème du fichier /etc/resolv.conf en
rajoutant des lignes "dns-search xxx" et "dns-nameservers xxx yyy" au
fichier /etc/network/interfaces. Enfin !
Tâche 1 : détection d'un changement potentiel
Je ne maîtrise vraiment pas cette partie, alors je fais vite. En gros,
il est conseillé d'utiliser APM ou ACPI (mutuellement exclusifs) et
d'installer apmd ou acpid, afin de pouvoir exécuter des scripts
lorsqu'il détecte un changement (suspension, reprise, branchement sur
l'alimentation et peut-être sur une station de dockage).
Il y a aussi ifplugd, un démon très simple qui (par défaut) lance
« ifup/ifdown <l'interface> » lorsqu'un cable vient d'être
branché/débranché. laptop-net (évalué plus bas dans ce document)
intègre cette fonctionnalité.
Il faudrait voir si hotplug ne peut pas nous être utile. Il me semble
qu'il ne se lance qu'une fois que l'interface réseau est configurée,
c'est-à-dire après la bataille, mais un oeil expert pourrait en dire
plus. De même, je n'utilise pas les paquets liés au PCMCIA, mais ils
sont surement capables eux aussi de lancer des scripts lorsqu'une
carte vient d'être ajoutée ou retirée.
Pour moi, apmd et ifplugd suffisent.
Tâche 2 : identification de l'état actuel/du réseau actuel
Tâche 3 : reconfiguration du système
Là, pas mal de paquets s'offrent à nous, certains ne faisant que l'une
des tâches, d'autres combinant les deux.
divine - Automatic IP configuration detection for laptops
guessnet - Guess which LAN is connected to a network device
ifscheme - scheme control for network interfaces
intuitively - Automatic IP configuration detection for laptops
laptop-net - Automatically adapt laptop ethernet
laptop-netconf - network detection and configuration program for laptops
netenv - Configure your system for different network environments
switchconf - Change system configuration to one of many predefined
whereami - Automatically reconfigure your (laptop) system for a new location
Allons-y par ordre alphabétique
divine (Automatic IP configuration detection for laptops)
- Tâches 2 et 3.a, laisse une possibilité de faire 3.b à la main
- Ne teste que l'IP d'une machine distante (pas l'adresse MAC)
- Pas intégré du tout à ifupdown (ne renseigne pas /etc/network/interfaces)
- Ne supporte pas le DHCP
- Format du fichier de configuration débile
- Se définit lui-même comme un « quick hack », posant des problèmes de sécurité
=> Pas de raisons de l'installer
guessnet (Guess which LAN is connected to a network device)
- Tâche 2 uniquement
- Teste l'IP et optionnellement la MAC d'une machine distante, peut
aussi tester la présence d'un concentrateur d'accès (via un modem
pppoe) (fonctionnalité qui reste à éprouver) ou lancer tout script
extérieur. Aussi, inclut un test de présence de cable réseau.
- Conçu pour les « schémas » d'ifupdown (complètement intégré à lui),
donc supporte tout ce que ifupdown supporte (IP statique, DHCP, ...).
Penser au paquet resolvconf pour le fichier /etc/resolv.conf.
- A recourt à des ruses pour se passer des options dans le fichier
/etc/network/interfaces. Lisibilité correcte, sans plus.
- Laisse ifup remplir la tâche 3.a et repose sur le mécanisme de ifup
pour la tâche 3.b (scripts lancés par ifup après que l'interface
soit configurée)
- Fournit des scripts prometteurs (test-dhcp, test-wifi-ap, etc...) mais
documentation incomplète
=> Bien, mais ne convient que pour une seule interface à la fois
ifscheme (scheme control for network interfaces)
- Intégré à ifupdown (permet d'activer un schéma particulier)
- Ne fait rien (suppose la localisation déjà connue, repose sur
ifupdown pour reconfigurer le système), si ce n'est qu'il active
un schéma décrit dans /etc/network/interfaces.
=> Pour ceux qui veulent manuellement, mais proprement (à la Debian)
reconfigurer leur réseau. Tout le monde ici est joueur, donc pas de
raisons de l'installer
intuitively (Automatic IP configuration detection for laptops)
- Semblable à divine, en plus propre
- Tâches 2 et 3.a, avec de quoi lancer ce que l'on veut pour la tâche 3.b
- Teste l'IP et optionnellement la MAC d'une machine distante
- Fichier de conf clair
- Pages de manuel et fichier README
- Utilise des liens symboliques rangés dans une sous-arborescence par schéma :
/etc/intuitively/boulot/etc/resolv.conf -> /etc/resolv.conf
- Ne supporte pas le DHCP
- Ignore ifupdown
=> Mieux que divine, mais toujours très incomplet
laptop-net (Automatically adapt laptop ethernet)
- Le tout-en-un : tâches 1, 2 et 3
- S'intègre à /etc/apm et détecte les changements d'état du lien réseau
(cable branché ou débranché, à la mii-tools)
- Ne teste que les adresses IP (pas MAC)
- Supporte le DHCP
- Ignore ifupdown
- Pas de page de manuel, pas de README, pas de temps à perdre à deviner.
- Bonus : laisse des liens symboliques morts a sa desinstallation
=> Sans doute uniquement utilisé par son auteur, et c'est normal
laptop-netconf (network detection and configuration program for laptops)
- Tâche 2, laisse la possibilité de faire 3.a (et 3.b) à la main
- Ne teste que sur un couple IP+MAC
- Execute un script écrit par l'utilisateur lorsqu'une machine
distance est identifiée
- Ne fonctionne que sur une seule interface (!)
- Se dit être encore en développement
- Peu de documentation : courte page de manuel et la doc dans les
fichiers de conf
- Propose d'utiliser des liens symboliques, il faut écrire son script
pour les utiliser
- Propose d'utiliser/truander ifupdown (remplacer /etc/network/interfaces)
=> Moins mature et moins complet que guessnet
netenv (Configure your system for different network environments)
- Tâche 3.a, laisse la possibilité de faire 3.b à la main
- Montre une boîte de dialogue (mode texte) au démarrage pour faire
choisir la configuration réseau (!) Elle peut être évitée.
- Permet de faire ce que les « schémas » de /etc/network/interfaces
permettent déjà de faire. Inutile pour Debian à part pour la boîte
de dialogue de choix et (à vérifier) l'interface pour définir les
configurations (comme si etherconf supportait plusieurs schémas)
- Page de manuel et documentation HTML
=> Pas de raisons de l'installer (voir plutôt ifscheme)
switchconf (Change system configuration to one of many predefined)
- Tâche 3.a, pas évident de faire ce que l'on veut en 3.b
- Utilise des liens symboliques « de façon élégante » (comme intuitively)
- Propose ainsi de truander ifupdown (remplacer /etc/network/interfaces)
- Utilise deux répertoires (after.d et before.d) pour ranger des
scripts (à écrire soi-même) que l'on veut lancer avant et après
chaque changement de configuration. Peu pratique pour lancer
certains scripts seulement dans certaines configuration : on
utilisera plutôt des lignes « up » dans /etc/network/interfaces
=> Pas de raisons de l'installer
whereami (Automatically reconfigure your (laptop) system for a new location)
- Tâches 2, 3.a et propose plusieurs scripts pour 3.b
- Impressionnant pour la détection de la situation : permet de tester
la présence d'une adresse IP et/ou MAC, la réponse à une requête
DHCP, la présence d'un cable réseau, d'un concentrateur d'acces
PPPOE, d'un motif dans la sortie de « lspci -v » (pour détecter une
station de dockage), d'un module chargé (lsmod), d'un point d'accès
WiFi, et enfin de tester si l'on a reçu des octets sur l'interface.
- Permet de cascader les tests, de tester successivement plusieurs
interfaces : les fichiers de conf d'exemple sont atrocement
compliqués mais montrent que pratiquement toutes les situation
peuvent être décrites et gérées.
- Ignore /etc/network/interface, typiquement. Reconfiguration de l'IP
à la main, apparemment (!)
- Permet d'exécuter tout script quand on arrive, quand on part ou
simplement quand on est dans une situation déterminée.
- Fournit des scripts pour adapter bins, masqmail, le fichier de conf
de Netscape (il y a un kill-netscape, aussi ;-), le fichier
/etc/resolv.conf, le smarthost d'exim4, d'exim, de postfix et de
qmail, la timezone, ...
- Optionnellement intégré à APM
- Pages de manuel et documentation au format HTML (pas parfaitement à jour)
- Au final, impressionnant pour la tâche 2, un peu faible pour la
tâche 3.a (ai-je raté quelque chose ?) et extrêmement flexible et
pratique, grace à ses scripts, pour la tâche 3.b.
=> Si whereami ne peut pas résoudre votre problème de configuration,
aucun autre paquet ne pourra le faire. Maintenant, vous pouvez
peut-être vous en tirez avec quelque chose de plus simple que
whereami...
Et le gagnant est :
Mon cas était suffisamment simple pour être décrit par deux schémas
dans /etc/network/interfaces (une seule interface réseau, qui oscille
entre deux réseaux). Par ailleurs, lorsqu'il s'agit du fonctionnement
du système, je suis attaché à la « philosophie Unix » : une tâche par
outil. Aussi, j'utilise :
- Tâche 1 (détection d'un changement potentiel) : paquets apmd et ifplugd
- Tâche 2 (identification de l'état actuel) : guessnet
- Tâche 3.a (reconfiguration de l'interface réseau) : ifupdown et ses
mappings, et le paquet resolvconf pour gérer /etc/resolv.conf
- Tâche 3.b (adaptation des démons/serveurs/applis) : pas encore fait,
mais je prévois d'utiliser des scripts persos et d'autres volés à
whereami.
Je n'ai pas eu à modifier la configuration d'apm, d'ifplugd ou de
resolvconf. Voici la partie intéressante de mon /etc/network/interfaces
(rédigé à la main). Remarquez les lignes dns-* et test-*.
mapping eth0
script /usr/sbin/guessnet-ifupdown
map default: none
map verbose: true
iface eth0-limsi inet static
address 192.44.78.186
netmask 255.255.255.0
broadcast 192.44.78.0
gateway 192.44.78.22
dns-search limsi.fr
dns-nameservers 192.44.78.7 192.44.78.53 192.175.152.129
test-peer address 192.44.78.22 mac 00:04:23:08:FD:55
iface eth0-famille inet static
address 192.168.2.26
netmask 255.255.255.0
broadcast 192.168.2.255
gateway 192.168.2.22
dns-search famille
dns-nameservers 194.117.200.10 194.117.200.15
test-peer address 192.168.2.1 mac 00:04:E2:2A:67:28
Je recommande guessnet parce que c'est la méthode la plus intégrée à
Debian : elle permet de détecter la localisation et de reconfigurer le
système de façon assez élégante. En revanche, elle ne pourra pas
cascader les tests comme en est capable whereami (si je n'ai pas le
réseau filaire, je teste le WiFi, et si par ailleurs telle condition
est remplie, je fais ça en plus). À vous de déterminer ce qui convient
le mieux à vos exigences ; j'espère que ce passage en revue des
différentes approches vous y aidera.
(Daniel Déchelotte (c) 2004 GNU Free Documentation License)
(Ah non c'est pas assez libre)
(Bof on s'en fout)
;-)
--
Daniel Déchelotte
http://yo.dan.free.fr/
Reply to: