[ClusterLabs] [External] : Reload DNSMasq after IPAddr2 change ?

[Robert Hayden]

> 
> From: Users <users-bounces at clusterlabs.org> On Behalf Of Adam Cecile
> Sent: Thursday, February 9, 2023 3:47 AM
> To: Cluster Labs - All topics related to open-source clustering welcomed <users at clusterlabs.org>
> Subject: [External] : [ClusterLabs] Reload DNSMasq after IPAddr2 change ?
>
> Hello,
>
> I might be stupid but I'm completely stuck with this requirement. We just figured out DNSMasq proxy is not working correctly after shared IP address is moved from one host to another because it does not > listen on the new address.
> My need is to issue a reload statement to DNSMasq to make it work again but I failed to find anyone describing how to implement this so I guess I completely wrong.
>

Look into Alerts and Recipients.  I had a project in Oracle's Cloud where I needed to register the virtual IP address with the infrastructure to get network traffic routed properly.   To do that is beyond the scope of your issue, but I created the following pcs Alert and Recipient structures.   The oci_move_ip.sh script can contain your commands to DNSMasq.

pcs alert create id=move_ip description="Move VIP using oci-cli" path=/usr/local/cluster/oci_move_ip.sh
pcs alert recipient add move_ip id=logfile_move_ip value=/var/log/pacemaker_move_ip.log

Relevant contents of my oci_move_ip.sh.  The Alert is triggered at any resource action, so you have to use the IF clause to limit it to a successful resource start.

#!/bin/bash
export LC_ALL=C.UTF-8
export LANG=c.UTF-8
if [ -z "$CRM_alert_version" ]; then
        echo "$0 must be run by Pacemaker version 1.1.15 or later"
        exit 0
fi
# Alert agents must always handle the case where no recipients are defined,
# even if it's a no-op (a recipient might be added to the configuration later).
if [ -z "${CRM_alert_recipient}" ]; then
        CRM_alert_recipient=/var/log/pacemaker_move_ip.log
fi
## https://clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Explained/singlehtml/index.html#document-alerts
## CRM_alert_kind       The type of alert (node, fencing, resource, or attribute)
## CRM_alert_target_rc  The expected numerical return code of the operation (resource alerts only)
## CRM_alert_task       The requested fencing or resource operation (provided with fencing and resource alerts only)
## CRM_alert_rsc        The name of the affected resource (resource alerts only)
## CRM_alert_node       Name of affected node
## Determine if resource is associated to IPaddr2 type with action being a successful start
if [[ "${CRM_alert_kind}" = "resource" && "${CRM_alert_target_rc}" = "0" && "${CRM_alert_task}" = "start" \
      && $(pcs resource show "${CRM_alert_rsc}" 2>/dev/null | grep -c "class=ocf provider=heartbeat type=IPaddr2") -eq 1 ]]; then

     <Actions here>

fi
exit 0



> Could someone explain me how I'm supposed to handle such situation ?
>
> Best regards, Adam.