On Tue, Apr 27, 2010 at 6:02 AM, Dejan Muhamedagic <[email protected]> wrote: > Hi, > > On Mon, Apr 26, 2010 at 04:35:31PM -0400, Sam Tran wrote: >> Hi All, >> >> I am running pacemaker 1.0.8 + corosync 1.2.1 + resource-agents 1.0.3 >> on a pair of OpenLDAP master servers (CentOS Linux 5.4). >> >> The active OpenLDAP master hold the failover IP resource. An OpenLDAP >> replica server is connecting to that failover IP address the master >> server for updates, then the connection is maintained, and the replica >> is waiting for subsequent updates from the master server. The >> connection state is successfully synchronized using csync2. If the >> active master server fails, the other master takes over the resources >> and I was expecting the Tickle Ack function in the portblock resource >> to break the established connection between the replica and the >> failover IP. But the latter didn't happen. I am not sure what I am >> doing wrong. Here is my crm configuration: >> >> node info-ldap-015.internal.example.com >> node info-ldap-016.internal.example.com >> primitive email-notify ocf:heartbeat:MailTo \ >> params email="[email protected]" >> subject="TEST_LDAP_PROVIDER_CLUSTER" >> primitive failover-ip1 ocf:heartbeat:IPaddr2 \ >> params ip="192.168.8.171" \ >> op monitor interval="5s" >> primitive portblock_block ocf:heartbeat:portblock \ >> params protocol="tcp" ip="192.168.8.171" portno="636" action="block" >> \ >> op monitor interval="10" timeout="10" depth="0" >> primitive portblock_unblock ocf:heartbeat:portblock \ >> params protocol="tcp" ip="192.168.8.171" portno="636" >> action="unblock" \ >> op monitor interval="10" timeout="10" depth="0" >> tickle_dir="/tmp/tickle" sync_script="/usr/sbin/csync2 -xvr" > > This can't stand just so, on its own. Wrong cut&paste? Anyway, it > should look like this: > > primitive portblock_unblock ocf:heartbeat:portblock \ > params protocol="tcp" ip="192.168.8.171" portno="636" action="unblock" > \ > tickle_dir="/tmp/tickle" sync_script="/usr/sbin/csync2 -xvr" \ > op monitor interval="10" timeout="10" depth="0" > > BTW, better keep the tickle_dir where only root can write. > > Otherwise, you can try to watch the wire with tcpdump and see if > the RA sends reset TCP packets to the clients. > > Thanks, > > Dejan > >> group ldap_cluster failover-ip1 email-notify portblock_block >> portblock_unblock >> location location_server_1 ldap_cluster \ >> rule $id="best_location_server_1" 500: #uname eq >> info-ldap-015.internal.example.com >> location location_server_2 ldap_cluster \ >> rule $id="best_location_server_2" 200: #uname eq >> info-ldap-016.internal.example.com >> property $id="cib-bootstrap-options" \ >> dc-version="1.0.8-9881a7350d6182bae9e8e557cf20a3cc5dac3ee7" \ >> cluster-infrastructure="openais" \ >> expected-quorum-votes="2" \ >> no-quorum-policy="ignore" \ >> stonith-enabled="false" \ >> default-resource-stickiness="1000" >> >> Here is the Iptables configuration on either master server: >> >> # Generated by iptables-save v1.2.11 on Fri May 12 14:27:46 2006 >> *filter >> :INPUT DROP [0:0] >> :FORWARD DROP [0:0] >> :OUTPUT ACCEPT [36:18708] >> :RH-Firewall-1-INPUT - [0:0] >> -A INPUT -j RH-Firewall-1-INPUT >> -A FORWARD -j RH-Firewall-1-INPUT >> -A RH-Firewall-1-INPUT -i lo -j ACCEPT >> -A RH-Firewall-1-INPUT -i eth1 -j ACCEPT >> -A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT >> -A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT >> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j >> ACCEPT >> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 389 -j >> ACCEPT >> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 636 -j >> ACCEPT >> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j >> ACCEPT >> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j >> ACCEPT >> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport >> 30865 -j ACCEPT >> -A RH-Firewall-1-INPUT -s 216.73.0.0/255.255.0.0 -p udp -m state >> --state NEW -m udp --dport 161 -j ACCEPT >> -A RH-Firewall-1-INPUT -s 172.16.8.0/24 -d 224.0.0.0/3 -p udp -m state >> --state NEW -m multiport --dports 5405 -j ACCEPT >> -A RH-Firewall-1-INPUT -s 172.16.8.0/24 -d 172.16.8.0/24 -p udp -m >> state --state NEW -m multiport --dports 5405 -j ACCEPT >> -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT >> -A RH-Firewall-1-INPUT -p igmp -j ACCEPT >> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited >> >> Any input would be very much appreciated. >> >> Thanks, >> Sam >> _______________________________________________________ >> Linux-HA-Dev: [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev >> Home Page: http://linux-ha.org/ > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ >
Hi Dejan, When I composed my original post I did a bad copy and paste. I do have the correct syntax in CRM. Will do some packet capture. Thanks, Sam _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
