[ClusterLabs] About RA ocf:heartbeat:portblock

[Oyvind Albrigtsen]

This could be related to the following PR:
https://github.com/ClusterLabs/resource-agents/pull/1924/files

The github version of portblock works fine on Fedora 40, so that's my
best guess.


Oyvind

On 22/10/24 21:44 +0300, Murat Inal wrote:
>Hello Oyvind,
>
>Using your suggestion, I located the issue at function chain_isactive().
>
>This function greps the "generated" rule string (via function 
>active_grep_pat()) in the rule table. Generated string does NOT match 
>with iptables output anymore. Consequently, RA decides that the rule 
>is ABSENT, although it is PRESENT.
>
>I opted to use "iptables --check" command for rule existence 
>detection. Below is the function with modification comments;
>
>
>#chain_isactive  {udp|tcp} portno,portno ip chain
>chain_isactive()
>{
>    [ "$4" = "OUTPUT" ] && ds="s" || ds="d"
>    #PAT=$(active_grep_pat "$1" "$2" "$3" "$ds") # grep pattern
>    #$IPTABLES $wait -n -L "$4" | grep "$PAT" >/dev/null             
>                                # old detection line
>    iptables -C "$4" -p "$1" -${ds} "$3" -m multiport --${ds}ports 
>"$2" -j DROP                # new detection using iptables --check/-C
>}
>
>I tested the modified RA with both actions (block & unblock). It 
>works. If you agree with the above, active_grep_pat() has NO use, it 
>can be deleted from the script.
>
>
>On 10/21/24 12:25, Oyvind Albrigtsen wrote:
>>I would try running "pcs resource debug-stop --full <resource>" to see
>>what's happening, and try to run the "iptables -D" line manually if it
>>doesnt show you an error.
>>
>>
>>Oyvind
>>
>>On 18/10/24 21:45 +0300, Murat Inal wrote:
>>>Hi Oyvind,
>>>
>>>Probably current portblock has a bug. It CREATES netfilter rule on 
>>>start(), however DOES NOT DELETE the rule on stop().
>>>
>>>Here is the configuration of my simple 2 node + 1 qdevice cluster;
>>>
>>>
>>>node 1: node-a-knet \
>>>    attributes standby=off
>>>node 2: node-b-knet \
>>>    attributes standby=off
>>>primitive r-porttoggle portblock \
>>>    params action=block direction=out ip=172.16.0.1 portno=1234 
>>>protocol=udp \
>>>    op monitor interval=10s timeout=10s \
>>>    op start interval=0s timeout=20s \
>>>    op stop interval=0s timeout=20s
>>>primitive r-vip IPaddr2 \
>>>    params cidr_netmask=24 ip=10.1.6.253 \
>>>    op monitor interval=10s timeout=20s \
>>>    op start interval=0s timeout=20s \
>>>    op stop interval=0s timeout=20s
>>>colocation c1 inf: r-porttoggle r-vip
>>>order o1 r-vip r-porttoggle
>>>property cib-bootstrap-options: \
>>>    have-watchdog=false \
>>>    dc-version=2.1.6-6fdc9deea29 \
>>>    cluster-infrastructure=corosync \
>>>    cluster-name=testcluster \
>>>    stonith-enabled=false \
>>>    last-lrm-refresh=1729272215
>>>
>>>
>>>- I checked the switchover and observed netfilter chain (watch 
>>>sudo iptables -L OUTPUT) real-time,
>>>
>>>- Tried portblock with parameter direction=out & both.
>>>
>>>- Checked if the relevant functions IptablesBLOCK() & 
>>>IptablesUNBLOCK() are executing (by inserting syslog mark messages 
>>>inside). They do run.
>>>
>>>However rule is ONLY created, NEVER deleted.
>>>
>>>Any suggestions?
>>>
>>>
>>>On 10/9/24 11:26, Oyvind Albrigtsen wrote:
>>>
>>>>Correct. That should block the port when the resource is stopped on a
>>>>node (e.g. if you have it grouped with the service you're using on the
>>>>port).
>>>>
>>>>I would do some testing to ensure it works exactly as you expect. E.g.
>>>>you can telnet to the port, or you can run nc/socat on the port and
>>>>telnet to it from the node it blocks/unblocks. If it doesnt accept
>>>>the connection you know it's blocked.
>>>>
>>>>
>>>>Oyvind Albrigtsen
>>>>
>>>>On 06/10/24 22:46 GMT, Murat Inal wrote:
>>>>>Hello,
>>>>>
>>>>>I'd like to confirm with you the mechanism of ocf:heartbeat:portblock.
>>>>>
>>>>>Given a resource definition;
>>>>>
>>>>>Resource: r41_LIO (class=ocf provider=heartbeat type=portblock)
>>>>>  Attributes: r41_LIO-instance_attributes
>>>>>    action=unblock
>>>>>    ip=10.1.8.194
>>>>>    portno=3260
>>>>>    protocol=tcp
>>>>>
>>>>>- If resource starts, TCP:3260 is UNBLOCKED.
>>>>>
>>>>>- If resource is stopped, TCP:3260 is BLOCKED.
>>>>>
>>>>>Is that correct? If action=block, it will run just the 
>>>>>opposite, correct?
>>>>>
>>>>>To toggle a port, a single portblock resource is enough, correct?
>>>>>
>>>>>Thanks,
>>>>>
>>>>>_______________________________________________
>>>>>Manage your subscription:
>>>>>https://lists.clusterlabs.org/mailman/listinfo/users
>>>>>
>>>>>ClusterLabs home: https://www.clusterlabs.org/
>>>>
>>>>_______________________________________________
>>>>Manage your subscription:
>>>>https://lists.clusterlabs.org/mailman/listinfo/users
>>>>
>>>>ClusterLabs home: https://www.clusterlabs.org/
>>>_______________________________________________
>>>Manage your subscription:
>>>https://lists.clusterlabs.org/mailman/listinfo/users
>>>
>>>ClusterLabs home: https://www.clusterlabs.org/
>>
>>_______________________________________________
>>Manage your subscription:
>>https://lists.clusterlabs.org/mailman/listinfo/users
>>
>>ClusterLabs home: https://www.clusterlabs.org/
>_______________________________________________
>Manage your subscription:
>https://lists.clusterlabs.org/mailman/listinfo/users
>
>ClusterLabs home: https://www.clusterlabs.org/