2023-02-14 09:01:56 +08:00
|
|
|
% vim:ft=erlang:
|
|
|
|
|
%
|
|
|
|
|
|
2017-03-17 18:55:12 +08:00
|
|
|
[{internal_auth_backend,
|
|
|
|
|
"auth_backends.1 = internal",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{auth_backends,[rabbit_auth_backend_internal]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{ldap_auth_backend,
|
|
|
|
|
"auth_backends.1 = ldap",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{auth_backends,[rabbit_auth_backend_ldap]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
2023-06-10 04:51:00 +08:00
|
|
|
{http_auth_backend,
|
|
|
|
|
"auth_backends.1 = http",
|
|
|
|
|
[{rabbit,[{auth_backends,[rabbit_auth_backend_http]}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{oauth2_auth_backend,
|
|
|
|
|
"auth_backends.1 = oauth2",
|
|
|
|
|
[{rabbit,[{auth_backends,[rabbit_auth_backend_oauth2]}]}],
|
|
|
|
|
[]},
|
2017-03-17 18:55:12 +08:00
|
|
|
{multiple_auth_backends,
|
|
|
|
|
"auth_backends.1 = ldap
|
|
|
|
|
auth_backends.2 = internal",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{auth_backends,
|
2019-01-10 02:55:55 +08:00
|
|
|
[rabbit_auth_backend_ldap,rabbit_auth_backend_internal]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{full_name_auth_backend,
|
|
|
|
|
"auth_backends.1 = ldap
|
|
|
|
|
# uses module name instead of a short alias, \"http\"
|
|
|
|
|
auth_backends.2 = rabbit_auth_backend_http",
|
|
|
|
|
[{rabbit,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{auth_backends,[rabbit_auth_backend_ldap,rabbit_auth_backend_http]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{third_party_auth_backend,
|
|
|
|
|
"auth_backends.1.authn = internal
|
|
|
|
|
# uses module name because this backend is from a 3rd party
|
|
|
|
|
auth_backends.1.authz = rabbit_auth_backend_ip_range",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{auth_backends,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit_auth_backend_internal,rabbit_auth_backend_ip_range}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{authn_authz_backend,
|
|
|
|
|
"auth_backends.1.authn = ldap
|
|
|
|
|
auth_backends.1.authz = internal",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{auth_backends,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit_auth_backend_ldap,rabbit_auth_backend_internal}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{authn_authz_multiple_backends,
|
|
|
|
|
"auth_backends.1.authn = ldap
|
|
|
|
|
auth_backends.1.authz = internal
|
|
|
|
|
auth_backends.2 = internal",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{auth_backends,
|
|
|
|
|
[{rabbit_auth_backend_ldap,rabbit_auth_backend_internal},
|
2019-01-10 02:55:55 +08:00
|
|
|
rabbit_auth_backend_internal]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{authn_backend_only,
|
|
|
|
|
"auth_backends.1.authn = ldap",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{auth_backends,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit_auth_backend_ldap,rabbit_auth_backend_ldap}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
"ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.verify = verify_peer
|
|
|
|
|
ssl_options.fail_if_no_peer_cert = true",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
|
|
|
|
{verify,verify_peer},
|
2019-01-10 02:55:55 +08:00
|
|
|
{fail_if_no_peer_cert,true}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{tcp_listener,
|
|
|
|
|
"listeners.tcp.default = 5673",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{tcp_listeners,[5673]}]}],[]},
|
2017-03-17 18:55:12 +08:00
|
|
|
{ssl_listener,
|
2019-01-10 02:55:55 +08:00
|
|
|
"listeners.ssl = none",[{rabbit,[{ssl_listeners,[]}]}],[]},
|
2017-03-17 18:55:12 +08:00
|
|
|
{num_acceptors,
|
2019-01-10 02:55:55 +08:00
|
|
|
"num_acceptors.ssl = 1",[{rabbit,[{num_ssl_acceptors,1}]}],[]},
|
2019-12-25 05:43:12 +08:00
|
|
|
|
2021-11-16 21:37:28 +08:00
|
|
|
{distribution_listener,
|
|
|
|
|
"distribution.listener.interface = 192.168.0.1
|
|
|
|
|
distribution.listener.port_range.min = 25679
|
|
|
|
|
distribution.listener.port_range.max = 25679",
|
|
|
|
|
[{kernel, [
|
|
|
|
|
{inet_dist_listen_min, 25679},
|
|
|
|
|
{inet_dist_listen_max, 25679},
|
|
|
|
|
{inet_dist_use_interface, {192,168,0,1}}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{distribution_listener_ipv6,
|
|
|
|
|
"distribution.listener.interface = ::1
|
|
|
|
|
distribution.listener.port_range.min = 25679
|
|
|
|
|
distribution.listener.port_range.max = 25679",
|
|
|
|
|
[{kernel, [
|
|
|
|
|
{inet_dist_listen_min, 25679},
|
|
|
|
|
{inet_dist_listen_max, 25679},
|
|
|
|
|
{inet_dist_use_interface, {0,0,0,0,0,0,0,1}}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2019-12-25 05:43:12 +08:00
|
|
|
{socket_writer_gc_threshold,
|
|
|
|
|
"socket_writer.gc_threshold = 999666111", [{rabbit, [{writer_gc_threshold, 999666111}]}],[]},
|
|
|
|
|
|
|
|
|
|
{socket_writer_gc_threshold_off,
|
|
|
|
|
"socket_writer.gc_threshold = off", [{rabbit, [{writer_gc_threshold, undefined}]}],[]},
|
|
|
|
|
|
2022-11-29 08:32:00 +08:00
|
|
|
{disk_free_limit_absolute_priority,
|
|
|
|
|
"disk_free_limit.relative = 1.0
|
|
|
|
|
disk_free_limit.absolute = 50000",
|
|
|
|
|
[{rabbit, [{disk_free_limit, 50000}]}],[]},
|
|
|
|
|
|
|
|
|
|
{disk_free_limit_absolute_priority_regardless_of_order,
|
|
|
|
|
"disk_free_limit.absolute = 50000
|
|
|
|
|
disk_free_limit.relative = 1.0",
|
|
|
|
|
[{rabbit, [{disk_free_limit, 50000}]}],[]},
|
|
|
|
|
|
|
|
|
|
{disk_free_limit_only_relative,
|
|
|
|
|
"disk_free_limit.relative = 1.0",
|
|
|
|
|
[{rabbit, [{disk_free_limit, {mem_relative, 1.0}}]}],[]},
|
|
|
|
|
|
Improve supported information units (Mi, Gi, Ti)
This revisits the information system conversion,
that is, support for suffixes like GiB, GB.
When configuration values like disk_free_limit.absolute,
vm_memory_high_watermark.absolute are set, the value
can contain an information unit (IU) suffix.
We now support several new suffixes and the meaning
a few more changes.
First, the changes:
* k, K now mean kilobytes and not kibibytes
* m, M now mean megabytes and not mebibytes
* g, G now means gigabytes and not gibibytes
This is to match the system used by Kubernetes.
There is no consensus in the industry about how
"k", "m", "g", and similar single letter suffixes
should be treated. Previously it was a power of 2,
now a power of 10 to align with a very popular OSS
project that explicitly documents what suffixes it supports.
Now, the additions:
Finally, the node will now validate these suffixes
at boot time, so an unsupported value will cause
the node to stop with a rabbitmq.conf validation
error.
The message logged will look like this:
````
2024-01-15 22:11:17.829272-05:00 [error] <0.164.0> disk_free_limit.absolute invalid, supported formats: 500MB, 500MiB, 10GB, 10GiB, 2TB, 2TiB, 10000000000
2024-01-15 22:11:17.829376-05:00 [error] <0.164.0> Error preparing configuration in phase validation:
2024-01-15 22:11:17.829387-05:00 [error] <0.164.0> - disk_free_limit.absolute invalid, supported formats: 500MB, 500MiB, 10GB, 10GiB, 2TB, 2TiB, 10000000000
````
Closes #10310
2024-01-16 11:11:57 +08:00
|
|
|
%%
|
|
|
|
|
%% Absolute free disk space limit
|
|
|
|
|
%%
|
|
|
|
|
|
|
|
|
|
{disk_free_limit_only_absolute_integer,
|
2022-11-29 08:32:00 +08:00
|
|
|
"disk_free_limit.absolute = 50000",
|
|
|
|
|
[{rabbit, [{disk_free_limit, 50000}]}],[]},
|
|
|
|
|
|
Improve supported information units (Mi, Gi, Ti)
This revisits the information system conversion,
that is, support for suffixes like GiB, GB.
When configuration values like disk_free_limit.absolute,
vm_memory_high_watermark.absolute are set, the value
can contain an information unit (IU) suffix.
We now support several new suffixes and the meaning
a few more changes.
First, the changes:
* k, K now mean kilobytes and not kibibytes
* m, M now mean megabytes and not mebibytes
* g, G now means gigabytes and not gibibytes
This is to match the system used by Kubernetes.
There is no consensus in the industry about how
"k", "m", "g", and similar single letter suffixes
should be treated. Previously it was a power of 2,
now a power of 10 to align with a very popular OSS
project that explicitly documents what suffixes it supports.
Now, the additions:
Finally, the node will now validate these suffixes
at boot time, so an unsupported value will cause
the node to stop with a rabbitmq.conf validation
error.
The message logged will look like this:
````
2024-01-15 22:11:17.829272-05:00 [error] <0.164.0> disk_free_limit.absolute invalid, supported formats: 500MB, 500MiB, 10GB, 10GiB, 2TB, 2TiB, 10000000000
2024-01-15 22:11:17.829376-05:00 [error] <0.164.0> Error preparing configuration in phase validation:
2024-01-15 22:11:17.829387-05:00 [error] <0.164.0> - disk_free_limit.absolute invalid, supported formats: 500MB, 500MiB, 10GB, 10GiB, 2TB, 2TiB, 10000000000
````
Closes #10310
2024-01-16 11:11:57 +08:00
|
|
|
{disk_free_limit_only_absolute_units_gb,
|
|
|
|
|
"disk_free_limit.absolute = 2GB",
|
|
|
|
|
[{rabbit,[{disk_free_limit, "2GB"}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{disk_free_limit_only_absolute_units_gib,
|
|
|
|
|
"disk_free_limit.absolute = 2GiB",
|
|
|
|
|
[{rabbit,[{disk_free_limit, "2GiB"}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{disk_free_limit_only_absolute_units_g,
|
|
|
|
|
"disk_free_limit.absolute = 2G",
|
|
|
|
|
[{rabbit,[{disk_free_limit, "2G"}]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{disk_free_limit_only_absolute_units_tb,
|
|
|
|
|
"disk_free_limit.absolute = 2TB",
|
|
|
|
|
[{rabbit,[{disk_free_limit, "2TB"}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{disk_free_limit_only_absolute_units_tib,
|
|
|
|
|
"disk_free_limit.absolute = 2TiB",
|
|
|
|
|
[{rabbit,[{disk_free_limit, "2TiB"}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{disk_free_limit_only_absolute_units_t,
|
|
|
|
|
"disk_free_limit.absolute = 2T",
|
|
|
|
|
[{rabbit,[{disk_free_limit, "2T"}]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{disk_free_limit_only_absolute_units_pb,
|
|
|
|
|
"disk_free_limit.absolute = 2PB",
|
|
|
|
|
[{rabbit,[{disk_free_limit, "2PB"}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{disk_free_limit_only_absolute_units_pib,
|
|
|
|
|
"disk_free_limit.absolute = 2PiB",
|
|
|
|
|
[{rabbit,[{disk_free_limit, "2PiB"}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{disk_free_limit_only_absolute_units_p,
|
|
|
|
|
"disk_free_limit.absolute = 2P",
|
|
|
|
|
[{rabbit,[{disk_free_limit, "2P"}]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2023-02-14 09:01:56 +08:00
|
|
|
{default_users,
|
|
|
|
|
"
|
|
|
|
|
default_users.a.vhost_pattern = banana
|
|
|
|
|
default_users.a.tags = administrator,operator
|
|
|
|
|
default_users.a.password = SECRET
|
|
|
|
|
default_users.a.read = .*
|
|
|
|
|
",
|
|
|
|
|
[{rabbit, [{default_users, [
|
|
|
|
|
{<<"a">>, [{<<"vhost_pattern">>, "banana"},
|
|
|
|
|
{<<"tags">>, [administrator, operator]},
|
2024-08-14 04:27:00 +08:00
|
|
|
{<<"password">>, <<"SECRET">>},
|
2023-02-14 09:01:56 +08:00
|
|
|
{<<"read">>, ".*"}]}]}]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2022-12-07 09:02:56 +08:00
|
|
|
{default_policies_operator,
|
2022-10-14 01:59:36 +08:00
|
|
|
"
|
2022-12-07 09:02:56 +08:00
|
|
|
default_policies.operator.a.expires = 1h
|
|
|
|
|
default_policies.operator.a.queue_pattern = apple
|
|
|
|
|
default_policies.operator.a.vhost_pattern = banana
|
2023-02-23 03:46:03 +08:00
|
|
|
default_policies.operator.a.classic_queues.ha_mode = exactly
|
|
|
|
|
default_policies.operator.a.classic_queues.ha_params = 2
|
2023-04-28 06:16:39 +08:00
|
|
|
default_policies.operator.a.classic_queues.ha_sync_mode = automatic
|
2023-09-27 03:09:55 +08:00
|
|
|
default_policies.operator.a.classic_queues.queue_version = 2
|
2023-04-28 06:16:39 +08:00
|
|
|
|
2022-10-14 01:59:36 +08:00
|
|
|
",
|
2022-12-07 09:02:56 +08:00
|
|
|
[{rabbit, [{default_policies, [{operator, [
|
|
|
|
|
{<<"a">>, [{<<"expires">>, 3600000},
|
2023-05-02 05:40:30 +08:00
|
|
|
{<<"ha_mode">>, <<"exactly">>},
|
2023-02-14 09:01:56 +08:00
|
|
|
{<<"ha_params">>, 2},
|
2023-05-02 05:40:30 +08:00
|
|
|
{<<"ha_sync_mode">>, <<"automatic">>},
|
2023-09-27 04:57:24 +08:00
|
|
|
{<<"queue_pattern">>, <<"apple">>},
|
2023-09-27 03:09:55 +08:00
|
|
|
{<<"queue_version">>, 2},
|
2023-02-14 09:01:56 +08:00
|
|
|
{<<"vhost_pattern">>, "banana"}]}]}]}]}],
|
2022-10-14 01:59:36 +08:00
|
|
|
[]},
|
|
|
|
|
|
2022-12-07 09:02:56 +08:00
|
|
|
{default_vhost_limits,
|
2022-10-14 01:59:36 +08:00
|
|
|
"
|
2022-12-07 09:02:56 +08:00
|
|
|
default_limits.vhosts.a.pattern = banana
|
2022-10-20 07:08:06 +08:00
|
|
|
default_limits.vhosts.a.max_queues = 10
|
2022-10-14 01:59:36 +08:00
|
|
|
",
|
2022-10-20 07:40:36 +08:00
|
|
|
[{rabbit, [{default_limits, [{vhosts, [
|
2022-12-07 09:02:56 +08:00
|
|
|
{<<"a">>, [{<<"pattern">>, "banana"},
|
2023-02-14 09:01:56 +08:00
|
|
|
{<<"max_queues">>, 10}]}]}]}]}],
|
2022-10-14 01:59:36 +08:00
|
|
|
[]},
|
|
|
|
|
|
2017-03-17 18:55:12 +08:00
|
|
|
{default_user_settings,
|
|
|
|
|
"default_user = guest
|
|
|
|
|
default_pass = guest
|
Add SASL mechanism ANONYMOUS
## 1. Introduce new SASL mechanism ANONYMOUS
### What?
Introduce a new `rabbit_auth_mechanism` implementation for SASL
mechanism ANONYMOUS called `rabbit_auth_mechanism_anonymous`.
### Why?
As described in AMQP section 5.3.3.1, ANONYMOUS should be used when the
client doesn't need to authenticate.
Introducing a new `rabbit_auth_mechanism` consolidates and simplifies how anonymous
logins work across all RabbitMQ protocols that support SASL. This commit
therefore allows AMQP 0.9.1, AMQP 1.0, stream clients to connect out of
the box to RabbitMQ without providing any username or password.
Today's AMQP 0.9.1 and stream protocol client libs hard code RabbitMQ default credentials
`guest:guest` for example done in:
* https://github.com/rabbitmq/rabbitmq-java-client/blob/0215e85643a9ae0800822869be0200024e2ab569/src/main/java/com/rabbitmq/client/ConnectionFactory.java#L58-L61
* https://github.com/rabbitmq/amqp091-go/blob/ddb7a2f0685689063e6d709b8e417dbf9d09469c/uri.go#L31-L32
Hard coding RabbitMQ specific default credentials in dozens of different
client libraries is an anti-pattern in my opinion.
Furthermore, there are various AMQP 1.0 and MQTT client libraries which
we do not control or maintain and which still should work out of the box
when a user is getting started with RabbitMQ (that is without
providing `guest:guest` credentials).
### How?
The old RabbitMQ 3.13 AMQP 1.0 plugin `default_user`
[configuration](https://github.com/rabbitmq/rabbitmq-server/blob/146b4862d8e570b344c99c37d91246760e218b18/deps/rabbitmq_amqp1_0/Makefile#L6)
is replaced with the following two new `rabbit` configurations:
```
{anonymous_login_user, <<"guest">>},
{anonymous_login_pass, <<"guest">>},
```
We call it `anonymous_login_user` because this user will be used for
anonymous logins. The subsequent commit uses the same setting for
anonymous logins in MQTT. Hence, this user is orthogonal to the protocol
used when the client connects.
Setting `anonymous_login_pass` could have been left out.
This commit decides to include it because our documentation has so far
recommended:
> It is highly recommended to pre-configure a new user with a generated username and password or delete the guest user
> or at least change its password to reasonably secure generated value that won't be known to the public.
By having the new module `rabbit_auth_mechanism_anonymous` internally
authenticate with `anonymous_login_pass` instead of blindly allowing
access without any password, we protect operators that relied on the
sentence:
> or at least change its password to reasonably secure generated value that won't be known to the public
To ease the getting started experience, since RabbitMQ already deploys a
guest user with full access to the default virtual host `/`, this commit
also allows SASL mechanism ANONYMOUS in `rabbit` setting `auth_mechanisms`.
In production, operators should disable SASL mechanism ANONYMOUS by
setting `anonymous_login_user` to `none` (or by removing ANONYMOUS from
the `auth_mechanisms` setting. This will be documented separately.
Even if operators forget or don't read the docs, this new ANONYMOUS
mechanism won't do any harm because it relies on the default user name
`guest` and password `guest`, which is recommended against in
production, and who by default can only connect from the local host.
## 2. Require SASL security layer in AMQP 1.0
### What?
An AMQP 1.0 client must use the SASL security layer.
### Why?
This is in line with the mandatory usage of SASL in AMQP 0.9.1 and
RabbitMQ stream protocol.
Since (presumably) any AMQP 1.0 client knows how to authenticate with a
username and password using SASL mechanism PLAIN, any AMQP 1.0 client
also (presumably) implements the trivial SASL mechanism ANONYMOUS.
Skipping SASL is not recommended in production anyway.
By requiring SASL, configuration for operators becomes easier.
Following the principle of least surprise, when an an operator
configures `auth_mechanisms` to exclude `ANONYMOUS`, anonymous logins
will be prohibited in SASL and also by disallowing skipping the SASL
layer.
### How?
This commit implements AMQP 1.0 figure 2.13.
A follow-up commit needs to be pushed to `v3.13.x` which will use SASL
mechanism `anon` instead of `none` in the Erlang AMQP 1.0 client
such that AMQP 1.0 shovels running on 3.13 can connect to 4.0 RabbitMQ nodes.
2024-08-14 18:19:17 +08:00
|
|
|
anonymous_login_user = guest
|
|
|
|
|
anonymous_login_pass = guest
|
2017-03-17 18:55:12 +08:00
|
|
|
default_user_tags.administrator = true
|
|
|
|
|
default_permissions.configure = .*
|
|
|
|
|
default_permissions.read = .*
|
|
|
|
|
default_permissions.write = .*",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{default_user,<<"guest">>},
|
|
|
|
|
{default_pass,<<"guest">>},
|
Add SASL mechanism ANONYMOUS
## 1. Introduce new SASL mechanism ANONYMOUS
### What?
Introduce a new `rabbit_auth_mechanism` implementation for SASL
mechanism ANONYMOUS called `rabbit_auth_mechanism_anonymous`.
### Why?
As described in AMQP section 5.3.3.1, ANONYMOUS should be used when the
client doesn't need to authenticate.
Introducing a new `rabbit_auth_mechanism` consolidates and simplifies how anonymous
logins work across all RabbitMQ protocols that support SASL. This commit
therefore allows AMQP 0.9.1, AMQP 1.0, stream clients to connect out of
the box to RabbitMQ without providing any username or password.
Today's AMQP 0.9.1 and stream protocol client libs hard code RabbitMQ default credentials
`guest:guest` for example done in:
* https://github.com/rabbitmq/rabbitmq-java-client/blob/0215e85643a9ae0800822869be0200024e2ab569/src/main/java/com/rabbitmq/client/ConnectionFactory.java#L58-L61
* https://github.com/rabbitmq/amqp091-go/blob/ddb7a2f0685689063e6d709b8e417dbf9d09469c/uri.go#L31-L32
Hard coding RabbitMQ specific default credentials in dozens of different
client libraries is an anti-pattern in my opinion.
Furthermore, there are various AMQP 1.0 and MQTT client libraries which
we do not control or maintain and which still should work out of the box
when a user is getting started with RabbitMQ (that is without
providing `guest:guest` credentials).
### How?
The old RabbitMQ 3.13 AMQP 1.0 plugin `default_user`
[configuration](https://github.com/rabbitmq/rabbitmq-server/blob/146b4862d8e570b344c99c37d91246760e218b18/deps/rabbitmq_amqp1_0/Makefile#L6)
is replaced with the following two new `rabbit` configurations:
```
{anonymous_login_user, <<"guest">>},
{anonymous_login_pass, <<"guest">>},
```
We call it `anonymous_login_user` because this user will be used for
anonymous logins. The subsequent commit uses the same setting for
anonymous logins in MQTT. Hence, this user is orthogonal to the protocol
used when the client connects.
Setting `anonymous_login_pass` could have been left out.
This commit decides to include it because our documentation has so far
recommended:
> It is highly recommended to pre-configure a new user with a generated username and password or delete the guest user
> or at least change its password to reasonably secure generated value that won't be known to the public.
By having the new module `rabbit_auth_mechanism_anonymous` internally
authenticate with `anonymous_login_pass` instead of blindly allowing
access without any password, we protect operators that relied on the
sentence:
> or at least change its password to reasonably secure generated value that won't be known to the public
To ease the getting started experience, since RabbitMQ already deploys a
guest user with full access to the default virtual host `/`, this commit
also allows SASL mechanism ANONYMOUS in `rabbit` setting `auth_mechanisms`.
In production, operators should disable SASL mechanism ANONYMOUS by
setting `anonymous_login_user` to `none` (or by removing ANONYMOUS from
the `auth_mechanisms` setting. This will be documented separately.
Even if operators forget or don't read the docs, this new ANONYMOUS
mechanism won't do any harm because it relies on the default user name
`guest` and password `guest`, which is recommended against in
production, and who by default can only connect from the local host.
## 2. Require SASL security layer in AMQP 1.0
### What?
An AMQP 1.0 client must use the SASL security layer.
### Why?
This is in line with the mandatory usage of SASL in AMQP 0.9.1 and
RabbitMQ stream protocol.
Since (presumably) any AMQP 1.0 client knows how to authenticate with a
username and password using SASL mechanism PLAIN, any AMQP 1.0 client
also (presumably) implements the trivial SASL mechanism ANONYMOUS.
Skipping SASL is not recommended in production anyway.
By requiring SASL, configuration for operators becomes easier.
Following the principle of least surprise, when an an operator
configures `auth_mechanisms` to exclude `ANONYMOUS`, anonymous logins
will be prohibited in SASL and also by disallowing skipping the SASL
layer.
### How?
This commit implements AMQP 1.0 figure 2.13.
A follow-up commit needs to be pushed to `v3.13.x` which will use SASL
mechanism `anon` instead of `none` in the Erlang AMQP 1.0 client
such that AMQP 1.0 shovels running on 3.13 can connect to 4.0 RabbitMQ nodes.
2024-08-14 18:19:17 +08:00
|
|
|
{anonymous_login_user,<<"guest">>},
|
|
|
|
|
{anonymous_login_pass,<<"guest">>},
|
2017-03-17 18:55:12 +08:00
|
|
|
{default_user_tags,[administrator]},
|
2019-01-10 02:55:55 +08:00
|
|
|
{default_permissions,[<<".*">>,<<".*">>,<<".*">>]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
Add SASL mechanism ANONYMOUS
## 1. Introduce new SASL mechanism ANONYMOUS
### What?
Introduce a new `rabbit_auth_mechanism` implementation for SASL
mechanism ANONYMOUS called `rabbit_auth_mechanism_anonymous`.
### Why?
As described in AMQP section 5.3.3.1, ANONYMOUS should be used when the
client doesn't need to authenticate.
Introducing a new `rabbit_auth_mechanism` consolidates and simplifies how anonymous
logins work across all RabbitMQ protocols that support SASL. This commit
therefore allows AMQP 0.9.1, AMQP 1.0, stream clients to connect out of
the box to RabbitMQ without providing any username or password.
Today's AMQP 0.9.1 and stream protocol client libs hard code RabbitMQ default credentials
`guest:guest` for example done in:
* https://github.com/rabbitmq/rabbitmq-java-client/blob/0215e85643a9ae0800822869be0200024e2ab569/src/main/java/com/rabbitmq/client/ConnectionFactory.java#L58-L61
* https://github.com/rabbitmq/amqp091-go/blob/ddb7a2f0685689063e6d709b8e417dbf9d09469c/uri.go#L31-L32
Hard coding RabbitMQ specific default credentials in dozens of different
client libraries is an anti-pattern in my opinion.
Furthermore, there are various AMQP 1.0 and MQTT client libraries which
we do not control or maintain and which still should work out of the box
when a user is getting started with RabbitMQ (that is without
providing `guest:guest` credentials).
### How?
The old RabbitMQ 3.13 AMQP 1.0 plugin `default_user`
[configuration](https://github.com/rabbitmq/rabbitmq-server/blob/146b4862d8e570b344c99c37d91246760e218b18/deps/rabbitmq_amqp1_0/Makefile#L6)
is replaced with the following two new `rabbit` configurations:
```
{anonymous_login_user, <<"guest">>},
{anonymous_login_pass, <<"guest">>},
```
We call it `anonymous_login_user` because this user will be used for
anonymous logins. The subsequent commit uses the same setting for
anonymous logins in MQTT. Hence, this user is orthogonal to the protocol
used when the client connects.
Setting `anonymous_login_pass` could have been left out.
This commit decides to include it because our documentation has so far
recommended:
> It is highly recommended to pre-configure a new user with a generated username and password or delete the guest user
> or at least change its password to reasonably secure generated value that won't be known to the public.
By having the new module `rabbit_auth_mechanism_anonymous` internally
authenticate with `anonymous_login_pass` instead of blindly allowing
access without any password, we protect operators that relied on the
sentence:
> or at least change its password to reasonably secure generated value that won't be known to the public
To ease the getting started experience, since RabbitMQ already deploys a
guest user with full access to the default virtual host `/`, this commit
also allows SASL mechanism ANONYMOUS in `rabbit` setting `auth_mechanisms`.
In production, operators should disable SASL mechanism ANONYMOUS by
setting `anonymous_login_user` to `none` (or by removing ANONYMOUS from
the `auth_mechanisms` setting. This will be documented separately.
Even if operators forget or don't read the docs, this new ANONYMOUS
mechanism won't do any harm because it relies on the default user name
`guest` and password `guest`, which is recommended against in
production, and who by default can only connect from the local host.
## 2. Require SASL security layer in AMQP 1.0
### What?
An AMQP 1.0 client must use the SASL security layer.
### Why?
This is in line with the mandatory usage of SASL in AMQP 0.9.1 and
RabbitMQ stream protocol.
Since (presumably) any AMQP 1.0 client knows how to authenticate with a
username and password using SASL mechanism PLAIN, any AMQP 1.0 client
also (presumably) implements the trivial SASL mechanism ANONYMOUS.
Skipping SASL is not recommended in production anyway.
By requiring SASL, configuration for operators becomes easier.
Following the principle of least surprise, when an an operator
configures `auth_mechanisms` to exclude `ANONYMOUS`, anonymous logins
will be prohibited in SASL and also by disallowing skipping the SASL
layer.
### How?
This commit implements AMQP 1.0 figure 2.13.
A follow-up commit needs to be pushed to `v3.13.x` which will use SASL
mechanism `anon` instead of `none` in the Erlang AMQP 1.0 client
such that AMQP 1.0 shovels running on 3.13 can connect to 4.0 RabbitMQ nodes.
2024-08-14 18:19:17 +08:00
|
|
|
{anonymous_login_user,
|
|
|
|
|
"anonymous_login_user = none",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{anonymous_login_user, none}]}],
|
|
|
|
|
[]},
|
2024-08-16 20:38:36 +08:00
|
|
|
|
|
|
|
|
{auth_mechanisms_ordered,
|
|
|
|
|
"auth_mechanisms.1 = PLAIN
|
|
|
|
|
auth_mechanisms.2 = AMQPLAIN
|
|
|
|
|
auth_mechanisms.3 = ANONYMOUS",
|
|
|
|
|
[],
|
|
|
|
|
[{rabbit,
|
|
|
|
|
%% We expect the mechanisms in the order as declared.
|
|
|
|
|
[{auth_mechanisms, ['PLAIN', 'AMQPLAIN', 'ANONYMOUS']}]
|
|
|
|
|
}],
|
|
|
|
|
[],
|
|
|
|
|
nosort
|
|
|
|
|
},
|
|
|
|
|
|
2017-06-05 21:12:23 +08:00
|
|
|
{cluster_formation,
|
|
|
|
|
"cluster_formation.peer_discovery_backend = rabbit_peer_discovery_classic_config
|
|
|
|
|
cluster_formation.classic_config.nodes.peer1 = rabbit@hostname1
|
|
|
|
|
cluster_formation.classic_config.nodes.peer2 = rabbit@hostname2
|
|
|
|
|
cluster_formation.node_type = disc",
|
2017-03-17 18:55:12 +08:00
|
|
|
[{rabbit,
|
2017-06-05 21:12:23 +08:00
|
|
|
[{cluster_formation,
|
2017-03-17 18:55:12 +08:00
|
|
|
[{peer_discovery_backend,rabbit_peer_discovery_classic_config},
|
|
|
|
|
{node_type,disc}]},
|
2019-01-10 02:55:55 +08:00
|
|
|
{cluster_nodes,{[rabbit@hostname2,rabbit@hostname1],disc}}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
2020-06-03 06:30:45 +08:00
|
|
|
|
|
|
|
|
{cluster_formation_module_classic_confog_alias,
|
|
|
|
|
"cluster_formation.peer_discovery_backend = classic_config
|
|
|
|
|
cluster_formation.classic_config.nodes.peer1 = rabbit@hostname1
|
|
|
|
|
cluster_formation.classic_config.nodes.peer2 = rabbit@hostname2",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{cluster_formation,
|
|
|
|
|
[{peer_discovery_backend,rabbit_peer_discovery_classic_config}]},
|
|
|
|
|
{cluster_nodes,{[rabbit@hostname2,rabbit@hostname1],disc}}]}],
|
|
|
|
|
[]},
|
2025-04-03 02:34:32 +08:00
|
|
|
|
2020-06-03 06:30:45 +08:00
|
|
|
{cluster_formation_module_dns_alias,
|
|
|
|
|
"cluster_formation.peer_discovery_backend = dns
|
|
|
|
|
cluster_formation.dns.hostname = discovery.eng.example.local",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[
|
|
|
|
|
{cluster_formation,
|
|
|
|
|
[{peer_discovery_backend,rabbit_peer_discovery_dns},
|
|
|
|
|
{peer_discovery_dns, [
|
|
|
|
|
{hostname, <<"discovery.eng.example.local">>}
|
|
|
|
|
]}]}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
2025-04-03 02:34:32 +08:00
|
|
|
|
2020-06-03 06:30:45 +08:00
|
|
|
{cluster_formation_disk,
|
2017-06-05 21:12:23 +08:00
|
|
|
"cluster_formation.peer_discovery_backend = rabbit_peer_discovery_classic_config
|
|
|
|
|
cluster_formation.classic_config.nodes.peer1 = rabbit@hostname1
|
|
|
|
|
cluster_formation.classic_config.nodes.peer2 = rabbit@hostname2
|
|
|
|
|
cluster_formation.node_type = disk",
|
2017-03-17 18:55:12 +08:00
|
|
|
[{rabbit,
|
2017-06-05 21:12:23 +08:00
|
|
|
[{cluster_formation,
|
2017-03-17 18:55:12 +08:00
|
|
|
[{peer_discovery_backend,rabbit_peer_discovery_classic_config},
|
|
|
|
|
{node_type,disc}]},
|
2019-01-10 02:55:55 +08:00
|
|
|
{cluster_nodes,{[rabbit@hostname2,rabbit@hostname1],disc}}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
2017-06-05 21:12:23 +08:00
|
|
|
{cluster_formation_ram_ignored,
|
2019-01-10 02:55:55 +08:00
|
|
|
"cluster_formation.node_type = ram",[],[]},
|
2021-11-03 06:40:05 +08:00
|
|
|
{cluster_formation_target_cluster_size_hint,
|
|
|
|
|
"cluster_formation.target_cluster_size_hint = 3",
|
|
|
|
|
[{rabbit, [
|
|
|
|
|
{cluster_formation, [
|
|
|
|
|
{target_cluster_size_hint, 3}
|
|
|
|
|
]}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2025-02-04 02:58:17 +08:00
|
|
|
%% registration is enabled by default for the backends that support it
|
2025-02-04 08:14:25 +08:00
|
|
|
{cluster_formation_explicitly_enable_registration,
|
2025-02-04 02:58:17 +08:00
|
|
|
"cluster_formation.registration.enabled = true",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{cluster_formation, [
|
|
|
|
|
{perform_registration, true}
|
|
|
|
|
]}]
|
|
|
|
|
}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{cluster_formation_opt_out_of_registration,
|
|
|
|
|
"cluster_formation.registration.enabled = false",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{cluster_formation, [
|
|
|
|
|
{perform_registration, false}
|
|
|
|
|
]}]
|
|
|
|
|
}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2017-03-17 18:55:12 +08:00
|
|
|
{tcp_listen_options,
|
|
|
|
|
"tcp_listen_options.backlog = 128
|
|
|
|
|
tcp_listen_options.nodelay = true
|
|
|
|
|
tcp_listen_options.exit_on_close = false",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{tcp_listen_options,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{backlog,128},{nodelay,true},{exit_on_close,false}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
Improve supported information units (Mi, Gi, Ti)
This revisits the information system conversion,
that is, support for suffixes like GiB, GB.
When configuration values like disk_free_limit.absolute,
vm_memory_high_watermark.absolute are set, the value
can contain an information unit (IU) suffix.
We now support several new suffixes and the meaning
a few more changes.
First, the changes:
* k, K now mean kilobytes and not kibibytes
* m, M now mean megabytes and not mebibytes
* g, G now means gigabytes and not gibibytes
This is to match the system used by Kubernetes.
There is no consensus in the industry about how
"k", "m", "g", and similar single letter suffixes
should be treated. Previously it was a power of 2,
now a power of 10 to align with a very popular OSS
project that explicitly documents what suffixes it supports.
Now, the additions:
Finally, the node will now validate these suffixes
at boot time, so an unsupported value will cause
the node to stop with a rabbitmq.conf validation
error.
The message logged will look like this:
````
2024-01-15 22:11:17.829272-05:00 [error] <0.164.0> disk_free_limit.absolute invalid, supported formats: 500MB, 500MiB, 10GB, 10GiB, 2TB, 2TiB, 10000000000
2024-01-15 22:11:17.829376-05:00 [error] <0.164.0> Error preparing configuration in phase validation:
2024-01-15 22:11:17.829387-05:00 [error] <0.164.0> - disk_free_limit.absolute invalid, supported formats: 500MB, 500MiB, 10GB, 10GiB, 2TB, 2TiB, 10000000000
````
Closes #10310
2024-01-16 11:11:57 +08:00
|
|
|
|
|
|
|
|
%%
|
|
|
|
|
%% Absolute high runtime memory watermark
|
|
|
|
|
%%
|
|
|
|
|
|
|
|
|
|
{vm_memory_watermark_absolute_integer,
|
2017-03-17 18:55:12 +08:00
|
|
|
"vm_memory_high_watermark.absolute = 1073741824",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{vm_memory_high_watermark,{absolute,1073741824}}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
Improve supported information units (Mi, Gi, Ti)
This revisits the information system conversion,
that is, support for suffixes like GiB, GB.
When configuration values like disk_free_limit.absolute,
vm_memory_high_watermark.absolute are set, the value
can contain an information unit (IU) suffix.
We now support several new suffixes and the meaning
a few more changes.
First, the changes:
* k, K now mean kilobytes and not kibibytes
* m, M now mean megabytes and not mebibytes
* g, G now means gigabytes and not gibibytes
This is to match the system used by Kubernetes.
There is no consensus in the industry about how
"k", "m", "g", and similar single letter suffixes
should be treated. Previously it was a power of 2,
now a power of 10 to align with a very popular OSS
project that explicitly documents what suffixes it supports.
Now, the additions:
Finally, the node will now validate these suffixes
at boot time, so an unsupported value will cause
the node to stop with a rabbitmq.conf validation
error.
The message logged will look like this:
````
2024-01-15 22:11:17.829272-05:00 [error] <0.164.0> disk_free_limit.absolute invalid, supported formats: 500MB, 500MiB, 10GB, 10GiB, 2TB, 2TiB, 10000000000
2024-01-15 22:11:17.829376-05:00 [error] <0.164.0> Error preparing configuration in phase validation:
2024-01-15 22:11:17.829387-05:00 [error] <0.164.0> - disk_free_limit.absolute invalid, supported formats: 500MB, 500MiB, 10GB, 10GiB, 2TB, 2TiB, 10000000000
````
Closes #10310
2024-01-16 11:11:57 +08:00
|
|
|
|
|
|
|
|
{vm_memory_watermark_absolute_units_mb,
|
2017-03-17 18:55:12 +08:00
|
|
|
"vm_memory_high_watermark.absolute = 1024MB",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{vm_memory_high_watermark,{absolute,"1024MB"}}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
Improve supported information units (Mi, Gi, Ti)
This revisits the information system conversion,
that is, support for suffixes like GiB, GB.
When configuration values like disk_free_limit.absolute,
vm_memory_high_watermark.absolute are set, the value
can contain an information unit (IU) suffix.
We now support several new suffixes and the meaning
a few more changes.
First, the changes:
* k, K now mean kilobytes and not kibibytes
* m, M now mean megabytes and not mebibytes
* g, G now means gigabytes and not gibibytes
This is to match the system used by Kubernetes.
There is no consensus in the industry about how
"k", "m", "g", and similar single letter suffixes
should be treated. Previously it was a power of 2,
now a power of 10 to align with a very popular OSS
project that explicitly documents what suffixes it supports.
Now, the additions:
Finally, the node will now validate these suffixes
at boot time, so an unsupported value will cause
the node to stop with a rabbitmq.conf validation
error.
The message logged will look like this:
````
2024-01-15 22:11:17.829272-05:00 [error] <0.164.0> disk_free_limit.absolute invalid, supported formats: 500MB, 500MiB, 10GB, 10GiB, 2TB, 2TiB, 10000000000
2024-01-15 22:11:17.829376-05:00 [error] <0.164.0> Error preparing configuration in phase validation:
2024-01-15 22:11:17.829387-05:00 [error] <0.164.0> - disk_free_limit.absolute invalid, supported formats: 500MB, 500MiB, 10GB, 10GiB, 2TB, 2TiB, 10000000000
````
Closes #10310
2024-01-16 11:11:57 +08:00
|
|
|
{vm_memory_watermark_absolute_units_mib,
|
|
|
|
|
"vm_memory_high_watermark.absolute = 1024MiB",
|
|
|
|
|
[{rabbit,[{vm_memory_high_watermark,{absolute,"1024MiB"}}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{vm_memory_watermark_absolute_units_m,
|
|
|
|
|
"vm_memory_high_watermark.absolute = 1024M",
|
|
|
|
|
[{rabbit,[{vm_memory_high_watermark,{absolute,"1024M"}}]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{vm_memory_watermark_absolute_units_gb,
|
|
|
|
|
"vm_memory_high_watermark.absolute = 4GB",
|
|
|
|
|
[{rabbit,[{vm_memory_high_watermark,{absolute,"4GB"}}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{vm_memory_watermark_absolute_units_gib,
|
|
|
|
|
"vm_memory_high_watermark.absolute = 3GiB",
|
|
|
|
|
[{rabbit,[{vm_memory_high_watermark,{absolute,"3GiB"}}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{vm_memory_watermark_absolute_units_g,
|
|
|
|
|
"vm_memory_high_watermark.absolute = 10G",
|
|
|
|
|
[{rabbit,[{vm_memory_high_watermark,{absolute,"10G"}}]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{vm_memory_watermark_absolute_units_tb,
|
|
|
|
|
"vm_memory_high_watermark.absolute = 1TB",
|
|
|
|
|
[{rabbit,[{vm_memory_high_watermark,{absolute,"1TB"}}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{vm_memory_watermark_absolute_units_tib,
|
|
|
|
|
"vm_memory_high_watermark.absolute = 1TiB",
|
|
|
|
|
[{rabbit,[{vm_memory_high_watermark,{absolute,"1TiB"}}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{vm_memory_watermark_absolute_units_t,
|
|
|
|
|
"vm_memory_high_watermark.absolute = 1T",
|
|
|
|
|
[{rabbit,[{vm_memory_high_watermark,{absolute,"1T"}}]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2022-11-29 08:32:00 +08:00
|
|
|
{vm_memory_watermark_absolute_priority,
|
|
|
|
|
"vm_memory_high_watermark.absolute = 1073741824
|
|
|
|
|
vm_memory_high_watermark.relative = 0.4",
|
|
|
|
|
[{rabbit,[{vm_memory_high_watermark,{absolute,1073741824}}]}],
|
|
|
|
|
[]},
|
2024-08-27 23:35:22 +08:00
|
|
|
%% DEPRECATED; just for backwards compatibility
|
2017-03-17 18:55:12 +08:00
|
|
|
{vm_memory_watermark_paging_ratio,
|
|
|
|
|
"vm_memory_high_watermark_paging_ratio = 0.75
|
|
|
|
|
vm_memory_high_watermark.relative = 0.4",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{vm_memory_high_watermark_paging_ratio,0.75},
|
2019-01-10 02:55:55 +08:00
|
|
|
{vm_memory_high_watermark,0.4}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
2024-08-27 23:35:22 +08:00
|
|
|
%% DEPRECATED; just for backwards compatibility
|
2017-06-14 22:31:40 +08:00
|
|
|
{memory_monitor_interval, "memory_monitor_interval = 5000",
|
|
|
|
|
[{rabbit,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{memory_monitor_interval, 5000}]}],
|
2017-06-14 22:31:40 +08:00
|
|
|
[]},
|
|
|
|
|
{vm_memory_calculation_strategy, "vm_memory_calculation_strategy = rss",
|
|
|
|
|
[{rabbit,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{vm_memory_calculation_strategy, rss}]}],
|
2017-06-14 22:31:40 +08:00
|
|
|
[]},
|
|
|
|
|
{vm_memory_calculation_strategy, "vm_memory_calculation_strategy = erlang",
|
|
|
|
|
[{rabbit,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{vm_memory_calculation_strategy, erlang}]}],
|
2017-06-14 22:31:40 +08:00
|
|
|
[]},
|
2017-10-12 23:11:03 +08:00
|
|
|
{vm_memory_calculation_strategy, "vm_memory_calculation_strategy = allocated",
|
|
|
|
|
[{rabbit,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{vm_memory_calculation_strategy, allocated}]}],
|
2017-10-12 23:11:03 +08:00
|
|
|
[]},
|
|
|
|
|
{vm_memory_calculation_strategy, "vm_memory_calculation_strategy = legacy",
|
|
|
|
|
[{rabbit,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{vm_memory_calculation_strategy, legacy}]}],
|
2017-10-12 23:11:03 +08:00
|
|
|
[]},
|
2017-12-08 12:17:48 +08:00
|
|
|
{total_memory_available_override_value,
|
|
|
|
|
"total_memory_available_override_value = 1000000000",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{total_memory_available_override_value, 1000000000}]}],
|
2017-12-08 12:17:48 +08:00
|
|
|
[]},
|
|
|
|
|
{total_memory_available_override_value_units,
|
|
|
|
|
"total_memory_available_override_value = 1024MB",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{total_memory_available_override_value, "1024MB"}]}],
|
2017-12-08 12:17:48 +08:00
|
|
|
[]},
|
2023-03-29 08:07:57 +08:00
|
|
|
{ranch_connection_max,
|
|
|
|
|
"ranch_connection_max = 999",
|
|
|
|
|
[{rabbit,[{ranch_connection_max, 999}]}],
|
2017-10-22 04:48:08 +08:00
|
|
|
[]},
|
2023-03-29 08:07:57 +08:00
|
|
|
{ranch_connection_max,
|
|
|
|
|
"ranch_connection_max = infinity",
|
|
|
|
|
[{rabbit,[{ranch_connection_max, infinity}]}],
|
2017-10-22 04:48:08 +08:00
|
|
|
[]},
|
|
|
|
|
{channel_max,
|
|
|
|
|
"channel_max = 16",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{channel_max, 16}]}],
|
2017-10-22 04:48:08 +08:00
|
|
|
[]},
|
2024-01-17 03:41:13 +08:00
|
|
|
{channel_max_per_node,
|
|
|
|
|
"channel_max_per_node = 16",
|
|
|
|
|
[{rabbit,[{channel_max_per_node, 16}]}],
|
|
|
|
|
[]},
|
2024-01-18 04:19:38 +08:00
|
|
|
{channel_max_per_node,
|
|
|
|
|
"channel_max_per_node = infinity",
|
|
|
|
|
[{rabbit,[{channel_max_per_node, infinity}]}],
|
|
|
|
|
[]},
|
2024-09-06 16:12:24 +08:00
|
|
|
{session_max_per_connection_1,
|
|
|
|
|
"session_max_per_connection = 1",
|
|
|
|
|
[{rabbit,[{session_max_per_connection, 1}]}],
|
2024-09-05 23:45:27 +08:00
|
|
|
[]},
|
2024-09-06 16:12:24 +08:00
|
|
|
{session_max_per_connection,
|
|
|
|
|
"session_max_per_connection = 65000",
|
|
|
|
|
[{rabbit,[{session_max_per_connection, 65_000}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{link_max_per_session_1,
|
|
|
|
|
"link_max_per_session = 1",
|
|
|
|
|
[{rabbit,[{link_max_per_session, 1}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{link_max_per_session,
|
|
|
|
|
"link_max_per_session = 4200000000",
|
|
|
|
|
[{rabbit,[{link_max_per_session, 4_200_000_000}]}],
|
2024-09-05 23:45:27 +08:00
|
|
|
[]},
|
2024-03-15 07:09:26 +08:00
|
|
|
{consumer_max_per_channel,
|
|
|
|
|
"consumer_max_per_channel = 16",
|
|
|
|
|
[{rabbit,[{consumer_max_per_channel, 16}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{consumer_max_per_channel,
|
|
|
|
|
"consumer_max_per_channel = infinity",
|
|
|
|
|
[{rabbit,[{consumer_max_per_channel, infinity}]}],
|
|
|
|
|
[]},
|
2019-01-09 22:43:48 +08:00
|
|
|
{max_message_size,
|
|
|
|
|
"max_message_size = 131072",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit, [{max_message_size, 131072}]}],
|
2019-01-09 22:43:48 +08:00
|
|
|
[]},
|
2017-03-17 18:55:12 +08:00
|
|
|
{listeners_tcp_ip,
|
|
|
|
|
"listeners.tcp.1 = 192.168.1.99:5672",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{tcp_listeners,[{"192.168.1.99",5672}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{listeners_tcp_ip_multiple,
|
|
|
|
|
"listeners.tcp.1 = 127.0.0.1:5672
|
|
|
|
|
listeners.tcp.2 = ::1:5672",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{tcp_listeners,[{"127.0.0.1",5672},{"::1",5672}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{listeners_tcp_ip_all,"listeners.tcp.1 = :::5672",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{tcp_listeners,[{"::",5672}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{listeners_tcp_ipv6,
|
|
|
|
|
"listeners.tcp.1 = fe80::2acf:e9ff:fe17:f97b:5672",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{tcp_listeners,[{"fe80::2acf:e9ff:fe17:f97b",5672}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{tcp_options_sndbuf,
|
|
|
|
|
"tcp_listen_options.backlog = 128
|
|
|
|
|
tcp_listen_options.nodelay = true
|
|
|
|
|
tcp_listen_options.sndbuf = 196608
|
|
|
|
|
tcp_listen_options.recbuf = 196608",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{tcp_listen_options,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{backlog,128},{nodelay,true},{sndbuf,196608},{recbuf,196608}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{tcp_listen_options_nodelay_with_kernel,
|
|
|
|
|
"tcp_listen_options.backlog = 4096
|
|
|
|
|
tcp_listen_options.nodelay = true",
|
|
|
|
|
[{kernel,
|
|
|
|
|
[{inet_default_connect_options,[{nodelay,true}]},
|
|
|
|
|
{inet_default_listen_options,[{nodelay,true}]}]}],
|
|
|
|
|
[{kernel,
|
|
|
|
|
[{inet_default_connect_options,[{nodelay,true}]},
|
|
|
|
|
{inet_default_listen_options,[{nodelay,true}]}]},
|
2019-01-10 02:55:55 +08:00
|
|
|
{rabbit,[{tcp_listen_options,[{backlog,4096},{nodelay,true}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{tcp_listen_options_nodelay,
|
|
|
|
|
"tcp_listen_options.backlog = 4096
|
|
|
|
|
tcp_listen_options.nodelay = true",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{tcp_listen_options,[{backlog,4096},{nodelay,true}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{ssl_handshake_timeout,
|
|
|
|
|
"ssl_handshake_timeout = 10000",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{ssl_handshake_timeout,10000}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{cluster_partition_handling_pause_if_all_down,
|
|
|
|
|
"cluster_partition_handling = pause_if_all_down
|
|
|
|
|
|
|
|
|
|
## Recover strategy. Can be either 'autoheal' or 'ignore'
|
|
|
|
|
cluster_partition_handling.pause_if_all_down.recover = ignore
|
|
|
|
|
|
|
|
|
|
## Node names to check
|
|
|
|
|
cluster_partition_handling.pause_if_all_down.nodes.1 = rabbit@myhost1
|
|
|
|
|
cluster_partition_handling.pause_if_all_down.nodes.2 = rabbit@myhost2",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{cluster_partition_handling,
|
2019-01-10 02:55:55 +08:00
|
|
|
{pause_if_all_down,[rabbit@myhost2,rabbit@myhost1],ignore}}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{cluster_partition_handling_autoheal,
|
|
|
|
|
"cluster_partition_handling = autoheal",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{cluster_partition_handling,autoheal}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{password_hashing,
|
|
|
|
|
"password_hashing_module = rabbit_password_hashing_sha512",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{password_hashing_module,rabbit_password_hashing_sha512}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{ssl_options_verify_peer,
|
|
|
|
|
"listeners.ssl.1 = 5671
|
|
|
|
|
ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.verify = verify_peer
|
|
|
|
|
ssl_options.fail_if_no_peer_cert = false",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{ssl_listeners,[5671]},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
|
|
|
|
{verify,verify_peer},
|
2019-01-10 02:55:55 +08:00
|
|
|
{fail_if_no_peer_cert,false}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{ssl_options_password,
|
|
|
|
|
"listeners.ssl.1 = 5671
|
|
|
|
|
ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.password = t0p$3kRe7",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{ssl_listeners,[5671]},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
2024-08-14 04:27:00 +08:00
|
|
|
{password,<<"t0p$3kRe7">>}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{ssl_options_tls_ver_old,
|
|
|
|
|
"listeners.ssl.1 = 5671
|
|
|
|
|
ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.versions.tls1_2 = tlsv1.2
|
|
|
|
|
ssl_options.versions.tls1_1 = tlsv1.1
|
|
|
|
|
ssl_options.versions.tls1 = tlsv1",
|
|
|
|
|
[{ssl,[{versions,['tlsv1.2','tlsv1.1',tlsv1]}]}],
|
|
|
|
|
[{ssl,[{versions,['tlsv1.2','tlsv1.1',tlsv1]}]},
|
|
|
|
|
{rabbit,
|
|
|
|
|
[{ssl_listeners,[5671]},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
2019-01-10 02:55:55 +08:00
|
|
|
{versions,['tlsv1.2','tlsv1.1',tlsv1]}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{ssl_options_tls_ver_new,
|
|
|
|
|
"listeners.ssl.1 = 5671
|
|
|
|
|
ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.versions.tls1_2 = tlsv1.2
|
|
|
|
|
ssl_options.versions.tls1_1 = tlsv1.1",
|
|
|
|
|
[{ssl,[{versions,['tlsv1.2','tlsv1.1']}]}],
|
|
|
|
|
[{ssl,[{versions,['tlsv1.2','tlsv1.1']}]},
|
|
|
|
|
{rabbit,
|
|
|
|
|
[{ssl_listeners,[5671]},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
2019-01-10 02:55:55 +08:00
|
|
|
{versions,['tlsv1.2','tlsv1.1']}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
2018-10-23 21:38:08 +08:00
|
|
|
|
|
|
|
|
{ssl_options_ciphers,
|
|
|
|
|
"listeners.ssl.1 = 5671
|
|
|
|
|
ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.versions.1 = tlsv1.2
|
|
|
|
|
ssl_options.versions.2 = tlsv1.1
|
|
|
|
|
ssl_options.ciphers.1 = ECDHE-ECDSA-AES256-GCM-SHA384
|
|
|
|
|
ssl_options.ciphers.2 = ECDHE-RSA-AES256-GCM-SHA384
|
|
|
|
|
ssl_options.ciphers.3 = ECDHE-ECDSA-AES256-SHA384
|
|
|
|
|
ssl_options.ciphers.4 = ECDHE-RSA-AES256-SHA384
|
|
|
|
|
ssl_options.ciphers.5 = ECDH-ECDSA-AES256-GCM-SHA384
|
|
|
|
|
ssl_options.ciphers.6 = ECDH-RSA-AES256-GCM-SHA384
|
|
|
|
|
ssl_options.ciphers.7 = ECDH-ECDSA-AES256-SHA384
|
|
|
|
|
ssl_options.ciphers.8 = ECDH-RSA-AES256-SHA384
|
|
|
|
|
ssl_options.ciphers.9 = DHE-RSA-AES256-GCM-SHA384",
|
|
|
|
|
[{ssl,[{versions,['tlsv1.2','tlsv1.1']}]}],
|
|
|
|
|
[{ssl,[{versions,['tlsv1.2','tlsv1.1']}]},
|
|
|
|
|
{rabbit,
|
|
|
|
|
[{ssl_listeners,[5671]},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{ciphers, [
|
2019-01-01 03:23:42 +08:00
|
|
|
"ECDHE-ECDSA-AES256-GCM-SHA384",
|
|
|
|
|
"ECDHE-RSA-AES256-GCM-SHA384",
|
|
|
|
|
"ECDHE-ECDSA-AES256-SHA384",
|
|
|
|
|
"ECDHE-RSA-AES256-SHA384",
|
2018-10-23 21:38:08 +08:00
|
|
|
"ECDH-ECDSA-AES256-GCM-SHA384",
|
|
|
|
|
"ECDH-RSA-AES256-GCM-SHA384",
|
2019-01-01 03:23:42 +08:00
|
|
|
"ECDH-ECDSA-AES256-SHA384",
|
2018-10-23 21:38:08 +08:00
|
|
|
"ECDH-RSA-AES256-SHA384",
|
2019-01-01 03:23:42 +08:00
|
|
|
"DHE-RSA-AES256-GCM-SHA384"
|
2018-10-23 21:38:08 +08:00
|
|
|
]},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
2019-01-10 02:55:55 +08:00
|
|
|
{versions,['tlsv1.2','tlsv1.1']}]}]}],
|
2018-10-23 21:38:08 +08:00
|
|
|
[]},
|
|
|
|
|
|
2017-03-17 18:55:12 +08:00
|
|
|
{ssl_options_allow_poodle,
|
|
|
|
|
"listeners.ssl.1 = 5671
|
|
|
|
|
ssl_allow_poodle_attack = true
|
|
|
|
|
ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.verify = verify_peer
|
|
|
|
|
ssl_options.fail_if_no_peer_cert = false",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{ssl_listeners,[5671]},
|
|
|
|
|
{ssl_allow_poodle_attack,true},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
|
|
|
|
{verify,verify_peer},
|
2019-01-10 02:55:55 +08:00
|
|
|
{fail_if_no_peer_cert,false}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{ssl_options_depth,
|
|
|
|
|
"listeners.ssl.1 = 5671
|
|
|
|
|
ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.depth = 2
|
|
|
|
|
ssl_options.verify = verify_peer
|
|
|
|
|
ssl_options.fail_if_no_peer_cert = false",
|
2020-11-04 21:06:55 +08:00
|
|
|
[{rabbit,
|
|
|
|
|
[{ssl_listeners,[5671]},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
|
|
|
|
{depth,2},
|
|
|
|
|
{verify,verify_peer},
|
|
|
|
|
{fail_if_no_peer_cert,false}]}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{ssl_options_depth_0,
|
|
|
|
|
"listeners.ssl.1 = 5671
|
|
|
|
|
ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.depth = 0
|
|
|
|
|
ssl_options.verify = verify_peer
|
|
|
|
|
ssl_options.fail_if_no_peer_cert = false",
|
2017-03-17 18:55:12 +08:00
|
|
|
[{rabbit,
|
|
|
|
|
[{ssl_listeners,[5671]},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
2020-11-04 21:09:09 +08:00
|
|
|
{depth,0},
|
2017-03-17 18:55:12 +08:00
|
|
|
{verify,verify_peer},
|
2019-01-10 02:55:55 +08:00
|
|
|
{fail_if_no_peer_cert,false}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
2020-11-04 21:44:05 +08:00
|
|
|
{ssl_options_depth_255,
|
|
|
|
|
"listeners.ssl.1 = 5671
|
|
|
|
|
ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.depth = 255
|
|
|
|
|
ssl_options.verify = verify_peer
|
|
|
|
|
ssl_options.fail_if_no_peer_cert = false",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{ssl_listeners,[5671]},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
|
|
|
|
{depth,255},
|
|
|
|
|
{verify,verify_peer},
|
|
|
|
|
{fail_if_no_peer_cert,false}]}]}],
|
|
|
|
|
[]},
|
2017-06-24 04:51:16 +08:00
|
|
|
{ssl_options_honor_cipher_order,
|
|
|
|
|
"listeners.ssl.1 = 5671
|
|
|
|
|
ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.depth = 2
|
|
|
|
|
ssl_options.verify = verify_peer
|
|
|
|
|
ssl_options.fail_if_no_peer_cert = false
|
|
|
|
|
ssl_options.honor_cipher_order = true",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{ssl_listeners,[5671]},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
|
|
|
|
{depth,2},
|
|
|
|
|
{verify,verify_peer},
|
|
|
|
|
{fail_if_no_peer_cert, false},
|
2019-01-10 02:55:55 +08:00
|
|
|
{honor_cipher_order, true}]}]}],
|
2017-06-24 04:51:16 +08:00
|
|
|
[]},
|
|
|
|
|
{ssl_options_honor_ecc_order,
|
|
|
|
|
"listeners.ssl.1 = 5671
|
|
|
|
|
ssl_options.cacertfile = test/config_schema_SUITE_data/certs/cacert.pem
|
|
|
|
|
ssl_options.certfile = test/config_schema_SUITE_data/certs/cert.pem
|
|
|
|
|
ssl_options.keyfile = test/config_schema_SUITE_data/certs/key.pem
|
|
|
|
|
ssl_options.depth = 2
|
|
|
|
|
ssl_options.verify = verify_peer
|
|
|
|
|
ssl_options.fail_if_no_peer_cert = false
|
|
|
|
|
ssl_options.honor_ecc_order = true",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{ssl_listeners,[5671]},
|
|
|
|
|
{ssl_options,
|
|
|
|
|
[{cacertfile,"test/config_schema_SUITE_data/certs/cacert.pem"},
|
|
|
|
|
{certfile,"test/config_schema_SUITE_data/certs/cert.pem"},
|
|
|
|
|
{keyfile,"test/config_schema_SUITE_data/certs/key.pem"},
|
|
|
|
|
{depth,2},
|
|
|
|
|
{verify,verify_peer},
|
|
|
|
|
{fail_if_no_peer_cert, false},
|
2019-01-10 02:55:55 +08:00
|
|
|
{honor_ecc_order, true}]}]}],
|
2017-06-24 04:51:16 +08:00
|
|
|
[]},
|
2025-04-03 02:34:32 +08:00
|
|
|
|
2020-10-30 06:22:38 +08:00
|
|
|
{ssl_cert_login_from_cn,
|
2017-03-17 18:55:12 +08:00
|
|
|
"ssl_cert_login_from = common_name",
|
2020-10-30 06:22:38 +08:00
|
|
|
[{rabbit,[{ssl_cert_login_from, common_name}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
2025-04-03 02:34:32 +08:00
|
|
|
|
2020-10-30 06:22:38 +08:00
|
|
|
{ssl_cert_login_from_dn,
|
|
|
|
|
"ssl_cert_login_from = distinguished_name",
|
|
|
|
|
[{rabbit,[{ssl_cert_login_from, distinguished_name}]}],
|
|
|
|
|
[]},
|
2025-04-03 02:34:32 +08:00
|
|
|
|
2020-10-30 06:22:38 +08:00
|
|
|
{ssl_cert_login_from_san_dns,
|
|
|
|
|
"ssl_cert_login_from = subject_alternative_name
|
|
|
|
|
ssl_cert_login_san_type = dns
|
|
|
|
|
ssl_cert_login_san_index = 0",
|
|
|
|
|
[{rabbit,[
|
|
|
|
|
{ssl_cert_login_from, subject_alternative_name},
|
|
|
|
|
{ssl_cert_login_san_type, dns},
|
|
|
|
|
{ssl_cert_login_san_index, 0}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
2025-04-03 02:34:32 +08:00
|
|
|
|
2020-12-17 23:53:14 +08:00
|
|
|
|
|
|
|
|
{ssl_options_bypass_pem_cache,
|
|
|
|
|
"ssl_options.bypass_pem_cache = true",
|
|
|
|
|
[{ssl, [
|
|
|
|
|
{bypass_pem_cache, true}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2017-03-17 18:55:12 +08:00
|
|
|
{tcp_listen_options_linger_on,
|
|
|
|
|
"tcp_listen_options.linger.on = true
|
|
|
|
|
tcp_listen_options.linger.timeout = 100",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{tcp_listen_options,[{linger,{true,100}}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{tcp_listen_options_linger_off,
|
|
|
|
|
"tcp_listen_options.linger.on = false
|
|
|
|
|
tcp_listen_options.linger.timeout = 100",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{tcp_listen_options,[{linger,{false,100}}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{tcp_listen_options_linger_on_notimeout,
|
|
|
|
|
"tcp_listen_options.linger.on = true",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{tcp_listen_options,[{linger,{true,0}}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{tcp_listen_options_linger_timeout,
|
|
|
|
|
"tcp_listen_options.linger.timeout = 100",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{tcp_listen_options,[{linger,{false,100}}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
2017-09-11 12:31:25 +08:00
|
|
|
|
Remove randomized startup delays
On initial cluster formation, only one node in a multi node cluster
should initialize the Mnesia database schema (i.e. form the cluster).
To ensure that for nodes starting up in parallel,
RabbitMQ peer discovery backends have used
either locks or randomized startup delays.
Locks work great: When a node holds the lock, it either starts a new
blank node (if there is no other node in the cluster), or it joins
an existing node. This makes it impossible to have two nodes forming
the cluster at the same time.
Consul and etcd peer discovery backends use locks. The lock is acquired
in the consul and etcd infrastructure, respectively.
For other peer discovery backends (classic, DNS, AWS), randomized
startup delays were used. They work good enough in most cases.
However, in https://github.com/rabbitmq/cluster-operator/issues/662 we
observed that in 1% - 10% of the cases (the more nodes or the
smaller the randomized startup delay range, the higher the chances), two
nodes decide to form the cluster. That's bad since it will end up in a
single Erlang cluster, but in two RabbitMQ clusters. Even worse, no
obvious alert got triggered or error message logged.
To solve this issue, one could increase the randomized startup delay
range from e.g. 0m - 1m to 0m - 3m. However, this makes initial cluster
formation very slow since it will take up to 3 minutes until
every node is ready. In rare cases, we still end up with two nodes
forming the cluster.
Another way to solve the problem is to name a dedicated node to be the
seed node (forming the cluster). This was explored in
https://github.com/rabbitmq/cluster-operator/pull/689 and works well.
Two minor downsides to this approach are: 1. If the seed node never
becomes available, the whole cluster won't be formed (which is okay),
and 2. it doesn't integrate with existing dynamic peer discovery backends
(e.g. K8s, AWS) since nodes are not yet known at deploy time.
In this commit, we take a better approach: We remove randomized startup
delays altogether. We replace them with locks. However, instead of
implementing our own lock implementation in an external system (e.g. in K8s),
we re-use Erlang's locking mechanism global:set_lock/3.
global:set_lock/3 has some convenient properties:
1. It accepts a list of nodes to set the lock on.
2. The nodes in that list connect to each other (i.e. create an Erlang
cluster).
3. The method is synchronous with a timeout (number of retries). It
blocks until the lock becomes available.
4. If a process that holds a lock dies, or the node goes down, the lock
held by the process is deleted.
The list of nodes passed to global:set_lock/3 corresponds to the nodes
the peer discovery backend discovers (lists).
Two special cases worth mentioning:
1. That list can be all desired nodes in the cluster
(e.g. in classic peer discovery where nodes are known at
deploy time) while only a subset of nodes is available.
In that case, global:set_lock/3 still sets the lock not
blocking until all nodes can be connected to. This is good since
nodes might start sequentially (non-parallel).
2. In dynamic peer discovery backends (e.g. K8s, AWS), this
list can be just a subset of desired nodes since nodes might not startup
in parallel. That's also not a problem as long as the following
requirement is met: "The peer disovery backend does not list two disjoint
sets of nodes (on different nodes) at the same time."
For example, in a 2-node cluster, the peer discovery backend must not
list only node 1 on node 1 and only node 2 on node 2.
Existing peer discovery backends fullfil that requirement because the
resource the nodes are discovered from is global.
For example, in K8s, once node 1 is part of the Endpoints object, it
will be returned on both node 1 and node 2.
Likewise, in AWS, once node 1 started, the described list of instances
with a specific tag will include node 1 when the AWS peer discovery backend
runs on node 1 or node 2.
Removing randomized startup delays also makes cluster formation
considerably faster (up to 1 minute faster if that was the
upper bound in the range).
2021-05-18 07:01:08 +08:00
|
|
|
{cluster_formation_internal_lock_retries,
|
|
|
|
|
"cluster_formation.internal_lock_retries = 10",
|
|
|
|
|
[{rabbit,[{cluster_formation,[{internal_lock_retries,10}]}]}],
|
2017-09-11 12:31:25 +08:00
|
|
|
[]},
|
|
|
|
|
|
2017-06-05 21:12:23 +08:00
|
|
|
{cluster_formation_dns,
|
|
|
|
|
"cluster_formation.peer_discovery_backend = rabbit_peer_discovery_dns
|
|
|
|
|
cluster_formation.dns.hostname = 192.168.0.2.xip.io
|
|
|
|
|
cluster_formation.node_type = disc",
|
2017-03-17 18:55:12 +08:00
|
|
|
[{rabbit,
|
2017-06-05 21:12:23 +08:00
|
|
|
[{cluster_formation,
|
2017-03-17 18:55:12 +08:00
|
|
|
[{peer_discovery_dns,[{hostname,<<"192.168.0.2.xip.io">>}]},
|
|
|
|
|
{peer_discovery_backend,rabbit_peer_discovery_dns},
|
2019-01-10 02:55:55 +08:00
|
|
|
{node_type,disc}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
2017-06-05 21:12:23 +08:00
|
|
|
{cluster_formation_classic,
|
|
|
|
|
"cluster_formation.peer_discovery_backend = rabbit_peer_discovery_classic_config
|
|
|
|
|
cluster_formation.node_type = disc",
|
2017-03-17 18:55:12 +08:00
|
|
|
[{rabbit,
|
2017-06-05 21:12:23 +08:00
|
|
|
[{cluster_formation,
|
2017-03-17 18:55:12 +08:00
|
|
|
[{peer_discovery_backend,rabbit_peer_discovery_classic_config},
|
2019-01-10 02:55:55 +08:00
|
|
|
{node_type,disc}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
2017-06-05 21:12:23 +08:00
|
|
|
{cluster_formation_classic_ram,
|
|
|
|
|
"cluster_formation.peer_discovery_backend = rabbit_peer_discovery_classic_config
|
|
|
|
|
cluster_formation.node_type = ram",
|
2017-03-17 18:55:12 +08:00
|
|
|
[{rabbit,
|
2017-06-05 21:12:23 +08:00
|
|
|
[{cluster_formation,
|
2017-03-17 18:55:12 +08:00
|
|
|
[{peer_discovery_backend,rabbit_peer_discovery_classic_config},
|
2019-01-10 02:55:55 +08:00
|
|
|
{node_type,ram}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
2025-04-03 02:34:32 +08:00
|
|
|
{cluster_formation_retry_limit_integer,
|
|
|
|
|
"cluster_formation.discovery_retry_limit = 500",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{cluster_formation,
|
|
|
|
|
[{discovery_retry_limit, 500}]}]}],
|
|
|
|
|
[]},
|
|
|
|
|
{cluster_formation_retry_limit_infinity,
|
|
|
|
|
"cluster_formation.discovery_retry_limit = unlimited",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{cluster_formation,
|
|
|
|
|
[{discovery_retry_limit, unlimited}]}]}],
|
|
|
|
|
[]},
|
2017-03-17 18:55:12 +08:00
|
|
|
{background_gc_enabled,
|
|
|
|
|
"background_gc_enabled = true
|
|
|
|
|
background_gc_target_interval = 30000",
|
|
|
|
|
[{rabbit,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{background_gc_enabled,true},{background_gc_target_interval,30000}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{background_gc_disabled,
|
|
|
|
|
"background_gc_enabled = false
|
|
|
|
|
background_gc_target_interval = 30000",
|
|
|
|
|
[{rabbit,
|
2019-01-10 02:55:55 +08:00
|
|
|
[{background_gc_enabled,false},{background_gc_target_interval,30000}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{credential_validator_length,
|
|
|
|
|
"credential_validator.validation_backend = rabbit_credential_validator_min_password_length
|
|
|
|
|
credential_validator.min_length = 10",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{credential_validator,
|
|
|
|
|
[{validation_backend,
|
|
|
|
|
rabbit_credential_validator_min_password_length},
|
2019-01-10 02:55:55 +08:00
|
|
|
{min_length,10}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{credential_validator_regexp,
|
|
|
|
|
"credential_validator.validation_backend = rabbit_credential_validator_password_regexp
|
|
|
|
|
credential_validator.regexp = ^abc\\d+",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{credential_validator,
|
|
|
|
|
[{validation_backend,rabbit_credential_validator_password_regexp},
|
2019-01-10 02:55:55 +08:00
|
|
|
{regexp,"^abc\\d+"}]}]}],
|
2017-03-17 18:55:12 +08:00
|
|
|
[]},
|
|
|
|
|
{proxy_protocol_on,
|
|
|
|
|
"proxy_protocol = true",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{proxy_protocol,true}]}],[]},
|
2017-03-17 18:55:12 +08:00
|
|
|
{proxy_protocol_off,
|
|
|
|
|
"proxy_protocol = false",
|
2019-01-10 02:55:55 +08:00
|
|
|
[{rabbit,[{proxy_protocol,false}]}],[]},
|
2019-06-13 21:55:16 +08:00
|
|
|
|
|
|
|
|
{default_worker_pool_size,
|
|
|
|
|
"default_worker_pool_size = 512",
|
|
|
|
|
[{rabbit, [
|
|
|
|
|
{default_worker_pool_size, 512}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2018-02-07 06:40:33 +08:00
|
|
|
{delegate_count,
|
|
|
|
|
"delegate_count = 64",
|
|
|
|
|
[{rabbit, [
|
|
|
|
|
{delegate_count, 64}
|
2019-01-10 02:55:55 +08:00
|
|
|
]}],
|
2018-02-22 18:25:45 +08:00
|
|
|
[]},
|
2018-12-02 17:23:30 +08:00
|
|
|
|
2018-02-22 18:25:45 +08:00
|
|
|
{kernel_net_ticktime,
|
|
|
|
|
"net_ticktime = 20",
|
|
|
|
|
[{kernel, [
|
|
|
|
|
{net_ticktime, 20}
|
2019-01-10 02:55:55 +08:00
|
|
|
]}],
|
2018-05-17 22:35:41 +08:00
|
|
|
[]},
|
2018-12-02 17:23:30 +08:00
|
|
|
|
2019-11-15 01:01:12 +08:00
|
|
|
{rabbit_consumer_timeout,
|
|
|
|
|
"consumer_timeout = 20000",
|
|
|
|
|
[{rabbit, [
|
|
|
|
|
{consumer_timeout, 20000}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2020-06-04 01:36:17 +08:00
|
|
|
{rabbit_msg_store_shutdown_timeout,
|
2020-06-04 01:27:05 +08:00
|
|
|
"message_store_shutdown_timeout = 600000",
|
|
|
|
|
[{rabbit, [
|
2020-06-04 01:36:17 +08:00
|
|
|
{msg_store_shutdown_timeout, 600000}
|
2020-06-04 01:27:05 +08:00
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{rabbit_mnesia_table_loading_retry_timeout,
|
|
|
|
|
"mnesia_table_loading_retry_timeout = 45000",
|
|
|
|
|
[{rabbit, [
|
|
|
|
|
{mnesia_table_loading_retry_timeout, 45000}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2019-11-12 09:12:55 +08:00
|
|
|
%%
|
|
|
|
|
%% Definitions
|
|
|
|
|
%%
|
|
|
|
|
|
2021-08-14 19:53:45 +08:00
|
|
|
%% classic configuration key, implies a local filesystem path
|
2019-11-12 09:12:55 +08:00
|
|
|
{definition_files, "load_definitions = test/definition_import_SUITE_data/case1.json",
|
|
|
|
|
[{rabbit,
|
|
|
|
|
[{load_definitions, "test/definition_import_SUITE_data/case1.json"}]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2021-08-14 19:53:45 +08:00
|
|
|
%% modern configuration key, local filesystem source
|
|
|
|
|
{definition_files, "definitions.import_backend = local_filesystem
|
|
|
|
|
definitions.local.path = test/definition_import_SUITE_data/case1.json",
|
|
|
|
|
[{rabbit, [
|
|
|
|
|
{definitions, [
|
|
|
|
|
{import_backend, rabbit_definitions_import_local_filesystem},
|
|
|
|
|
{local_path, "test/definition_import_SUITE_data/case1.json"}
|
|
|
|
|
]}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2021-08-18 01:42:53 +08:00
|
|
|
%% modern configuration key, HTTPS source
|
|
|
|
|
{definition_files, "definitions.import_backend = https
|
|
|
|
|
definitions.https.url = https://rabbitmq.eng.megacorp.local/env-1/case1.json
|
|
|
|
|
definitions.tls.versions.1 = tlsv1.2
|
|
|
|
|
definitions.tls.log_level = error
|
|
|
|
|
|
|
|
|
|
definitions.tls.secure_renegotiate = true
|
|
|
|
|
|
|
|
|
|
definitions.tls.ciphers.1 = ECDHE-ECDSA-AES256-GCM-SHA384
|
|
|
|
|
definitions.tls.ciphers.2 = ECDHE-RSA-AES256-GCM-SHA384
|
|
|
|
|
definitions.tls.ciphers.3 = ECDH-ECDSA-AES256-GCM-SHA384
|
|
|
|
|
definitions.tls.ciphers.4 = ECDH-RSA-AES256-GCM-SHA384
|
|
|
|
|
definitions.tls.ciphers.5 = DHE-RSA-AES256-GCM-SHA384
|
|
|
|
|
definitions.tls.ciphers.6 = DHE-DSS-AES256-GCM-SHA384
|
|
|
|
|
definitions.tls.ciphers.7 = ECDHE-ECDSA-AES128-GCM-SHA256
|
|
|
|
|
definitions.tls.ciphers.8 = ECDHE-RSA-AES128-GCM-SHA256
|
|
|
|
|
definitions.tls.ciphers.9 = ECDH-ECDSA-AES128-GCM-SHA256
|
|
|
|
|
definitions.tls.ciphers.10 = ECDH-RSA-AES128-GCM-SHA256
|
|
|
|
|
definitions.tls.ciphers.11 = DHE-RSA-AES128-GCM-SHA256
|
|
|
|
|
definitions.tls.ciphers.12 = DHE-DSS-AES128-GCM-SHA256",
|
|
|
|
|
[{rabbit, [
|
|
|
|
|
{definitions, [
|
|
|
|
|
{import_backend, rabbit_definitions_import_https},
|
|
|
|
|
{url, "https://rabbitmq.eng.megacorp.local/env-1/case1.json"},
|
|
|
|
|
{ssl_options, [
|
|
|
|
|
{log_level, error},
|
|
|
|
|
{secure_renegotiate, true},
|
|
|
|
|
{versions, ['tlsv1.2']},
|
|
|
|
|
{ciphers, [
|
|
|
|
|
"ECDHE-ECDSA-AES256-GCM-SHA384",
|
|
|
|
|
"ECDHE-RSA-AES256-GCM-SHA384",
|
|
|
|
|
"ECDH-ECDSA-AES256-GCM-SHA384",
|
|
|
|
|
"ECDH-RSA-AES256-GCM-SHA384",
|
|
|
|
|
"DHE-RSA-AES256-GCM-SHA384",
|
|
|
|
|
"DHE-DSS-AES256-GCM-SHA384",
|
|
|
|
|
"ECDHE-ECDSA-AES128-GCM-SHA256",
|
|
|
|
|
"ECDHE-RSA-AES128-GCM-SHA256",
|
|
|
|
|
"ECDH-ECDSA-AES128-GCM-SHA256",
|
|
|
|
|
"ECDH-RSA-AES128-GCM-SHA256",
|
|
|
|
|
"DHE-RSA-AES128-GCM-SHA256",
|
|
|
|
|
"DHE-DSS-AES128-GCM-SHA256"
|
|
|
|
|
]}
|
|
|
|
|
]}
|
|
|
|
|
]}]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2019-10-28 01:35:04 +08:00
|
|
|
%%
|
|
|
|
|
%% Raft
|
|
|
|
|
%%
|
|
|
|
|
|
2020-05-30 01:58:50 +08:00
|
|
|
{raft_data_dir,
|
|
|
|
|
"raft.data_dir = /data/rabbitmq/raft/log",
|
|
|
|
|
[{ra, [
|
|
|
|
|
{data_dir, "/data/rabbitmq/raft/log"}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2019-10-28 01:35:04 +08:00
|
|
|
{raft_segment_max_entries,
|
2023-10-19 23:27:14 +08:00
|
|
|
"raft.segment_max_entries = 32768",
|
2019-10-28 01:35:04 +08:00
|
|
|
[{ra, [
|
2023-10-19 23:27:14 +08:00
|
|
|
{segment_max_entries, 32768}
|
2019-10-28 01:35:04 +08:00
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{raft_wal_max_size_bytes,
|
|
|
|
|
"raft.wal_max_size_bytes = 1048576",
|
|
|
|
|
[{ra, [
|
|
|
|
|
{wal_max_size_bytes, 1048576}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2022-01-19 04:36:22 +08:00
|
|
|
{raft_wal_max_batch_size,
|
|
|
|
|
"raft.wal_max_batch_size = 4096",
|
|
|
|
|
[{ra, [
|
|
|
|
|
{wal_max_batch_size, 4096}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{raft_snapshot_chunk_size,
|
|
|
|
|
"raft.snapshot_chunk_size = 1000000",
|
|
|
|
|
[{ra, [
|
|
|
|
|
{snapshot_chunk_size, 1000000}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
2019-10-28 01:35:04 +08:00
|
|
|
|
2022-12-12 20:45:45 +08:00
|
|
|
{raft_adaptive_failure_detector_poll_interval,
|
|
|
|
|
"raft.adaptive_failure_detector.poll_interval = 10000",
|
|
|
|
|
[{aten, [
|
|
|
|
|
{poll_interval, 10000}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2022-01-19 04:36:22 +08:00
|
|
|
%%
|
|
|
|
|
%% Backing queue version
|
|
|
|
|
%%
|
|
|
|
|
|
2022-01-24 23:19:22 +08:00
|
|
|
{classic_queue_default_version_2,
|
2022-02-09 23:20:35 +08:00
|
|
|
"classic_queue.default_version = 2",
|
2022-01-19 04:36:22 +08:00
|
|
|
[{rabbit, [
|
2022-01-24 23:19:22 +08:00
|
|
|
{classic_queue_default_version, 2}
|
2022-01-19 04:36:22 +08:00
|
|
|
]}],
|
|
|
|
|
[]},
|
2022-01-24 23:19:22 +08:00
|
|
|
{classic_queue_default_version_invalid,
|
2022-02-09 23:20:35 +08:00
|
|
|
"classic_queue.default_version = 3",
|
2022-01-19 04:36:22 +08:00
|
|
|
[],
|
2022-07-06 18:23:15 +08:00
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
%%
|
|
|
|
|
%% Quorum queue
|
|
|
|
|
%%
|
|
|
|
|
|
|
|
|
|
{quorum_queue_compute_checksums,
|
|
|
|
|
"quorum_queue.compute_checksums = true",
|
|
|
|
|
[{rabbit, [
|
|
|
|
|
{quorum_compute_checksums, true}
|
|
|
|
|
]}],
|
2023-03-24 23:54:58 +08:00
|
|
|
[]},
|
|
|
|
|
|
2023-04-18 01:19:33 +08:00
|
|
|
%%
|
|
|
|
|
%% Runtime parameters
|
|
|
|
|
%%
|
|
|
|
|
|
|
|
|
|
{runtime_parameters_limits,
|
|
|
|
|
"
|
2023-04-18 08:51:38 +08:00
|
|
|
runtime_parameters.limits.federation = 2
|
|
|
|
|
runtime_parameters.limits.shovel = 1
|
2023-04-18 01:19:33 +08:00
|
|
|
",
|
|
|
|
|
[{rabbit, [{runtime_parameters, [{limits, [
|
2023-04-18 08:51:38 +08:00
|
|
|
{<<"shovel">>, 1},
|
|
|
|
|
{<<"federation">>, 2}
|
2023-04-18 01:19:33 +08:00
|
|
|
]}]}]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
2023-03-24 23:54:58 +08:00
|
|
|
%%
|
|
|
|
|
%% Deprecated features
|
|
|
|
|
%%
|
|
|
|
|
|
|
|
|
|
{deprecated_features_cmq,
|
2023-07-05 17:10:53 +08:00
|
|
|
"deprecated_features.permit.classic_queue_mirroring = false",
|
2023-03-24 23:54:58 +08:00
|
|
|
[{rabbit, [
|
2023-07-05 17:10:53 +08:00
|
|
|
{permit_deprecated_features, #{classic_queue_mirroring => false}}
|
2023-03-24 23:54:58 +08:00
|
|
|
]}],
|
Move plugin rabbitmq-message-timestamp to the core
As reported in https://groups.google.com/g/rabbitmq-users/c/x8ACs4dBlkI/
plugins that implement rabbit_channel_interceptor break with
Native MQTT in 3.12 because Native MQTT does not use rabbit_channel anymore.
Specifically, these plugins don't work anymore in 3.12 when sending a message
from an MQTT publisher to an AMQP 0.9.1 consumer.
Two of these plugins are
https://github.com/rabbitmq/rabbitmq-message-timestamp
and
https://github.com/rabbitmq/rabbitmq-routing-node-stamp
This commit moves both plugins into rabbitmq-server.
Therefore, these plugins are deprecated starting in 3.12.
Instead of using these plugins, the user gets the same behaviour by
configuring rabbitmq.conf as follows:
```
incoming_message_interceptors.set_header_timestamp.overwrite = false
incoming_message_interceptors.set_header_routing_node.overwrite = false
```
While both plugins were incompatible to be used together, this commit
allows setting both headers.
We name the top level configuration key `incoming_message_interceptors`
because only incoming messages are intercepted.
Currently, only `set_header_timestamp` and `set_header_routing_node` are
supported. (We might support more in the future.)
Both can set `overwrite` to `false` or `true`.
The meaning of `overwrite` is the same as documented in
https://github.com/rabbitmq/rabbitmq-message-timestamp#always-overwrite-timestamps
i.e. whether headers should be overwritten if they are already present
in the message.
Both `set_header_timestamp` and `set_header_routing_node` behave exactly
to plugins `rabbitmq-message-timestamp` and `rabbitmq-routing-node-stamp`,
respectively.
Upon node boot, the configuration is put into persistent_term to not
cause any performance penalty in the default case where these settings
are disabled.
The channel and MQTT connection process will intercept incoming messages
and - if configured - add the desired AMQP 0.9.1 headers.
For now, this allows using Native MQTT in 3.12 with the old plugins
behaviour.
In the future, once "message containers" are implemented,
we can think about more generic message interceptors where plugins can be
written to modify arbitrary headers or message contents for various protocols.
Likewise, in the future, once MQTT 5.0 is implemented, we can think
about an MQTT connection interceptor which could function similar to a
`rabbit_channel_interceptor` allowing to modify any MQTT packet.
2023-05-12 22:12:50 +08:00
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
%%
|
|
|
|
|
%% Message interceptors
|
|
|
|
|
%%
|
|
|
|
|
|
|
|
|
|
{message_interceptors,
|
2023-05-15 18:06:01 +08:00
|
|
|
"message_interceptors.incoming.set_header_timestamp.overwrite = true",
|
Move plugin rabbitmq-message-timestamp to the core
As reported in https://groups.google.com/g/rabbitmq-users/c/x8ACs4dBlkI/
plugins that implement rabbit_channel_interceptor break with
Native MQTT in 3.12 because Native MQTT does not use rabbit_channel anymore.
Specifically, these plugins don't work anymore in 3.12 when sending a message
from an MQTT publisher to an AMQP 0.9.1 consumer.
Two of these plugins are
https://github.com/rabbitmq/rabbitmq-message-timestamp
and
https://github.com/rabbitmq/rabbitmq-routing-node-stamp
This commit moves both plugins into rabbitmq-server.
Therefore, these plugins are deprecated starting in 3.12.
Instead of using these plugins, the user gets the same behaviour by
configuring rabbitmq.conf as follows:
```
incoming_message_interceptors.set_header_timestamp.overwrite = false
incoming_message_interceptors.set_header_routing_node.overwrite = false
```
While both plugins were incompatible to be used together, this commit
allows setting both headers.
We name the top level configuration key `incoming_message_interceptors`
because only incoming messages are intercepted.
Currently, only `set_header_timestamp` and `set_header_routing_node` are
supported. (We might support more in the future.)
Both can set `overwrite` to `false` or `true`.
The meaning of `overwrite` is the same as documented in
https://github.com/rabbitmq/rabbitmq-message-timestamp#always-overwrite-timestamps
i.e. whether headers should be overwritten if they are already present
in the message.
Both `set_header_timestamp` and `set_header_routing_node` behave exactly
to plugins `rabbitmq-message-timestamp` and `rabbitmq-routing-node-stamp`,
respectively.
Upon node boot, the configuration is put into persistent_term to not
cause any performance penalty in the default case where these settings
are disabled.
The channel and MQTT connection process will intercept incoming messages
and - if configured - add the desired AMQP 0.9.1 headers.
For now, this allows using Native MQTT in 3.12 with the old plugins
behaviour.
In the future, once "message containers" are implemented,
we can think about more generic message interceptors where plugins can be
written to modify arbitrary headers or message contents for various protocols.
Likewise, in the future, once MQTT 5.0 is implemented, we can think
about an MQTT connection interceptor which could function similar to a
`rabbit_channel_interceptor` allowing to modify any MQTT packet.
2023-05-12 22:12:50 +08:00
|
|
|
[{rabbit, [
|
|
|
|
|
{incoming_message_interceptors, [{set_header_timestamp, true}]}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{message_interceptors,
|
|
|
|
|
"
|
2023-05-15 18:06:01 +08:00
|
|
|
message_interceptors.incoming.set_header_routing_node.overwrite = false
|
|
|
|
|
message_interceptors.incoming.set_header_timestamp.overwrite = false
|
Move plugin rabbitmq-message-timestamp to the core
As reported in https://groups.google.com/g/rabbitmq-users/c/x8ACs4dBlkI/
plugins that implement rabbit_channel_interceptor break with
Native MQTT in 3.12 because Native MQTT does not use rabbit_channel anymore.
Specifically, these plugins don't work anymore in 3.12 when sending a message
from an MQTT publisher to an AMQP 0.9.1 consumer.
Two of these plugins are
https://github.com/rabbitmq/rabbitmq-message-timestamp
and
https://github.com/rabbitmq/rabbitmq-routing-node-stamp
This commit moves both plugins into rabbitmq-server.
Therefore, these plugins are deprecated starting in 3.12.
Instead of using these plugins, the user gets the same behaviour by
configuring rabbitmq.conf as follows:
```
incoming_message_interceptors.set_header_timestamp.overwrite = false
incoming_message_interceptors.set_header_routing_node.overwrite = false
```
While both plugins were incompatible to be used together, this commit
allows setting both headers.
We name the top level configuration key `incoming_message_interceptors`
because only incoming messages are intercepted.
Currently, only `set_header_timestamp` and `set_header_routing_node` are
supported. (We might support more in the future.)
Both can set `overwrite` to `false` or `true`.
The meaning of `overwrite` is the same as documented in
https://github.com/rabbitmq/rabbitmq-message-timestamp#always-overwrite-timestamps
i.e. whether headers should be overwritten if they are already present
in the message.
Both `set_header_timestamp` and `set_header_routing_node` behave exactly
to plugins `rabbitmq-message-timestamp` and `rabbitmq-routing-node-stamp`,
respectively.
Upon node boot, the configuration is put into persistent_term to not
cause any performance penalty in the default case where these settings
are disabled.
The channel and MQTT connection process will intercept incoming messages
and - if configured - add the desired AMQP 0.9.1 headers.
For now, this allows using Native MQTT in 3.12 with the old plugins
behaviour.
In the future, once "message containers" are implemented,
we can think about more generic message interceptors where plugins can be
written to modify arbitrary headers or message contents for various protocols.
Likewise, in the future, once MQTT 5.0 is implemented, we can think
about an MQTT connection interceptor which could function similar to a
`rabbit_channel_interceptor` allowing to modify any MQTT packet.
2023-05-12 22:12:50 +08:00
|
|
|
",
|
|
|
|
|
[{rabbit, [
|
|
|
|
|
{incoming_message_interceptors, [{set_header_routing_node, false},
|
|
|
|
|
{set_header_timestamp, false}]}
|
|
|
|
|
]}],
|
2024-07-19 21:20:32 +08:00
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
%%
|
|
|
|
|
%% Stream replication port range
|
|
|
|
|
%%
|
|
|
|
|
|
|
|
|
|
{stream_replication_port_range,
|
|
|
|
|
"
|
|
|
|
|
stream.replication.port_range.min = 4000
|
|
|
|
|
stream.replication.port_range.max = 4600
|
|
|
|
|
",
|
|
|
|
|
[{osiris, [
|
|
|
|
|
{port_range, {4000, 4600}}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{stream_replication_port_range,
|
|
|
|
|
"
|
|
|
|
|
stream.replication.port_range.min = 4000
|
|
|
|
|
",
|
|
|
|
|
[{osiris, [
|
|
|
|
|
{port_range, {4000, 4500}}
|
|
|
|
|
]}],
|
|
|
|
|
[]},
|
|
|
|
|
|
|
|
|
|
{stream_replication_port_range,
|
|
|
|
|
"
|
|
|
|
|
stream.replication.port_range.max = 4600
|
|
|
|
|
",
|
|
|
|
|
[{osiris, [
|
|
|
|
|
{port_range, {4100, 4600}}
|
|
|
|
|
]}],
|
2024-06-22 16:16:50 +08:00
|
|
|
[]}
|
2023-03-24 23:54:58 +08:00
|
|
|
|
2017-08-30 22:08:05 +08:00
|
|
|
].
|
