<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Oyvind,</p>
<p>I checked out PR1924 and exacty applied it to my test cluster.</p>
<p>Problem still exists. Rules do not get deleted, only created.</p>
<p>Note that;</p>
<p>- My cluster runs Ubuntu Server 24.04</p>
<p>- grep is GNU 3.11</p>
<p>- Switches -qE are valid & exist in grep man page.<br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 10/23/24 14:43, Oyvind Albrigtsen
wrote:<br>
</div>
<blockquote type="cite" cite="mid:btsulkcq5bwk4yigf7ink5bnyalhr2p2tjcwcc7rwucf3ddkff@lgvaioahctrr">This
could be related to the following PR:
<br>
<a class="moz-txt-link-freetext" href="https://github.com/ClusterLabs/resource-agents/pull/1924/files">https://github.com/ClusterLabs/resource-agents/pull/1924/files</a>
<br>
<br>
The github version of portblock works fine on Fedora 40, so that's
my
<br>
best guess.
<br>
<br>
<br>
Oyvind
<br>
<br>
On 22/10/24 21:44 +0300, Murat Inal wrote:
<br>
<blockquote type="cite">Hello Oyvind,
<br>
<br>
Using your suggestion, I located the issue at function
chain_isactive().
<br>
<br>
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.
<br>
<br>
I opted to use "iptables --check" command for rule existence
detection. Below is the function with modification comments;
<br>
<br>
<br>
#chain_isactive {udp|tcp} portno,portno ip chain
<br>
chain_isactive()
<br>
{
<br>
[ "$4" = "OUTPUT" ] && ds="s" || ds="d"
<br>
#PAT=$(active_grep_pat "$1" "$2" "$3" "$ds") # grep pattern
<br>
#$IPTABLES $wait -n -L "$4" | grep "$PAT" >/dev/null
# old detection line
<br>
iptables -C "$4" -p "$1" -${ds} "$3" -m multiport
--${ds}ports "$2" -j DROP # new detection using
iptables --check/-C
<br>
}
<br>
<br>
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.
<br>
<br>
<br>
On 10/21/24 12:25, Oyvind Albrigtsen wrote:
<br>
<blockquote type="cite">I would try running "pcs resource
debug-stop --full <resource>" to see
<br>
what's happening, and try to run the "iptables -D" line
manually if it
<br>
doesnt show you an error.
<br>
<br>
<br>
Oyvind
<br>
<br>
On 18/10/24 21:45 +0300, Murat Inal wrote:
<br>
<blockquote type="cite">Hi Oyvind,
<br>
<br>
Probably current portblock has a bug. It CREATES netfilter
rule on start(), however DOES NOT DELETE the rule on stop().
<br>
<br>
Here is the configuration of my simple 2 node + 1 qdevice
cluster;
<br>
<br>
<br>
node 1: node-a-knet \
<br>
attributes standby=off
<br>
node 2: node-b-knet \
<br>
attributes standby=off
<br>
primitive r-porttoggle portblock \
<br>
params action=block direction=out ip=172.16.0.1
portno=1234 protocol=udp \
<br>
op monitor interval=10s timeout=10s \
<br>
op start interval=0s timeout=20s \
<br>
op stop interval=0s timeout=20s
<br>
primitive r-vip IPaddr2 \
<br>
params cidr_netmask=24 ip=10.1.6.253 \
<br>
op monitor interval=10s timeout=20s \
<br>
op start interval=0s timeout=20s \
<br>
op stop interval=0s timeout=20s
<br>
colocation c1 inf: r-porttoggle r-vip
<br>
order o1 r-vip r-porttoggle
<br>
property cib-bootstrap-options: \
<br>
have-watchdog=false \
<br>
dc-version=2.1.6-6fdc9deea29 \
<br>
cluster-infrastructure=corosync \
<br>
cluster-name=testcluster \
<br>
stonith-enabled=false \
<br>
last-lrm-refresh=1729272215
<br>
<br>
<br>
- I checked the switchover and observed netfilter chain
(watch sudo iptables -L OUTPUT) real-time,
<br>
<br>
- Tried portblock with parameter direction=out & both.
<br>
<br>
- Checked if the relevant functions IptablesBLOCK() &
IptablesUNBLOCK() are executing (by inserting syslog mark
messages inside). They do run.
<br>
<br>
However rule is ONLY created, NEVER deleted.
<br>
<br>
Any suggestions?
<br>
<br>
<br>
On 10/9/24 11:26, Oyvind Albrigtsen wrote:
<br>
<br>
<blockquote type="cite">Correct. That should block the port
when the resource is stopped on a
<br>
node (e.g. if you have it grouped with the service you're
using on the
<br>
port).
<br>
<br>
I would do some testing to ensure it works exactly as you
expect. E.g.
<br>
you can telnet to the port, or you can run nc/socat on the
port and
<br>
telnet to it from the node it blocks/unblocks. If it
doesnt accept
<br>
the connection you know it's blocked.
<br>
<br>
<br>
Oyvind Albrigtsen
<br>
<br>
On 06/10/24 22:46 GMT, Murat Inal wrote:
<br>
<blockquote type="cite">Hello,
<br>
<br>
I'd like to confirm with you the mechanism of
ocf:heartbeat:portblock.
<br>
<br>
Given a resource definition;
<br>
<br>
Resource: r41_LIO (class=ocf provider=heartbeat
type=portblock)
<br>
Attributes: r41_LIO-instance_attributes
<br>
action=unblock
<br>
ip=10.1.8.194
<br>
portno=3260
<br>
protocol=tcp
<br>
<br>
- If resource starts, TCP:3260 is UNBLOCKED.
<br>
<br>
- If resource is stopped, TCP:3260 is BLOCKED.
<br>
<br>
Is that correct? If action=block, it will run just the
opposite, correct?
<br>
<br>
To toggle a port, a single portblock resource is enough,
correct?
<br>
<br>
Thanks,
<br>
<br>
_______________________________________________
<br>
Manage your subscription:
<br>
<a class="moz-txt-link-freetext" href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a>
<br>
<br>
ClusterLabs home: <a class="moz-txt-link-freetext" href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Manage your subscription:
<br>
<a class="moz-txt-link-freetext" href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a>
<br>
<br>
ClusterLabs home: <a class="moz-txt-link-freetext" href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a>
<br>
</blockquote>
_______________________________________________
<br>
Manage your subscription:
<br>
<a class="moz-txt-link-freetext" href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a>
<br>
<br>
ClusterLabs home: <a class="moz-txt-link-freetext" href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Manage your subscription:
<br>
<a class="moz-txt-link-freetext" href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a>
<br>
<br>
ClusterLabs home: <a class="moz-txt-link-freetext" href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a>
<br>
</blockquote>
_______________________________________________
<br>
Manage your subscription:
<br>
<a class="moz-txt-link-freetext" href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a>
<br>
<br>
ClusterLabs home: <a class="moz-txt-link-freetext" href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Manage your subscription:
<br>
<a class="moz-txt-link-freetext" href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a>
<br>
<br>
ClusterLabs home: <a class="moz-txt-link-freetext" href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a>
<br>
</blockquote>
</body>
</html>