dhclient-script - script de configuration réseau du client DHCP

Le script de configuration réseau du client DHCP est invoqué de temps en temps par dhclient(8). Ce script est utilisé par le client dhcp pour la configuration initiale de chaque interface avant de demander une adresse, pour tester l’adresse acquise et pour la configuration finale de l’interface une fois que la concession a expiré. Si aucune concession n’est acquise, le script est utilisé pour tester les concessions prédéfinies, s’il y en a, et il est aussi appelé si aucune concession valide ne peut être identifiée.

Ce script n’est pas destiné à être personnalisé par l’utilisateur final. Si des personnalisations locales sont nécessaires, il est possible d’utiliser des points de dérivations en entrée et sortie (voir DÃRIVATIONS pour les détails). Ces dérivations vont permettre de remplacer le comportement par défaut du client en créant un fichier /etc/resolv.conf.

Il n’existe pas toujours de scripts clients standards pour certains systèmes d’exploitation, bien que des clients puissent fonctionner, aussi un utilisateur pionnier peut avoir besoin de créer ou de modifier un script. En général, les personnalisations spécifiques à un ordinateur particulier devrait être faite dans le fichier /etc/dhclient.conf. Si vous découvrez que la modification de ce fichier et les points de dérivations, ne suffisent pas, veuillez s’il vous plaît soumettre un rapport de bogue.

Quand il commence, le script client définit premièrement une fonction shell, make_resolv_conf, qui est utilisée plus tard pour créer le fichier /etc/resolv.conf. Pour remplacer le comportement par défaut, redéfinissez cette fonction dans le script de dérivation en entrée.

Après avoir défini la fonction make_resolv_conf, le script client vérifie la présence du script exécutable /etc/dhclient-enter-hooks, il invoque le script en lui-même (dans le même processus), en utilisant la commande Bourne shell « . ». L’intégralité de l’environnement documenté dans la rubrique OPÃRATION est disponible dans ce script. Ce dernier peut modifier l’environnement si nécessaire pour changer son comportement. Si une erreur survient pendant l’exécution du script, il peut positionner la variable exit_status à une valeur non-nulle, et le script /sbin/dhclient-script se terminera avec ce code d’erreur immédiatement après la fin du script client.

Après que tout se soit terminé, /sbin/dhclient-script vérifie la présence du script exécutable /etc/dhclient-exit-hooks, et s’il est présent il est invoqué en utilisant la commande « . ». La valeur de sortie de dhclient-script sera transmise à dhclient-exit-hooks dans la variable shell exit_status, et sera toujours nulle si le script réussi la tâche pour laquelle il a été invoqué. Le reste de l’environnement tel que décrit précédemment pour dhclient-enter-hooks est aussi présent. Le script /etc/dhclient-exit-hooks peut modifier exit_status pour changer la valeur de sortie de dhclient-script.

Quand dhclient a besoin d’invoquer le script de configuration du client, il écrit un script shell dans /tmp qui définit toute une variété de variables. Dans tous les cas, $reason est positionné avec le motif pour lequel le script a été invoqué. Les raisons suivantes sont actuellement définies : MEDIUM, PREINIT, BOUND, RENEW, REBIND, REBOOT, EXPIRE, FAIL et TIMEOUT.

Le client DHCP est en train de demander la configuration du type de support physique d’une interface. Le nom de l’interface est passé dans $interface, et le type de support physique dans $medium.

Le client DHCP client est en train de demander la configuration de l’interface dans le but d’envoyer des paquets avant de recevoir une véritable adresse. Pour les clients qui utilisent la bibliothèque des sockets BSD, cela signifie que l’interface est configurée avec une adresse IP de 0.0.0.0 et une adresse de diffusion de 255.255.255.255. Pour les autres clients, il pourrait être possible d’activer simplement l’interface sans donner d’adresse IP. Le nom de l’interface est passé dans $interface, et le type de support physique dans $medium.

Si une adresse IP alias a été déclarée dans dhclient.conf, cette adresse sera passée dans $alias_ip_address, et l’IP alias devra être effacée de cette interface, ainsi que toutes les routes qui y conduisent.

Le client DHCP a fait l’acquisition d’une nouvelle adresse. La nouvelle adresse IP est passée dans $new_ip_address, et le nom de l’interface est passé dans $interface. Le type de support physique est passé dans $medium. Toutes les options acquises depuis le serveur sont passées en utilisant le nom de l’option décrit dans dhcp-options, sauf que les tirets (’-’) sont remplacés par des soulignés (’_’) dans le but de les transformer en variables shell valides, et le nom des variables commence par new_. Par exemple, le nouveau masque de sous-réseau sera transmis dans $new_subnet_mask.

Avant de véritablement configurer l’adresse, dhclient-script devrait émettre une requête ARP et quitter avec une valeur de sortie non-nulle s’il reçoit une réponse. Dans ce cas le client enverra un message DHCPDECLINE au serveur et demandera une autre adresse. Ceci peut aussi être fait dans les états RENEW, REBIND, ou REBOOT, mais ce n’est pas obligatoire.

Lorsque l’acquisition de l’adresse est terminée, plusieurs paramètres réseaux, ont besoin d’être mis à jour. Un nouveau /etc/resolv.conf doit être créé, en utilisant les valeurs de $new_domain_name et $new_domain_name_servers (qui peut définir une liste de serveurs séparés par des espaces). Une route par défaut est définie en utilisant $new_routers, et les routes statiques peuvent avoir besoin d’être mises à jour en utilisant $new_static_routes.

Si une IP alias a été déclarée, elle doit être positionnée ici. L’adresse IP alias sera écrite en tant que $alias_ip_address, et les autres options DHCP qui sont positionnées pour l’alias (par ex. le masque de sous-réseau) seront transmis dans des variables nommées comme décrit précédemment sauf qu’elles commencent par $alias_ au lieu de $new_. Il faut prendre garde, l’adresse IP alias ne sera pas utilisée si elle est identique à l’adresse IP associée ($new_ip_address), puisque les autres paramètres alias peuvent être incorrects dans ce cas.

Lorsque qu’une concession a été renouvelée, le script est invoqué comme pour BOUND, sauf qu’un ensemble de variables commençant par $old_ s’ajoute à celui dont les variables commencent par $new_. Les paramètres persistants qui peuvent avoir changés doivent être effacés - par exemple, si une route locale associée à une adresse est en train d’être configurée, l’ancienne route locale doit être effacée. Si la route par défaut a changé, l’ancienne route par défaut doit être effacée. Si les routes statiques ont changé, les anciennes doivent être effacées. Autrement dit, le traitement peut être fait dans BOUND.

Le client DHCP a été réassocié à un nouveau serveur DHCP. Ceci peut être géré comme dans RENEW, sauf que si l’adresse IP a changé, la table ARP doit être purgée.

Le client DHCP a récupéré avec succès son ancienne adresse IP après un redémarrage. Ceci peut être géré comme dans BOUND.

Le client DHCP a échoué dans le renouvellement ou dans l’acquisition d’une nouvelle concession, et que la sienne a expiré. L’adresse IP doit être abandonnée, et tous les paramètres associés doivent être effacés, comme dans RENEW et REBIND.

Le client DHCP a été incapable de contacter un serveur DHCP, et toutes les concessions qui ont été testées étaient invalides. Les paramètres de la dernière concession doivent être déconfigurés. Ceci peut être fait de la même manière que dans EXPIRE.

Le client DHCP a été incapable de contacter un serveur DHCP. Cependant, si une ancienne concession a été identifiée, et ses paramètres ont été passés comme dans BOUND. Le script de configuration du client devrait tester ses paramètres, et s’il a une raison de penser qu’ils sont valides, il quittera avec une valeur de sortie nulle. Sinon, la valeur de sortie sera non-nulle.

La manière habituelle pour tester une concession est de configurer le réseau comme dans REBIND (puisque cette méthode permet de tester plus d’une concession) puis d’appeler le premier routeur défini dans $routers. Si une réponse est reçue, la concession doit être valide pour le réseau auquel l’interface est connectée. Il serait plus exhaustif d’essayer d’appeler tous les routeurs de la liste $new_routers, ainsi que ceux listés dans $new_static_routes, mais les scripts actuels ne le font pas.

Chaque système d’exploitation devrait avoir son propre fichier script, bien que les fichiers scripts pour des systèmes d’exploitation similaires soient quasi-identiques. Les fichiers scripts inclus dans la distribution DHCP de l’Internet Software Consortium apparaissent dans l’arborescence dans client/scripts, et portent les noms des systèmes d’exploitations sous lesquels ils sont censés fonctionner.

Si plus d’une interface est en train d’être utilisée, il n’y aucune manière évidente d’éviter des conflits entre les paramètres de configurations fournis par le serveurs - par exemple, le dhclient-script réécrit /etc/resolv.conf. Si plus d’une interface est en train d’être configurée, /etc/resolv.conf sera réécrit avec les valeurs fournies par un serveur, puis avec celles de l’autre. En supposant que les informations fournies par les deux serveurs sont valides, ça ne devrait pas provoquer de réels problèmes, mais cela peut prêter à confusion.

dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) et dhclient.leases(5).

dhclient-script(8) a été écrit pour l’Internet Software Consortium par Ted Lemon <mellon@fugue.com> en coopération avec Vixie Enterprises. Pour en savoir plus sur l’Internet Software Consortium, voyez http://www.vix.com/isc. Pour en apprendre davantage au sujet de Vixie Enterprises, voyez http://www.vix.com.

Sébastien Blanchet, 2001