dhcpd.conf

DHCPD.CONF(5)                  File Formats Manual                 DHCPD.CONF(5)



NOM
       dhcpd.conf - Fichier de configuration de dhcpd

DESCRIPTION
       Le fichier dhcpd.conf contient les paramètres de configuration pour
       dhcpd, 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é (share-network)  et de sous-réseau
       (subnet).  Si les clients d'un sous-réseau doivent recevoir dynamiquement
       leurs adresses, une  déclaration de plage (range) 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 (host).   Une déclaration de groupe (group) 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 fixed-address
       (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 fixed-address.
       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.

EXEMPLES
       Un fichier dhcpd.conf typique ressemblera à quelque chose comme ceci :

       paramètres globaux

       shared-network ISC-BIGGIE {
         paramètres spécifiques au réseau partagé...
         subnet 204.254.239.0 netmask 255.255.255.224 {
           paramètres 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 {
           paramètres 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 {
         paramètres spécifiques au sous-réseau...
         range 204.254.239.74 204.254.239.94;
       }

       group {
         paramètres spécifiques au groupe...
         host zappo.test.isc.org {
           paramètres spécifiques à l'hôte...
         }
         host beppo.test.isc.org {
           paramètres spécifiques à l'hôte...
         }
         host harpo.test.isc.org {
           paramètres spécifiques à l'hôte...
         }
       }

                                       Figure 1


       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 :

            option domain-name "isc.org";
            option domain-name-servers ns1.isc.org, ns2.isc.org;

                                       Figure 2

       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 (shared-network et subnet) peuvent avoir des
       paramètres.  Imaginons que le réseau partagé ISC-BIGGIE 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 :

            option domain-name "comptabilite.isc.org";

       Ainsi toutes les sous-réseaux déclarés dans la déclaration du réseau
       partagé ISC-BIGGIE auront  l'option de nom de domaine (domain-name) 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 :

            option routers 204.254.239.1;

       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 :

            option domain-name "test.isc.org";

       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 :
            max-lease-time 120;
            default-lease-time 120;

       Vous avez peut être remarqué que certains paramètres débutent avec le
       mot-clé option et d'autres non.  Les paramètres débutant avec le mot-clé
       option 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
       (hostname), le nom du fichier (filename) à lui envoyer ou l'adresse du
       serveur depuis lequel le fichier sera envoyé (paramètre next-server).  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 :

       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; }
       }

RÉFÉRENCE: DÉCLARATIONS
       La déclaration shared-network (réseau partagé)

        shared-network name {
          [ paramètres ]
          [ déclarations ]
        }

       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.

       name 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.

       La déclaration subnet (sous-réseau)

        subnet subnet-number netmask netmask {
          [ paramètres ]
          [ déclarations ]
        }

       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 range (plage ou intervalle
       [d'adresses]).

       L'adresse de sous-réseau subnet-number doit être une adresse IP ou un nom
       de domaine qui se résout en cette adresse IP.  Le masque de réseau
       netmask 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
       option 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.

       La déclaration range (plage [d'adresses])

        range [ dynamic-bootp ] low-address [ high-address];

       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 (low-address) et la plus grande adresse
       IP (high-address) 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 dynamic-bootp 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 (high-address) peut être omise.

       La déclaration host (hôte)

        host hostname {
          [ paramètres ]
          [ déclarations ]
        }

       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 fixed-address (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 fixed-address.  hostname est le nom identifiant l'hôte.
       Si aucune autre option hostname n'est spécifiée pour l'hôte, alors
       hostname est utilisé.

       Les déclarations d'hôtes sont comparées aux clients DHCP et BOOTP réels
       en mettant en correspondance l'option dhcp-client-identifier 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 dhcp-client-identifier, en comparant l'adresse matérielle du
       client avec le paramètre hardware de la déclaration d'hôte.  Normalement,
       les clients BOOTP ne fournissent pas d'option dhcp-client-identifier,
       aussi l'adresse matérielle doit être utilisée pour tous les clients
       utilisant le protocole BOOTP.

       La déclaration group (group)

        group {
          [ paramètres ]
          [ déclarations ]
        }

       La déclaration group 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.

RÉFÉRENCE: ALLOW et DENY
       Les déclarations allow (autoriser) et deny (interdire) peuvent être
       utilisées pour contrôler le comportement de dhcpd en fonction de la
       nature des requêtes.


       Le mot-clé unknown-clients (clients inconnus)

        allow unknown-clients;
        deny unknown-clients;

       Le mot clé unknown-clients est utilisé pour indiquer à dhcpd s'il doit
       oui ou non attribuer dynamiquement des adresses aux clients inconnus. Par
       défaut, l'attribution dynamique des adresses est autorisée pour les
       clients inconnus.

       Le mot-clé bootp

        allow bootp;
        deny bootp;

       Le mot-clé bootp 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
       autorisées.

       Le mot-clé booting

        allow booting;
        deny booting;

       Le mot-clé booting 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 autorisé, mais si il est désactivé pour un client particulier, alors
       ce client sera incapable d'obtenir une adresse depuis le serveur DHCP.

RÉFÉRENCE: PARAMÈTRES
       Le paramètre default-lease-time

        default-lease-time time;

       time spécifie la durée en secondes de la concession attribuée à un client
       qui n'a pas demandé une durée spécifique.

       Le paramètre max-lease-time

        max-lease-time time;

       time spécifie la durée maximale en secondes de la concession attribuée à
       un client qui a demandé une durée spécifique.

       Le paramètre hardware

        hardware hardware-type hardware-address;

       Dans le but de reconnaître un client BOOTP, son adresse matérielle doit
       être déclarée en utilisant la clause hardware dans la déclaration d'hôte.
       hardware-type doit être le nom d'un type d'interface matérielle.
       Actuellement seuls les types, ethernet et token-ring sont reconnus, bien
       que le support pour d'autres types d'interfaces matérielles telles que
       fddi soit souhaitable.  L'adresse matérielle (hardware-address) 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 hardware
       peut aussi être utilisé pour les clients DHCP.

       Le paramètre filename (nom de fichier)

        filename "filename";

       Le paramètre filename 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.

       Le paramètre server-name (nom de serveur)

        server-name "name";

       Le paramètre server-name est utilisé pour indiquer aux clients le nom du
       serveur depuis lequel ils sont en train de démarrer.  name sera le nom
       fourni au client.

       Le paramètre next-server (prochain serveur)

        next-server server-name;

       Le paramètre next-server 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 filename) sera chargé.  server-name doit être une adresse IP
       numérique ou un nom de domaine.  Si aucun paramètre next-server ne
       s'applique à un client donné, l'adresse du serveur DHCP est utilisée.

       Le paramètre fixed-address (adresse fixe)

        fixed-address address [, address ... ];

       Le paramètre fixed-address 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 fixed-address 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.  address est  une adresse IP numérique ou un nom de domaine qui
       se résout en une ou plusieurs adresses IP.

       Le paramètre dynamic-bootp-lease-cutoff (coupure des concessions bootp
       dynamiques)

        dynamic-bootp-lease-cutoff date;

       Le paramètre dynamic-bootp-lease-cutoff 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.

       date devrait être la date à laquelle toutes les concessions BOOTP
       attribuées devront être interrompues. La date est spécifiée dans le
       format suivant

                                 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.

       Le paramètre dynamic-bootp-lease-length (durée des concessions BOOTP
       dynamiques)

        dynamic-bootp-lease-length length;

       Le paramètre dynamic-bootp-lease-length 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
       length 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
       à length, 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.

       Le paramètre get-lease-hostnames

        get-lease-hostnames flag; (trouver le nom des concessionnaires)

       Le paramètre get-lease-hostnames 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 hostname de DHCP.  Si flag est positionné à true (vrai),
       alors cette recherche sera faite pour toutes les adresses dans le
       contexte actuel. Par défaut, la valeur est positionnée à false (faux), et
       aucune recherche n'est faite.

       Le paramètre use-host-decl-names (utiliser le nom de la déclaration
       d'hôte comme nom d'hôte)

        use-host-decl-names flag;

       Si le paramètre use-host-decl-names 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

           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";
             }

       Une instruction option host-name au sein d'une déclaration d'hôte
       remplacera l'utilisation du nom dans la déclaration d'hôte.

       La clause authoritative

        authoritative;

        not 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 not authoritative
       devrait être écrite dans le bloc approprié dans le fichier de
       configuration.

       Habituellement, écrire not 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.

       Le paramètre use-lease-addr-for-default-route (utiliser l'adresse de
       concession comme route par défaut)

        use-lease-addr-for-default-route flag;

       Si le paramètre use-lease-addr-for-default-route 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 use-lease-addr-for-default-route est activé et que l'option router et
       aussi dans le même bloc, l'option router 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.

       Le paramètre always-reply-rfc1048 (toujours répondre en rfc1048)

        always-reply-rfc1048 flag;

       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 always-reply-rfc1048 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.

       Le paramètre server-identifier identificateur du serveur

        server-identifier hostname;

       Le paramètre server-identifier 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 doit ê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 server-identifier  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 server-identifier 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 dhcp-server-identifier option est
       équivalent à utiliser le paramètre server-identifier.

RÉFÉRENCE: OPTION DÉCLARATION
       Les options des déclarations DHCP sont documentées dans la page de manuel
       dhcp-options(5).

VOIR AUSSI
       dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.

AUTEUR
       dhcpd(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 http://www.isc.org/isc.

TRADUCTION
       Sébastien Blanchet, 2001



                                                                   DHCPD.CONF(5)