[Pacemaker] Dnsmasq
Gregg Stock
gregg at damagecontrolusa.com
Sun Mar 25 03:14:02 UTC 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