[et-mgmt-tools] dnsmasq

Michael DeHaan mdehaan at redhat.com
Thu May 24 14:34:34 UTC 2007

Michael DeHaan wrote:
> Daniel P. Berrange wrote:
>> On Wed, May 23, 2007 at 05:58:34PM -0400, Michael DeHaan wrote:
>>> Michael DeHaan wrote:
>>>> Bryan K. Wright wrote:
>>>>> Hi folks,
>>>>> Here's a note I sent recently to Michael DeHaan, and his response.
>>>>> He suggested I forward it to the list. As he suggests, I'll take a 
>>>>> look
>>>>> at Cobbler's trigger infrastructure and see what would be required
>>>>> to get Cobbler to play with dnsmasq.
>>> I've got a rough implementation coded up together on my server now 
>>> that allows for using dnsmasq instead of ISC. Works pretty well.
>>> What you do is set "manage_dhcpd_mode" to "dnsmasq" and then can do 
>>> things like:
>>> cobbler system add --name=AA:BB:CC:DD:EE:FF 
>>> --ip-address= --hostname=blippy
>>> I should have something checked in to the repo tomorrow, (default 
>>> mode = "isc"), though I'm experiencing some problems with routing 
>>> setup. If there are any dnsmasq experts who might be able to help 
>>> debug what's up with the kickstart files not being retrieved, that 
>>> would prove useful. Basically the system will PXE fine, DHCP works 
>>> as intended, but the cobbler server address ( in this 
>>> case) is apparently not reachable.
>>> Anyhow, this is pretty close to achieving dynamic DNS management 
>>> within cobbler. I like what I see so far.
>>> If someone knows how to add host entries (DHCP and DNS) into dnsmasq 
>>> without restart, that would also prove useful -- I see something can 
>>> be done with polling resolv.conf (nice) but am not sure about the 
>>> DHCP component. Right now cobbler is templating out 
>>> /etc/dnsmasq.conf using /etc/cobbler/dnsmasq.template and reloading 
>>> the service, much like the way the DHCP management works now.
>> dnsmasq has a DBus API you can use to control it while running. Never 
>> used
>> it myself, but it sounds like the kinda thing you'd need. Also worth
>> checking to see if sending the proess a SIGHUP / SIGUSR1 might cause it
>> to reload its resolv.conf
>> Dan.
> Very cool. Per the manpage, SIGHUP does resolv.conf but at least from 
> the documentation it sounded like there wasn't a way to manipulate 
> DHCP ...

Incidentally my percieved "routing" problem was that I didn't have httpd 
started yesterday :)

Changes coming in shortly, looking at dbus shortly after that ...


More information about the et-mgmt-tools mailing list