dhcpd.conf(5)
NOM
dhcpd.conf - fichier de configuration de dhcpd
DESCRIPTION
Le fichier dhcpd.conf contient la configuration de dhcpd, le Serveur DHCP du Consortium de Logiciels Internet. C'est un fichier texte ASCII de forme libre. Il est analysé de façon récursive descendante par dhcpd. Il peut contenir des tabulations ou des espaces supplémentaires afin de clarifier sa présentation. Les mot-clés sont sensibles à la casse majuscule ou minuscule. Les commentaires peuvent se trouver n'importe où dans le fichier (à part entre guillements), ils commencent par un "#" et finissent avec la ligne. Ce fichier consiste essentiellement en une liste d'annonces de deux grandes catégories : les paramètres et les déclarations. Les paramètres disent soit comment faire quelque chose (par exemple, quelle durée de bail céder), soit s'il faut faire quelque chose (par exemple, peut-on fournir une adresse à un client inconnu), soit quel paramètre fournir au client (par exemple, utiliser la passerelle 220.177.244.7). Les déclarations sont utilisées pour décrire la topologie du réseau, décrire les clients du réseau, indiquer les adresses à fournir ou appliquer un groupe de paramètres à un groupe de déclarations. Dans tout groupe de paramètres et déclarations, les paramètres doivent être indiqués avant les déclarations qui en dépendent. Les déclarations concernant la topologie du réseau incluent shared-network et subnet. Si des client d'un sous-réseau doivent recevoir des adresses dynamiquement, une plage (range) d'adresses doit apparaitre dans la déclaration du sous-réseau. Pour les clients ayant des adresses statiques ou dans le cas d'une installation ne comportant que des clients connus, une déclaration host (hôte) doit être indiquée pour chacun d'eux. Si des paramètres doivent s'appliquer à un groupe de déclarations sans stricte relation avec un sous-réseau, le group peut être utilisé. Pour chaque sous-réseau à servir et pour chaque sous-réseau auquel est connecté dhcpd, doit exister une déclaration subnet qui dit à dhcpd comment savoir quelle adresse appartient à quel sous-réseau. Une telle déclaration est nécessaire même pour les sous réseaux n'ayant pas d'allocation dynamique d'adresses. Certaines installations réseaux sont constituées de plusieurs sous-réseaux IP. Par exemple, si un site a besoin de masques sous-réseau de 8 bits mais qu'un département avec un unique réseau ethernet physique s'étend sur plus de 254 noeuds, il peut être nécessaire de mettre en place deux sous-réseaux 8 bits sur le même ethernet comme s'il y en avait deux. Dans ce cas, la déclaration subnet de ces deux réseaux doit être incluses dans une déclaration shared-network. Certains sites ont des départements dont les clients sont sur plus d'un sous-réseau et il serait pratique que leurs paramètres soient uniformes mais différents de ce qui pourrait être prévu pour des clients d'autres départements sur le même sous-réseau. Pour les clients spécifiquement déclarés avec l'option host, ces déclarations peuvent être regroupées dans un group possédant les paramètres communs à ce département. Pour ceux qui doivent recevoir une adresse dynamique, il n'y a actuellement aucun moyen de regrouper ces paramètres autrement que par la topologie réseau. Lorsqu'un client s'apprête à démarrer, ses paramètres sont déterminés en consultant d'abord la déclaration host (si elle existe) puis la déclaration group (si elle existe) qui comprend la déclaration host puis la déclaration subnet du sous-réseau accueillant le client, puis la déclaration shared-network (si elle existe) contenant le sous-réseau et enfin les paramètres de haut niveau qui peuvent être indiqués indépendament de toute déclaration. Lorsque dhcpd recherche la déclaration host d'un client, il commence par en regarder une qui possède une adresse fixe (fixed-address) correspondant au sous-réseau ou au réseau partagé du client. S'il n'en trouve pas, il en cherche une sans adresse fixe. S'il n'en trouve toujours pas, dhcpd fait alors comme s'il n'y avait aucune référence à ce client dans le fichier dhcpd.conf même si l'entrée se trouve dans un autre sous-réseau ou réseau partagé.
Le fichier dhcpd.conf contient la configuration de dhcpd, le Serveur DHCP du Consortium de Logiciels Internet.
C'est un fichier texte ASCII de forme libre. Il est analysé de façon récursive descendante par dhcpd. Il peut contenir des tabulations ou des espaces supplémentaires afin de clarifier sa présentation. Les mot-clés sont sensibles à la casse majuscule ou minuscule. Les commentaires peuvent se trouver n'importe où dans le fichier (à part entre guillements), ils commencent par un "#" et finissent avec la ligne.
Ce fichier consiste essentiellement en une liste d'annonces de deux grandes catégories : les paramètres et les déclarations.
Les paramètres disent soit comment faire quelque chose (par exemple, quelle durée de bail céder), soit s'il faut faire quelque chose (par exemple, peut-on fournir une adresse à un client inconnu), soit quel paramètre fournir au client (par exemple, utiliser la passerelle 220.177.244.7).
Les déclarations sont utilisées pour décrire la topologie du réseau, décrire les clients du réseau, indiquer les adresses à fournir ou appliquer un groupe de paramètres à un groupe de déclarations. Dans tout groupe de paramètres et déclarations, les paramètres doivent être indiqués avant les déclarations qui en dépendent.
Les déclarations concernant la topologie du réseau incluent shared-network et subnet. Si des client d'un sous-réseau doivent recevoir des adresses dynamiquement, une plage (range) d'adresses doit apparaitre dans la déclaration du sous-réseau. Pour les clients ayant des adresses statiques ou dans le cas d'une installation ne comportant que des clients connus, une déclaration host (hôte) doit être indiquée pour chacun d'eux. Si des paramètres doivent s'appliquer à un groupe de déclarations sans stricte relation avec un sous-réseau, le group peut être utilisé.
Pour chaque sous-réseau à servir et pour chaque sous-réseau auquel est connecté dhcpd, doit exister une déclaration subnet qui dit à dhcpd comment savoir quelle adresse appartient à quel sous-réseau. Une telle déclaration est nécessaire même pour les sous réseaux n'ayant pas d'allocation dynamique d'adresses.
Certaines installations réseaux sont constituées de plusieurs sous-réseaux IP. Par exemple, si un site a besoin de masques sous-réseau de 8 bits mais qu'un département avec un unique réseau ethernet physique s'étend sur plus de 254 noeuds, il peut être nécessaire de mettre en place deux sous-réseaux 8 bits sur le même ethernet comme s'il y en avait deux. Dans ce cas, la déclaration subnet de ces deux réseaux doit être incluses dans une déclaration shared-network.
Certains sites ont des départements dont les clients sont sur plus d'un sous-réseau et il serait pratique que leurs paramètres soient uniformes mais différents de ce qui pourrait être prévu pour des clients d'autres départements sur le même sous-réseau. Pour les clients spécifiquement déclarés avec l'option host, ces déclarations peuvent être regroupées dans un group possédant les paramètres communs à ce département. Pour ceux qui doivent recevoir une adresse dynamique, il n'y a actuellement aucun moyen de regrouper ces paramètres autrement que par la topologie réseau.
Lorsqu'un client s'apprête à démarrer, ses paramètres sont déterminés en consultant d'abord la déclaration host (si elle existe) puis la déclaration group (si elle existe) qui comprend la déclaration host puis la déclaration subnet du sous-réseau accueillant le client, puis la déclaration shared-network (si elle existe) contenant le sous-réseau et enfin les paramètres de haut niveau qui peuvent être indiqués indépendament de toute déclaration.
Lorsque dhcpd recherche la déclaration host d'un client, il commence par en regarder une qui possède une adresse fixe (fixed-address) correspondant au sous-réseau ou au réseau partagé du client. S'il n'en trouve pas, il en cherche une sans adresse fixe. S'il n'en trouve toujours pas, dhcpd fait alors comme s'il n'y avait aucune référence à ce client dans le fichier dhcpd.conf même si l'entrée se trouve dans un autre sous-réseau ou réseau partagé.
EXEMPLES
Voici un exemple de fichier dhcpd.conf classique :
paramètres globaux... shared-network ISC-BIGGIE { paramètres du réseau-partagé... subnet 204.254.239.0 netmask 255.255.255.224 { paramètres du sous-réseau... range 204.254.239.10 204.254.239.30; } subnet 204.254.239.32 netmask 255.255.255.224 { paramètres du sous-réseau... range 204.254.239.42 204.254.239.62; } } subnet 204.254.239.64 netmask 255.255.255.224 { paramètres du sous-réseau... range 204.254.239.74 204.254.239.94; }
paramètres globaux... shared-network ISC-BIGGIE {
paramètres du réseau-partagé... subnet 204.254.239.0 netmask 255.255.255.224 { paramètres du sous-réseau... range 204.254.239.10 204.254.239.30; } subnet 204.254.239.32 netmask 255.255.255.224 { paramètres du sous-réseau... range 204.254.239.42 204.254.239.62; }
paramètres du réseau-partagé... subnet 204.254.239.0 netmask 255.255.255.224 {
paramètres du sous-réseau... range 204.254.239.10 204.254.239.30;
} subnet 204.254.239.32 netmask 255.255.255.224 {
paramètres du sous-réseau... range 204.254.239.42 204.254.239.62;
}
} subnet 204.254.239.64 netmask 255.255.255.224 {
paramètres du sous-réseau... range 204.254.239.74 204.254.239.94;
group { paramètres du groupe... host zappo.test.isc.org { paramètres de l'hôte... } host beppo.test.isc.org { paramètres de l'hôte... } host harpo.test.isc.org { paramètres de l'hôte... } } Figure 1 Notez, au début du fichier, la place des paramètres globaux. Ce peut être des informations telles que le nom de domaine, l'adresse des serveurs de noms (s'ils sont communs à toute l'organisation), etc... Par exemple :
group {
paramètres du groupe... host zappo.test.isc.org { paramètres de l'hôte... } host beppo.test.isc.org { paramètres de l'hôte... } host harpo.test.isc.org { paramètres de l'hôte... }
paramètres du groupe... host zappo.test.isc.org {
paramètres de l'hôte...
} host beppo.test.isc.org {
} host harpo.test.isc.org {
Figure 1
Notez, au début du fichier, la place des paramètres globaux. Ce peut être des informations telles que le nom de domaine, l'adresse des serveurs de noms (s'ils sont communs à toute l'organisation), etc... 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 déclarer les paramètres sous forme de noms plutôt que sous forme d'adresses IP numériques. Si un nom d'hôte correspond à plusieurs adresses IP (par exemple s'il a deux interfaces réseau), toutes sont fournies au client. Dans la figure 1, vous pouvez voir que les déclarations du réseau partagé et du sous-réseau peuvent avoir leurs propres paramètres. Le réseau partagé ISC-BIGGIE gère un département complet (peut-être celui des comptes). Si la comptabilité a son propre domaine, un paramètrage spécifique du réseau partagé pourrait être :
Figure 2
Comme vous pouvez le voir dans la figure 2, il est possible de déclarer les paramètres sous forme de noms plutôt que sous forme d'adresses IP numériques. Si un nom d'hôte correspond à plusieurs adresses IP (par exemple s'il a deux interfaces réseau), toutes sont fournies au client.
Dans la figure 1, vous pouvez voir que les déclarations du réseau partagé et du sous-réseau peuvent avoir leurs propres paramètres. Le réseau partagé ISC-BIGGIE gère un département complet (peut-être celui des comptes). Si la comptabilité a son propre domaine, un paramètrage spécifique du réseau partagé pourrait être :
option domain-name "compta.isc.org"; Tous les sous-réseaux du réseau partagé auront alors l'option domain-name à "compta.isc.org" au lieu de "isc.org". La raison la plus évidente pour laquelle le sous-réseau peut avoir ses propres paramètres, comme dans la figure 1, est que chaque sous-réseau a nécessairement son routeur. Donc pour le premier sous-réseau, on peut, par exemple, trouver :
option domain-name "compta.isc.org";
Tous les sous-réseaux du réseau partagé auront alors l'option domain-name à "compta.isc.org" au lieu de "isc.org". La raison la plus évidente pour laquelle le sous-réseau peut avoir ses propres paramètres, comme dans la figure 1, est que chaque sous-réseau a nécessairement son routeur. Donc pour le premier sous-réseau, on peut, par exemple, trouver :
option routers 204.254.239.1; Notez que l'adresse est ici sous forme numérique. Ce n'est pas obligatoire : si vous avez des domaines différents sur chaque interface de votre routeur, il est légitime d'utiliser le nom de domaine de l'interface plutôt que son adresse numérique. Il est cependant assez courrant que les adresses IP du routeur appartiennent au même domaine, obligeant l'utilisation de l'adresse numérique. La figure 1 présente aussi une déclaration group qui fournit les paramètres communs à trois hôtes (zappo, beppo et harpo). Comme vous pouvez le voir, ils sont tout les trois dans le domaine test.isc.org et il est donc logique de mettre ce paramètre pour le groupe : option domain-name "test.isc.org"; De plus, d'après le nom de domaine, ces machines sont certainement destinées à des tests. Si nous voulions mettre à l'épreuve le système de bail de DHCP, il est sans doute intéressant que la durée cédée soit plus courte que celle par défaut : max-lease-time 120; default-lease-time 120; Vous avez dû remarquer que certains paramètres commencent par le mot option et d'autres pas. Ceux qui commencent avec option sont de véritables options DHCP alors que les autres, soit déterminent le comportement du serveur DHCP (par exemple la durée de bail à céder), soit spécifie des paramètres non optionnels du protocol DHCP (par exemple, le nom du serveur et le nom du fichier). Dans la figure 1, chaque hôte possède ses propres paramètres. Ceux-ci peuvent être l'option hostname (nom d'hôte), le nom du fichier à charger (filename) et l'adresse du serveur sur lequel charger le fichier (next-server). En général, les paramètres peuvent apparaitre à n'importe quel endroit où ils sont autorisés et ils s'appliqueront où il faut par rapport à leur place. Imaginons que nous ayons un site muni d'une bonne quantité de terminaux X NCD. Ce sont des modèles différents et nous voulons utiliser un fichier différent pour chaque modèle. Une des façons de faire est de déclarer les hôte pour chaque serveur et de les grouper par modèles : 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; } }
option routers 204.254.239.1;
Notez que l'adresse est ici sous forme numérique. Ce n'est pas obligatoire : si vous avez des domaines différents sur chaque interface de votre routeur, il est légitime d'utiliser le nom de domaine de l'interface plutôt que son adresse numérique. Il est cependant assez courrant que les adresses IP du routeur appartiennent au même domaine, obligeant l'utilisation de l'adresse numérique.
La figure 1 présente aussi une déclaration group qui fournit les paramètres communs à trois hôtes (zappo, beppo et harpo). Comme vous pouvez le voir, ils sont tout les trois dans le domaine test.isc.org et il est donc logique de mettre ce paramètre pour le groupe :
option domain-name "test.isc.org";
De plus, d'après le nom de domaine, ces machines sont certainement destinées à des tests. Si nous voulions mettre à l'épreuve le système de bail de DHCP, il est sans doute intéressant que la durée cédée soit plus courte que celle par défaut :
max-lease-time 120; default-lease-time 120;
Vous avez dû remarquer que certains paramètres commencent par le mot option et d'autres pas. Ceux qui commencent avec option sont de véritables options DHCP alors que les autres, soit déterminent le comportement du serveur DHCP (par exemple la durée de bail à céder), soit spécifie des paramètres non optionnels du protocol DHCP (par exemple, le nom du serveur et le nom du fichier).
Dans la figure 1, chaque hôte possède ses propres paramètres. Ceux-ci peuvent être l'option hostname (nom d'hôte), le nom du fichier à charger (filename) et l'adresse du serveur sur lequel charger le fichier (next-server). En général, les paramètres peuvent apparaitre à n'importe quel endroit où ils sont autorisés et ils s'appliqueront où il faut par rapport à leur place.
Imaginons que nous ayons un site muni d'une bonne quantité de terminaux X NCD. Ce sont des modèles différents et nous voulons utiliser un fichier différent pour chaque modèle. Une des façons de faire est de déclarer les hôte pour chaque serveur et de les grouper par modèles :
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; } }
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; } }
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 nom { [ paramètres ] [ déclarations ] } La déclaration shared-network indique au serveur DHCP que des sous réseaux IP partagent le même réseau physique. Tous les sous-réseaux du réseau partagé doivent être indiqués dans cette déclaration. Les paramètres seront utilisés lors du démarrage du client à moins qu'ils ne soient remplacés par ceux des déclarations du sous-réseau ou de l'hôte. Si des sous-réseau disposent d'adresses à allouer dynamiquement, celles-ci sont rassemblées dans un pot commun et distribuées aux clients du réseau partagé, à la demande. Il n'y a pas de moyen de savoir sur quel sous-réseau du réseau partagé démarre le client. Le nom est celui du réseau partagé. Il est utilisé à l'affichage des messages de débogage, donc il doit être aussi descriptif que possible. Il doit avoir la même syntaxe que les noms de domaines (même s'il n'est jamais utilisé en tant que tel) ou bien sous forme libre entre guillemets. La déclaration subnet (sous-réseau)
shared-network nom { [ paramètres ] [ déclarations ] }
shared-network nom {
[ paramètres ] [ déclarations ]
La déclaration shared-network indique au serveur DHCP que des sous réseaux IP partagent le même réseau physique. Tous les sous-réseaux du réseau partagé doivent être indiqués dans cette déclaration. Les paramètres seront utilisés lors du démarrage du client à moins qu'ils ne soient remplacés par ceux des déclarations du sous-réseau ou de l'hôte. Si des sous-réseau disposent d'adresses à allouer dynamiquement, celles-ci sont rassemblées dans un pot commun et distribuées aux clients du réseau partagé, à la demande. Il n'y a pas de moyen de savoir sur quel sous-réseau du réseau partagé démarre le client.
Le nom est celui du réseau partagé. Il est utilisé à l'affichage des messages de débogage, donc il doit être aussi descriptif que possible. Il doit avoir la même syntaxe que les noms de domaines (même s'il n'est jamais utilisé en tant que tel) ou bien sous forme libre entre guillemets.
La déclaration subnet (sous-réseau)
subnet numéro netmask masque { [ paramètres ] [ déclarations ] } La déclaration subnet sert à dhcpd à avoir suffisament d'informations pour déterminer si une adresse IP est ou pas sur un réseau. Elle peut aussi être utilisée pour indiquer des paramètres propres au sous-réseau ainsi que des adresses à allouer dynamiquement aux clients qui démarrent dessus. Ces adresses sont spécifiées à l'aide de la déclaration range. Le numéro est une adresse IP ou un nom qui correspond au sous-réseau en cours de description. De même, le masque est soit une adresse IP soit un nom qui correspond au sous-réseau en cours de description. Le numéro de sous-réseau associé au masque est suffisant pour déterminer si une adresse IP appartient au sous-réseau. Bien que le masque doive être donné avec chaque déclaration, il est recommandé d'utiliser une option subnet-mask pour chaque sous-réseau car elle remplace le masque indiqué dans la déclaration du sous-réseau. Dans le cas où les masques sous-réseau d'un site sont amenés à changer, il est préférable d'utiliser une option subnet-mask (voir dhcp-options(5)) pour chaque sous-réseau plutôt que de l'indiquer ici dans chaque déclaration puisque les valeurs de cette option remplacent celles de la déclaration. La déclaration range (plage d'adresses) range [ dynamic-bootp ] adresse-mini [ adresse-maxi]; Il doit exister au moins une plage d'adresses pour les réseaux à adressage dynamique. La déclaration indique la plus petite et la plus grande adresse IP de la plage. Toutes celles-ci doivent appartenir au sous-réseau dans lequel elles sont déclarées. L'option dynamic-bootp peut être indiquée dans le cas où les adresses dynamiques correspondent indifféremment aux clients BOOTP ou DHCP. Si la déclaration ne contient qu'une seule adresse, celle maximum peut être omise. La déclaration host (Hôte) host nom d'hôte { [ paramètres ] [ déclarations ] } Il doit exister au moins une déclaration host pour chaque client BOOTP à servir. De même pour les clients DHCP bien que ça ne soit pas obligatoire tant que le démarage n'est autorisé que pour les hôtes connus. Si vous voulez autoriser un client DHCP ou BOOTP à démarrer sur plus d'un sous-réseau avec des adresses fixes, plus d'une adresse peuvent être inscrites dans le paramètre fixed-address ou bien plus d'une déclaration host peuvent être spécifiées. Si des paramètres spécifiques au client ont à changer suite à des modifications sur le réseau, plusieurs déclarations host peuvent alors être utilisées. Si un client est amené à démarrer avec une adresse fixe si possible et dynamique sinon, une déclaration host doit être spécifiée sans la clause fixed-address. Le nom d'hôte est celui qui identifie l'hôte. S'il n'y a pas d'option hostname, c'est celui-ci qui est utilisé. Une déclaration host correspond à un client DHCP ou BOOTP lorsque l'option dhcp-client-identifier de la déclaration correspond à celle donnée par le client. Si l'une des deux n'est pas pas fournie, c'est la pramètre hardware qui est comparé à l'adresse réseau matérielle fournie par le client. Notez que les clients BOOTP ne fournissent normalement pas de dhcp-client-identifier, donc c'est l'adresse matérielle qui est systématiquement utilisée par le protocole BOOTP. La déclaration group (groupe)
subnet numéro netmask masque { [ paramètres ] [ déclarations ] }
subnet numéro netmask masque {
La déclaration subnet sert à dhcpd à avoir suffisament d'informations pour déterminer si une adresse IP est ou pas sur un réseau. Elle peut aussi être utilisée pour indiquer des paramètres propres au sous-réseau ainsi que des adresses à allouer dynamiquement aux clients qui démarrent dessus. Ces adresses sont spécifiées à l'aide de la déclaration range.
Le numéro est une adresse IP ou un nom qui correspond au sous-réseau en cours de description. De même, le masque est soit une adresse IP soit un nom qui correspond au sous-réseau en cours de description. Le numéro de sous-réseau associé au masque est suffisant pour déterminer si une adresse IP appartient au sous-réseau.
Bien que le masque doive être donné avec chaque déclaration, il est recommandé d'utiliser une option subnet-mask pour chaque sous-réseau car elle remplace le masque indiqué dans la déclaration du sous-réseau.
Dans le cas où les masques sous-réseau d'un site sont amenés à changer, il est préférable d'utiliser une option subnet-mask (voir dhcp-options(5)) pour chaque sous-réseau plutôt que de l'indiquer ici dans chaque déclaration puisque les valeurs de cette option remplacent celles de la déclaration.
La déclaration range (plage d'adresses)
range [ dynamic-bootp ] adresse-mini [ adresse-maxi];
Il doit exister au moins une plage d'adresses pour les réseaux à adressage dynamique. La déclaration indique la plus petite et la plus grande adresse IP de la plage. Toutes celles-ci doivent appartenir au sous-réseau dans lequel elles sont déclarées. L'option dynamic-bootp peut être indiquée dans le cas où les adresses dynamiques correspondent indifféremment aux clients BOOTP ou DHCP. Si la déclaration ne contient qu'une seule adresse, celle maximum peut être omise.
La déclaration host (Hôte)
host nom d'hôte { [ paramètres ] [ déclarations ] }
host nom d'hôte {
Il doit exister au moins une déclaration host pour chaque client BOOTP à servir. De même pour les clients DHCP bien que ça ne soit pas obligatoire tant que le démarage n'est autorisé que pour les hôtes connus.
Si vous voulez autoriser un client DHCP ou BOOTP à démarrer sur plus d'un sous-réseau avec des adresses fixes, plus d'une adresse peuvent être inscrites dans le paramètre fixed-address ou bien plus d'une déclaration host peuvent être spécifiées.
Si des paramètres spécifiques au client ont à changer suite à des modifications sur le réseau, plusieurs déclarations host peuvent alors être utilisées.
Si un client est amené à démarrer avec une adresse fixe si possible et dynamique sinon, une déclaration host doit être spécifiée sans la clause fixed-address. Le nom d'hôte est celui qui identifie l'hôte. S'il n'y a pas d'option hostname, c'est celui-ci qui est utilisé.
Une déclaration host correspond à un client DHCP ou BOOTP lorsque l'option dhcp-client-identifier de la déclaration correspond à celle donnée par le client. Si l'une des deux n'est pas pas fournie, c'est la pramètre hardware qui est comparé à l'adresse réseau matérielle fournie par le client. Notez que les clients BOOTP ne fournissent normalement pas de dhcp-client-identifier, donc c'est l'adresse matérielle qui est systématiquement utilisée par le protocole BOOTP.
La déclaration group (groupe)
group { [ paramètres ] [ déclarations ] } La déclaration group est simplement utilisée pour appliquer un ou plusieurs paramètres à un ensemble de déclarations. Elle peut être utilisée pour grouper des hôtes, des réseaux partagés, des sous-réseaux et même d'autre groupes.
group { [ paramètres ] [ déclarations ] }
La déclaration group est simplement utilisée pour appliquer un ou plusieurs paramètres à un ensemble de déclarations. Elle peut être utilisée pour grouper des hôtes, des réseaux partagés, des sous-réseaux et même d'autre groupes.
RÉFÉRENCE : ALLOW and DENY (permettre et empêcher)
Les déclarations allow (permettre) et deny (empêcher) sont utilisées pour contrôler le comportement de dhcpd à diverses requètes. Le mot clef unknown-clients (clients inconnus)
Les déclarations allow (permettre) et deny (empêcher) sont utilisées pour contrôler le comportement de dhcpd à diverses requètes.
Le mot clef unknown-clients (clients inconnus)
allow unknown-clients; deny unknown-clients; Ceci est utilisé pour indiquer à dhcpd s'il faut ou non donner dynamiquement une adresse à un client inconnu. Par défaut, l'assignation est permise (allow). Le mot clef bootp allow bootp; deny bootp; Ceci est utilisé pour indiquer à dhcpd s'il doit ou non répondre aux requètes bootp. Par défaut, dhcpd y répond (allow). Le mot clef booting (démarrer) allow booting; deny booting; Ceci est utilisé pour indiquer à dhcpd s'il faut ou non répondre aux requètes d'un client particulier. Cette déclaration n'a de sens que si elle apparait dans le paramètrage d'un hôte. Par défaut, le démarrage est permis (allow) mais s'il est empêché (deny), le client ne pourra pas avoir d'adresse par ce serveur DHCP.
allow unknown-clients; deny unknown-clients;
Ceci est utilisé pour indiquer à dhcpd s'il faut ou non donner dynamiquement une adresse à un client inconnu. Par défaut, l'assignation est permise (allow).
Le mot clef bootp
allow bootp; deny bootp;
Ceci est utilisé pour indiquer à dhcpd s'il doit ou non répondre aux requètes bootp. Par défaut, dhcpd y répond (allow).
Le mot clef booting (démarrer)
allow booting; deny booting;
Ceci est utilisé pour indiquer à dhcpd s'il faut ou non répondre aux requètes d'un client particulier. Cette déclaration n'a de sens que si elle apparait dans le paramètrage d'un hôte. Par défaut, le démarrage est permis (allow) mais s'il est empêché (deny), le client ne pourra pas avoir d'adresse par ce serveur DHCP.
RÉFÉRENCE : PARAMÈTRES
La déclaration default-lease-time (durée de bail par défaut) default-lease-time durée; La durée, en secondes, est le temps pendant lequel le bail est cédé au client si celui-ci n'en demande pas de particulière. La déclaration max-lease-time (durée maximum de bail) max-lease-time durée; La durée, en secondes, est la durée maximum du bail que dhcpd peut céder à client qui en demande une spécifique. La déclaration hardware (matériel) hardware type-matériel adresse-matérielle; Pour qu'un client bootp soir reconnu, son adresse réseau matérielle doit être déclarée dans la clause hardware de la déclaration host. Le type-matériel est le nom du type d'interface physique. Actuellement, seuls les types ethernet et token-ring sont reconnus bien que le support de fddi (et d'autres) soit désirable. l'adresse-matérielle est une suite d'octets hexadéciamux (nombres de 0 à ff) séparés par les deux points. Cette déclaration peut aussi exister pour les clients DHCP.
La déclaration default-lease-time (durée de bail par défaut)
default-lease-time durée;
La durée, en secondes, est le temps pendant lequel le bail est cédé au client si celui-ci n'en demande pas de particulière.
La déclaration max-lease-time (durée maximum de bail)
max-lease-time durée;
La durée, en secondes, est la durée maximum du bail que dhcpd peut céder à client qui en demande une spécifique.
La déclaration hardware (matériel)
hardware type-matériel adresse-matérielle;
Pour qu'un client bootp soir reconnu, son adresse réseau matérielle doit être déclarée dans la clause hardware de la déclaration host. Le type-matériel est le nom du type d'interface physique. Actuellement, seuls les types ethernet et token-ring sont reconnus bien que le support de fddi (et d'autres) soit désirable. l'adresse-matérielle est une suite d'octets hexadéciamux (nombres de 0 à ff) séparés par les deux points. Cette déclaration peut aussi exister pour les clients DHCP.
La déclaration filename (nom de fichier) filename "nom de fichier"; Elle sert à indiquer quel est le fichier qu'un client doit charger afin de démarrer. Le nom de fichier doit être un nom reconnu par tout protocole que le client est susceptible d'utiliser.
La déclaration filename (nom de fichier)
filename "nom de fichier";
Elle sert à indiquer quel est le fichier qu'un client doit charger afin de démarrer. Le nom de fichier doit être un nom reconnu par tout protocole que le client est susceptible d'utiliser.
La déclaration server-name (nom de serveur) server-name "nom"; Elle est utilisée pour informer le client du nom du serveur sur lequel il démarre. Le nom est celui envoyé au client. La déclaration next-server (serveur suivant) next-server nom de serveur; Elle sert à indiquer sur quel serveur se trouve le fichier de démarrage, indiqué par la déclaration filename, à télécharger. Le nom de serveur peut être une adresse IP numérique ou bien un nom de domaine. Si elle n'est pas spécifiée pour un client, c'est l'adresse du serveur DHCP qui est utilisée. La déclaration fixed-address (adresse fixe) fixed-address adresse [, adresse ... ]; Cette déclaration sert à affecter une ou plusieurs adresses fixes à un client. Elle ne doit donc apparaitre que dans une déclaration host. Si plus d'une adresse lui est réservée, le client, au démarrage, acquerra celle qui correspond au réseau sur lequel il démarre. Si aucune adresse de fixed-address ne correspond à ce réseau, le client ne correspond pas à la définition host en question. Chaque adresse peut être une adresse IP ou un nom de domaine pointant sur une ou plusieurs adresses IP. La déclaration dynamic-bootp-lease-cutoff (suspension de bail) dynamic-bootp-lease-cutoff date; Elle permet de définir une date à partir de laquelle les baux bootp dynamiques ne seront plus cédés. Comme les clients BOOTP n'ont pas les moyens de renouveler un bail ni de savoir que celui-ci expire, dhcpd donne une date infine par défaut. Cependant, certaines situations peuvent demander un arrêt des baux (par exemple à la fin d'une période scolaire ou la nuit lorsque le service est fermé et que les machines doivent être éteintes). La date est celle à laquelle plus aucun bail BOOTP n'est cédé. Elle doit être sous la forme : S AAAA/MM/JJ HH:MM:SS S est le jour de la semaine de zéro (dimanche) à 6 (samedi). AAAA est l'année sur quatre chiffres (siècle inclus). MM le mois de 1 à 12. JJ le jour du mois à partir de 1. HH est l'heure de 0 à 23. MM les minutes et SS les secondes. L'heure est toujours celle de Greenwitch (GMT), jamais l'heure locale. La déclaration dynamic-bootp-lease-length (durée de bail bootp) dynamic-bootp-lease-length durée; Cette déclaration sert à définir la durée du bail cédé aux clients BOOTP. Dans certains cas, on suppose que le bail n'est plus utilisé si son possesseur n'a pas utilisé BOOTP ou DHCP pour demander son adresse dans une certaine période. Celle-ci est définie par durée en nombre de secondes. Si un client redémarre en utilisant BOOTP pendant la période de dépassement, la durée du bail est remise à durée. Ainsi, un client qui redémarre assez souvent ne perdra jamais son bail. Bien entendu, ce paramètre doit être ajusté avec d'extrèmes précautions. La déclaration get-lease-hostnames (recherche du nom de domaine) get-lease-hostnames option; Cette déclaration indique à dhcpd s'il faut ou non rechercher le nom de domaine correspondant à l'adresse IP de chaque adresse de la réserve de baux et de l'utiliser pour l'option hostname de DHCP. Si option est true (vrai) cette recherche est effectuée pour toutes les adresses actuellement utilisées. Par défaut ou si option est false (faux), aucune recherche n'est effectuée. La déclaration use-host-decl-names (utiliser le nom d'hôte déclaré) use-host-decl-names option; Si le paramètre de use-host-decl-names est vrai pour dans un espace donné, alors, pour chaque hôte de cet espace, le nom déclaré sera fourni au client qui l'utilisera comme nom d'hôte. Par exemple : group { use-host-decl-names on; host joe { hardware ethernet 08:00:2b:4c:29:32; fixed-address joe.fugue.com; } } est équivalent à :
La déclaration server-name (nom de serveur)
server-name "nom";
Elle est utilisée pour informer le client du nom du serveur sur lequel il démarre. Le nom est celui envoyé au client.
La déclaration next-server (serveur suivant)
next-server nom de serveur;
Elle sert à indiquer sur quel serveur se trouve le fichier de démarrage, indiqué par la déclaration filename, à télécharger. Le nom de serveur peut être une adresse IP numérique ou bien un nom de domaine. Si elle n'est pas spécifiée pour un client, c'est l'adresse du serveur DHCP qui est utilisée.
La déclaration fixed-address (adresse fixe)
fixed-address adresse [, adresse ... ];
Cette déclaration sert à affecter une ou plusieurs adresses fixes à un client. Elle ne doit donc apparaitre que dans une déclaration host. Si plus d'une adresse lui est réservée, le client, au démarrage, acquerra celle qui correspond au réseau sur lequel il démarre. Si aucune adresse de fixed-address ne correspond à ce réseau, le client ne correspond pas à la définition host en question. Chaque adresse peut être une adresse IP ou un nom de domaine pointant sur une ou plusieurs adresses IP.
La déclaration dynamic-bootp-lease-cutoff (suspension de bail)
dynamic-bootp-lease-cutoff date;
Elle permet de définir une date à partir de laquelle les baux bootp dynamiques ne seront plus cédés. Comme les clients BOOTP n'ont pas les moyens de renouveler un bail ni de savoir que celui-ci expire, dhcpd donne une date infine par défaut. Cependant, certaines situations peuvent demander un arrêt des baux (par exemple à la fin d'une période scolaire ou la nuit lorsque le service est fermé et que les machines doivent être éteintes).
La date est celle à laquelle plus aucun bail BOOTP n'est cédé. Elle doit être sous la forme :
S AAAA/MM/JJ HH:MM:SS
S est le jour de la semaine de zéro (dimanche) à 6 (samedi). AAAA est l'année sur quatre chiffres (siècle inclus). MM le mois de 1 à 12. JJ le jour du mois à partir de 1. HH est l'heure de 0 à 23. MM les minutes et SS les secondes. L'heure est toujours celle de Greenwitch (GMT), jamais l'heure locale.
La déclaration dynamic-bootp-lease-length (durée de bail bootp)
dynamic-bootp-lease-length durée;
Cette déclaration sert à définir la durée du bail cédé aux clients BOOTP. Dans certains cas, on suppose que le bail n'est plus utilisé si son possesseur n'a pas utilisé BOOTP ou DHCP pour demander son adresse dans une certaine période. Celle-ci est définie par durée en nombre de secondes. Si un client redémarre en utilisant BOOTP pendant la période de dépassement, la durée du bail est remise à durée. Ainsi, un client qui redémarre assez souvent ne perdra jamais son bail. Bien entendu, ce paramètre doit être ajusté avec d'extrèmes précautions.
La déclaration get-lease-hostnames (recherche du nom de domaine)
get-lease-hostnames option;
Cette déclaration indique à dhcpd s'il faut ou non rechercher le nom de domaine correspondant à l'adresse IP de chaque adresse de la réserve de baux et de l'utiliser pour l'option hostname de DHCP. Si option est true (vrai) cette recherche est effectuée pour toutes les adresses actuellement utilisées. Par défaut ou si option est false (faux), aucune recherche n'est effectuée.
La déclaration use-host-decl-names (utiliser le nom d'hôte déclaré)
use-host-decl-names option;
Si le paramètre de use-host-decl-names est vrai pour dans un espace donné, alors, pour chaque hôte de cet espace, le nom déclaré sera fourni au client qui l'utilisera comme nom d'hôte. Par exemple :
group { use-host-decl-names on; host joe { hardware ethernet 08:00:2b:4c:29:32; fixed-address joe.fugue.com; } }
use-host-decl-names on; host joe { hardware ethernet 08:00:2b:4c:29:32; fixed-address joe.fugue.com; }
use-host-decl-names on; host joe {
hardware ethernet 08:00:2b:4c:29:32; fixed-address joe.fugue.com;
est équivalent à :
host joe { hardware ethernet 08:00:2b:4c:29:32; fixed-address joe.fugue.com; option host-name "joe"; } La ligne option host-name d'une déclaration d'hôte remplace le nom de la déclaration (ici joe).
host joe { hardware ethernet 08:00:2b:4c:29:32; fixed-address joe.fugue.com; option host-name "joe"; }
host joe {
hardware ethernet 08:00:2b:4c:29:32; fixed-address joe.fugue.com; option host-name "joe";
La ligne option host-name d'une déclaration d'hôte remplace le nom de la déclaration (ici joe).
La déclaration authoritative (autorisé) authoritative; not authoritative; Normalement, le serveur DHCP suppose que les informations sur un réseau donné sont correctes et autorisées. Donc si un client demande une adresse IP sur un sous-réseau que le serveur sait invalide, ce dernier répondra par DHCPNAK, le client oubliera son adresse et en demandera une autre. Si un serveur DHCP est configuré par une autre personne que l'administrateur système et qui n'a donc pas ce niveau d'autorisations, l'option " not authoritative" (non autorisé) doit être inscrite à l'endroit approprié du fichier de configuration. Habituellement, inscrire "not authoritative" au début du fichier est suffisant. Cependant, si le serveur DHCP est amené à gérer des réseaux sur lesquels il est autorisé et d'autres sur lesquels il ne l'est pas, il est sans doute plus approprié de faire cette déclaration pour chaque réseau. Le concept d'autorisation est plus particulièrement adapté aux réseaux physiques (un réseau partagé ou un sous-réseau non-inclus dans un réseau partagé). Il n'est en revanche pas adapté pour dire que le serveur est autorisé sur certains sous-réseaux d'un réseau partagé et pas sur d'autres ni pour certains hôtes et pas d'autres. La déclaration use-lease-addr-for-default-route (adresse de bail comme route) use-lease-addr-for-default-route option; Si ce paramètre est vrai dans un espace donné, alors, au lieu d'envoyer la valeur indiquée par l'option routers (ou au lieu de ne rien envoyer du tout), c'est l'adresse IP du bail cédé qui est envoyée. Celà inciterait les machines Windows95 à utiliser ARP pour toute adresse IP, ce qui est utile si votre routeur est configuré pour un proxy ARP. Si use-lease-addr-for-default-route est activé et qu'une option "routers" existe au même endroit, cette dernière sera préférée. La raison est que, si vous voulez utiliser cette caractéristique, vous voulez probablement l'appliquer à un ensemble de machines Windows95 et vous voulez qu'elle soit remplacée pour d'autres. Si c'est malheureusement le contraire qui se passe, cette option est certainement désactivée. La déclaration always-reply-rfc1048 (réponse rfc1048) always-reply-rfc1048 option; Certains clients BOOTP attendent une réponse conforme au RFC1048 alors que leurs requètes ne le sont pas. Vous pouvez dire qu'un client a un problème lorsqu'il ne reçoit pas les options que vous lui destiniez et si le message "(non-rfc1048)" apparait à chaque BOOTREQUEST enregistré dans le fichier log. Si vous voulez envoyer des options rfc1048 à ces clients, indiquez l'option always-reply-rfc1048 dans leur déclaration host. Le serveur répondra alors conformément aux spécifications. Cette option peut être placée à n'importe quel endroit et affectera tous les clients concernés.
La déclaration authoritative (autorisé)
authoritative; not authoritative;
Normalement, le serveur DHCP suppose que les informations sur un réseau donné sont correctes et autorisées. Donc si un client demande une adresse IP sur un sous-réseau que le serveur sait invalide, ce dernier répondra par DHCPNAK, le client oubliera son adresse et en demandera une autre.
Si un serveur DHCP est configuré par une autre personne que l'administrateur système et qui n'a donc pas ce niveau d'autorisations, l'option " not authoritative" (non autorisé) doit être inscrite à l'endroit approprié du fichier de configuration.
Habituellement, inscrire "not authoritative" au début du fichier est suffisant. Cependant, si le serveur DHCP est amené à gérer des réseaux sur lesquels il est autorisé et d'autres sur lesquels il ne l'est pas, il est sans doute plus approprié de faire cette déclaration pour chaque réseau.
Le concept d'autorisation est plus particulièrement adapté aux réseaux physiques (un réseau partagé ou un sous-réseau non-inclus dans un réseau partagé). Il n'est en revanche pas adapté pour dire que le serveur est autorisé sur certains sous-réseaux d'un réseau partagé et pas sur d'autres ni pour certains hôtes et pas d'autres.
La déclaration use-lease-addr-for-default-route (adresse de bail comme route)
use-lease-addr-for-default-route option;
Si ce paramètre est vrai dans un espace donné, alors, au lieu d'envoyer la valeur indiquée par l'option routers (ou au lieu de ne rien envoyer du tout), c'est l'adresse IP du bail cédé qui est envoyée. Celà inciterait les machines Windows95 à utiliser ARP pour toute adresse IP, ce qui est utile si votre routeur est configuré pour un proxy ARP.
Si use-lease-addr-for-default-route est activé et qu'une option "routers" existe au même endroit, cette dernière sera préférée. La raison est que, si vous voulez utiliser cette caractéristique, vous voulez probablement l'appliquer à un ensemble de machines Windows95 et vous voulez qu'elle soit remplacée pour d'autres. Si c'est malheureusement le contraire qui se passe, cette option est certainement désactivée.
La déclaration always-reply-rfc1048 (réponse rfc1048)
always-reply-rfc1048 option;
Certains clients BOOTP attendent une réponse conforme au RFC1048 alors que leurs requètes ne le sont pas. Vous pouvez dire qu'un client a un problème lorsqu'il ne reçoit pas les options que vous lui destiniez et si le message "(non-rfc1048)" apparait à chaque BOOTREQUEST enregistré dans le fichier log.
Si vous voulez envoyer des options rfc1048 à ces clients, indiquez l'option always-reply-rfc1048 dans leur déclaration host. Le serveur répondra alors conformément aux spécifications. Cette option peut être placée à n'importe quel endroit et affectera tous les clients concernés.
La déclaration server-identifier ( Identifiant serveur) server-identifier hôte; Cette déclaration est utilisée pour définir la valeur envoyée par le serveur dans un espace donné. Cette valeur doit être une adresse IP du serveur et doit être accessible à tous les clients de l'espace. L'utilisation de server-identifier n'est pas recommandée. La seule raison de le faire est de forcer une valeur autre que celle par défaut dans le cas où celle-ci serait incorrecte. La valeur par défaut est la première adresse IP associée à l'interface réseau sur laquelle arrive la requète. Le cas le plus courrant est lorsque l'interface physique possède plus d'une adresse IP et que celle envoyée par défaut n'est pas appropriée pour certains clients. Un autre cas est si un alias est défini pour avoir une adresse IP de serveur cohérante et que les clients doivent utiliser cette adresse pour contacter le serveur. Donner une valeur à l'option "dhcp-server-identifier" est équivalent à donner une valeur à la déclaration server-identifier.
La déclaration server-identifier ( Identifiant serveur)
server-identifier hôte;
Cette déclaration est utilisée pour définir la valeur envoyée par le serveur dans un espace donné. Cette valeur doit être une adresse IP du serveur et doit être accessible à tous les clients de l'espace.
L'utilisation de server-identifier n'est pas recommandée. La seule raison de le faire est de forcer une valeur autre que celle par défaut dans le cas où celle-ci serait incorrecte. La valeur par défaut est la première adresse IP associée à l'interface réseau sur laquelle arrive la requète.
Le cas le plus courrant est lorsque l'interface physique possède plus d'une adresse IP et que celle envoyée par défaut n'est pas appropriée pour certains clients. Un autre cas est si un alias est défini pour avoir une adresse IP de serveur cohérante et que les clients doivent utiliser cette adresse pour contacter le serveur.
Donner une valeur à l'option "dhcp-server-identifier" est équivalent à donner une valeur à la déclaration server-identifier.
RÉFÉRENCE : OPTION de déclarations
Les déclarations d'options sont détaillées dans la page de manuel dhcp-options(5).
VOIR AUSSI
dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
AUTEURS
dhcpd(8) a été écrit par Ted Lemon <mellon@vix.com> en relation avec Vixie Labs. Les bases de ce projet sont de l'Internet Software Corporation. Pour plus d'informations sur le consortium de Logiciels Internet, reportez-vous au site http://www.isc.org/isc. La version française est de Guillain SEUILLOT <Guillain@Lycosmail.com> le 13 juin 2000.
dhcpd(8) a été écrit par Ted Lemon <mellon@vix.com> en relation avec Vixie Labs. Les bases de ce projet sont de l'Internet Software Corporation. Pour plus d'informations sur le consortium de Logiciels Internet, reportez-vous au site http://www.isc.org/isc.
La version française est de Guillain SEUILLOT <Guillain@Lycosmail.com> le 13 juin 2000.