[ClusterLabs] Concept of a Shared ipaddress/resource for generic applicatons

Tue Dec 3 17:14:41 EST 2019

On 03/12/19 20:38 +0100, Valentin Vidić wrote:
> On Tue, Dec 03, 2019 at 03:06:14PM +0100, Jan Pokorný wrote:
>> You likely refer to
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43270b1bc5f1e33522dacf3d3b9175c29404c36c
>> 
>> however this extension is activelly maintained to this day, so don't
>> see any immediate risks other than something related to containers
>> as referred to from said commit -- that is good to know about in
>> such scenarios nonetheless.
>> 
>> My up2date Fedora Rawhide iptables installation, or rather its
>> iptables-extensions(8) man page does not mention any deprecation
>> at all (unlike with ULOG extension).
>> 
>> OTOH, what may be a true show stopper is a support for IPv4 only,
>> which xt_cluster seems to rectify.
> 
> The module might still work but the iptables command from the agent fails:
> 
> [  842.536916] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
> [  842.539215] ipt_CLUSTERIP: cannot use CLUSTERIP target from nftables compat
> 
> # uname -a
> Linux sid 5.3.0-2-amd64 #1 SMP Debian 5.3.9-3 (2019-11-19) x86_64 GNU/Linux
> 
> # iptables --version
> iptables v1.8.3 (nf_tables)

Hm, you made me feel so much behind in this area :-/

Actually thank you, since this is going to bite the meat,
different story than looming proclamations :-)

TBH, there's so much going on in Fedora in the firewall area that
I momentarily thought I was completely drowned -- not covered by
firewall at all (per casual "iptables -nvL", haha):
https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables

So, in order to reproduce your situation, I had to install something
that comes as "iptables-nft" in Fedora Rawhide, with the command
being canonically named iptables-nft:

 # uname -srvmp
 > Linux 5.4.0-0.rc6.git2.1.fc32.x86_64 #1 SMP Thu Nov 7 16:31:36 UTC
 > 2019 x86_64 x86_64

 # modprobe ipt_CLUSTERIP
 dmesg <- "ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully"

 # iptables-nft -I INPUT -i lo -d 127.0.0.200 -j CLUSTERIP --new \
   --hashmode sourceip-sourceport --clustermac 01:00:5E:00:00:c8
   --total-nodes 2 --local-node 1
 > iptables v1.8.3 (nf_tables):  RULE_INSERT failed (Operation not
 > supported): rule in chain INPUT
 dmesg <- "pt_CLUSTERIP: cannot use CLUSTERIP target from nftables
           compat"

 where --version matches your standard "iptables"

 # iptables-nft --version
 > iptables v1.8.3 (nf_tables)

However!

 # readlink -f /usr/sbin/iptables{,-legacy}
 > /usr/sbin/xtables-legacy-multi
 > /usr/sbin/xtables-legacy-multi

 # iptables --version
 > iptables v1.8.3 (legacy)

 # iptables -I INPUT -i lo -d 127.0.0.200 -j CLUSTERIP --new \
   --hashmode sourceip-sourceport --clustermac 01:00:5E:00:00:20
   --total-nodes 2 --local-node 1
 # echo $?
 > 0
 dmesg <- "ipt_CLUSTERIP: ipt_CLUSTERIP is deprecated and it will
           removed soon, use xt_cluster instead"

And it even works (hypothesis: there will be about 50% probability
the "virtual IP" 127.0.0.200 will be unavailable as long as source
port randomization of the client side is fair)!

 # mkdir /tmp/hello; touch hello.world; python3 -m http.server&
 CMD1> Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/)

 # curl -m1 127.0.0.200:8000
 CMD1> 127.0.0.1 - - [03/Dec/2019 22:55:46] "GET / HTTP/1.1" 200 -
 CMD2> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
 CMD2> "http://www.w3.org/TR/html4/strict.dtd">
 CMD2> <html>
 CMD2> <head>
 CMD2> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
 CMD2> <title>Directory listing for /</title>
 CMD2> </head>
 CMD2> <body>
 CMD2> <h1>Directory listing for /</h1>
 CMD2> <hr>
 CMD2> <ul>
 CMD2> <li><a href="hello.world">hello.world</a></li>
 CMD2> </ul>
 CMD2> <hr>
 CMD2> </body>
 CMD2> </html>

 # curl -m1 127.0.0.200:8000
 CMD2> curl: (28) Connection timed out after 1001 milliseconds
 # fg
 > python3 -m http.server
 ^C
 > Keyboard interrupt received, exiting

Ok, it is relatively fair, so the hypothesis holds based on
these empiric data.

The conclusion is hence that even with bleeding edge software
collection, there's no real problem in using ipt_CLUSTERIP
(when compiled in or alongside kernel) when a proper interface
is used, which may boil down to using an appropriate version of
iptables command.  The respective logic to select the proper one
could be easily extended in the IPaddr2 agent (sorry, I mis-cased
this name previously; in a nutshell: if there's iptables-legacy
command, prefer that instead), which looks far more attainable
than porting to xt_cluster any time soon unless there are
volunteers.

Is there any iptables-legacy command equivalent in Debian?

What I want to demonstrate with this is that no bridge appears
to be burnt, regardless any declarations and worries, yet.

Once again, thanks for pushing for this in-depth analysis,
so we could gain more knowledge on the matter.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20191203/98a1658a/attachment.sig>