Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] dhcpd.conf - fichier de configuration de dhcpd [size=18] [b]Description[/b] [/size] Le fichier dhcpd.conf contient les paramètres de configuration pour [b]dhcpd[/b], le serveur DHCP de l'Internet Software Consortium. Le fichier dhcpd.conf est un fichier texte ASCII texte de format libre. Il est analysé par l'analyseur récursif-descendant intégré à dhcpd(8). Le fichier peut comporter des caractères de tabulations et de retour à la ligne supplémentaires pour la mise à page. Les mots clés du fichier sont insensibles à la casse (i.e. à la différence majuscule/minuscule). Les commentaires peuvent être placés n'importe où dans le fichier (sauf au sein des apostrophes). Les commentaires débutent par le caractère # et se terminent avec la ligne. Le fichier est essentiellement constitué d'une liste de paramètres et de déclarations. Les paramètres déterminent les valeurs internes du serveur (par ex. la durée de concession à offrir), définissent son comportement (par ex. est ce que dhcpd doit attribuer des adresses aux clients inconnus) et spécifient les informations qu'il doit fournir aux clients (par ex. utiliser la passerelle d'adresse 220.177.244.7). Les déclarations sont utilisées pour décrire la topologie du réseau, les clients et les adresses attribuables, ou pour appliquer un groupe de paramètres à un groupe de déclarations. Dans tout groupe de paramètres et de déclarations, les paramètres doivent être spécifiés avant les déclarations qui en dépendent. Les déclarations en relation avec la topologie du réseau incluent les déclarations de réseau partagé ([i]share-network[/i]) et de sous-réseau ([i]subnet[/i]). Si les clients d'un sous-réseau doivent recevoir dynamiquement leurs adresses, une déclaration de plage ([i]range[/i]) d'adresses doit apparaître au sein de la déclaration du sous-réseau. Pour les clients, qui reçoivent des adresses statiques, ou pour les installations où seuls les clients connus sont servis, chaque client doit avoir une déclaration d'hôte ([i]host[/i]). Une déclaration de groupe ([i]group[/i]) peut être utilisée pour appliquer des paramètres à un groupe de déclaration qui ne suit pas le partionnement en sous-réseau. Il doit y avoir une déclaration de sous-réseau pour chaque sous-réseau servi par dhcpd, ainsi que pour tous ceux auxquels le serveur DHCP est connecté. Ces déclarations permettent à dhcpd de déterminer si une adresse appartient à l'un de ces sous-réseaux. La déclaration de sous-réseau est obligatoire même si aucune adresse ne sera allouée dynamiquement sur celui-ci. Certaines installations possèdent des réseaux physiques sur lesquels fonctionnent plusieurs sous-réseau IP. Par exemple, imaginons un site qui utilise un masque sous-réseau de 8 bit pour l'ensemble de ses départements, mais qu'un d'eux s'étende à un tel point qu'il ait plus de 254 noeuds sur le même réseau ethernet. Il est alors nécessaire d'utiliser deux sous-réseaux IP sur le même réseau ethernet en attendant l'installation d'un nouveau réseau physique. Dans ce cas, les déclarations de ces deux réseaux peuvent comporter une clause de réseau partagé. Certains sites peuvent avoir des départements qui ont des clients sur plusieurs sous-réseaux, et qui veulent offrir à leurs clients un ensemble uniforme de paramètres, mais différents de ceux proposés aux clients des autres départements, bien qu'étant situés sur les mêmes sous-réseaux. Pour les clients qui seront explicitement déclarés par une déclaration d'hôte, ces déclarations peuvent être regroupées dans une déclaration de groupe avec les paramètres communs au département. Pour des clients dont les adresses seront assignées dynamiquement, il n'y a actuellement aucun moyen de grouper les paramètres d'assignements autrement que suivant la topologie du réseau. Lorsqu'un client doit être démarré, ses paramètres de démarrage sont déterminés en consultant en premier lieu la déclaration d'hôte du client (s'il y en a une), puis en deuxième lieu la déclaration de groupe (s'il y en a une) qui comprend une déclaration d'hôte pour le client, puis en troisième lieu la déclaration du sous-réseau sur lequel le client est en train de démarrer, puis en quatrième lieu la déclaration de réseau partagé (s'il y en a une) contenant ce sous-réseau, et finalement les paramètres du niveau principal qui peuvent être spécifiés en dehors de toute déclaration. Lorsque dhcpd essaye de trouver une déclaration d'hôte pour un client, il recherche d'abord une déclaration d'hôte avec un paramètre [i]fixed-address[/i] (adresse fixe) correspondant au sous-réseau ou au réseau partagé sur lequel le client est en train de démarrer. S'il ne trouve pas une telle entrée, alors il recommence sa recherche sans le paramètre [i]fixed-address[/i]. S'il ne trouve toujours rien, alors dhcpd considère qu'il n'y a pas d'entrée dans le fichier dhcpd.conf pour ce client : il ignore une éventuelle une entrée pour ce client sur un sous-réseau ou un réseau partagé différent. [size=18] [b]Exemples[/b] [/size] Un fichier dhcpd.conf typique ressemblera à quelque chose comme ceci : .nf [i]paramètres globaux[/i] shared-network ISC-BIGGIE { [i]paramètres[/i] spécifiques au réseau partagé... subnet 204.254.239.0 netmask 255.255.255.224 { [i]paramètres[/i] spécifiques au sous-réseau... range 204.254.239.10 204.254.239.30; } subnet 204.254.239.32 netmask 255.255.255.224 { [i]paramètres[/i] spécifiques au sous-réseau... range 204.254.239.42 204.254.239.62; } } subnet 204.254.239.64 netmask 255.255.255.224 { [i]paramètres[/i] spécifiques au sous-réseau... range 204.254.239.74 204.254.239.94; } group { [i]paramètres[/i] spécifiques au groupe... host zappo.test.isc.org { [i]paramètres[/i] spécifiques à l'hôte... } host beppo.test.isc.org { [i]paramètres[/i] spécifiques à l'hôte... } host harpo.test.isc.org { [i]paramètres[/i] spécifiques à l'hôte... } } .ce 1 Figure 1 .fi Notez qu'au début du fichier se trouve un emplacement pour les paramètres globaux. Ce peut être des choses comme le nom de domaine de l'organisation, les adresses des serveurs de noms (s'ils sont commun à l'ensemble de l'organisation), et d'autres choses encore. Par exemple : .nf option domain-name "isc.org"; option domain-name-servers ns1.isc.org, ns2.isc.org; .ce 1 Figure 2 .fi Comme vous pouvez le voir dans la figure 2, il est possible de spécifier par nom les adresses des hôtes plutôt que par adresses IP numériques. Si un nom d'hôte donné se résout en plusieurs adresses IP (par exemple, si un hôte à deux interfaces ethernets), elles sont toutes fournies au client. Dans la figure 1, vous pouvez voir que les deux déclaration de réseau partagé et sous-réseau ([i]shared-network[/i] et [i]subnet[/i]) peuvent avoir des paramètres. Imaginons que le réseau partagé [i]ISC-BIGGIE[/i] supporte un département entier - par exemple le département comptable. Si la comptabilité à son propre domaine alors les paramètres spécifiques au réseau partagé peuvent être : .nf option domain-name "comptabilite.isc.org"; .fi Ainsi toutes les sous-réseaux déclarés dans la déclaration du réseau partagé [i]ISC-BIGGIE[/i] auront l'option de nom de domaine ([i]domain-name[/i]) mise à "comptabilite.isc.org", au lieu "isc.org" défini au niveau global. La raison la plus évidente d'avoir des paramètres spécifiques à un sous-réseau est montré dans la Figure 1 : chaque sous-réseau, par nécessité, a son propre routeur. Aussi pour le premier sous-réseau, par exemple, on peut avoir quelque chose comme : .nf option routers 204.254.239.1; .fi Notez qu'ici l'adresse est spécifiée numériquement. Ce n'est pas une obligation - si vous avez un nom de domaine différent pour chaque interface de votre routeur, il est parfaitement légitime d'utiliser le nom de domaine pour les interfaces plutôt que les adresses numériques. Cependant, dans la plupart des cas, vous n'aurez qu'un seul nom de domaine pour toutes les adresses IP d'un routeur, et il ne sera pas approprié d'utiliser ce nom ici. Dans la Figure 1, il y a aussi une déclaration de groupe qui fournit les paramètres communs pour un ensemble de trois hôtes - « zappo », « beppo » et « harpo ». Comme vous pouvez le constater, ces hôtes sont tous dans le domaine test.isc.org, aussi on peut donc choisir d'avoir un paramètre spécifique au groupe qui remplacera le nom de domaine fourni à ces hôtes : .nf option domain-name "test.isc.org"; .fi Vu le nom de domaine dans lequel se trouvent ces machines, elles sont probablement destinés à des tests. Si nous voulons tester le mécanisme de concession de DHCP, nous pouvons mettre la durée de concession à une valeur inférieure à la valeur par défaut : .nf max-lease-time 120; default-lease-time 120; .fi Vous avez peut être remarqué que certains paramètres débutent avec le mot-clé [i]option[/i] et d'autres non. Les paramètres débutant avec le mot-clé [i]option[/i] sont réellement optionnels pour DHCP tandis que les autres, soit contrôlent le comportement du serveur DHCP (par ex. la durée des concessions fournie par dhcpd), soit spécifient des paramètres obligatoires des clients DHCP (par ex. nom de serveur et nom de fichier). Dans la Figure 1, chaque machine a des paramètres d'hôtes spécifiques. Parmi ces paramètres on trouve des choses telles que le nom d'hôte ([i]hostname[/i]), le nom du fichier ([i]filename[/i]) à lui envoyer ou l'adresse du serveur depuis lequel le fichier sera envoyé (paramètre [i]next-server[/i]). En général, n'importe quel paramètre peut apparaître à n'importe quel endroit où les paramètres sont autorisés. Il sera appliqué en fonction de la portée du bloc dans lequel il apparaît. Imaginons un site avec de nombreux Terminaux-X de marque NCD. Ces terminaux sont de différents modèles, et il vous faut spécifier un fichier de démarrage par type de modèle. Une méthode serait d'avoir une déclaration d'hôte par terminal et de les grouper par modèle : .nf group { filename "Xncd19r"; next-server ncd-booter; host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; } host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; } host ncd8 { hardware ethernet 0:c0:c3:22:46:81; } } group { filename "Xncd19c"; next-server ncd-booter; host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } } group { filename "XncdHMX"; next-server ncd-booter; host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } } .fi [size=18] [b]RÉfÉrence: dÉclarations[/b] [/size] [b]La[/b] déclaration [i]shared-network[/i] [b](réseau[/b] partagé) .nf [b]shared-network[/b] [i]name[/i] [b]{[/b] [ [i]paramètres[/i] ] [ [i]déclarations[/i] ] [b]}[/b] .fi La déclaration de réseau partagé est utilisée pour informer le serveur DHCP que certains sous-réseau IP partagent en réalité le même réseau physique. Tout sous-réseau d'un réseau partagé devrait être déclaré au sein d'une telle déclaration. Les paramètres spécifiés dans la déclaration de réseau partagé seront utilisés lorsque les clients démarreront sur ces sous-réseaux à moins que ces paramètres ne soient écrasés par ceux fournis au niveau du réseau ou de l'hôte. Dans un réseau partagé, les adresses disponibles dans chaque sous-réseau pour l'allocation dynamique sont mises en commun. Il n'y a aucun moyen de choisir le sous-réseau du réseau partagé sur lequel un client doit démarrer. [i]name[/i] devrait être le nom du réseau partagé. Ce nom est utilisé lors de l'impression de messages de debug, aussi il devrait être descriptif pour le réseau partagé. Le nom peut avoir la syntaxe d'un nom de domaine valide (bien qu'il ne sera jamais utilisé en tant que tel), ou bien n'importe quel nom entre guillemets. [b]La[/b] déclaration [i]subnet[/i] [b](sous-réseau)[/b] .nf [b]subnet[/b] [i]subnet-number[/i] [b]netmask[/b] [i]netmask[/i] [b]{[/b] [ [i]paramètres[/i] ] [ [i]déclarations[/i] ] [b]}[/b] .fi La déclaration de sous-réseau est utilisée pour que dhcpd puisse déterminer si une adresse IP appartient à un sous-réseau. Elle peut aussi être utilisée pour fournir des paramètres spécifiques au sous-réseau et pour spécifier quelles adresses peuvent être dynamiquement allouées aux clients démarrant sur ce sous-réseau. De telles adresses sont spécifiées en utilisant la déclaration [i]range[/i] (plage ou intervalle [d'adresses]). L'adresse de sous-réseau [i]subnet-number[/i] doit être une adresse IP ou un nom de domaine qui se résout en cette adresse IP. Le masque de réseau [i]netmask[/i] doit aussi être une adresse IP ou un nom de domaine qui se résout en cette adresse IP. L'adresse du sous-réseau et le masque de réseau suffisent à déterminer si une adresse IP donnée appartient à ce sous-réseau. Bien qu'un masque de réseau doit être donné avec chaque déclaration d'un sous-réseau, il est recommandé dans le cas où on utilise le même masque de réseau pour tout un site, d'utiliser la déclaration de paramètre [i]option[/i] subnet-mask dans chaque déclaration de sous-réseau, puisqu'elle écrasera le masque de réseau indiqué à la déclaration du sous-réseau. [b]La[/b] déclaration [i]range[/i] [b](plage[/b] [d'adresses]) .nf [b]range[/b] [ [b]dynamic-bootp[/b] ] [i]low-address[/i] [ [i]high-address[/i]][b];[/b] .fi Tout sous-réseau sur lequel des adresses seront assignés dynamiquement, doit comporter au moins une déclaration de plage d'adresse. Cette déclaration donne la plus petite ([i]low-address[/i]) et la plus grande adresse IP ([i]high-address[/i]) de la plage. Toutes les adresses IP de la plage doivent appartenir au sous-réseau dans lequel la plage est déclarée. L'option [i]dynamic-bootp[/i] peut être spécifiée pour indiquer que les adresses de la plage peuvent être assignées dynamiquement aussi bien aux clients DHCP que BOOTP. Lorsque la plage se réduit à une seule adresse, l'adresse supérieure ([i]high-address[/i]) peut être omise. [b]La[/b] déclaration [i]host[/i] [b](hôte)[/b] .nf [b]host[/b] [i]hostname[/i] { [ [i]paramètres[/i] ] [ [i]déclarations[/i] ] [b]}[/b] .fi Il doit y avoir au moins une déclaration d'hôte pour chaque client BOOTP à servir. Cette déclaration peut aussi être spécifiée pour les clients DHCP, bien que ce ne soit pas nécessaire à moins que le démarrage ne soit activé que pour les hôtes connus. Si on veut être capable de démarrer un client DHCP ou BOOTP sur plus d'un sous-réseau avec des adresses fixes, on peut spécifier plusieurs adresses dans le paramètre [i]fixed-address[/i] (adresse fixe), ou bien utiliser plusieurs déclarations d'hôtes. Si les paramètres de démarrage spécifiques à un client varient en fonction du réseau auquel il est rattaché, alors il faut utiliser plusieurs déclaration d'hôtes. Si un client doit être démarré dans la mesure du possible en utilisant une adresse fixe, mais qu'en cas d'impossibilité il doit recevoir une adresse dynamique, alors il faut ajouter une deuxième déclaration d'hôte sans le paramètre [b]fixed-address[/b]. [i]hostname[/i] est le nom identifiant l'hôte. Si aucune autre option [i]hostname[/i] n'est spécifiée pour l'hôte, alors [i]hostname[/i] est utilisé. Les déclarations d'hôtes sont comparées aux clients DHCP et BOOTP réels en mettant en correspondance l'option [i]dhcp-client-identifier[/i] spécifiée dans la déclaration d'hôte avec celle fournie par le client, ou, si cette option est absente de la déclaration d'hôte ou si le client ne fournit pas d'option [i]dhcp-client-identifier[/i], en comparant l'adresse matérielle du client avec le paramètre [i]hardware[/i] de la déclaration d'hôte. Normalement, les clients BOOTP ne fournissent pas d'option [i]dhcp-client-identifier[/i], aussi l'adresse matérielle doit être utilisée pour tous les clients utilisant le protocole BOOTP. [b]La[/b] déclaration [i]group[/i] [b](group)[/b] .nf [b]group[/b] { [ [i]paramètres[/i] ] [ [i]déclarations[/i] ] [b]}[/b] .fi La déclaration [i]group[/i] est utilisée tout simplement pour appliquer un ou plusieurs paramètres à un groupe de déclaration. Elle peut être utilisée pour grouper hôtes, réseaux partagés, sous-réseaux, ou même d'autres groupes. [size=18] [b]RÉfÉrence: allow et deny[/b] [/size] Les déclarations [i]allow[/i] (autoriser) et [i]deny[/i] (interdire) peuvent être utilisées pour contrôler le comportement de [b]dhcpd[/b] en fonction de la nature des requêtes. [b]Le mot-clé [i]unknown-clients[/i] (clients inconnus)[/b] [b]allow[/b] unknown-clients; [b]deny[/b] unknown-clients; Le mot clé [b]unknown-clients[/b] est utilisé pour indiquer à [b]dhcpd[/b] s'il doit oui ou non attribuer dynamiquement des adresses aux clients inconnus. Par défaut, l'attribution dynamique des adresses est [b]autorisée[/b] pour les clients inconnus. [b]Le mot-clé[/b] [i]bootp[/i] [b]allow[/b] bootp; [b]deny[/b] bootp; Le mot-clé [b]bootp[/b] est utilisé pour indiquer à dhcpd s'il doit oui ou non répondre aux requêtes bootp. Par défaut, les requêtes bootp sont [b]autorisées[/b]. [b]Le mot-clé[/b] [i]booting[/i] [b][/b] [b]allow[/b] booting; [b]deny[/b] booting; Le mot-clé [b]booting[/b] est utilisé pour dire à dhcpd si oui ou non il doit répondre aux demandes d'un client particulier Ce mot-clé n'a de signification uniquement dans une déclaration d'hôte. Par défaut booting est [b]autorisé[/b], mais si il est désactivé pour un client particulier, alors ce client sera incapable d'obtenir une adresse depuis le serveur DHCP. [size=18] [b]RÉfÉrence: paramÈtres[/b] [/size] [b]Le paramètre[/b] [i]default-lease-time[/i] [b]default-lease-time[/b] [i]time[/i][b];[/b] [i]time[/i] spécifie la durée en secondes de la concession attribuée à un client qui n'a pas demandé une durée spécifique. [b]Le paramètre[/b] [i]max-lease-time[/i] [b]max-lease-time[/b] [i]time[/i][b];[/b] [i]time[/i] spécifie la durée maximale en secondes de la concession attribuée à un client qui a demandé une durée spécifique. [b]Le paramètre [/b] [i]hardware[/i] [b]hardware[/b] [i]hardware-type[/i] [i]hardware-address[/i][b];[/b] Dans le but de reconnaître un client BOOTP, son adresse matérielle doit être déclarée en utilisant la clause [i]hardware[/i] dans la déclaration d'hôte. [i]hardware-type[/i] doit être le nom d'un type d'interface matérielle. Actuellement seuls les types, [b]ethernet[/b] et [b]token-ring[/b] sont reconnus, bien que le support pour d'autres types d'interfaces matérielles telles que [b]fddi[/b] soit souhaitable. L'adresse matérielle ([i]hardware-address[/i]) doit être spécifiée en utilisant la notation hexadécimale et en séparant les octets par des deux-points (par ex: 5A:54:05:F6:5D:B6). Le paramètre [i]hardware[/i] peut aussi être utilisé pour les clients DHCP. Le paramètre [i]filename[/i] (nom de fichier) [b]filename[/b] [b]"[/b][i]filename[/i][b]";[/b] Le paramètre [i]filename[/i] peut être utilisé pour spécifier le nom du fichier de démarrage initial qui doit être utilisé par un client. Le nom de fichier doit être un nom de fichier reconnaissable par tous les protocoles de transport de fichier que le client utilisera pour charger le fichier. [b]Le paramètre [i]server-name[/i] (nom de serveur)[/b] [b]server-name[/b] "[i]name[/i][b]";[/b] Le paramètre [i]server-name[/i] est utilisé pour indiquer aux clients le nom du serveur depuis lequel ils sont en train de démarrer. [i]name[/i] sera le nom fourni au client. [b]Le paramètre [i]next-server[/i] (prochain serveur)[/b] [b]next-server[/b] [i]server-name[/i][b];[/b] Le paramètre [i]next-server[/i] est utilisé pour spécifier l'adresse hôte du serveur depuis lequel le fichier de démarrage initial (spécifié par le paramètre [i]filename[/i]) sera chargé. [i]server-name[/i] doit être une adresse IP numérique ou un nom de domaine. Si aucun paramètre [i]next-server[/i] ne s'applique à un client donné, l'adresse du serveur DHCP est utilisée. [b]Le[/b] paramètre [i]fixed-address[/i] (adresse fixe) [b]fixed-address[/b] [i]address[/i] [[b],[/b] [i]address[/i] ... ][b];[/b] Le paramètre [i]fixed-address[/i] est utilisée pour assigner une ou plusieurs adresse IP fixes à un client. Elle devrait apparaître uniquement dans une déclaration d'hôte. Si plus d'une adresse est fournie, alors lorsque le client démarre, il reçoit l'adresse correspondant au réseau sur lequel il démarre. Si aucune adresse spécifiée dans la clause [i]fixed-address[/i] ne correspond au réseau sur lequel le client est en train de démarrer, alors le client ne correspondra pas à la déclaration d'hôte qui contient cette clause. [i]address[/i] est une adresse IP numérique ou un nom de domaine qui se résout en une ou plusieurs adresses IP. [b]Le[/b] paramètre [i]dynamic-bootp-lease-cutoff[/i] (coupure des concessions bootp dynamiques) [b]dynamic-bootp-lease-cutoff[/b] [i]date[/i][b];[/b] Le paramètre [i]dynamic-bootp-lease-cutoff[/i] définit une date de fin pour toutes les concessions attribuées dynamiquement aux clients BOOTP. Comme les clients BOOTP n'ont aucun moyen pour renouveler les concessions et qu'ils ne savent pas quand leurs concessions expirent, par défaut dhcpd attribue des concessions à perpétuité aux clients BOOTP. Cependant, dans certaines situations on veut fixer une date de clôture pour toutes les concessions BOOTP - par exemple, pendant la nuit quand un bâtiment est fermé et que toutes les machines doivent être éteintes. [i]date[/i] devrait être la date à laquelle toutes les concessions BOOTP attribuées devront être interrompues. La date est spécifiée dans le format suivant .ce 1 W AAAA/MM/JJ HH:MM:SS W est le jour de la semaine exprimé sous forme de nombre depuis 0 (Dimanche) jusqu'à 6 (Samedi). AAAA est l'année, avec les 4 chiffres. MM est le mois exprimé sous forme numérique de 1 à 12. JJ est le jour du mois, qui commence à 1. HH est l'heure de 0 à 23. MM pour les minutes et SS les secondes. L'heure est toujours donnée en heure universelle (UTC=Universal Time Coordinated ), et non en heure locale. [b]Le[/b] paramètre [i]dynamic-bootp-lease-length[/i] (durée des concessions BOOTP dynamiques) [b]dynamic-bootp-lease-length[/b] [i]length[/i][b];[/b] Le paramètre [i]dynamic-bootp-lease-length[/i] est utilisé pour fixer la durée des concessions attribuées aux clients BOOTP. Sur certains sites, il est possible de supposer qu'une concession n'est plus utilisée si son propriétaire n'a pas utilisé BOOTP ou DHCP pour récupérer son adresse depuis un certain temps. Cette durée est spécifiée par le paramètre [i]length[/i] en secondes. Si un client redémarre en utilisant BOOTP, avant l'expiration de cette durée, la durée de sa concession est réinitialisée à [i]length[/i], aussi un client BOOTP qui redémarre suffisamment fréquemment ne perdra jamais sa concession. Il est inutile de préciser que ce paramètre doit être ajusté avec une extrême prudence. [b]Le paramètre[/b] [i]get-lease-hostnames[/i] [b]get-lease-hostnames[/b] [i]flag[/i][b];[/b] (trouver le nom des concessionnaires) Le paramètre [i]get-lease-hostnames[/i] est utilisé pour indiquer à dhcpd s'il doit oui ou non rechercher les nom de domaines qui correspondent aux adresses IP disponibles pour l'allocation dynamique et utiliser cette adresse l'option [i]hostname[/i] de DHCP. Si [i]flag[/i] est positionné à [i]true[/i] (vrai), alors cette recherche sera faite pour toutes les adresses dans le contexte actuel. Par défaut, la valeur est positionnée à [i]false[/i] (faux), et aucune recherche n'est faite. [b]Le[/b] paramètre [i]use-host-decl-names[/i] (utiliser le nom de la déclaration d'hôte comme nom d'hôte) [b]use-host-decl-names[/b] [i]flag[/i][b];[/b] Si le paramètre [i]use-host-decl-names[/i] est vrai dans la portée d'un bloc, alors pour chaque déclaration d'hôtes à l'intérieur de ce bloc, le nom fourni pour la déclaration sera fourni au client pour devenir son nom d'hôte. Par exemple .nf group { use-host-decl-names on; host toto { hardware ethernet 08:00:2b:4c:29:32; fixed-address toto.fugue.com; } } est équivalent à host toto { hardware ethernet 08:00:2b:4c:29:32; fixed-address toto.fugue.com; option host-name "toto"; } .fi Une instruction [i]option[/i] host-name au sein d'une déclaration d'hôte remplacera l'utilisation du nom dans la déclaration d'hôte. [b]La clause[/b] [i]authoritative[/i] [b]authoritative;[/b] [b]not[/b] authoritative; Normalement le serveur serveur DHCP supposera que les informations de configuration d'un segment de réseau donné sont correctes et font autorité. Aussi si un client demande une adresse IP sur un segment de réseau que le serveur sait être invalide pour ce segment, le serveur répondra par un message DHCPNAK, provoquant chez le client l'abandon de son adresse IP et la demande d'une nouvelle. Si un serveur DHCP est en train d'être configuré par quelqu'un d'autre que l'administrateur réseau et qui par conséquent ne souhaite pas endosser ce niveau d'autorité, alors l'instruction [i]not[/i] authoritative devrait être écrite dans le bloc approprié dans le fichier de configuration. Habituellement, écrire [b]not[/b] authoritative; au plus haut niveau du fichier devrait être suffisant, cependant, si un serveur DHCP est configuré par quelqu'un qui sait qu'il fait autorité sur certains réseaux et pas sur les autres, il peut être plus approprié de déclarer l'autorité au niveau de chaque segment réseau. Remarquez que la portée de bloc la plus spécifique pour ce concept d'autorité qui a un sens est le segment physique du réseau~: c'est donc soit un réseau partagé, soit un sous-réseau qui ne fait pas parti d'un réseau partagé. Ça n'a aucun sens de spécifier qu'un serveur fait autorité pour certains sous-réseaux d'un réseau partagé et pas pour les autres, de même ça n'a pas de sens de spécifier qu'un serveur fait autorité pour certaines déclarations d'hôte et pas pour les autres. [b]Le paramètre[/b] [i]use-lease-addr-for-default-route [/i] (utiliser l'adresse de concession comme route par défaut) [b]use-lease-addr-for-default-route[/b] [i]flag[/i][b];[/b] Si le paramètre [i]use-lease-addr-for-default-route[/i] est vrai dans un bloc donné, alors au lieu d'envoyer la valeur spécifiée dans l'option des routeurs (ou de n'envoyer rien du tout), l'adresse IP de la concession en train d'être attribuée est envoyée au client. C'est supposé provoquer la résolution ARP pour les machines Win95, ce qui peut être utile si votre routeur est configuré en proxy ARP. Si [i]use-lease-addr-for-default-route[/i] est activé et que l'option [i]router[/i] et aussi dans le même bloc, l'option [i]router[/i] sera choisie. La raison pour cela est qu'il y a des situations où vous voudrez utiliser cette caractéristique. Par exemple vous voulez l'activer pour un ensemble important de machines Win95, et l'écraser pour quelques autres machines. Malheureusement, si le contraire est vrai pour votre site (un petit nombre de machines Win95, et l'écrasement sur un nombre important d'autres machines), vous ferez mieux de ne pas essayer d'utiliser ce paramètre. [b]Le paramètre[/b] [i]always-reply-rfc1048[/i] (toujours répondre en rfc1048) [b][/b] [b]always-reply-rfc1048[/b] [i]flag[/i][b];[/b] Certains clients BOOTP clients s'attendent à des réponses de type RFC1048, mais n'envoie pas leurs requêtes dans ce format. Vous pouvez supposer qu'un client à ce problème s'il ne récupère pas les options que vous lui avez configuré et que vous voyez dans les messages de log du serveur "(non-rfc1048)" pour chaque BOOTREQUEST enregistré. Si vous voulez envoyer des options rfc1048 à un tel client, vous pouvez positionner l'option [b]always-reply-rfc1048[/b] dans la déclaration d'hôte d'un client, et le serveur DHCP pourra répondre avec un champ d'option de type RFC-1048. Ce paramètre peut être positionné dans tout bloc et il affectera tous les clients couverts par la portée de ce bloc. [b]Le paramètre[/b] [i]server-identifier[/i] identificateur du serveur [b]server-identifier[/b] [i]hostname[/i][b];[/b] Le paramètre [i]server-identifier[/i] peut être utilisé pour définir la valeur que prendra l'option d'identificateur du serveur DHCP dans la portée d'un bloc. La valeur spécifiée [b]doit[/b] être l'adresse IP d'un serveur DHCP, et être atteignable par tous les clients servis par ce contexte particulier. L'utilisation du paramètre [i]server-identifier[/i] n'est pas recommandée - la seule raison de l'utiliser, c'est pour forcer une valeur autre que celle par défaut et pour être envoyé dans des occasions où la valeur par défaut pourrait être incorrecte. La valeur par défaut est la première adresse IP associée à l'interface réseau matérielle sur laquelle la requête est arrivée. Le cas habituel où le paramètre [i]server-identifier[/i] a besoin d'être envoyé c'est lorsqu'une interface matérielle qui possède plusieurs adresses IP et que celle qui envoyée par défaut est inappropriée pour certains clients servis par cette interface. Un autre cas commun c'est lorsqu'un alias est défini dans le but d'avoir une adresse constante pour le serveur DHCP,et que l'on désire que les clients utilisent cette adresse pour contacter le serveur DHCP. Fournir une valeur pour l'option [i]dhcp-server-identifier[/i] option est équivalent à utiliser le paramètre [i]server-identifier[/i]. [size=18] [b]RÉfÉrence: option dÉclaration[/b] [/size] Les options des déclarations DHCP sont documentées dans la page de manuel [b]dhcp-options[/b](5). [size=18] [b]Voir aussi[/b] [/size] [b]dhcpd.conf[/b](5), [b]dhcpd.leases[/b](5), RFC2132, RFC2131. [size=18] [b]Auteur[/b] [/size] [b]dhcpd[/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