RABBITMQ_NODE_PORT is exported by default and set to 5672. Re-exporting it in that
case will actually break the case where we set up rabbit with tls on the default port:

  2021-02-28 07:44:10.732 [error] <0.453.0> Failed to start Ranch listener
  {acceptor,{172,17,1,93},5672} in ranch_ssl:listen([{cacerts,'...'},{key,'...'},{cert,'...'},{ip,{172,17,1,93}},{port,5672},
  inet,{keepalive,true}, {versions,['tlsv1.1','tlsv1.2']},{certfile,"/etc/pki/tls/certs/rabbitmq.crt"},{keyfile,"/etc/pki/tls/private/rabbitmq.key"},
  {depth,1},{secure_renegotiate,true},{reuse_sessions,true},{honor_cipher_order,true},{verify,verify_none},{fail_if_no_peer_cert,false}])
  for reason eaddrinuse (address already in use)

This is because by explicitely always exporting it, we force rabbit to listen to
that port via tcp and that is a problem when we want to do SSL on that port.
Since 5672 is the default port already we can just avoid exporting this port when
the user does not customize the port.

Tested both in a non-TLS env (A) and in a TLS-env (B) successfully:
(A) Non-TLS
[root@messaging-0 /]# grep -ir -e tls -e ssl /etc/rabbitmq
[root@messaging-0 /]#
[root@messaging-0 /]# pcs status |grep rabbitmq
    * rabbitmq-bundle-0 (ocf::rabbitmq:rabbitmq-server-ha):      Master messaging-0
    * rabbitmq-bundle-1 (ocf::rabbitmq:rabbitmq-server-ha):      Master messaging-1
    * rabbitmq-bundle-2 (ocf::rabbitmq:rabbitmq-server-ha):      Master messaging-2

(B) TLS
[root@messaging-0 /]# grep -ir -e tls -e ssl /etc/rabbitmq/ |head -n3
/etc/rabbitmq/rabbitmq.config:  {ssl, [{versions, ['tlsv1.1', 'tlsv1.2']}]},
/etc/rabbitmq/rabbitmq.config:    {ssl_listeners, [{"172.17.1.48", 5672}]},
/etc/rabbitmq/rabbitmq.config:    {ssl_options, [

[root@messaging-0 ~]# pcs status |grep rabbitmq
    * rabbitmq-bundle-0 (ocf::rabbitmq:rabbitmq-server-ha):      Master messaging-0
    * rabbitmq-bundle-1 (ocf::rabbitmq:rabbitmq-server-ha):      Master messaging-1
    * rabbitmq-bundle-2 (ocf::rabbitmq:rabbitmq-server-ha):      Master messaging-2

Note: I don't believe we should export RABBITMQ_NODE_PORT at all, since you can specify all ports
in the rabbit configuration anyways, but prefer to play it safe here as folks might rely on being
able to customize this.

Signed-off-by: Michele Baldessari <michele@acksyn.org>

Currently every call to unblock_client_access() is followed by a log line
showing which function requested the unblocking. When we pass the parameter
OCF_RESKEY_avoid_using_iptables=true it makes no sense to log
unblocking of iptables since it is effectively a no-op.

Let's move that logging inside the unblock_client_access() function
allowing a parameter to log which function called it.

Tested on a cluster with rabbitmq bundles with avoid_using_iptables=true
and observed no spurious logging any longer:

[root@messaging-0 ~]# journalctl |grep 'unblocked access to RMQ port' |wc -l
0

We introduce the OCF_RESKEY_allowed_cluster_node parameter which can be used to specify
which nodes of the cluster rabbitmq is expected to run on. When this variable is not
set the resource agent assumes that all nodes of the cluster (output of crm_node -l)
are eligible to run rabbitmq. The use case here is clusters that have a large
numbers of node, where only a specific subset is used for rabbitmq (usually this is
done with some constraints).

Tested in a 9-node cluster as follows:
[root@messaging-0 ~]# pcs resource config rabbitmq
 Resource: rabbitmq (class=ocf provider=rabbitmq type=rabbitmq-server-ha)
  Attributes: allowed_cluster_nodes="messaging-0 messaging-1 messaging-2" avoid_using_iptables=true
  Meta Attrs: container-attribute-target=host master-max=3 notify=true ordered=true
  Operations: demote interval=0s timeout=30 (rabbitmq-demote-interval-0s)
              monitor interval=5 timeout=30 (rabbitmq-monitor-interval-5)
              monitor interval=3 role=Master timeout=30 (rabbitmq-monitor-interval-3)
              notify interval=0s timeout=20 (rabbitmq-notify-interval-0s)
              promote interval=0s timeout=60s (rabbitmq-promote-interval-0s)
              start interval=0s timeout=200s (rabbitmq-start-interval-0s)
              stop interval=0s timeout=200s (rabbitmq-stop-interval-0s)

[root@messaging-0 ~]# pcs status |grep -e rabbitmq -e messaging
  * Online: [ controller-0 controller-1 controller-2 database-0 database-1 database-2 messaging-0 messaging-1 messaging-2 ]
...
  * Container bundle set: rabbitmq-bundle [cluster.common.tag/rhosp16-openstack-rabbitmq:pcmklatest]:
    * rabbitmq-bundle-0 (ocf::rabbitmq:rabbitmq-server-ha):      Master messaging-0
    * rabbitmq-bundle-1 (ocf::rabbitmq:rabbitmq-server-ha):      Master messaging-1
    * rabbitmq-bundle-2 (ocf::rabbitmq:rabbitmq-server-ha):      Master messaging-2

Console output is handled in the SysV init scripts consistently (no more
differences between the Debian and RPM packages). See the previous
commit.

This fixes an issue for users who used to define $RABBITMQ_LOG_BASE in
the environment and called this script directly (i.e. not using the SysV
init scripts). Before commit 4b7048205d1afa80bb0d644acb90e13106b2b8c1
(which made it to RabbitMQ 3.8.4), `rabbitmq-script-wrapper` took
$RABBITMQ_LOG_BASE from rabbitmq-env(8) or the environment. After the
mentionned commit, $RABBITMQ_LOG_BASE was hard-coded to setup console
redirection (in the case of Debian only) because rabbitmq-env(8) didn't
have the variable anymore and thus was not sourced.

For those users, it meant they couldn't override $RABBITMQ_LOG_BASE in
the environment and call this script, even if they wanted to change the
location of RabbitMQ actual log files.

Now that console redirection is handled by the SysV init scripts, we can
get rid of that code in `rabbitmq-script-wrapper`.

Fixes rabbitmq/rabbitmq-server-release#131.

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::heartbeat: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::heartbeat: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::heartbeat: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>