Currently the resource agent hard-codes iptables calls to block off
client access before the resource becomes master. This was done
historically because many libraries were fairly buggy detecting a
not-yet functional rabbitmq, so they were being helped by getting
a tcp RST packet and they would go on trying their next configured
server.
It makes sense to be able to disable this behaviour because
most libraries by now have gotten better at detecting timeouts when
talking to rabbit and because when you run rabbitmq inside a bundle
(pacemaker term for a container with an OCF resource inside) you
normally do not have access to iptables.
Tested by creating a three-node bundle cluster inside a container:
Container bundle set: rabbitmq-bundle [cluster.common.tag/rhosp16-openstack-rabbitmq:pcmklatest]
Replica[0]
rabbitmq-bundle-podman-0 (ocf:💓podman): Started controller-0
rabbitmq-bundle-0 (ocf::pacemaker:remote): Started controller-0
rabbitmq (ocf::rabbitmq:rabbitmq-server-ha): Master rabbitmq-bundle-0
Replica[1]
rabbitmq-bundle-podman-1 (ocf:💓podman): Started controller-1
rabbitmq-bundle-1 (ocf::pacemaker:remote): Started controller-1
rabbitmq (ocf::rabbitmq:rabbitmq-server-ha): Master rabbitmq-bundle-1
Replica[2]
rabbitmq-bundle-podman-2 (ocf:💓podman): Started controller-2
rabbitmq-bundle-2 (ocf::pacemaker:remote): Started controller-2
rabbitmq (ocf::rabbitmq:rabbitmq-server-ha): Master rabbitmq-bundle-2
The ocf resource was created inside a bundle with:
pcs resource create rabbitmq ocf:rabbitmq:rabbitmq-server-ha avoid_using_iptables="true" \
meta notify=true container-attribute-target=host master-max=3 ordered=true \
op start timeout=200s stop timeout=200s promote timeout=60s bundle rabbitmq-bundle
Signed-off-by: Michele Baldessari <michele@acksyn.org>
This was used to define `$RABBITMQ_LOG_BASE`, but this variable is no
longer define there.
rabbitmq-env would also load `rabbitmq-env.conf` which could redefine
`$RABBITMQ_LOG_BASE`, but this is a corner case and doesn't fit
packaging well: packages already prepare a location for log files and
will clean this location up on removal.
Now, we set `$RABBITMQ_LOG_BASE` value in those scripts and get rid of
rabbitmq-env load.
This commit updates URLs to prefer the https protocol. Redirects are not followed to avoid accidentally expanding intentionally shortened URLs (i.e. if using a URL shortener).
# Fixed URLs
## Fixed Success
These URLs were switched to an https URL with a 2xx status. While the status was successful, your review is still recommended.
* [ ] http://www.apache.org/licenses/LICENSE-2.0 with 1 occurrences migrated to:
https://www.apache.org/licenses/LICENSE-2.0 ([https](https://www.apache.org/licenses/LICENSE-2.0) result 200).
Instead of calling crm_node directly it is preferrable to use the
ocf_attribute_target function. This function will return crm_node -n
as usual, except when run inside a bundle (aka container in pcmk
language). Inside a bundle it will return the bundle name or, if the
meta attribute meta_container_attribute_target is set to 'host', it
will return the physical node name where the bundle is running.
Typically when running a rabbitmq cluster inside containers it is
desired to set 'meta_container_attribute_target=host' on the rabbit
cluster resource so that the RA is aware on which host it is running.
Tested both on baremetal (without containers):
Master/Slave Set: rabbitmq-master [rabbitmq]
Masters: [ controller-0 controller-1 controller-2 ]
And with bundles as well.
Co-Authored-By: Damien Ciabrini <dciabrin@redhat.com>
Exit codes from sysexits.h were introduced in rabbitmq CLI with
https://github.com/rabbitmq/rabbitmq-server/pull/412. The OCF
agent for non-clustered setup was not updated and some exit codes
were incorrectly reported as unexpected.
In is_clustered_with(), commands that we run to check if the node is
clustered with us, or partitioned with us may fail. When they fail, it
actually doesn't tell us anything about the remote node.
Until now, we were considering such failures as hints that the remote
node is not in a sane state with us. But doing so has pretty negative
impact, as it can cause rabbitmq to get restarted on the remote node,
causing quite some disruption.
So instead of doing this, ignore the error (it's still logged).
There was a comment in the code wondering what is the best behavior;
based on experience, I think preferring stability is the slightly more
acceptable poison between the two options.
Right now, every time we get a start notification, all nodes will ensure
the rabbitmq app is started. This makes little sense, as nodes that are
already active don't need to do that.
On top of that, this had the sideeffect of updating the start time for
each of these nodes, which could result in the master moving to another
node.
If there's nothing starting and nothing active, then we do a -z " ",
which doesn't have the same result as -z "". Instead, just test for
emptiness for each set of nodes.
It may happen that two nodes have the same start time, and one of these
is the master. When this happens, the node actually gets the same score
as the master and can get promoted. There's no reason to avoid being
stable here, so let's keep the same master in that scenario.
Remove argument quoting which is not necessary as long as command is
passed to `/sbin/runuser` and `/bin/su` as arguments instead of a
string.
Fixes#44.
[#150221349]
Because the rabbitmq user shell defaults to /bin/false, we must
explicitly define a shell when using the runuser command
Issue: rabbitmq/rabbitmq-server-release#32
PR: rabbitmq/rabbitmq-server-release#40
[#150221349]
Signed-off-by: Gerhard Lazu <gerhard@rabbitmq.com>
The previous patch was meant to make it clear that an unprivileged user
(other than `rabbitmq`) shouldn't run rabbitmq-plugins.
Unfortunately, it broke the script when called by root, because the
real script was executed as `rabbitmq`. This user doesn't have write
permissions to `/etc/rabbitmq` by default.
Now, rabbitmq-plugins' wrapper must be executed as root and so is the
real script. This should fix the problem described above.
[#149840153]
If the current working directory is not readable, Erlang will crash.
This ensures that we run RabbitMQ scripts from a readable directory.
[#149425921]
Signed-off-by: Gerhard Lazu <gerhard@rabbitmq.com>
The logic is a bit crazy, and the whole purpose of this script is
questionable, but until we get rid of it, we've refactor it to make it
more obvious just how crazy it actually is.
[#149425921]
Signed-off-by: Gerhard Lazu <gerhard@rabbitmq.com>
For some reason, the rabbitmq-plugins command could be run
from arbitrary user, which would result in errors unable to
access a cookie file or plugins configuration files.
Changed to work the same way as rabbitmqctl - require root
or rabbitmq user.
[Fixes#149425921]
Some parts of #21 have not been added to the stable branch. This change
fixes the issue by adding missing changes to rabbitmq-server-ha.ocf and
also fixing rabbitmq-server.ocf
Some parts of #21 have not been added to the stable branch. This change
fixes the issue by adding missing changes to rabbitmq-server-ha.ocf and
also fixing rabbitmq-server.ocf
For some reason some changes were lost from #21, adding back those.
The original PR message:
This enables to change the limit of open files, as the default on
distributions is usually too low for rabbitmq. Default is 65535.
For some reason some changes were lost from #21, adding back those.
The original PR message:
This enables to change the limit of open files, as the default on
distributions is usually too low for rabbitmq. Default is 65535.
It would be helpful to see rabbit's output when it exits with non-zero
status code. The log level is left at info, as it might be business as
usual that a node is not running rabbit. The -q switch prevents the
output from being logged if the return value is zero.
It would be helpful to see rabbit's output when it exits with non-zero
status code. The log level is left at info, as it might be business as
usual that a node is not running rabbit. The -q switch prevents the
output from being logged if the return value is zero.
This enables the cluster to focus on a vhost that is not /, in case the
most important vhost is something else.
For reference, other vhosts may exist in the cluster, but these are not
guaranteed to not suffer from any data loss. This patch doesn't address
this issue.
Closes https://github.com/rabbitmq/rabbitmq-server-release/issues/22
Jean-Sébastien Pédron
Michele Baldessari
Michael Klishin
Michael Klishin
Spring Operator
Luke Bakken
Jacek Tomasiak
Vincent Untz
Daniil Fedotov
Luke Bakken
Gerhard Lazu
Mate Lakat
Michael Klishin
Alberto Planas