[ClusterLabs] About RA ocf:heartbeat:portblock

[Murat Inal]

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/