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

2023-02-10 Thread Jehan-Guillaume de Rorthais via Users
Hi,

What about using the Dummy resource agent (ocf_heartbeat_dummy(7)) and collocate
it with your IP address? This RA creates a local file on start and removes it
on stop. The game now is to watch for this path from a systemd path unit and
trigger the reload when file appears. See systemd.path(5).

There might be multiple other ways to trigger such a reload using various
strategies and hack relying on systemd or even DBus events...

Regards,
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/


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

2023-02-10 Thread Adam Cécile

On 2/9/23 15:14, Robert Hayden wrote:

From: Users  On Behalf Of Adam Cecile
Sent: Thursday, February 9, 2023 3:47 AM
To: Cluster Labs - All topics related to open-source clustering welcomed 

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_rscThe 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

  

fi
exit 0


Thanks a lot.

It looks like extremely hackish but if I understood properly, I should 
be able to workaround my issue with that.


___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/