Security update for rabbitmq-server
This update for rabbitmq-server fixes the following issues:
Changes in rabbitmq-server:
Update to 4.1.5:
- Highlights
- Khepri, an alternative schema data store developed to replace Mnesia,
has matured and is now fully supported (it previously was an experimental feature)
- AMQP 1.0 is now a core protocol that is always enabled. Its plugin is now a no-op that only exists to simplify upgrades.
- The AMQP 1.0 implementation is now significantly more efficient: its peak throughput is more than double than that of 3.13.x
on some workloads
- Efficient sub-linear quorum queue recovery on node startup using checkpoints
- Quorum queues now support priorities (but not exactly the same way as classic queues)
- AMQP 1.0 clients now can manage topologies similarly to how AMQP 0-9-1 clients do it
- The AMQP 1.0 convention (address format) used for interacting with with AMQP 0-9-1 entities is now easier to reason about
- Mirroring (replication) of classic queues was removed after several years of deprecation. For replicated messaging data types,
use quorum queues and/or streams. Non-replicated classic queues remain and their development continues
- Classic queue storage efficiency improvements, in particular recovery time and storage of multi-MiB messages
- Nodes with multiple enabled plugins and little on disk data to recover now start up to 20-30% faster
- New exchange type: Local Random Exchange
- Quorum queue log reads are now offloaded to channels (sessions, connections).
- Initial Support for AMQP 1.0 Filter Expressions
- Feature Flags Quality of Life Improvements
- rabbitmqadmin v2
- Breaking Changes
- Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate
successfully. Before the authenticated phase, a special lower frame_max value
is used.
- With this release, the value was increased from the original 4096 bytes to 8192
to accommodate larger JWT tokens.
- amqplib is a popular client library that has been using
a low frame_max default of 4096. Its users must upgrade to a compatible version
(starting with 0.10.7) or explicitly use a higher frame_max.
amqplib versions older than 0.10.7 will not be able to connect to
RabbitMQ 4.1.0 and later versions due to the initial AMQP 0-9-1 maximum frame size
increase covered above.
- The default MQTT Maximum Packet Size changed from 256 MiB to 16 MiB.
- The following rabbitmq.conf settings are unsupported:
- cluster_formation.etcd.ssl_options.fail_if_no_peer_cert
- cluster_formation.etcd.ssl_options.dh
- cluster_formation.etcd.ssl_options.dhfile
- Classic Queues is Now a Non-Replicated Queue Type
- Quorum Queues Now Have a Default Redelivery Limit
- Up to RabbitMQ 3.13, when an AMQP 0.9.1 client (re-)published a message to RabbitMQ, RabbitMQ interpreted the
- AMQP 0.9.1 x-death header in the published message's basic_message.content.properties.headers field.
- RabbitMQ 4.x will not interpret this x-death header anymore when clients (re-)publish a message.
- CQv1 Storage Implementation was Removed
- Settings cluster_formation.randomized_startup_delay_range.* were Removed
- Several Disk I/O-Related Metrics were Removed
- Default Maximum Message Size Reduced to 16 MiB
- RabbitMQ 3.13 rabbitmq.conf setting rabbitmq_amqp1_0.default_vhost is unsupported in RabbitMQ 4.0.
- RabbitMQ 3.13 rabbitmq.conf settings mqtt.default_user, mqtt.default_password,
and amqp1_0.default_user are unsupported in RabbitMQ 4.0.
- Starting with Erlang 26, client side TLS peer certificate chain verification settings are enabled by default in most contexts:
from federation links to shovels to TLS-enabled LDAP client connections.
- RabbitMQ Shovels will be able connect to a RabbitMQ 4.0 node via AMQP 1.0 only when the Shovel runs on a RabbitMQ node >= 3.13.7.
- See https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.0.1
- and https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.1.0 for more info
- Restore SLES logrotate file, (bsc#1246091)
