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.
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.
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.
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.
host haagen {
hardware ethernet 08:00:2b:4c:59:23;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
}
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).