dhcpd

DHCPD(8)                     System Manager's Manual                    DHCPD(8)



NOM
       dhcpd - Dynamic Host Configuration Protocol Server

SYNOPSIS
       dhcpd [ -p port ] [ -f ] [ -d ] [ -q ] [ -cf config-file ] [ -lf lease-
       file ] [ if0 [ ...ifN ] ]

DESCRIPTION
       Le serveur DHCP de l'Internet Software Consortium, dhcpd, implémente le
       protocole DHCP (Dynamic Host Configuration Protocol), protocole de
       configuration dynamique des hôtes et le protocole de démarrage par
       internet (BOOTP). DHCP permet à des hôtes appartenant à un réseau TCP/IP
       de demander et d'obtenir l'affectation d'adresses IP, mais aussi de
       découvrir les informations relatives au réseau auquel ils sont rattachés.
       BOOTP fournit des fonctionnalités similaires, mais avec quelques
       restrictions.

OPERATION
       Le protocole DHCP permet  à un hôte, qui est inconnu de l'administrateur
       réseau, d'obtenir l'affectation d'une nouvelle adresse IP parmi un
       ensemble d'adresses pour ce réseau. Pour ce faire, l'administrateur du
       réseau alloue un ensemble d'adresses dans chaque sous-réseau et les
       déclare dans le fichier dhcpd.conf(5).

       Au démarrage, dhcpd lit le fichier dhcpd.conf et stocke en mémoire la
       liste des adresses disponibles dans chaque sous-réseau.  Lorsqu'un client
       demande une adresse en utilisant le protocole DHCP, dhcpd lui en attribue
       une. Chaque client reçoit son adresse en concession : la concession
       expire au bout d'une durée choisie par l'administrateur (par défaut, une
       journée). Les clients qui ont reçu une adresse sont supposés renouveler
       la concession avant expiration, pour pouvoir continuer à l'utiliser.  Une
       fois que la durée de la concession s'est écoulée, le client titulaire
       n'est plus autorisé à utiliser l'adresse IP qu'il avait reçue.

       Pour garder la trace des concessions accordées en dépit des redémarrages
       du serveur, dhcpd inscrit la liste des concessions attribuées dans le
       fichier dhcpd.lease(5). Avant d'accorder une concession à un hôte, dhcpd
       enregistre l'attribution dans ce fichier et s'assure que le contenu du
       fichier est recopié sur le disque. Ceci permet d'être sûr que, même dans
       le cas d'un crash système, dhcpd n'oubliera rien d'une concession qui a
       été accordée. Au démarrage, après avoir lu le fichier dhcpd.conf, dhcpd
       lit le fichier dhcpd.leases pour mettre à jour sa mémoire à propos des
       concessions qui ont été accordées.

       Les nouvelles concessions sont ajoutées à la fin du fichier dhcpd.leases.
       Pour éviter que le fichier ne devienne trop gros, de temps en temps dhcpd
       crée un nouveau fichier dhcpd.lease à partir de sa base de données
       interne des concessions. Une fois que ce fichier a été écrit sur le
       disque, l'ancien fichier est renommé dhcpd.leases~ , et le nouveau
       fichier est renommé dhcpd.leases. Si le système s'arrête au milieu de
       cette opération, quel que soit le fichier dhcpd.leases qui reste, il
       contient toutes les informations sur les concessions, c'est pourquoi une
       procédure spéciale de récupération après incident n'est pas nécessaire.

       Ce serveur fournit également le support pour BOOTP.  Contrairement à
       DHCP, le protocole BOOTP ne comprend pas de mécanisme pour récupérer les
       adresses attribuées dynamiquement une fois qu'elles ne sont plus
       utilisées.  Il est encore possible d'assigner dynamiquement des adresses
       aux clients BOOTP, mais des procédures administratives sont nécessaires
       pour récupérer les adresses.  Par défaut, les clients BOOTP reçoivent des
       concessions à perpétuité, bien que l'administrateur du réseau puisse
       fixer une date d'expiration ou une durée plus courte pour les concessions
       BOOTP, si besoin est.

       Les clients BOOTP peuvent également être servis de l'ancienne manière,
       qui consiste tout simplement en une déclaration dans le fichier
       dhcpd.conf pour chacun des clients BOOTP, l'adresse étant assignée de
       manière permanente à chaque client.

       Quels que soient les changements opérés sur le fichier dhcpd.conf, dhcpd
       doit être redémarré. Pour redémarrer dhcpd, envoyez un signal SIGTERM
       (signal 15) au numéro de processus indiqué dans le fichier
       /var/run/dhcpd.pid, puis relancez dhcpd. Comme la base de données du
       serveur DHCP n'est pas aussi légère que celle de BOOTP, dhcpd ne
       redémarre pas automatiquement lorsqu'il détecte un changement dans le
       fichier dhcpd.conf.

       Remarque : Nous recevons beaucoup de plaintes à ce sujet. Nous sommes
       conscient que ce serait formidable s'il suffisait d'envoyer le signal
       SIGHUP au serveur, pour qu'il recharge la base de donnée. Ce n'est pas
       techniquement impossible mais cela nécessiterait beaucoup de travail pour
       fonctionner. Malheureusement nos ressources sont vraiment très limitées
       et nous préférons les utiliser ailleurs pour le mieux.  Aussi, nous vous
       prions de ne pas vous plaindre sur la liste de diffusion électronique à
       moins que vous ne soyez prêt à financer un projet pour implémenter cette
       caractéristique, ou que vous soyez prêt à le faire par vous-même.

LIGNE DE COMMANDE
       Les noms des interfaces réseaux sur lesquelles dhcpd doit écouter les
       diffusions peuvent être spécifiés sur la ligne de commande.  Cela devrait
       être fait sur les systèmes où dhcpd est incapable d'identifier les
       interfaces non diffusantes, mais n'est pas nécessaire sur les autres
       systèmes. Si aucun nom d'interface n'est spécifié sur la ligne de
       commande, dhcpd identifiera toutes les interfaces réseaux qui sont
       actives, en éliminant si possible les interfaces non-diffusantes, et
       écoutera les diffusions DHCP sur chacune.

       Si dhcpd doit écouter sur un autre port que le port standard (port 67),
       il faut utiliser l'option -p suivi du numéro de port udp, sur lequel
       dhcpd doit écouter. C'est principalement utile dans un but de mise au
       point.  Si l'option -p est spécifiée, le serveur transmettra les réponses
       aux clients sur le numéro de port immédiatement supérieur à celui
       spécifié - i.e., si vous spécifiez -p 67, alors le serveur écoutera sur
       le port 67  et répondra sur le port 68.  Les datagrammes qui doivent
       traverser des agents relais sont envoyés sur le numéro de port spécifié
       par l'option -p - si vous désirez utiliser d'autre numéro de port, vous
       devez configurer tous les agents relais utilisés pour qu'ils utilisent le
       même numéro de port.

       Pour lancer dhcpd en tant que processus d'avant-plan, plutôt que de le
       laisser fonctionner en tant que démon en tâche de fond, il faut spécifier
       l'option -f.  C'est utile pour lancer dhcpd au sein d'un debugger, ou
       lorsqu'il fonctionne en dehors du contexte de l'inittab sur les systèmes
       System V.

       Pour que dhcpd écrive ses logs sur la sortie d'erreur standard, spécifiez
       l'option -d.  Cela peut être utile pour la mise au point, mais aussi pour
       les sites où tous les logs d'activités de dhcp doivent être conservés,
       mais avec un syslogd qui n'est pas fiable ou qui ne peut pas être
       utilisé.  Normalement, dhcpd écrit tous ses sorties logs en utilisant la
       fonction syslog(3) avec le paramètre « facility » positionné à
       LOG_DAEMON.

       Dhcpd peut utiliser un autre fichier de configuration en utilisant
       l'option -cf, ou un autre fichier de concessions avec l'option -lf. En
       raison de l'importance d'utiliser toujours le même fichier de concession
       lorsque dhcpd fonctionne en production, ces options devraient être
       réservé uniquement à des fins de test des fichiers de concessions ou de
       base de données dans un environnement de non-production.

       Lorsque dchpd est lancé depuis un script de démarrage système (par ex.,
       /etc/rc), l'impression intégrale du message de copyright au lancement
       peut être indésirable.  Pour éviter ce message l'option -q peut être
       spécifiée.

CONFIGURATION
       La syntaxe du fichier dhcpd.conf(5) fait l'objet d'une discussion
       séparée.  Cette section peut être utile pour avoir une vue d'ensemble du
       processus de configuration, et la documentation de dhcpd.conf(5) devrait
       être utilisée pour obtenir  des informations de références détaillées.

Sous-réseaux
       dhcpd a besoin de connaître les adresses et les masques de sous-réseaux
       de tous les sous-réseaux qui ont besoin de son service. D'autre part,
       dans le but d'allouer dynamiquement les adresses sur chaque sous-réseau,
       une ou plusieurs plages d'adresses doivent être attribuées dans chaque
       sous-réseau avant d'être ensuite assignées aux hôtes clients.  Une
       configuration très simple fournissant le support DHCP ressemblera à ceci
       :

            subnet 239.252.197.0 netmask 255.255.255.0 {
              range 239.252.197.10 239.252.197.250;
            }

       Plusieurs plages d'adresses peuvent être spécifiées comme ceci :

            subnet 239.252.197.0 netmask 255.255.255.0 {
              range 239.252.197.10 239.252.197.107;
              range 239.252.197.113 239.252.197.250;
            }

       Si un sous-réseau  ne désire que les services de BOOTP et pas
       d'attribution dynamique des adresses, la clause « `range »  peut être
       laissée entièrement vide, mais la commande « subnet » doit apparaître.

Durée des concessions
       La durée des concessions DHCP peuvent être fixée à n'importe quelle
       valeur, de zéro secondes à l'infini. Quelle durée de concession à du sens
       pour un sous-réseau donné, ou pour une installation donnée ? Cela dépend
       du type d'hôtes qui seront servis.

       Par exemple, dans un environnement de bureau, où les systèmes sont
       ajoutés et retirés de temps en temps, mais relativement peu fréquemment,
       une concession d'un mois ou plus peut avoir un sens.  Dans un
       environnement de test final d'un processus de fabrication, une durée de
       concession de 30 minutes maximum peut avoir du sens - assez de temps pour
       réaliser une procédure de test sur un équipement réseau avant de
       l'emballer pour le livrer.

       Il est possible de spécifier 2 durées de concession : la durée par défaut
       qui sera donnée si un client ne demande pas de durée particulière, et une
       durée maximale. Elles sont spécifiée en tant que clauses dans la commande
       `subnet' :

            subnet 239.252.197.0 netmask 255.255.255.0 {
              range 239.252.197.10 239.252.197.107;
              default-lease-time 600;
              max-lease-time 7200;
            }

       Cette déclaration de sous-réseau spécifie une durée de concession de 600
       secondes (dix minutes), et une durée maximale de 7200 secondes (deux
       heures). D'autres valeurs courantes seront 86400 (un jour), 604800 (une
       semaine), 2592000 (30 jours).

       Chaque sous-réseau n'a pas besoin d'avoir la même durée de concession
       —dans le cas d'un environnement de bureau et de fabrication servis par le
       même serveur DHCP, ça peut avoir un sens d'avoir des valeurs très
       disparates pour les durées de concession par défaut et maximale sur
       chaque sous-réseau.

Support BOOTP
       Chaque client BOOTP doit être explicitement déclaré dans le fichier
       dhcpd.conf.  Une déclaration basique de client spécifiera l'adresse
       matérielle de l'interface réseau du client et l'adresse IP à lui
       assigner.  Si un client a besoin de charger un fichier de démarrage
       depuis le serveur, le nom de ce fichier doit être spécifié. Une
       déclaration simple d'un client BOOTP ressemblera à ceci :

            host haagen {
              hardware ethernet 08:00:2b:4c:59:23;
              fixed-address 239.252.197.9;
              filename "/tftpboot/haagen.boot";
            }

Options
       DHCP (et aussi BOOTP avec des extensions du fabricant) fournit un
       mécanisme par lequel le serveur peut fournir à un client les informations
       pour configurer son interface réseau (par ex., le masque de sous-réseau),
       et aussi les informations pour accéder aux différents services du réseaux
       (par ex., DNS, routeur IP, et autres).

       Ces options peuvent être spécifiées pour chaque sous-réseau et
       individuellement pour les clients BOOTP. Dans le cas où la déclaration
       des options d'un client BOOTP entre en concurrence avec celles du sous-
       réseau, les paramètres du client sont prioritaires.  Une configuration
       DHCP, raisonnablement complète, ressemblera à quelque chose comme ceci :

            subnet 239.252.197.0 netmask 255.255.255.0 {
              range 239.252.197.10 239.252.197.250;
              default-lease-time 600 max-lease-time 7200;
              option subnet-mask 255.255.255.0;
              option broadcast-address 239.252.197.255;
              option routers 239.252.197.1;
              option domain-name-servers 239.252.197.2, 239.252.197.3;
              option domain-name "isc.org";
            }

       Un hôte BOOTP appartenant à un sous-réseau mais qui à besoin d'être dans
       un domaine différent et d'utiliser un serveur de nom différent pourra
       être déclaré comme suit :

            host haagen {
              hardware ethernet 08:00:2b:4c:59:23;
              fixed-address 239.252.197.9;
              filename "/tftpboot/haagen.boot";
              option domain-name-servers 192.5.5.1;
              option domain-name "vix.com";
            }

       Une description plus complète de la syntaxe du fichier dhcpd.conf se
       trouve dans la page de manuel dhcpd.conf(5).

FICHIERS
       /etc/dhcpd.conf, /var/lib/dhcp     /dhcpd.leases, /var/run/dhcpd.pid,
       /var/lib/dhcp  /dhcpd.leases~.

VOIR AUSSI
       dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5)

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(8)