[ClusterLabs] When does pacemaker call 'restart'/'force-reload' operations on LSB resource?
Hi ClusterLabs list, When adding 'LSB' script to pacemaker cluster I can see that pacemaker advertises 'restart' and 'force-reload' operations to be present - regardless if the LSB script supports it or not. This seems to be coming from following piece of code. https://github.com/ClusterLabs/pacemaker/blob/92b0c1d69ab1feb0b89e141b5007f8792e69655e/lib/services/services_lsb.c#L39-L40 Questions: 1. When the 'restart' and 'force-reload' operations are called on the LSB script cluster resource? 2. How can I trigger 'restart' and 'force-reload' operation on LSB script cluster resource in pacemaker? Cluster resource definition looks like this: name="force-reload" timeout="15s"/> name="monitor" timeout="15"/> name="restart" timeout="15"/> timeout="15"/> timeout="15"/> I would have expected that 'restart' operation would be called when using 'crm_resource --restart --resource myResource', but I can see that 'stop' and 'start' operations are used in that case instead. For 'force-reload' I have no idea on how to try trigger it looking at 'crm_resource --help' output. I want to make sure that cluster will not attempt running 'restart' nor 'force-reload' on script that is not implementing them. As for now I'm considering to return exit code '3' from script when these actions are called to indicate that they are 'unimplemented feature' as suggested by LSB specification below. However I would like to verify that this works as expected. http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html -- Ondrej ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Concept of a Shared ipaddress/resource for generic applicatons
On Tue, Dec 03, 2019 at 11:14:41PM +0100, Jan Pokorný wrote: > 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. Indeed, I have tested with 2 nodes and TCP connections work as expected: packets arrive at both nodes but only one of them responds - sometimes the first node and sometimes the second. For ARP both nodes respond with the same multicast MAC: 22:33:14.231779 ARP, Request who-has 192.168.122.101 tell 192.168.122.1, length 28 22:33:14.231833 ARP, Reply 192.168.122.101 is-at 21:53:69:51:3e:b1, length 28 22:33:14.231833 ARP, Reply 192.168.122.101 is-at 21:53:69:51:3e:b1, length 28 > Is there any iptables-legacy command equivalent in Debian? Yes, iptables package in Debian installs both: /usr/sbin/iptables-legacy /usr/sbin/iptables-nft so the agent can be modified to prefer iptables-legacy over iptables. -- Valentin ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Concept of a Shared ipaddress/resource for generic applicatons
On 03/12/19 23:19 +0100, Valentin Vidić wrote: > Interesting enough, ipt_CLUSTERIP still seems to work when using > iptables-legacy :) 5 minutes ago, in another part of this thread :) -- Jan (Poki) pgpS99Ce6dNGb.pgp Description: PGP signature ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Concept of a Shared ipaddress/resource for generic applicatons
On Tue, Dec 03, 2019 at 08:38:06PM +0100, Valentin Vidić wrote: > 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) Interesting enough, ipt_CLUSTERIP still seems to work when using iptables-legacy :) OTHO, xt_cluster is a much simpler module so the same functionality requires more setup. Probably better to create a new ClusterIP agent than pollute IPaddr2 even more... -- Valentin ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Concept of a Shared ipaddress/resource for generic applicatons
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> "http://www.w3.org/TR/html4/strict.dtd;>
CMD2>
CMD2>
CMD2>
CMD2> Directory listing for /
CMD2>
CMD2>
CMD2> Directory listing for /
CMD2>
CMD2>
CMD2> hello.world
CMD2>
CMD2>
CMD2>
CMD2>
# 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)
pgpdQC1VnGfqg.pgp
Description: PGP signature
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Antw: Re: Concept of a Shared ipaddress/resource for generic applicatons
On Tue, Dec 03, 2019 at 08:03:18AM +0100, Ulrich Windl wrote: > Probably while doing so, also provide better documentation (e.g. hardware > requirements). I could not get the cluster IP working when I tried several > years ago. Maybe it was due to our networking equipment, but actually I never > found out why... It seems to require working multicast MAC support :) -- Valentin ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Concept of a Shared ipaddress/resource for generic applicatons
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) -- Valentin ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Concept of a Shared ipaddress/resource for generic applicatons
On 02/12/19 09:50 -0600, Ken Gaillot wrote: > On Sat, 2019-11-30 at 18:58 +0300, Andrei Borzenkov wrote: >> 29.11.2019 17:46, Jan Pokorný пишет: >>> "Clone" feature for IPAddr2 is actually sort of an overloading that >>> agent with an alternative functionality -- trivial low-level load >>> balancing. You can ignore that if you don't need any such. >>> >> >> I would say IPaddr2 in clone mode does something similar to >> SharedAddress. > > Just a side note about something that came up recently: > > IPaddr2 cloning utilizes the iptables "clusterip" feature, which has > been deprecated in the Linux kernel since 2015. IPaddr2 cloning > therefore must be considered deprecated as well. (Using it for a single > floating IP is still fully supported.) > > IPaddr2 could be modified to use a newer iptables capability called > "xt_cluster", but someone would have to volunteer to do that as it's > not a priority. 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. -- Jan (Poki) pgpBadtkZA8r0.pgp Description: PGP signature ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] 2020 Summit is right around the corner!
Yeah once a decade isn't a bad average actually. Hardly manage to remember not to touch my laptop where the yubikey is plugged when I lift it for longer than a week ;-) And you've all seen what happens if the focus is on an email in the works or the irc-chat ... Klaus On 12/2/19 9:13 PM, Digimer wrote: > I pasted my password into fpaste/IRC a month ago. So... ya. :) > > digimer > > On 2019-12-02 2:24 p.m., Steven Levine wrote: >> I did *not* mean this message to go to the whole list. My profuse apologies. >> >> I haven't made this rookie mistake in a decade or more. >> >> Sorry, >> >> Steven >> >> - Original Message - >> From: "Steven Levine" >> To: "Cluster Labs - All topics related to open-source clustering welcomed" >> >> Sent: Monday, December 2, 2019 1:23:44 PM >> Subject: Re: [ClusterLabs] 2020 Summit is right around the corner! >> >> Ken: >> >> I plan to be there. I wasn't sure if I needed to let you know specifically. >> >> I got budget approval last fall when we thought this would happen in >> November, but my department asked me to withdraw that request and re-apply >> this quarter when the date was changed. And then they told me we had no >> more money in the travel budget, so my manager has asked Chris if the budget >> could come from his department. >> >> But I plan to come anyway, even if I have to pay my own way again. It's >> much too important to my ability to do my job well for me to miss this if I >> can possibly attend. >> >> Steven >> >> - Original Message - >> From: "Ken Gaillot" >> To: users@clusterlabs.org >> Sent: Monday, December 2, 2019 12:43:01 PM >> Subject: [ClusterLabs] 2020 Summit is right around the corner! >> >> The 2020 ClusterLabs summit is only two months away! Details are >> available at: >> >> http://plan.alteeve.ca/index.php/HA_Cluster_Summit_2020 >> >> So far we have responses from Alteeve, Canonical, IBM MQ, NTT, Proxmox, >> Red Hat, and SUSE. If anyone else thinks they might attend, please >> reply here or email me privately so we can firm up the head count and >> finalize planning. >> >> Thanks, >> > ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
