[et-mgmt-tools] dnsmasq

[Michael DeHaan]

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=192.168.1.50 
>> --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 (192.168.1.210 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 ...