Une version plus complète et bien mieux mise en forme se trouve en ligne à l'adresse http://yo.dan.free.fr/profils-reseau.phtml.fr. La licence a changé, également (maintenant ?CeCILL).

GeorgesMariano : Certes, mais

MaitreyoDan : Je pense effectivement qu'il est bon de conserver les deux versions (article chez moi et wiki ici), et d'importer de temps en temps dans l'un certaines des modifications apportées dans l'autre (les deux documents évolueraient en parallèle, le wiki de façon plus rapide). Concernant la conversion HTML->kwiki, j'ai effectivement cherché, HTML::?WikiConverter (de CPAN) a été le plus proche de pouvoir le faire, mais finalement je n'ai pas pu le faire (?WikiConverter disait ne pas connaître le "dialect" kwiki, mais peut-être que d'autres réussiront là ou j'ai échoué).


 (Daniel Déchelotte (c) 2004 GNU Free Documentation License)
 (Ah non c'est pas assez libre)
 (Bof on s'en fout)

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éplaçant 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 câble 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'identification 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ésout 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 câble 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 câble 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 recours à 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 désinstallation => 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 - Exécute un script écrit par l'utilisateur lorsqu'une machine distante 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

 iface eth0-famille inet static

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)