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> |
||
---|---|---|
.github | ||
ci | ||
deps | ||
doc | ||
mk | ||
packaging | ||
scripts | ||
workflow_sources | ||
.gitignore | ||
.travis.yml | ||
.travis.yml.patch | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
LICENSE | ||
LICENSE-APACHE2 | ||
LICENSE-MPL-RabbitMQ | ||
Makefile | ||
PKG_LINUX.md | ||
PKG_WINDOWS.md | ||
README.md | ||
SERVER_RELEASES.md | ||
erlang.mk | ||
plugins.mk | ||
rabbitmq-components.mk |
README.md
RabbitMQ Server
RabbitMQ is a feature rich, multi-protocol messaging broker. It supports:
- AMQP 0-9-1
- AMQP 1.0
- MQTT 3.1.1
- STOMP 1.0 through 1.2
Installation
- Installation guides for various platforms
- Kubernetes Cluster Operator
- Changelog
- Releases on GitHub
- Supported and unsupported series
- Supported Erlang versions
Tutorials & Documentation
Some key doc guides include
- CLI tools guide
- Clustering and Cluster Formation guides
- Configuration guide
- Client libraries and tools
- Monitoring and Prometheus/Grafana guides
- Production checklist
- Quorum queues: a replicated, data safety- and consistency-oriented queue type
- Runnable tutorials
- Documentation source
Commercial Support
- Commercial support from VMware for open source RabbitMQ
Getting Help from the Community
- GitHub Discussions
- RabbitMQ mailing list
- Community Slack
#rabbitmq
on Freenode
Contributing
See CONTRIBUTING.md and our development process overview.
Questions about contributing, internals and so on are very welcome on the mailing list.
Licensing
RabbitMQ server is licensed under the MPL 2.0.
Building From Source and Packaging
Copyright
(c) 2007-2020 VMware, Inc. or its affiliates.