Dans le passé, j'ai configuré un serveur PXE plusieurs fois en faisant en sorte que le serveur DHCP normal retourne tout ce qui est nécessaire pour le démarrage réseau: à la fois la configuration IP régulière et bootinfo dans une seule configuration DHCP. De cette façon, c'est facile à faire .
Selon la documentation que j'ai lue ( wikipedia a un bon résumé ), il devrait être possible d'avoir un serveur DHCP non modifié (par exemple si l'administrateur de votre emplacement refuse l'accès) et un serveur séparé qui renvoie UNIQUEMENT les informations de démarrage. Il s'agit généralement du serveur "PXE server" ou "Proxy DHCP". Dans le passé, j'ai vu (non utilisé) ce serveur pxe (la dernière version remonte à 5 ans).
Hier, j'ai installé Cobbler pour voir ce qu'il fait vraiment. Maintenant, je voudrais l'utiliser (j'adore la facilité d'utilisation), mais modifier le serveur dhcpd «principal» pour obtenir PXE n'est pas une option.
Je n'ai pas pu trouver de documentation sur la façon de faire fonctionner cobbler en utilisant un vrai serveur PXE (== proxy dhcp).
Cela peut-il être fait avec un cordonnier?
Puis-je configurer le serveur isc dhcp pour qu'il se comporte comme un serveur PXE (c.-à-d. PAS d'informations IP, uniquement des informations de démarrage)?
Ou devrais-je opter pour une approche complètement différente (si oui, quelle est votre suggestion)?
Merci
Nouvelle découverte que je viens de faire: le changelog pour dnsmasq version 2.4.8 dit:
"Proxy-DHCP, où dnsmasq fournit uniquement les informations PXE et un autre serveur DHCP fait l'allocation des adresses, est également autorisé."
TRÈS INTÉRESSANT. Surtout parce que le cordonnier peut déjà contrôler dnsmasq.
Mise à jour:
dnsmasq 2.51 prendra en charge cette configuration qui fait entièrement le tour que je voulais.
Mon /etc/cobbler/dnsmasq.template ressemble maintenant à ceci:
# Cobbler generated configuration file for dnsmasq
# $date
#
# resolve.conf .. ?
#no-poll
#enable-dbus
read-ethers
addn-hosts = /var/lib/cobbler/cobbler_hosts
# Be a proxyDHCP server
dhcp-range=10.10.0.0,proxy
# Only respond to clients that are known (i.e present in /etc/ethers)
dhcp-ignore=#known
# Set this (and domain: see below) if you want to have a domain
# automatically added to simple names in a hosts-file.
expand-hosts
domain=test.basjes.nl,10.10.15.0
# Loads <tftp-root>/pxelinux.0 from dnsmasq TFTP server.
pxe-service=x86PC, "Boot PXELinux (=Cobbler controlled)", pxelinux ,$next_server
$insert_cobbler_system_definitions
Mise à jour: 2012-04-30
Il y a quelques mois, j'ai reçu un e-mail de quelqu'un me disant qu'il ne pouvait pas faire fonctionner ce qui précède. Il s'avère que j'avais réparé et changé mon propre cordonnier que j'avais oublié. J'ai donc apporté la solution cruciale au cordonnier de la ligne principale qui vient de faire partie du coffre. J'ai également créé des documents de support supplémentaires .
Réponses:
Ce que nous faisons, c'est monter un fichier ISO que nous avons créé, démarrer un noyau et initrd à partir de cela et lui faire charger un kickstart à partir d'un emplacement central. Ce fichier kickstart pointe ensuite vers un référentiel contenant des fichiers RPM, qui pourrait être votre serveur cordonnier.
Je n'ai pas beaucoup d'expérience avec Cobbler (malheureusement), mais c'est peut-être une option pour vous?
la source
La ROM PXE a besoin d'une directive "next-server" du serveur DHCP afin de trouver et de charger le chargeur de démarrage (que ce soit grub, pxelinux ou tout autre chargeur de démarrage). Si un "serveur suivant" n'est pas fourni, c'est à la ROM PXE de décider quoi faire. Vous devrez regarder la configuration du bios de votre carte réseau et voir s'il existe une option pour peut-être spécifier le serveur manuellement.
Comme indiqué dans la réponse ci-dessus, l'utilisation d'une clé ISO ou d'une clé USB personnalisée pour démarrer la machine, avec toutes les informations déjà fournies sur la ligne de commande du noyau, est probablement la meilleure solution. Si vous n'avez pas accès à la configuration du serveur DHCP.
la source
si vous voulez simplement exécuter des tests, vous pouvez avoir plusieurs serveurs DHCP sur le même réseau. vous pouvez demander à un cordonnier de créer une configuration dhcpd qui ne dira à un serveur que de répondre lorsqu'un MAC particulier fera une requête ARP. et si vous commentez / désactivez simplement des plages sur ce serveur (et je parle ici de isc-dhcpd), cela ne sera pas intrusif. Vous pouvez obtenir des boîtes Windows se plaindre (dans les émissions) que ce serveur DHCP ne fasse pas autorité si vous utilisez AD et autres, mais à part cela, je ne pense pas qu'il y ait beaucoup de danger.
Mais le meilleur moyen est d'avoir le cordonnier / DHCP et les serveurs que vous essayez de provisionner sur un VLAN distinct du reste de votre réseau. De cette façon, vous limitez votre domaine de diffusion et aucune autre boîte ne verra même vos annonces dhcp.
la source