Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] dhclient.conf - fichier de configuration du client DHCP [size=18] [b]Description[/b] [/size] Le fichier dhclient.conf contient les paramètres de configuration pour [i]dhclient[/i], le client DHCP de l'Internet Software Consortium. Le fichier dhclient.conf est un fichier texte ASCII libre de forme. Il est analysé par l'analyseur récursif-descendant intégré à dhclient. Le fichier peut contenir des retours à la ligne, des tabulations supplémentaires pour la mise en page. Les mots clés du fichier sont insensibles à la casse (différence minuscule/majuscule). Les commentaires peuvent être placés n'importe où dans le fichier, sauf au sein des guillemets. Les commentaires commencent avec le caractère # et se terminent avec la ligne. Le fichier dhclient.conf permet de configurer le comportement du client jusque dans le moindre détail : déroulement temporel du protocole, paramètres à demander au serveur, valeurs par défaut, valeurs pour remplacer/compléter celles du serveurs. Le fichier de configuration peut aussi être préinitialisé avec des adresses pour les réseaux sans serveurs DHCP. [size=18] [b]DÉroulement temporel du protocole[/b] [/size] Le comportement temporel du client n'a pas vraiment besoin d'être configuré par l'utilisateur, car celui par défaut convient dans la plupart des cas. Il produit des mises à jour assez fréquentes sans provoquer de charges désordonnées sur le serveur. Si toutefois c'est nécessaire, les déclarations suivantes peut être utilisées pour ajuster le comportement temporel du client DHCP : [i]La déclaration[/i] [b]timeout[/b] [b]timeout[/b] [i]time[/i] [b];[/b] La déclaration [i]timeout[/i] détermine la durée comprise entre le moment où le client essaye de déterminer son adresse et celui où il décide qu'il n'arrivera pas à contacter le serveur. La valeur par défaut de décompte est 60 secondes. Une fois qu'il a expiré, si des concessions statiques sont définies dans le fichier de configuration, ou s'il reste des concessions qui n'ont pas encore expiré dans la base de données des concessions, le client va parcourir ces concessions et s'il en trouve une valide, il utilisera l'adresse associée. Si le client ne parvient pas à trouver une concession valide, il reprendra le déroulement protocole au début, après un intervalle de temps défini. [i]La déclaration [/i] [b]retry[/b] [b]retry[/b] [i]time[/i][b];[/b] La déclaration [i]retry[/i] détermine la durée que le client doit laisser s'écouler avant de retenter de contacter le serveur DHCP après une tentative infructueuse. Par défaut, cette durée est de 5 minutes. [i]La déclaration [/i] [b]select-timeout[/b] [b]select-timeout[/b] [i]time[/i][b];[/b] Quand plusieurs serveurs DHCP servent un même réseau, il est possible que le client reçoivent plusieurs réponses à son message de découverte de concession initiale et d'avoir des préférences parmi ses offres (par ex. choisir une adresse qui n'a jamais été utilisée plutôt que de réutiliser une adresse qui vient juste de se libérer). [i]select-timeout[/i] est la durée pendant laquelle le client doit attendre les offres des serveurs avant de choisir. Si aucune offre n'a été reçue avant l'expiration de [i]select-timeout[/i], le client acceptera la première offre qui arrivera. Par défaut, [i]select-timeout[/i] vaut zéro secondes - aussi le client choisi la première proposition qu'il reçoit. [i]La déclaration [/i] [b]reboot[/b] [b]reboot[/b] [i]time[/i][b];[/b] Quand le client redémarre, il essaye en premier lieu de récupérer la dernière adresse qu'il avait. Ceci est appelé l'état INIT-REBOOT. Si son redémarrage ne s'est pas accompagné d'un changement de réseau, c'est la méthode la plus rapide pour démarrer. La déclaration [i]reboot[/i] définit la durée octroyée au client pour pour récupérer son ancienne adresse. Au delà il abandonnera et essayera d'en découvrir une nouvelle. Par défaut, le décompte de reboot est de 10 secondes. [i]La déclaration [/i] [b]backoff-cutoff[/b] [b]backoff-cutoff[/b] [i]time[/i][b];[/b] Les clients utilisent un algorithme à retour exponentiel qui introduit de l'aléatoire, aussi si plusieurs clients tentent de se configurer simultanément, il n'y aura pas interblocage. La déclaration [i]backoff-cutoff[/i] détermine la durée maximal que les clients sont autorisés à passer dans la boucle de retour. Par défaut cette durée est de 2 minutes. [i]La déclaration[/i] [b]initial-interval[/b] [b]initial-interval[/b] [i]time[/i][b];[/b] La déclaration [i]initial-interval[/i] définit la durée entre la première et la seconde tentative de contacter un serveur. À chaque fois, un message est envoyé, l'intervalle entre les messages est doublé et l'intervalle courant est multiplié par un nombre aléatoire entre 0 et 1. Si l'intervalle est plus grand que la quantité [i]backoff-cutoff[/i], et il est réduit à cette quantité. La valeur par défaut est 10 secondes. [size=18] [b]Concessions requises et requÊtes[/b] [/size] Le protocole DHCP autorise le client à demander l'envoi par le serveur d'informations spécifiques et de ne pas envoyer les autres informations qu'il n'est pas préparé à accepter. Le protocole autorise aussi le client à rejeter les offres de serveurs qui ne lui donnent pas satisfaction. Les offres que les serveurs envoient aux clients DHCP peuvent contenir des données variées. Ces données qui peuvent être spécialement demandées sont appelés [i]les[/i] options DHCP et sont définies dans [b]dhcp-options[/b](5). [i]La déclaration[/i] [b]request[/b] [b]request[/b] [ [i]option[/i] ] [[b],[/b][i][/i] ... [i]option[/i] ][b];[/b] La déclaration [i]request[/i] oblige le client à demander à tout serveur lui répondant de lui envoyer les valeurs pour les options spécifiées. Seuls les noms des options doivent être spécifiés dans la déclaration [i]request[/i] - pas les paramètres des options. Par défaut, il demandera au serveur DHCP les options [i]subnet-mask[/i], [i]broadcast-address[/i], [i]time-offset[/i], [i]routers[/i], [i]domain-name[/i], [i]domain-name-servers[/i] et [i]host-name[/i]. Si vous ne voulez rien demander, écrivez simplement la déclaration [i]request[/i] mais ne spécifiez aucun paramètre. .nf request; .fi [i]La déclaration[/i] [b]require[/b] [b]require[/b] [ [i]option[/i] ] [[b],[/b][i][/i] ... [i]option[/i] ][b];[/b] La déclaration [i]require[/i] énumère la liste des options qui doivent être présentes dans une offre pour qu'elle soit acceptée. Les offres ne contenant pas toutes les options mentionnées seront ignorées. [i]La déclaration[/i] [b]send[/b] [b]send[/b] { [ [i]option[/i] declaration ] [[b],[/b][i][/i] ... [i]option[/i] declaration ][b]}[/b] La déclaration [i]send[/i] oblige le client à envoyer au serveur les options mentionnées avec les valeurs spécifiées. Il y a de nombreuses déclarations d'options comme décrit dans [b]dhcp-options[/b](5). Les options qui sont systématiquement envoyées dans le protocole DHCP ne devraient pas être spécifiées ici, à moins que le client ne spécifie une option [b]requested-lease-time[/b] différente de la durée de concession demandée par défaut, qui est de deux heures. L'autre utilisation évidente de cette déclaration est d'envoyer des informations au serveur qui vont lui permettre de différencier ce client des autres. [size=18] [b]Dns dynamique[/b] [/size] Désormais le client supporte de façon très limitée les mises à jours DNS quand une concession est acquise. Ce n'est encore qu'au stade expérimental et ne fera probablement pas ce que vous voulez. Ça ne peut marcher que si ça vous arrive d'aller au delà du contrôle de votre serveur DNS, ce qui est assez rare. Pour que ça fonctionne, il faut que vous déclariez une clé et une zone dans le serveur DHCP (voir [b]dhcpd.conf[/b](5) pour les détails). Vous avez également besoin de configurer l'option [i]fqdn[/i] du client comme suit : .nf send fqdn.fqdn "grosse.fugue.com."; send fqdn.encoded on; send fqdn.server-update off; .fi L'option [i]fqdn.fqdn[/i] [b]DOIT[/b] être un nom de domaine complet. Vous [b]DEVEZ[/b] définir une déclaration [i]zone[/i] pour la zone qui sera mise à jour. L'option [i]fqdn.encoded[/i] peut être nécessaire pour positionner à [i]on[/i] ou [i]off[/i], en fonction du serveur DHCP que vous utiliser. [size=18] [b]Options[/b] [/size] Dans certains cas, un client peut recevoir des paramètres depuis le serveur, qui ne sont pas vraiment approprié pour ce client, ou il peut ne pas recevoir les informations dont il a besoin et pour lesquelles l'existence de valeurs par défaut serait la bienvenue. Il peut également recevoir des informations utiles, mais qui doivent être complétées par des informations locales. Pour gérer tous ces besoins, plusieurs modificateurs d'options sont disponibles. [i]La déclaration[/i] [b]default[/b] [b]default[/b] [ [i]option[/i] declaration ] [b];[/b] Si pour certaines options, le client doit utiliser une valeur fournie par le serveur, mais a besoin d'une valeur par défaut quand le serveur n'en a pas fournie, ces valeurs peuvent être définies dans la déclaration [b]default[/b]. [i]La déclaration[/i] [b]supersede[/b] [b]supersede[/b] [ [i]option[/i] declaration ] [b];[/b] Si pour certaines options le client doit toujours utiliser une valeur locale plutôt que les valeurs du serveur quelles qu'elles soient, ces valeurs peuvent être définies dans la déclaration [b]supersede[/b]. [i]La déclaration[/i] [b]prepend[/b] [b]prepend[/b] [ [i]option[/i] declaration ] [b];[/b] Si pour certains ensembles d'options le client doit utiliser une valeur que vous fournissez, puis les valeurs fournies par le serveur s'il y en a, ces valeurs peuvent être définies dans la déclaration [b]prepend[/b]. Cette déclaration peut être uniquement utilisée pour les options qui acceptent plus d'une valeur. Cette restriction ne doit pas être contournée - sinon le comportement sera imprévisible. [i]La déclaration[/i] [b]append[/b] [b]append[/b] [ [i]option[/i] declaration ] [b];[/b] Si pour certains ensembles d'options le client doit d'abord utiliser les valeurs fournies par le serveur s'il y en a puis les valeurs que vous fournissez, ces dernières doivent être définies dans la déclaration [b]append[/b]. Cette déclaration ne doit être utilisée que pour les options qui acceptent plus d'une valeur. Cette restriction ne doit pas être contournée - sinon le comportement sera imprévisible. [size=18] [b]DÉclarations de concessions[/b] [/size] [i]La déclaration[/i] [b]lease[/b] [b]lease[/b] { [i]lease-declaration[/i] [ ... [i]lease-declaration[/i] ] [b]}[/b] Le client DHCP peut décider après une certaine période de temps (voir [b]DÉROULEMENT[/b] TEMPOREL DU PROTOCOLE) qu'il ne réussira pas à contacter le serveur. À ce moment, il consulte sa propre base de données des anciennes concessions et teste celles qui n'ont pas encore expiré en pingant le routeur mentionné pour cette concession pour voir si cette concession peut marcher. Il est possible de définir une ou plusieurs concessions [i]fixed[/i] dans le fichier de configuration du client pour les réseaux où il n'y a ni services DHCP ni BOOTP, ainsi le client peut encore configurer automatiquement son adresse. Ceci est fait avec la déclaration [b]lease[/b]. NOTE : la déclaration « lease » est aussi utilisé dans le fichier dhclient.lease dans le but d'enregistrer les concessions que les serveurs DHCP ont envoyé au client. Une partie de la syntaxe pour les concessions décrite ci-dessous est seulement requise dans le fichier dhclient.leases. Cette syntaxe est documentée ici pour être complet. Une déclaration [i]lease[/i] consiste dans le mot clé lease, suivi par une accolade ouvrante, suivie par une ou plusieurs déclarations de concessions, suivie par une accolade fermante. Les déclarations de concession suivantes sont possibles : [b]bootp;[/b] La déclaration [b]bootp[/b] est utilisée pour indiquer que la concession a été acquise en utilisant le protocole BOOTP plutôt que le protocole DHCP. Il n'est jamais nécessaire de le spécifier dans le fichier de configuration du client. Le client utilise cette syntaxe dans son fichier base de données de concession. [b]interface[/b] [b]"[/b][i]string[/i][b]";[/b] La déclaration de concession [b]interface[/b] est utilisée pour indiquer l'interface sur laquelle la concession est valide. Si cette concession est choisie elle ne sera essayée que sur cette interface. Lorsque le client reçoit une concession depuis le serveur, il enregistre le numéro d'interface sur laquelle la concession a été reçue. Si une concession prédéfinie est spécifiée dans le fichier dhclient.conf, bien que facultative, l'interface devrait aussi être spécifiée. [b]fixed-address[/b] [i]ip-address[/i][b];[/b] La déclaration [b]fixed-address[/b] est utilisée pour positionner l'adresse IP pour une concession particulière. Cette déclaration est obligatoire pour toutes les déclarations de concessions L'adresse IP doit être spécifiée sous forme de quatrain pointé (par ex. 12.34.56.78). [b]filename[/b] "[i]string[/i][b]";[/b] La déclaration [b]filename[/b] spécifie le nom du fichier de démarrage à utiliser. Ceci ne doit pas être utilisé par le script standard de configuration du client, mais elle est cité ici pour être complet. [b]server-name[/b] "[i]string[/i][b]";[/b] La déclaration [b]server-name[/b] spécifie le nom du serveur de démarrage à utiliser. Ceci est également inutilisé dans le script standard de configuration du client. [b]option[/b] [i]option-declaration[/i][b];[/b] La déclaration [b]option[/b] est utilisée pour spécifier la valeur d'une option fournie par le serveur, ou, dans le cas d'une concession prédéfinie déclarée dans dhclient.conf, la valeur que les utilisateurs souhaitent utiliser dans le script de configuration du client si la concession prédéfinie est utilisée. [b]script[/b] "[i]script-name[/i][b]";[/b] La déclaration [b]script[/b] est utilisée pour spécifier le nom de chemin du script de configuration du client. Ce script est utilisé par le client dhcp pour initialiser la configuration de chaque adresse avant de demander une adresse, pour tester l'adresse une fois qu'elle a été offerte, et pour positionner la configuration finale une fois que la concession a été acquise. Si aucune concession n'est acquise, le script est utilisé pour tester les concessions prédéfinies, si il y en a, et il est appelé si aucune concession valide ne peut être identifiée. Pour plus d'information, voyez [b]dhclient-script[/b](8). [b]vendor[/b] option space "[i]name[/i][b]";[/b] La déclaration [b]vendor option space[/b] est utilisée pour spécifier l'espace d'option doit être utilisé pour décoder d'éventuelles options d'encapsulation propriétaires. Le [i]dhcp-vendor-identifier[/i] peut être utilisé pour demander une classe spécifique d'option propriétaire depuis le serveur. Voir [b]dhcp-options[/b](5) pour les détails. [b]medium[/b] "[i]media[/i] setup[b]";[/b] La déclaration [b]medium[/b] peut être utilisée sur les systèmes où l'interface réseau ne peut pas déterminer automatiquement le type de réseau à laquelle elle est connectée. La chaîne de caractère de configuration du médium est un paramètre dépendant du système qui est passé au script de configuration du client dhcp lorsqu'il initialise l'interface. Sur les systèmes Unix, l'argument est passé à la commande ifconfig lors de la configuration de l'interface. Le client dhcp déclarera automatiquement ce paramètre s'il l'utilise (voir la déclaration [b]media[/b]) lors de la configuration de l'interface dans le but d'obtenir une concession. Cette déclaration ne devrait être utilisé dans les concessions prédéfinies que si l'interface réseau la requièrt. [b]renew[/b] [i]date[/i][b];[/b] [b]rebind[/b] [i]date[/i][b];[/b] [b]expire[/b] [i]date[/i][b];[/b] La déclaration [b]renew[/b] définit la date à laquelle le client dhcp doit commencer à essayer de contacter son serveur pour renouveler la concession qu'il utilise. La déclaration [b]rebind[/b] définie la date à laquelle le client dhcp doit commencer à essayer de contacter un serveur dhcp [i]quelconque[/i] pour renouveler sa concession. La déclaration [b]expire[/b] définie la date à laquelle le client dhcp doit arrêter d'utiliser sa concession s'il n'a pas été pas capable de contacter un serveur pour la renouveler. Ces déclarations sont automatiquement positionnées pour les concessions acquises par le client DHCP, mais doivent obligatoirement être spécifiées pour les concessions prédéfinies - une concession prédéfinies dont la date d'expiration est passée ne sera pas utilisée par le client DHCP. Les dates sont spécifiées comme suit : [i]<jour-semaine>[/i] <année>[b]/[/b][i]<mois>[/i][b]/[/b][i]<jour>[/i] <heure>[b]:[/b][i]<min>[/i][b]:[/b][i]<sec>[/i] Le jour de la semaine n'est présent que pour rendre la lecture humaine plus facile - il est spécifié sous forme d'un nombre compris entre 0 et 6 (Dimanche = 0). Lors de la déclaration de concessions prédéfinies, il peut être égal en permanence à 0. L'année est spécifiée avec le siècle, i.e. avec 4 chiffres. Le mois est un nombre entre 1 et 12 (Janvier = 1). Le jour est un nombre entre 1 et le nombre de jour dans le mois. L'heure est un nombre entre 0 et 23, les minutes et les secondes sont des nombres entre 0 et 59. [size=18] [b]DÉclarations dalias[/b] [/size] [b]alias[/b] { [i][/i] declarations ... [b]}[/b] Certains clients DHCP faisant fonctionner des protocoles TCP/IP mobiles peuvent nécessiter en plus de la concession qu'il acquière via DHCP, une adresse IP alias et ainsi ils peuvent avoir une une adresse permanente même lors de leurs déplacements. Le client DHCP de l'Internet Software Consortium ne supporte pas directement la mobilité avec des adresses fixes, mais dans le but de facilité une telle expérimentation, le client dhcp peut être configuré avec une IP alias en utilisant la déclaration [b]alias[/b]. La déclaration alias ressemble a une déclaration de concession, sauf que les options autres que l'option de masque de sous-réseaux sont ignorées par le script standard de configuration du client et les dates d'expiration sont ignorées. Une déclaration alias typique comporte une déclaration d'interface, une déclaration d'adresse fixe pour l'adresse IP alias et une déclaration de masque de sous-réseau. Une déclaration [i]medium[/i] ne doit jamais être inclue dans une déclaration [i]alias[/i]. [size=18] [b]Autres dÉclarations[/b] [/size] [b]reject[/b] [i]ip-address[/i][b];[/b] La déclaration reject oblige le client DHCP à rejecter les offres du serveurs qui utilisent une adresse spécifique en tant qu'identifiant serveur. Ceci peut être utilisé pour éviter d'être configuré par un imposteur ou des serveurs dhcp mal configurés, toutefois ceci ne devrait être utilisé qu'en dernier ressort - il vaut mieux essayer de trouver les mauvais serveurs DHCP et les corriger. [b]interface[/b] "[i]name[/i][b]"[/b] { [i]declarations[/i] ... [b] } Un client avec plus d'une interface réseau peut nécessiter différents comportements en fonction de l'interface qui est en cours de configuration. Tous les paramètres temporels et les déclarations autres que celles des concessions et déclarations alias peuvent être encapsulées dans la déclaration d'interface, et les paramètres seront alors utilisés uniquement pour l'interface qui correspond au nom spécifié. Les interfaces pour lesquelles il n'y a pas de déclaration d'interface utiliseront les paramètres déclarés en dehors de toute déclaration d'interface, ou les paramètres par défaut. [b]pseudo[/b] "[i]name[/i]" "[i]real-name[/i][b]"[/b] { [i]declarations[/i] ... [b] } Dans certaines circonstances, il peut être utile de déclarer une pseudo-interface et que le client DHCP acquière une configuration pour cette interface. Chaque interface supportée par le client DHCP dispose d'un automate client qui fonctionne dessus pour acquérir et maintenir la concession. Une pseudo-interface est simplement une autre machine à état fonctionnant sur l'interface nommée [i]real-name[/i], avec sa propre concession et son propre état. Si vous utilisez cette caractéristique, vous pouvez fournir un identifiant client pour la pseudo-interface et l'interface réelle, mais les deux identifiants doivent être différents. Vous devez également fournir un script client séparé pour la pseudo-interface pour faire ce que vous voulez avec l'adresse IP. Par exemple : .nf interface "ep0" { send dhcp-client-identifier "my-client-ep0"; } pseudo "secondary" "ep0" { send dhcp-client-identifier "my-client-ep0-secondary"; script "/etc/dhclient-secondary"; } .fi Le script client pour la pseudo-interface ne devrait pas configurer l'interface pour l'activer (up) ou la désactiver (down) - principalement, tout ce dont elle a besoin de gérer, ce sont les états dans lesquels une concession a été acquise ou renouvelée, et les états dans lesquels une concession a expirée. Voyez [b]dhclient-script[/b](8) pour plus d'informations [b]media[/b] "[i]media[/i] setup[b]"[/b][i][/i] [ [b],[/b] "[i]media[/i] setup[b]",[/b] [i]...[/i] ][b];[/b] La déclaration [b]media[/b] définit un ou plusieurs paramètre de configuration de support physique qui peuvent être essayé lors de la tentative d'acquisition d'une adresse IP. Le client dhcp fera un cycle à travers chaque chaîne de caractère de configuration du média de la liste, configurant l'interface en utilisant le configurateur et tentera de démarrer, puis il essayera la suivante. C'est utilisé pour les interfaces réseaux qui ne sont pas capables de détecter toutes seules le type de support physique - quel qu'il soit s'il permet d'envoyer une requête au serveur et de recevoir réponse il sera considéré comme correct (sans garantie). La configuration du support physique est utilisé uniquement dans la phase initiale d'acquisition de l'adresse (ce sont les paquets DHCPDISCOVER et DHCPOFFER). Une fois que l'adresse a été acquise, le client dhcp l'enregistrera dans sa base de données des concessions ainsi que le type de support physique qui a servi à l'obtenir. Quand le client essayera de renouveler la concession, il utilisera le même type de support physique. La concession doit expirer avant que le client ne reviennent de son cycle au travers des types de supports physiques. [size=18] [b]Exemple[/b] [/size] Le fichier de configuration suivant est utilisé sur un ordinateur portable fonctionnant sous NetBSD. L'ordinateur a une adresse IP alias de 192.5.5.213 et il possède une interface, ep0 (une 3com 3C589C). Les intervalles de démarrage ont été raccourcis par rapport aux valeurs par défaut, car le client ne se connecte qu'à des réseaux où il y a peu d'activités DHCP, mais l'ordinateur portable va errer sur de multiples réseaux. .nf timeout 60; retry 60; reboot 10; select-timeout 5; initial-interval 2; reject 192.33.137.209; interface "ep0" { send host-name "andare.fugue.com"; send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; send dhcp-lease-time 3600; supersede domain-name "fugue.com rc.vix.com home.vix.com"; prepend domain-name-servers 127.0.0.1; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name; require subnet-mask, domain-name-servers; script "/etc/dhclient-script"; media "media 10baseT/UTP", "media 10base2/BNC"; } alias { interface "ep0"; fixed-address 192.5.5.213; option subnet-mask 255.255.255.255; } .fi C'est un fichier dhclient.conf très compliqué - en général, le vôtre devrait être beaucoup plus simple. Dans de nombreux de cas, il suffit de créer un fichier dhclient.conf vide - les valeurs par défaut suffisent le plus souvent. [size=18] [b]Voir aussi[/b] [/size] dhcp-options(5), dhclient.leases(5), dhcpd(8), dhcpd.conf(5), RFC2132, RFC2131. [size=18] [b]Auteur[/b] [/size] [b]dhclient[/b](8) a été écrit par Ted Lemon <mellon@vix.com> dans le cadre d'un contrat avec Vixie Labs. Le financement de ce projet a été pris en charge par l'Internet Software Corporation. Pour en savoir plus sur l'Internet Software Consortium, rendez-vous sur [b]http://www.isc.org/isc[/b]. [size=18] [b]Traduction[/b] [/size] Sébastien Blanchet, 2001
Fichier