[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=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 ...
>
>
>
>
>
Incidentally my percieved "routing" problem was that I didn't have httpd
started yesterday :)
Changes coming in shortly, looking at dbus shortly after that ...
--Michael
More information about the et-mgmt-tools
mailing list