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/
