[Pacemaker] Dnsmasq

Gregg Stock gregg at damagecontrolusa.com
Sat Mar 24 23:14:02 EDT 2012


In the dnsmasq.conf file I have

listen-address=127.0.0.1
listen-address=192.168.1.250

Where 192.168.1.250 is the virtual IP.

Otherwise, I think it will listen on all interfaces.

On 3/24/2012 7:22 PM, Alan Robertson wrote:
> Or if there's a way to get your dnsmasq server to bind to a specific 
> IP address, that's an even better solution.
>
>
> On 3/23/2012 8:27 PM, Trevor Hemsley wrote:
>> I'd guess that your replies are going back with the wrong source IP
>> address on them and the Windows clients are being picky about accepting
>> them. Perhaps you need to investigate ocf:heartbeat:IPsrcaddr
>>
>>
>> On 24/03/12 01:35, Gregg Stock wrote:
>>> I'm have some "interesting" behavior with a pacemaker managed DNS
>>> server.  Here is the basic setup:
>>>
>>> primitive p_dnsmasq lsb:dnsmasq \
>>>           op monitor interval="60s" timeout="30s"
>>> primitive p_ip_dnsmasq ocf:heartbeat:IPaddr2 \
>>>           params ip="192.168.1.250" cidr_netmask="24" \
>>>           op monitor interval="10s"
>>> order o_ip_before_dns inf: p_ip_dnsmasq p_dnsmasq
>>>
>>> The cluster seems to manage the resource ok.
>>>
>>> If the dnsmasq server is running on the hosts regular ip address,
>>> everything is fine. When switching to the cluster managed ip address, I
>>> get the following behavior on our network. The behavior was the same 
>>> for
>>> various permutation of the listening addresses in the dnsmasq.conf 
>>> file.
>>>
>>> 1. Linux hosts are fine.
>>> 2. Windows and Mac hosts can ping the DNS server but don't get DNS
>>> service. I was able to verify that the requests were getting to the DNS
>>> server but the replies were getting and ICMP destination unreachable on
>>> the way back.
>>>
>>> I was able fine a tidbit of information here
>>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2010q2/003906.html 
>>>
>>>
>>>           A destination unreachable ICMP reply is normally generated by
>>> the kernel
>>>           when there is nothing listening on that port. The most likely
>>> reason for
>>>           that is that the dnsmasq process no longer exists. If that's
>>> the case
>>>           the problem changes into "find why the dnsmasq daemon is 
>>> exiting".
>>>
>>> This doesn't seem to be completely applicable because the dnsmasq 
>>> daemon
>>> is running.
>>>
>>> Any additional information required?
>>>
>>> Thanks in advance.
>>>
>>> Best regards,
>>> Gregg Stock
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: 
>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
>>
>> _______________________________________________
>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>




More information about the Pacemaker mailing list