[Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

Oliver Freyermuth o.freyermuth at googlemail.com
Mon Jun 4 22:33:57 BST 2018


Am 04.06.2018 um 23:27 schrieb Roy Marples:
> On 25/05/2018 13:07, Oliver Freyermuth wrote:
>> I fear the following is a design issue of DHCPv6, but I wonder if there's a way to overcome it with dnsmasq...
>>
>> When automatically deploying machines via PXE / network installer, there's usually first a DHCPv6 client running in the installer,
>> and afterwards (when the machine is installed) the "real" DHCPv6 client running on the machine.
>> Naturally, both will usually have different client DUIDs...
> 
> The partial solution to this, without any dnsmasq hackery OR DHCPv6 client fixes, would be to seed the installed image with the duid from the installer.
> The only issue is if you re-run the installer it will create a new duid - unless it performs a disk scan, finds the installation and then uses it. This is an issue because there could be more than one installed target found, and which to use?
> 
> NetBSD installer has been doing this with great success for some time now, no reason why others cannot.

That's indeed a good point. It seems at least the Debian Installer is not doing that, I'm not 100% sure about RedHats kickstart, since I never had it in my test setup. 
But I know that some Linux installers, e.g. autoyast (openSUSE) also scrape existing installations for SSH host keys, to deploy them to the new installation. 
So the concept is certainly not new also for Linux, but apparently it has not made its way to the end just yet. 
I should probably go ahead at some point and open a bug report against Debian-Installer, and check out how Kickstart behaves. 

Of course, something which would fail in any case would be the approach to boot e.g. a temporary "bare-metal discovery" image to detect hardware, then the installer, and only then provision the machine. 
That's commonly done (see e.g. Foreman's discovery image). We're not doing that yet, but are planning to. 
The only solution for that would be RFC 6355, or using a type-3 DUID in the discovery image, since that's really volatile by design. 
Once we start to use the Foreman discovery image, I'll have a look what it does. 

Cheers,
	Oliver

> 
> Roy



More information about the Dnsmasq-discuss mailing list