[ClusterLabs] About RA ocf:heartbeat:portblock
Oyvind Albrigtsen
oalbrigt at redhat.com
Wed Oct 23 13:08:07 UTC 2024
In that case I would report the bug to Ubuntu.
Oyvind
On 23/10/24 15:49 +0300, Murat Inal wrote:
> Hi Oyvind,
>
> I checked out PR1924 and exacty applied it to my test cluster.
>
> Problem still exists. Rules do not get deleted, only created.
>
> Note that;
>
> - My cluster runs Ubuntu Server 24.04
>
> - grep is GNU 3.11
>
> - Switches -qE are valid & exist in grep man page.
>
> On 10/23/24 14:43, Oyvind Albrigtsen wrote:
>
> This could be related to the following PR:
> [1]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:
> [2]https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: [3]https://www.clusterlabs.org/
>
> _______________________________________________
> Manage your subscription:
> [4]https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: [5]https://www.clusterlabs.org/
>
> _______________________________________________
> Manage your subscription:
> [6]https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: [7]https://www.clusterlabs.org/
>
> _______________________________________________
> Manage your subscription:
> [8]https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: [9]https://www.clusterlabs.org/
>
> _______________________________________________
> Manage your subscription:
> [10]https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: [11]https://www.clusterlabs.org/
>
> _______________________________________________
> Manage your subscription:
> [12]https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: [13]https://www.clusterlabs.org/
>
>Links:
>1. https://github.com/ClusterLabs/resource-agents/pull/1924/files
>2. https://lists.clusterlabs.org/mailman/listinfo/users
>3. https://www.clusterlabs.org/
>4. https://lists.clusterlabs.org/mailman/listinfo/users
>5. https://www.clusterlabs.org/
>6. https://lists.clusterlabs.org/mailman/listinfo/users
>7. https://www.clusterlabs.org/
>8. https://lists.clusterlabs.org/mailman/listinfo/users
>9. https://www.clusterlabs.org/
>10. https://lists.clusterlabs.org/mailman/listinfo/users
>11. https://www.clusterlabs.org/
>12. https://lists.clusterlabs.org/mailman/listinfo/users
>13. https://www.clusterlabs.org/
>_______________________________________________
>Manage your subscription:
>https://lists.clusterlabs.org/mailman/listinfo/users
>
>ClusterLabs home: https://www.clusterlabs.org/
More information about the Users
mailing list