RabbitMQ 3.8.18 发布-Linuxeden开源社区

RabbitMQ 3.8.18 is a maintenance release that includes a security patch.

This release addresses an undisclosed vulnerability with CVSS 3.1 score of 3.1 (low).
This section will be updated when the details are made public.

Our team would like to thank Fahimhusain Raydurg for responsibly disclosing
the vulnerability and Patrik Ragnarsson from CloudAMQP for contributing a fix.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith,
and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 and supports Erlang 24.

Provisioning Latest Erlang Releases explains
what package repositories and tools can be used to provision modern Erlang versions.

Upgrade and Compatibility Notes

See the Upgrading guide for general documentation on upgrades and
RabbitMQ change log for release notes of other releases.

If upgrading from a3.7.x release, see 3.8.0 release notes
upgrade and compatibility notes first.

If upgrading from a 3.6.x or older release series, first upgrade
to 3.7.27 and then to this version.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list
and RabbitMQ community Slack.

Changes Worth Mentioning

Core Server

Enhancements

Peer discovery no longer uses randomized delays to avoid the inherent race condition
during initial cluster formation. Instead it relies on an internal
distributed locking mechanism available in modern Erlang releases.

While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
startup, it by definition assumes that with some low probability more than one node can still start as seed nodes,
and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.
Note that etcd and Consul-based peer discovery still use those service’s support for distributed locks.

cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
will no longer have any effect.

GitHub issue: #3075
Node startup banner now includes Erlang version, runtime operation mode (JIT vs. emulator),
and underlying crypto library version (e.g. OpenSSL 1.1.1k) it was built against.

GitHub issue: #2777
Build system targets now use hostname(1) in a way that is compatible with Solaris.
Contributed by Pavel @tropikhajma Heimlich.

GitHub issue: #3117

Bug Fixes

Queue deletion could run into an exception in some rare cases.
Contributed by @tomyouyou.

GitHub issue: #3086

Prometheus Plugin

Bug Fixes

In certain double stack (IPv4 and IPv6) environments, the plugin would start a single listener
but register two internally. That extra non-existent listener would make rabbitmq-diagnostics drain
fail as it disables all registered listeners.

GitHub issue: #3021

Management Plugin

Bug Fixes

In certain double stack (IPv4 and IPv6) environments, the plugin would start a single listener
but register two internally. That extra non-existent listener would make rabbitmq-diagnostics drain
fail as it disables all registered listeners.

GitHub issue: #3021

Kubernetes Peer Discovery Plugin

Enhancements

Kubernetes peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition
during initial cluster formation. Instead it relies on an internal
distributed locking mechanism available in modern Erlang releases.

While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes,
and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.

cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
will no longer have any effect.

GitHub issue: #3075

AWS Peer Discovery Plugin

Enhancements

AWS peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition
during initial cluster formation. Instead it relies on an internal
distributed locking mechanism available in modern Erlang releases.

While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node
startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes,
and be joined by different groups of cluster peers. The locking mechanism does not have this downside.
Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.

cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys
will no longer have any effect.

GitHub issue: #3075

Federation Plugin

Bug Fixes

Queue federation will now declare queues on the upstream side only if it does not already
exist. This makes it possible to federate pre-declared queues of different types.

Note that such setups should be considered edge cases. Queue federation was never meant
to federated queues of different types under the same name in different clusters.
Such setups could be useful in Blue/Green deployment upgrade scenarios but
otherwise should be avoided.

GitHub issue: #3107

AuthN/AuthZ Backend HTTP Plugin

Bug Fixes

auth_http.connection_timeout and auth_http.request_timeout are two new configuration parameters that control HTTP client connection
and overall request timeouts. They both default to 15 seconds. The value can be increased for services that can occasionally slow down
significantly.

Contributed by Miłosz @SzumiecM Szumiec.

GitHub issue: #3140

Dependency Upgrades

jose was updated from 1.11.1 to 2b1d66b5f4
jsx was updated from 2.11.0 to 3.1.0
observer_cli was updated from 1.6.1 to 1.6.2

Source Code Archives

To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.8.18.tar.xz
instead of the source tarball produced by GitHub.

11 people reacted