2021-08-03 18:19:52 +08:00
|
|
|
## This example configuration file demonstrates various settings
|
|
|
|
## available via rabbitmq.conf. It primarily focuses core broker settings
|
|
|
|
## but some tier 1 plugin settings are also covered.
|
|
|
|
##
|
|
|
|
## This file is AN EXAMPLE. It is NOT MEANT TO BE USED IN PRODUCTION. Instead of
|
|
|
|
## copying the entire (large!) file, create or generate a new rabbitmq.conf for the target system
|
|
|
|
## and populate it with the necessary settings.
|
|
|
|
##
|
|
|
|
## See https://rabbitmq.com/configure.html to learn about how to configure RabbitMQ,
|
|
|
|
## the ini-style format used by rabbitmq.conf, how it is different from `advanced.config`,
|
|
|
|
## how to verify effective configuration, and so on.
|
|
|
|
##
|
|
|
|
## See https://rabbitmq.com/documentation.html for the rest of RabbitMQ documentation.
|
|
|
|
##
|
|
|
|
## In case you have questions, please use RabbitMQ community Slack and the rabbitmq-users Google group
|
|
|
|
## instead of GitHub issues.
|
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
# ======================================
|
2021-08-03 18:19:52 +08:00
|
|
|
# Core broker section
|
2016-02-01 22:27:56 +08:00
|
|
|
# ======================================
|
|
|
|
|
2017-10-17 07:17:04 +08:00
|
|
|
|
2017-10-17 06:40:01 +08:00
|
|
|
## Networking
|
2016-02-01 22:27:56 +08:00
|
|
|
## ====================
|
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/networking.html.
|
2017-10-17 06:40:01 +08:00
|
|
|
##
|
2016-02-01 22:27:56 +08:00
|
|
|
## By default, RabbitMQ will listen on all interfaces, using
|
2017-10-17 06:36:15 +08:00
|
|
|
## the standard (reserved) AMQP 0-9-1 and 1.0 port.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2016-02-17 19:11:57 +08:00
|
|
|
# listeners.tcp.default = 5672
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
|
|
|
|
## To listen on a specific interface, provide an IP address with port.
|
|
|
|
## For example, to listen only on localhost for both IPv4 and IPv6:
|
|
|
|
##
|
|
|
|
# IPv4
|
2016-02-17 19:11:57 +08:00
|
|
|
# listeners.tcp.local = 127.0.0.1:5672
|
2016-02-01 22:27:56 +08:00
|
|
|
# IPv6
|
2016-02-17 19:11:57 +08:00
|
|
|
# listeners.tcp.local_v6 = ::1:5672
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## You can define multiple listeners using listener names
|
2016-02-17 19:11:57 +08:00
|
|
|
# listeners.tcp.other_port = 5673
|
|
|
|
# listeners.tcp.other_ip = 10.10.10.10:5672
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
|
2017-10-17 06:36:15 +08:00
|
|
|
## TLS listeners are configured in the same fashion as TCP listeners,
|
2016-02-01 22:27:56 +08:00
|
|
|
## including the option to control the choice of interface.
|
|
|
|
##
|
2016-02-17 19:11:57 +08:00
|
|
|
# listeners.ssl.default = 5671
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2020-08-18 00:47:13 +08:00
|
|
|
## It is possible to disable regular TCP (non-TLS) listeners. Clients
|
|
|
|
## not configured to use TLS and the correct TLS-enabled port won't be able
|
|
|
|
## to connect to this node.
|
|
|
|
# listeners.tcp = none
|
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
## Number of Erlang processes that will accept connections for the TCP
|
2017-10-17 06:36:15 +08:00
|
|
|
## and TLS listeners.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# num_acceptors.tcp = 10
|
2019-02-11 20:04:27 +08:00
|
|
|
# num_acceptors.ssl = 10
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2019-12-25 05:43:12 +08:00
|
|
|
## Socket writer will force GC every so many bytes transferred.
|
|
|
|
## Default is 1 GiB (`1000000000`). Set to 'off' to disable.
|
|
|
|
##
|
|
|
|
# socket_writer.gc_threshold = 1000000000
|
|
|
|
#
|
|
|
|
## To disable:
|
|
|
|
# socket_writer.gc_threshold = off
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2019-02-11 20:30:40 +08:00
|
|
|
## Maximum amount of time allowed for the AMQP 0-9-1 and AMQP 1.0 handshake
|
|
|
|
## (performed after socket connection and TLS handshake) to complete, in milliseconds.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# handshake_timeout = 10000
|
|
|
|
|
|
|
|
## Set to 'true' to perform reverse DNS lookups when accepting a
|
2019-02-11 20:30:40 +08:00
|
|
|
## connection. rabbitmqctl and management UI will then display hostnames
|
|
|
|
## instead of IP addresses. Default value is `false`.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2019-02-11 20:30:40 +08:00
|
|
|
# reverse_dns_lookups = false
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
##
|
2017-10-17 07:17:04 +08:00
|
|
|
## Security, Access Control
|
2016-02-01 22:27:56 +08:00
|
|
|
## ==============
|
|
|
|
##
|
|
|
|
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/access-control.html.
|
2017-10-17 07:17:04 +08:00
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
## The default "guest" user is only permitted to access the server
|
|
|
|
## via a loopback interface (e.g. localhost).
|
|
|
|
## {loopback_users, [<<"guest">>]},
|
|
|
|
##
|
2016-02-17 19:11:57 +08:00
|
|
|
# loopback_users.guest = true
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Uncomment the following line if you want to allow access to the
|
|
|
|
## guest user from anywhere on the network.
|
2016-02-17 19:11:57 +08:00
|
|
|
# loopback_users.guest = false
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2017-10-17 07:17:04 +08:00
|
|
|
## TLS configuration.
|
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/ssl.html.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2021-02-13 21:14:48 +08:00
|
|
|
# listeners.ssl.1 = 5671
|
2021-02-13 21:09:30 +08:00
|
|
|
#
|
2016-02-17 19:11:57 +08:00
|
|
|
# ssl_options.verify = verify_peer
|
|
|
|
# ssl_options.fail_if_no_peer_cert = false
|
2016-02-22 23:41:05 +08:00
|
|
|
# ssl_options.cacertfile = /path/to/cacert.pem
|
|
|
|
# ssl_options.certfile = /path/to/cert.pem
|
|
|
|
# ssl_options.keyfile = /path/to/key.pem
|
2018-10-23 21:38:08 +08:00
|
|
|
#
|
|
|
|
# ssl_options.honor_cipher_order = true
|
|
|
|
# ssl_options.honor_ecc_order = true
|
2021-02-14 04:25:12 +08:00
|
|
|
#
|
2021-02-14 06:35:08 +08:00
|
|
|
## These are highly recommended for TLSv1.2 but cannot be used
|
|
|
|
## with TLSv1.3. If TLSv1.3 is enabled, these lines MUST be removed.
|
|
|
|
# ssl_options.client_renegotiation = false
|
|
|
|
# ssl_options.secure_renegotiate = true
|
|
|
|
#
|
2021-02-14 04:25:12 +08:00
|
|
|
## Limits what TLS versions the server enables for client TLS
|
|
|
|
## connections. See https://www.rabbitmq.com/ssl.html#tls-versions for details.
|
|
|
|
##
|
|
|
|
## Cutting edge TLS version which requires recent client runtime
|
|
|
|
## versions and has no cipher suite in common with earlier TLS versions.
|
2021-02-13 21:09:30 +08:00
|
|
|
# ssl_options.versions.1 = tlsv1.3
|
2021-02-14 04:25:12 +08:00
|
|
|
## Enables TLSv1.2 for best compatibility
|
2021-02-13 21:09:30 +08:00
|
|
|
# ssl_options.versions.2 = tlsv1.2
|
2021-02-14 04:25:12 +08:00
|
|
|
## Older TLS versions have known vulnerabilities and are being phased out
|
|
|
|
## from wide use.
|
2018-10-23 21:38:08 +08:00
|
|
|
|
2021-02-14 04:25:12 +08:00
|
|
|
## Limits what cipher suites the server will use for client TLS
|
|
|
|
## connections. Narrowing this down can prevent some clients
|
2021-02-14 05:01:23 +08:00
|
|
|
## from connecting.
|
|
|
|
## If TLSv1.3 is enabled and cipher suites are overridden, TLSv1.3-specific
|
|
|
|
## cipher suites must also be explicitly enabled.
|
|
|
|
## See https://www.rabbitmq.com/ssl.html#cipher-suites and https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites
|
|
|
|
## for details.
|
|
|
|
#
|
|
|
|
## The example below uses TLSv1.3 cipher suites only
|
|
|
|
#
|
|
|
|
# ssl_options.ciphers.1 = TLS_AES_256_GCM_SHA384
|
|
|
|
# ssl_options.ciphers.2 = TLS_AES_128_GCM_SHA256
|
|
|
|
# ssl_options.ciphers.3 = TLS_CHACHA20_POLY1305_SHA256
|
|
|
|
# ssl_options.ciphers.4 = TLS_AES_128_CCM_SHA256
|
|
|
|
# ssl_options.ciphers.5 = TLS_AES_128_CCM_8_SHA256
|
|
|
|
#
|
|
|
|
## The example below uses TLSv1.2 cipher suites only
|
2021-02-14 04:25:12 +08:00
|
|
|
#
|
2018-10-23 21:38:08 +08:00
|
|
|
# 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_options.ciphers.10 = DHE-DSS-AES256-GCM-SHA384
|
|
|
|
# ssl_options.ciphers.11 = DHE-RSA-AES256-SHA256
|
|
|
|
# ssl_options.ciphers.12 = DHE-DSS-AES256-SHA256
|
|
|
|
# ssl_options.ciphers.13 = ECDHE-ECDSA-AES128-GCM-SHA256
|
|
|
|
# ssl_options.ciphers.14 = ECDHE-RSA-AES128-GCM-SHA256
|
|
|
|
# ssl_options.ciphers.15 = ECDHE-ECDSA-AES128-SHA256
|
|
|
|
# ssl_options.ciphers.16 = ECDHE-RSA-AES128-SHA256
|
|
|
|
# ssl_options.ciphers.17 = ECDH-ECDSA-AES128-GCM-SHA256
|
|
|
|
# ssl_options.ciphers.18 = ECDH-RSA-AES128-GCM-SHA256
|
|
|
|
# ssl_options.ciphers.19 = ECDH-ECDSA-AES128-SHA256
|
|
|
|
# ssl_options.ciphers.20 = ECDH-RSA-AES128-SHA256
|
|
|
|
# ssl_options.ciphers.21 = DHE-RSA-AES128-GCM-SHA256
|
|
|
|
# ssl_options.ciphers.22 = DHE-DSS-AES128-GCM-SHA256
|
|
|
|
# ssl_options.ciphers.23 = DHE-RSA-AES128-SHA256
|
|
|
|
# ssl_options.ciphers.24 = DHE-DSS-AES128-SHA256
|
|
|
|
# ssl_options.ciphers.25 = ECDHE-ECDSA-AES256-SHA
|
|
|
|
# ssl_options.ciphers.26 = ECDHE-RSA-AES256-SHA
|
|
|
|
# ssl_options.ciphers.27 = DHE-RSA-AES256-SHA
|
|
|
|
# ssl_options.ciphers.28 = DHE-DSS-AES256-SHA
|
|
|
|
# ssl_options.ciphers.29 = ECDH-ECDSA-AES256-SHA
|
|
|
|
# ssl_options.ciphers.30 = ECDH-RSA-AES256-SHA
|
|
|
|
# ssl_options.ciphers.31 = ECDHE-ECDSA-AES128-SHA
|
|
|
|
# ssl_options.ciphers.32 = ECDHE-RSA-AES128-SHA
|
|
|
|
# ssl_options.ciphers.33 = DHE-RSA-AES128-SHA
|
|
|
|
# ssl_options.ciphers.34 = DHE-DSS-AES128-SHA
|
|
|
|
# ssl_options.ciphers.35 = ECDH-ECDSA-AES128-SHA
|
|
|
|
# ssl_options.ciphers.36 = ECDH-RSA-AES128-SHA
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2020-12-17 23:53:14 +08:00
|
|
|
# ssl_options.bypass_pem_cache = true
|
|
|
|
|
2016-02-24 19:48:23 +08:00
|
|
|
## Select an authentication/authorisation backend to use.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2016-03-22 21:01:08 +08:00
|
|
|
## Alternative backends are provided by plugins, such as rabbitmq-auth-backend-ldap.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2016-03-22 21:01:08 +08:00
|
|
|
## NB: These settings require certain plugins to be enabled.
|
2017-10-17 07:17:04 +08:00
|
|
|
##
|
|
|
|
## Related doc guides:
|
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## * https://rabbitmq.com/plugins.html
|
|
|
|
## * https://rabbitmq.com/access-control.html
|
2017-10-17 07:17:04 +08:00
|
|
|
##
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2016-03-22 21:01:08 +08:00
|
|
|
# auth_backends.1 = rabbit_auth_backend_internal
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2016-03-22 21:01:08 +08:00
|
|
|
## uses separate backends for authentication and authorisation,
|
|
|
|
## see below.
|
|
|
|
# auth_backends.1.authn = rabbit_auth_backend_ldap
|
|
|
|
# auth_backends.1.authz = rabbit_auth_backend_internal
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## The rabbitmq_auth_backend_ldap plugin allows the broker to
|
|
|
|
## perform authentication and authorisation by deferring to an
|
|
|
|
## external LDAP server.
|
|
|
|
##
|
2017-10-17 07:17:04 +08:00
|
|
|
## Relevant doc guides:
|
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## * https://rabbitmq.com/ldap.html
|
|
|
|
## * https://rabbitmq.com/access-control.html
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2016-03-22 21:01:08 +08:00
|
|
|
## uses LDAP for both authentication and authorisation
|
|
|
|
# auth_backends.1 = rabbit_auth_backend_ldap
|
|
|
|
|
|
|
|
## uses HTTP service for both authentication and
|
|
|
|
## authorisation
|
|
|
|
# auth_backends.1 = rabbit_auth_backend_http
|
|
|
|
|
|
|
|
## uses two backends in a chain: HTTP first, then internal
|
|
|
|
# auth_backends.1 = rabbit_auth_backend_http
|
|
|
|
# auth_backends.2 = rabbit_auth_backend_internal
|
|
|
|
|
|
|
|
## Authentication
|
|
|
|
## The built-in mechanisms are 'PLAIN',
|
|
|
|
## 'AMQPLAIN', and 'EXTERNAL' Additional mechanisms can be added via
|
|
|
|
## plugins.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/authentication.html.
|
2016-03-22 21:01:08 +08:00
|
|
|
##
|
|
|
|
# auth_mechanisms.1 = PLAIN
|
|
|
|
# auth_mechanisms.2 = AMQPLAIN
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2016-03-22 21:01:08 +08:00
|
|
|
## The rabbitmq-auth-mechanism-ssl plugin makes it possible to
|
|
|
|
## authenticate a user based on the client's x509 (TLS) certificate.
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/authentication.html.
|
2016-03-22 21:01:08 +08:00
|
|
|
##
|
|
|
|
## To use auth-mechanism-ssl, the EXTERNAL mechanism should
|
|
|
|
## be enabled:
|
|
|
|
##
|
|
|
|
# auth_mechanisms.1 = PLAIN
|
|
|
|
# auth_mechanisms.2 = AMQPLAIN
|
|
|
|
# auth_mechanisms.3 = EXTERNAL
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2016-03-22 21:01:08 +08:00
|
|
|
## To force x509 certificate-based authentication on all clients,
|
|
|
|
## exclude all other mechanisms (note: this will disable password-based
|
|
|
|
## authentication even for the management UI!):
|
|
|
|
##
|
|
|
|
# auth_mechanisms.1 = EXTERNAL
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2016-03-22 21:01:08 +08:00
|
|
|
## This pertains to both the rabbitmq-auth-mechanism-ssl plugin and
|
2017-10-17 07:17:04 +08:00
|
|
|
## STOMP ssl_cert_login configurations. See the RabbitMQ STOMP plugin
|
2016-02-01 22:27:56 +08:00
|
|
|
## configuration section later in this file and the README in
|
|
|
|
## https://github.com/rabbitmq/rabbitmq-auth-mechanism-ssl for further
|
|
|
|
## details.
|
|
|
|
##
|
2017-10-17 06:36:15 +08:00
|
|
|
## To use the TLS cert's CN instead of its DN as the username
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# ssl_cert_login_from = common_name
|
|
|
|
|
2017-10-17 06:36:15 +08:00
|
|
|
## TLS handshake timeout, in milliseconds.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# ssl_handshake_timeout = 5000
|
|
|
|
|
|
|
|
|
2023-01-06 22:43:47 +08:00
|
|
|
##
|
|
|
|
## Loading Definitions
|
|
|
|
## ====================
|
|
|
|
##
|
|
|
|
## Relevant documentation: https://www.rabbitmq.com/definitions.html#import-on-boot
|
|
|
|
##
|
|
|
|
## To import definitions from a local file on node boot, set the
|
|
|
|
## load_definitions config key to a path of a previously exported
|
|
|
|
## JSON file with definitions. Does not require management plugin
|
|
|
|
## to be enabled.
|
|
|
|
##
|
|
|
|
# load_definitions = /path/to/definitions/file.json
|
|
|
|
|
|
|
|
|
|
|
|
##
|
2019-08-13 00:37:26 +08:00
|
|
|
## Cluster name
|
2023-01-06 22:43:47 +08:00
|
|
|
## ====================
|
2019-08-13 00:37:26 +08:00
|
|
|
##
|
|
|
|
# cluster_name = dev3.eng.megacorp.local
|
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
## Password hashing implementation. Will only affect newly
|
|
|
|
## created users. To recalculate hash for an existing user
|
|
|
|
## it's necessary to update her password.
|
|
|
|
##
|
|
|
|
## To use SHA-512, set to rabbit_password_hashing_sha512.
|
|
|
|
##
|
|
|
|
# password_hashing_module = rabbit_password_hashing_sha256
|
|
|
|
|
|
|
|
## When importing definitions exported from versions earlier
|
|
|
|
## than 3.6.0, it is possible to go back to MD5 (only do this
|
|
|
|
## as a temporary measure!) by setting this to rabbit_password_hashing_md5.
|
|
|
|
##
|
|
|
|
# password_hashing_module = rabbit_password_hashing_md5
|
|
|
|
|
|
|
|
##
|
|
|
|
## Default User / VHost
|
|
|
|
## ====================
|
|
|
|
##
|
|
|
|
|
|
|
|
## On first start RabbitMQ will create a vhost and a user. These
|
2017-10-17 07:17:04 +08:00
|
|
|
## config items control what gets created.
|
2019-03-20 16:21:37 +08:00
|
|
|
## Relevant doc guide: https://rabbitmq.com/access-control.html
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# default_vhost = /
|
|
|
|
# default_user = guest
|
|
|
|
# default_pass = guest
|
|
|
|
|
|
|
|
# default_permissions.configure = .*
|
|
|
|
# default_permissions.read = .*
|
|
|
|
# default_permissions.write = .*
|
|
|
|
|
|
|
|
## Tags for default user
|
|
|
|
##
|
|
|
|
## For more details about tags, see the documentation for the
|
2019-03-20 16:21:37 +08:00
|
|
|
## Management Plugin at https://rabbitmq.com/management.html.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# default_user_tags.administrator = true
|
|
|
|
|
|
|
|
## Define other tags like this:
|
|
|
|
# default_user_tags.management = true
|
|
|
|
# default_user_tags.custom_tag = true
|
|
|
|
|
|
|
|
##
|
|
|
|
## Additional network and protocol related configuration
|
|
|
|
## =====================================================
|
|
|
|
##
|
|
|
|
|
2021-02-27 01:11:31 +08:00
|
|
|
## Set the server AMQP 0-9-1 heartbeat timeout in seconds.
|
|
|
|
## RabbitMQ nodes will send heartbeat frames at roughly
|
|
|
|
## the (timeout / 2) interval. Two missed heartbeats from
|
|
|
|
## a client will close its connection.
|
|
|
|
##
|
|
|
|
## Values lower than 6 seconds are very likely to produce
|
|
|
|
## false positives and are not recommended.
|
|
|
|
##
|
2017-10-17 07:17:04 +08:00
|
|
|
## Related doc guides:
|
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## * https://rabbitmq.com/heartbeats.html
|
|
|
|
## * https://rabbitmq.com/networking.html
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2018-06-02 04:14:21 +08:00
|
|
|
# heartbeat = 60
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Set the max permissible size of an AMQP frame (in bytes).
|
|
|
|
##
|
|
|
|
# frame_max = 131072
|
|
|
|
|
|
|
|
## Set the max frame size the server will accept before connection
|
|
|
|
## tuning occurs
|
|
|
|
##
|
|
|
|
# initial_frame_max = 4096
|
|
|
|
|
|
|
|
## Set the max permissible number of channels per connection.
|
|
|
|
## 0 means "no limit".
|
|
|
|
##
|
|
|
|
# channel_max = 128
|
|
|
|
|
2017-10-17 07:17:04 +08:00
|
|
|
## Customising TCP Listener (Socket) Configuration.
|
|
|
|
##
|
|
|
|
## Related doc guides:
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## * https://rabbitmq.com/networking.html
|
|
|
|
## * https://www.erlang.org/doc/man/inet.html#setopts-2
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
|
2016-02-17 19:11:57 +08:00
|
|
|
# tcp_listen_options.backlog = 128
|
|
|
|
# tcp_listen_options.nodelay = true
|
|
|
|
# tcp_listen_options.exit_on_close = false
|
2018-02-06 04:36:24 +08:00
|
|
|
#
|
|
|
|
# tcp_listen_options.keepalive = true
|
|
|
|
# tcp_listen_options.send_timeout = 15000
|
|
|
|
#
|
|
|
|
# tcp_listen_options.buffer = 196608
|
|
|
|
# tcp_listen_options.sndbuf = 196608
|
|
|
|
# tcp_listen_options.recbuf = 196608
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
##
|
|
|
|
## Resource Limits & Flow Control
|
|
|
|
## ==============================
|
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/memory.html.
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Memory-based Flow Control threshold.
|
|
|
|
##
|
|
|
|
# vm_memory_high_watermark.relative = 0.4
|
|
|
|
|
|
|
|
## Alternatively, we can set a limit (in bytes) of RAM used by the node.
|
|
|
|
##
|
|
|
|
# vm_memory_high_watermark.absolute = 1073741824
|
|
|
|
|
|
|
|
## Or you can set absolute value using memory units (with RabbitMQ 3.6.0+).
|
|
|
|
## Absolute watermark will be ignored if relative is defined!
|
|
|
|
##
|
|
|
|
# vm_memory_high_watermark.absolute = 2GB
|
|
|
|
##
|
2019-04-23 23:08:01 +08:00
|
|
|
## Supported unit symbols:
|
|
|
|
##
|
|
|
|
## k, kiB: kibibytes (2^10 - 1,024 bytes)
|
|
|
|
## M, MiB: mebibytes (2^20 - 1,048,576 bytes)
|
|
|
|
## G, GiB: gibibytes (2^30 - 1,073,741,824 bytes)
|
|
|
|
## kB: kilobytes (10^3 - 1,000 bytes)
|
|
|
|
## MB: megabytes (10^6 - 1,000,000 bytes)
|
|
|
|
## GB: gigabytes (10^9 - 1,000,000,000 bytes)
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Fraction of the high watermark limit at which queues start to
|
|
|
|
## page message out to disc in order to free up memory.
|
2017-07-27 00:59:32 +08:00
|
|
|
## For example, when vm_memory_high_watermark is set to 0.4 and this value is set to 0.5,
|
|
|
|
## paging can begin as early as when 20% of total available RAM is used by the node.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2017-07-27 00:59:32 +08:00
|
|
|
## Values greater than 1.0 can be dangerous and should be used carefully.
|
|
|
|
##
|
|
|
|
## One alternative to this is to use durable queues and publish messages
|
|
|
|
## as persistent (delivery mode = 2). With this combination queues will
|
|
|
|
## move messages to disk much more rapidly.
|
|
|
|
##
|
|
|
|
## Another alternative is to configure queues to page all messages (both
|
|
|
|
## persistent and transient) to disk as quickly
|
2019-03-20 16:21:37 +08:00
|
|
|
## as possible, see https://rabbitmq.com/lazy-queues.html.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# vm_memory_high_watermark_paging_ratio = 0.5
|
|
|
|
|
2017-10-12 23:11:03 +08:00
|
|
|
## Selects Erlang VM memory consumption calculation strategy. Can be `allocated`, `rss` or `legacy` (aliased as `erlang`),
|
2017-10-19 22:03:03 +08:00
|
|
|
## Introduced in 3.6.11. `rss` is the default as of 3.6.12.
|
2017-10-12 23:11:03 +08:00
|
|
|
## See https://github.com/rabbitmq/rabbitmq-server/issues/1223 and rabbitmq/rabbitmq-common#224 for background.
|
2017-10-19 22:03:03 +08:00
|
|
|
# vm_memory_calculation_strategy = rss
|
2017-08-26 03:49:20 +08:00
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
## Interval (in milliseconds) at which we perform the check of the memory
|
|
|
|
## levels against the watermarks.
|
|
|
|
##
|
|
|
|
# memory_monitor_interval = 2500
|
|
|
|
|
2017-12-08 12:17:48 +08:00
|
|
|
## The total memory available can be calculated from the OS resources
|
|
|
|
## - default option - or provided as a configuration parameter.
|
|
|
|
# total_memory_available_override_value = 2GB
|
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
## Set disk free limit (in bytes). Once free disk space reaches this
|
|
|
|
## lower bound, a disk alarm will be set - see the documentation
|
|
|
|
## listed above for more details.
|
|
|
|
##
|
|
|
|
## Absolute watermark will be ignored if relative is defined!
|
|
|
|
# disk_free_limit.absolute = 50000
|
|
|
|
|
|
|
|
## Or you can set it using memory units (same as in vm_memory_high_watermark)
|
|
|
|
## with RabbitMQ 3.6.0+.
|
|
|
|
# disk_free_limit.absolute = 500KB
|
|
|
|
# disk_free_limit.absolute = 50mb
|
|
|
|
# disk_free_limit.absolute = 5GB
|
|
|
|
|
|
|
|
## Alternatively, we can set a limit relative to total available RAM.
|
|
|
|
##
|
|
|
|
## Values lower than 1.0 can be dangerous and should be used carefully.
|
|
|
|
# disk_free_limit.relative = 2.0
|
|
|
|
|
|
|
|
##
|
|
|
|
## Clustering
|
|
|
|
## =====================
|
|
|
|
##
|
|
|
|
# cluster_partition_handling = ignore
|
|
|
|
|
2021-03-26 03:10:11 +08:00
|
|
|
## Pauses all nodes on the minority side of a partition. The cluster
|
|
|
|
## MUST have an odd number of nodes (3, 5, etc)
|
|
|
|
# cluster_partition_handling = pause_minority
|
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
## pause_if_all_down strategy require additional configuration
|
|
|
|
# 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
|
2016-02-29 22:15:19 +08:00
|
|
|
# cluster_partition_handling.pause_if_all_down.nodes.1 = rabbit@localhost
|
|
|
|
# cluster_partition_handling.pause_if_all_down.nodes.2 = hare@localhost
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Mirror sync batch size, in messages. Increasing this will speed
|
|
|
|
## up syncing but total batch size in bytes must not exceed 2 GiB.
|
|
|
|
## Available in RabbitMQ 3.6.0 or later.
|
|
|
|
##
|
|
|
|
# mirroring_sync_batch_size = 4096
|
|
|
|
|
2017-10-17 07:17:04 +08:00
|
|
|
## Make clustering happen *automatically* at startup. Only applied
|
2016-02-01 22:27:56 +08:00
|
|
|
## to nodes that have just been reset or started for the first time.
|
2017-10-17 07:17:04 +08:00
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## Relevant doc guide: https://rabbitmq.com//cluster-formation.html
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2016-11-14 00:59:29 +08:00
|
|
|
|
2018-02-10 00:40:51 +08:00
|
|
|
# cluster_formation.peer_discovery_backend = rabbit_peer_discovery_classic_config
|
2016-11-14 00:59:29 +08:00
|
|
|
#
|
2018-02-10 00:40:51 +08:00
|
|
|
# cluster_formation.classic_config.nodes.1 = rabbit1@hostname
|
|
|
|
# cluster_formation.classic_config.nodes.2 = rabbit2@hostname
|
|
|
|
# cluster_formation.classic_config.nodes.3 = rabbit3@hostname
|
|
|
|
# cluster_formation.classic_config.nodes.4 = rabbit4@hostname
|
2016-10-12 18:14:04 +08:00
|
|
|
|
2016-10-25 22:50:02 +08:00
|
|
|
## DNS-based peer discovery. This backend will list A records
|
|
|
|
## of the configured hostname and perform reverse lookups for
|
|
|
|
## the addresses returned.
|
2016-11-14 00:59:29 +08:00
|
|
|
|
2018-02-10 00:40:51 +08:00
|
|
|
# cluster_formation.peer_discovery_backend = rabbit_peer_discovery_dns
|
|
|
|
# cluster_formation.dns.hostname = discovery.eng.example.local
|
2016-10-25 22:50:02 +08:00
|
|
|
|
2016-10-12 18:14:04 +08:00
|
|
|
## This node's type can be configured. If you are not sure
|
|
|
|
## what node type to use, always use 'disc'.
|
2018-02-10 00:40:51 +08:00
|
|
|
# cluster_formation.node_type = disc
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Interval (in milliseconds) at which we send keepalive messages
|
|
|
|
## to other cluster members. Note that this is not the same thing
|
|
|
|
## as net_ticktime; missed keepalive messages will not cause nodes
|
|
|
|
## to be considered down.
|
|
|
|
##
|
|
|
|
# cluster_keepalive_interval = 10000
|
|
|
|
|
|
|
|
##
|
|
|
|
## Statistics Collection
|
|
|
|
## =====================
|
|
|
|
##
|
|
|
|
|
|
|
|
## Statistics collection interval (in milliseconds). Increasing
|
|
|
|
## this will reduce the load on management database.
|
|
|
|
##
|
|
|
|
# collect_statistics_interval = 5000
|
|
|
|
|
2020-02-12 21:00:19 +08:00
|
|
|
## Fine vs. coarse statistics
|
|
|
|
#
|
|
|
|
# This value is no longer meant to be configured directly.
|
|
|
|
#
|
|
|
|
# See https://www.rabbitmq.com/management.html#fine-stats.
|
|
|
|
|
2019-10-28 01:35:04 +08:00
|
|
|
##
|
|
|
|
## Ra Settings
|
|
|
|
## =====================
|
|
|
|
##
|
2019-10-28 18:49:26 +08:00
|
|
|
# raft.segment_max_entries = 65536
|
2019-10-28 01:35:04 +08:00
|
|
|
# raft.wal_max_size_bytes = 1048576
|
2020-05-01 18:43:42 +08:00
|
|
|
# raft.wal_max_batch_size = 4096
|
2019-10-28 01:35:04 +08:00
|
|
|
# raft.snapshot_chunk_size = 1000000
|
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
## Misc/Advanced Options
|
|
|
|
## =====================
|
|
|
|
##
|
|
|
|
## NB: Change these only if you understand what you are doing!
|
|
|
|
##
|
|
|
|
|
Deprecated features: New module to manage deprecated features (!)
This introduces a way to declare deprecated features in the code, not
only in our communication. The new module allows to disallow the use of
a deprecated feature and/or warn the user when he relies on such a
feature.
[Why]
Currently, we only tell people about deprecated features through blog
posts and the mailing-list. This might be insufficiant for our users
that a feature they use will be removed in a future version:
* They may not read our blog or mailing-list
* They may not understand that they use such a deprecated feature
* They might wait for the big removal before they plan testing
* They might not take it seriously enough
The idea behind this patch is to increase the chance that users notice
that they are using something which is about to be dropped from
RabbitMQ. Anopther benefit is that they should be able to test how
RabbitMQ will behave in the future before the actual removal. This
should allow them to test and plan changes.
[How]
When a feature is deprecated in other large projects (such as FreeBSD
where I took the idea from), it goes through a lifecycle:
1. The feature is still available, but users get a warning somehow when
they use it. They can disable it to test.
2. The feature is still available, but disabled out-of-the-box. Users
can re-enable it (and get a warning).
3. The feature is disconnected from the build. Therefore, the code
behind it is still there, but users have to recompile the thing to be
able to use it.
4. The feature is removed from the source code. Users have to adapt or
they can't upgrade anymore.
The solution in this patch offers the same lifecycle. A deprecated
feature will be in one of these deprecation phases:
1. `permitted_by_default`: The feature is available. Users get a warning
if they use it. They can disable it from the configuration.
2. `denied_by_default`: The feature is available but disabled by
default. Users get an error if they use it and RabbitMQ behaves like
the feature is removed. They can re-enable is from the configuration
and get a warning.
3. `disconnected`: The feature is present in the source code, but is
disabled and can't be re-enabled without recompiling RabbitMQ. Users
get the same behavior as if the code was removed.
4. `removed`: The feature's code is gone.
The whole thing is based on the feature flags subsystem, but it has the
following differences with other feature flags:
* The semantic is reversed: the feature flag behind a deprecated feature
is disabled when the deprecated feature is permitted, or enabled when
the deprecated feature is denied.
* The feature flag behind a deprecated feature is enabled out-of-the-box
(meaning the deprecated feature is denied):
* if the deprecation phase is `permitted_by_default` and the
configuration denies the deprecated feature
* if the deprecation phase is `denied_by_default` and the
configuration doesn't permit the deprecated feature
* if the deprecation phase is `disconnected` or `removed`
* Feature flags behind deprecated feature don't appear in feature flags
listings.
Otherwise, deprecated features' feature flags are managed like other
feature flags, in particular inside clusters.
To declare a deprecated feature:
-rabbit_deprecated_feature(
{my_deprecated_feature,
#{deprecation_phase => permitted_by_default,
msgs => #{when_permitted => "This feature will be removed in RabbitMQ X.0"},
}}).
Then, to check the state of a deprecated feature in the code:
case rabbit_deprecated_features:is_permitted(my_deprecated_feature) of
true ->
%% The deprecated feature is still permitted.
ok;
false ->
%% The deprecated feature is gone or should be considered
%% unavailable.
error
end.
Warnings and errors are logged automatically. A message is generated
automatically, but it is possible to define a message in the deprecated
feature flag declaration like in the example above.
Here is an example of a logged warning that was generated automatically:
Feature `my_deprecated_feature` is deprecated.
By default, this feature can still be used for now.
Its use will not be permitted by default in a future minor RabbitMQ version and the feature will be removed from a future major RabbitMQ version; actual versions to be determined.
To continue using this feature when it is not permitted by default, set the following parameter in your configuration:
"deprecated_features.permit.my_deprecated_feature = true"
To test RabbitMQ as if the feature was removed, set this in your configuration:
"deprecated_features.permit.my_deprecated_feature = false"
To override the default state of `permitted_by_default` and
`denied_by_default` deprecation phases, users can set the following
configuration:
# In rabbitmq.conf:
deprecated_features.permit.my_deprecated_feature = true # or false
The actual behavior protected by a deprecated feature check is out of
scope for this subsystem. It is the repsonsibility of each deprecated
feature code to determine what to do when the deprecated feature is
denied.
V1: Deprecated feature states are initially computed during the
initialization of the registry, based on their deprecation phase and
possibly the configuration. They don't go through the `enable/1`
code at all.
V2: Manage deprecated feature states as any other non-required
feature flags. This allows to execute an `is_feature_used()`
callback to determine if a deprecated feature can be denied. This
also allows to prevent the RabbitMQ node from starting if it
continues to use a deprecated feature.
V3: Manage deprecated feature states from the registry initialization
again. This is required because we need to know very early if some
of them are denied, so that an upgrade to a version of RabbitMQ
where a deprecated feature is disconnected or removed can be
performed.
To still prevent the start of a RabbitMQ node when a denied
deprecated feature is actively used, we run the `is_feature_used()`
callback of all denied deprecated features as part of the
`sync_cluster()` task. This task is executed as part of a feature
flag refresh executed when RabbitMQ starts or when plugins are
enabled. So even though a deprecated feature is marked as denied in
the registry early in the boot process, we will still abort the
start of a RabbitMQ node if the feature is used.
V4: Support context-dependent warnings. It is now possible to set a
specific message when deprecated feature is permitted, when it is
denied and when it is removed. Generic per-context messages are
still generated.
V5: Improve default warning messages, thanks to @pstack2021.
V6: Rename the configuration variable from `permit_deprecated_features.*`
to `deprecated_features.permit.*`. As @michaelklishin said, we tend
to use shorter top-level names.
2023-02-23 00:26:52 +08:00
|
|
|
## To permit or deny a deprecated feature when it is in its
|
|
|
|
## `permitted_by_default` or `denied_by_default` deprecation phase, the
|
|
|
|
## default state can be overriden from the configuration.
|
|
|
|
##
|
|
|
|
## When a deprecated feature is permitted by default (first phase of the
|
|
|
|
## deprecation period), it means the feature is available by default and can
|
|
|
|
## be turned off by setting it to false in the configuration.
|
|
|
|
##
|
|
|
|
## When a deprecated feature is denied by default (second phase of the
|
|
|
|
## deprecation period), it means the feature is unavailable by default but can
|
|
|
|
## be turned back on by setting it to true in the configuration.
|
|
|
|
##
|
|
|
|
## When a deprecated feature is "disconnected" or "removed" (last two phases
|
|
|
|
## of the deprecation period), it is no longer possible to turn it back on
|
|
|
|
## from the configuration.
|
|
|
|
##
|
|
|
|
# deprecated_features.permit.a_deprecated_feature = true
|
|
|
|
# deprecated_features.permit.another_deprecated_feature = false
|
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
## Timeout used when waiting for Mnesia tables in a cluster to
|
|
|
|
## become available.
|
|
|
|
##
|
2016-11-04 23:05:51 +08:00
|
|
|
# mnesia_table_loading_retry_timeout = 30000
|
|
|
|
|
|
|
|
## Retries when waiting for Mnesia tables in the cluster startup. Note that
|
|
|
|
## this setting is not applied to Mnesia upgrades or node deletions.
|
|
|
|
##
|
|
|
|
# mnesia_table_loading_retry_limit = 10
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2017-10-17 07:17:04 +08:00
|
|
|
## Size in bytes below which to embed messages in the queue index.
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/persistence-conf.html
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# queue_index_embed_msgs_below = 4096
|
|
|
|
|
|
|
|
## You can also set this size in memory units
|
|
|
|
##
|
|
|
|
# queue_index_embed_msgs_below = 4kb
|
|
|
|
|
2018-03-21 15:07:07 +08:00
|
|
|
## Whether or not to enable background periodic forced GC runs for all
|
|
|
|
## Erlang processes on the node in "waiting" state.
|
2016-11-29 20:28:39 +08:00
|
|
|
##
|
|
|
|
## Disabling background GC may reduce latency for client operations,
|
2018-03-21 15:07:07 +08:00
|
|
|
## keeping it enabled may reduce median RAM usage by the binary heap
|
|
|
|
## (see https://www.erlang-solutions.com/blog/erlang-garbage-collector.html).
|
2019-01-08 04:31:54 +08:00
|
|
|
##
|
2018-03-21 15:07:07 +08:00
|
|
|
## Before trying this option, please take a look at the memory
|
2019-03-20 16:21:37 +08:00
|
|
|
## breakdown (https://www.rabbitmq.com/memory-use.html).
|
2016-11-29 17:25:32 +08:00
|
|
|
##
|
2017-06-07 22:56:39 +08:00
|
|
|
# background_gc_enabled = false
|
2016-11-29 17:25:32 +08:00
|
|
|
|
2016-11-29 20:28:39 +08:00
|
|
|
## Target (desired) interval (in milliseconds) at which we run background GC.
|
|
|
|
## The actual interval will vary depending on how long it takes to execute
|
|
|
|
## the operation (can be higher than this interval). Values less than
|
|
|
|
## 30000 milliseconds are not recommended.
|
2016-11-29 17:25:32 +08:00
|
|
|
##
|
|
|
|
# background_gc_target_interval = 60000
|
|
|
|
|
2017-02-13 18:52:38 +08:00
|
|
|
## Whether or not to enable proxy protocol support.
|
|
|
|
## Once enabled, clients cannot directly connect to the broker
|
|
|
|
## anymore. They must connect through a load balancer that sends the
|
|
|
|
## proxy protocol header to the broker at connection time.
|
|
|
|
## This setting applies only to AMQP clients, other protocols
|
|
|
|
## like MQTT or STOMP have their own setting to enable proxy protocol.
|
|
|
|
## See the plugins documentation for more information.
|
|
|
|
##
|
|
|
|
# proxy_protocol = false
|
|
|
|
|
Add ability to customize product name, version & banner
To override the product name (defaulting to "RabbitMQ"):
* set the `$RABBITMQ_PRODUCT_NAME` environment variable, or
* set the `rabbit` application `product_name` variable.
To override the product version:
* set the `$RABBITMQ_PRODUCT_VERSION` environment variable, or
* set the `rabbit` application `product_version` variable.
To add content to the banner (both the copy logged and the one printed
to stdout), indicate the filename which contains it, à la `/etc/motd`
using:
* the `$RABBITMQ_MOTD_FILE` environment variable, or
* the `rabbit` application `motd_file` variable.
The default motd file is `/etc/rabbitmq/motd` on Unix and
`%APPDATA%\RabbitMQ\motd.txt` on Windows.
Here is an example of the printed banner with name, version & motd
configured:
## ## WeatherMQ 1.2.3
## ##
########## Copyright (c) 2007-2020 Pivotal Software, Inc.
###### ##
########## Licensed under the MPL 1.1. Website: https://rabbitmq.com
This is an example of a RabbitMQ message of the day.
The message is written in Paris, France. \ /
It is partly cloudy outside, with a _ /"".-.
temperature of 12°C. Wind is around \_( ).
30-40 km/h, from south-west. /(___(__)
Doc guides: https://rabbitmq.com/documentation.html
Support: https://rabbitmq.com/contact.html
Tutorials: https://rabbitmq.com/getstarted.html
Monitoring: https://rabbitmq.com/monitoring.html
Logs: /tmp/rabbitmq-test-instances/rabbit/log/rabbit@cassini.log
/tmp/rabbitmq-test-instances/rabbit/log/rabbit@cassini_upgrade.log
Config file(s): /tmp/rabbitmq-test-instances/test.config
Starting broker... completed with 0 plugins.
New APIS are available to query those product informations and use them
in e.g. plugins such as the management API/UI:
* rabbit:product_info/0
* rabbit:product_name/0
* rabbit:product_version/0
* rabbit:motd_file/0
* rabbit:motd/0
[#170054940]
2020-01-13 18:24:01 +08:00
|
|
|
## Overriden product name and version.
|
|
|
|
## They are set to "RabbitMQ" and the release version by default.
|
|
|
|
# product.name = RabbitMQ
|
|
|
|
# product.version = 1.2.3
|
|
|
|
|
|
|
|
## "Message of the day" file.
|
|
|
|
## Its content is used to expand the logged and printed banners.
|
|
|
|
## Default to /etc/rabbitmq/motd on Unix, %APPDATA%\RabbitMQ\motd.txt
|
|
|
|
## on Windows.
|
|
|
|
# motd_file = /etc/rabbitmq/motd
|
|
|
|
|
2021-04-21 00:44:14 +08:00
|
|
|
## Consumer timeout
|
|
|
|
## If a message delivered to a consumer has not been acknowledge before this timer
|
|
|
|
## triggers the channel will be force closed by the broker. This ensure that
|
|
|
|
## faultly consumers that never ack will not hold on to messages indefinitely.
|
|
|
|
##
|
|
|
|
# consumer_timeout = 900000
|
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
## Advanced Erlang Networking/Clustering Options.
|
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/clustering.html
|
2016-02-01 22:27:56 +08:00
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
|
|
|
|
# ======================================
|
|
|
|
# Kernel section
|
|
|
|
# ======================================
|
|
|
|
|
2018-12-02 17:28:59 +08:00
|
|
|
## Timeout used to detect peer unavailability, including CLI tools.
|
|
|
|
## Related doc guide: https://www.rabbitmq.com/nettick.html.
|
|
|
|
##
|
2018-02-22 18:25:45 +08:00
|
|
|
# net_ticktime = 60
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2018-12-02 17:28:59 +08:00
|
|
|
## Inter-node communication port range.
|
2019-08-13 00:37:26 +08:00
|
|
|
## The parameters inet_dist_listen_min and inet_dist_listen_max
|
2019-02-14 16:59:12 +08:00
|
|
|
## can be configured in the classic config format only.
|
2018-12-02 17:28:59 +08:00
|
|
|
## Related doc guide: https://www.rabbitmq.com/networking.html#epmd-inet-dist-port-range.
|
2019-02-14 16:59:12 +08:00
|
|
|
|
2018-12-02 17:28:59 +08:00
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
## RabbitMQ Management Plugin
|
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/management.html.
|
2016-02-01 22:27:56 +08:00
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
|
|
|
|
# =======================================
|
|
|
|
# Management section
|
|
|
|
# =======================================
|
|
|
|
|
2017-10-17 07:17:04 +08:00
|
|
|
## Preload schema definitions from the following JSON file.
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/management.html#load-definitions.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2017-10-17 06:36:15 +08:00
|
|
|
# management.load_definitions = /path/to/exported/definitions.json
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Log all requests to the management HTTP API to a file.
|
|
|
|
##
|
|
|
|
# management.http_log_dir = /path/to/access.log
|
|
|
|
|
2019-01-08 04:31:54 +08:00
|
|
|
## HTTP listener and embedded Web server settings.
|
|
|
|
# ## See https://rabbitmq.com/management.html for details.
|
|
|
|
#
|
|
|
|
# management.tcp.port = 15672
|
|
|
|
# management.tcp.ip = 0.0.0.0
|
|
|
|
#
|
|
|
|
# management.tcp.shutdown_timeout = 7000
|
|
|
|
# management.tcp.max_keepalive = 120
|
|
|
|
# management.tcp.idle_timeout = 120
|
|
|
|
# management.tcp.inactivity_timeout = 120
|
|
|
|
# management.tcp.request_timeout = 120
|
|
|
|
# management.tcp.compress = true
|
|
|
|
|
|
|
|
## HTTPS listener settings.
|
|
|
|
## See https://rabbitmq.com/management.html and https://rabbitmq.com/ssl.html for details.
|
|
|
|
##
|
|
|
|
# management.ssl.port = 15671
|
|
|
|
# management.ssl.cacertfile = /path/to/ca_certificate.pem
|
|
|
|
# management.ssl.certfile = /path/to/server_certificate.pem
|
|
|
|
# management.ssl.keyfile = /path/to/server_key.pem
|
|
|
|
|
|
|
|
## More TLS options
|
|
|
|
# management.ssl.honor_cipher_order = true
|
|
|
|
# management.ssl.honor_ecc_order = true
|
2021-02-14 06:35:08 +08:00
|
|
|
|
|
|
|
## These are highly recommended for TLSv1.2 but cannot be used
|
|
|
|
## with TLSv1.3. If TLSv1.3 is enabled, these lines MUST be removed.
|
2019-01-08 04:31:54 +08:00
|
|
|
# management.ssl.client_renegotiation = false
|
|
|
|
# management.ssl.secure_renegotiate = true
|
|
|
|
|
|
|
|
## Supported TLS versions
|
|
|
|
# management.ssl.versions.1 = tlsv1.2
|
|
|
|
|
|
|
|
## Cipher suites the server is allowed to use
|
|
|
|
# management.ssl.ciphers.1 = ECDHE-ECDSA-AES256-GCM-SHA384
|
|
|
|
# management.ssl.ciphers.2 = ECDHE-RSA-AES256-GCM-SHA384
|
|
|
|
# management.ssl.ciphers.3 = ECDHE-ECDSA-AES256-SHA384
|
|
|
|
# management.ssl.ciphers.4 = ECDHE-RSA-AES256-SHA384
|
|
|
|
# management.ssl.ciphers.5 = ECDH-ECDSA-AES256-GCM-SHA384
|
|
|
|
# management.ssl.ciphers.6 = ECDH-RSA-AES256-GCM-SHA384
|
|
|
|
# management.ssl.ciphers.7 = ECDH-ECDSA-AES256-SHA384
|
|
|
|
# management.ssl.ciphers.8 = ECDH-RSA-AES256-SHA384
|
|
|
|
# management.ssl.ciphers.9 = DHE-RSA-AES256-GCM-SHA384
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2020-02-12 08:49:38 +08:00
|
|
|
## URL path prefix for HTTP API and management UI
|
2020-02-12 08:50:24 +08:00
|
|
|
# management.path_prefix = /a-prefix
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## One of 'basic', 'detailed' or 'none'. See
|
2019-03-20 16:21:37 +08:00
|
|
|
## https://rabbitmq.com/management.html#fine-stats for more details.
|
2016-02-01 22:27:56 +08:00
|
|
|
# management.rates_mode = basic
|
|
|
|
|
|
|
|
## Configure how long aggregated data (such as message rates and queue
|
|
|
|
## lengths) is retained. Please read the plugin's documentation in
|
2019-03-20 16:21:37 +08:00
|
|
|
## https://rabbitmq.com/management.html#configuration for more
|
2016-02-01 22:27:56 +08:00
|
|
|
## details.
|
2017-08-11 06:15:06 +08:00
|
|
|
## Your can use 'minute', 'hour' and 'day' keys or integer key (in seconds)
|
2016-02-01 22:27:56 +08:00
|
|
|
# management.sample_retention_policies.global.minute = 5
|
|
|
|
# management.sample_retention_policies.global.hour = 60
|
2017-08-11 06:15:06 +08:00
|
|
|
# management.sample_retention_policies.global.day = 1200
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
# management.sample_retention_policies.basic.minute = 5
|
|
|
|
# management.sample_retention_policies.basic.hour = 60
|
|
|
|
|
|
|
|
# management.sample_retention_policies.detailed.10 = 5
|
|
|
|
|
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
## RabbitMQ Shovel Plugin
|
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/shovel.html
|
2016-02-01 22:27:56 +08:00
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
|
2018-08-14 20:59:36 +08:00
|
|
|
## See advanced.config.example for a Shovel plugin example
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
|
|
|
|
## ----------------------------------------------------------------------------
|
2017-10-17 06:36:15 +08:00
|
|
|
## RabbitMQ STOMP Plugin
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/stomp.html
|
2016-02-01 22:27:56 +08:00
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
|
|
|
|
# =======================================
|
|
|
|
# STOMP section
|
|
|
|
# =======================================
|
|
|
|
|
2019-01-08 04:31:54 +08:00
|
|
|
## See https://rabbitmq.com/stomp.html for details.
|
|
|
|
|
|
|
|
## TCP listeners.
|
|
|
|
##
|
|
|
|
# stomp.listeners.tcp.1 = 127.0.0.1:61613
|
|
|
|
# stomp.listeners.tcp.2 = ::1:61613
|
|
|
|
|
|
|
|
## TCP listener settings
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2019-01-08 04:31:54 +08:00
|
|
|
# stomp.tcp_listen_options.backlog = 2048
|
|
|
|
# stomp.tcp_listen_options.recbuf = 131072
|
|
|
|
# stomp.tcp_listen_options.sndbuf = 131072
|
|
|
|
#
|
|
|
|
# stomp.tcp_listen_options.keepalive = true
|
|
|
|
# stomp.tcp_listen_options.nodelay = true
|
|
|
|
#
|
|
|
|
# stomp.tcp_listen_options.exit_on_close = true
|
2022-12-12 16:57:33 +08:00
|
|
|
# stomp.tcp_listen_options.send_timeout = 120000
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2019-01-08 04:31:54 +08:00
|
|
|
## Proxy protocol support
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2019-01-08 04:31:54 +08:00
|
|
|
# stomp.proxy_protocol = false
|
|
|
|
|
|
|
|
## TLS listeners
|
|
|
|
## See https://rabbitmq.com/stomp.html and https://rabbitmq.com/ssl.html for details.
|
2016-02-17 19:11:57 +08:00
|
|
|
# stomp.listeners.ssl.default = 61614
|
2019-01-08 04:31:54 +08:00
|
|
|
#
|
|
|
|
# ssl_options.cacertfile = path/to/cacert.pem
|
|
|
|
# ssl_options.certfile = path/to/cert.pem
|
|
|
|
# ssl_options.keyfile = path/to/key.pem
|
|
|
|
# ssl_options.verify = verify_peer
|
|
|
|
# ssl_options.fail_if_no_peer_cert = true
|
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Number of Erlang processes that will accept connections for the TCP
|
2017-10-17 07:17:04 +08:00
|
|
|
## and TLS listeners.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# stomp.num_acceptors.tcp = 10
|
|
|
|
# stomp.num_acceptors.ssl = 1
|
|
|
|
|
2017-10-17 07:17:04 +08:00
|
|
|
## Additional TLS options
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2017-10-17 07:17:04 +08:00
|
|
|
## Extract a name from the client's certificate when using TLS.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# stomp.ssl_cert_login = true
|
|
|
|
|
|
|
|
## Set a default user name and password. This is used as the default login
|
|
|
|
## whenever a CONNECT frame omits the login and passcode headers.
|
|
|
|
##
|
|
|
|
## Please note that setting this will allow clients to connect without
|
|
|
|
## authenticating!
|
|
|
|
##
|
|
|
|
# stomp.default_user = guest
|
|
|
|
# stomp.default_pass = guest
|
|
|
|
|
2017-10-17 07:17:04 +08:00
|
|
|
## If a default user is configured, or you have configured use TLS client
|
2016-02-01 22:27:56 +08:00
|
|
|
## certificate based authentication, you can choose to allow clients to
|
|
|
|
## omit the CONNECT frame entirely. If set to true, the client is
|
|
|
|
## automatically connected as the default user or user supplied in the
|
2017-10-17 07:17:04 +08:00
|
|
|
## TLS certificate whenever the first frame sent on a session is not a
|
2016-02-01 22:27:56 +08:00
|
|
|
## CONNECT frame.
|
|
|
|
##
|
|
|
|
# stomp.implicit_connect = true
|
|
|
|
|
2017-02-13 18:52:38 +08:00
|
|
|
## Whether or not to enable proxy protocol support.
|
|
|
|
## Once enabled, clients cannot directly connect to the broker
|
|
|
|
## anymore. They must connect through a load balancer that sends the
|
|
|
|
## proxy protocol header to the broker at connection time.
|
|
|
|
## This setting applies only to STOMP clients, other protocols
|
|
|
|
## like MQTT or AMQP have their own setting to enable proxy protocol.
|
|
|
|
## See the plugins or broker documentation for more information.
|
|
|
|
##
|
|
|
|
# stomp.proxy_protocol = false
|
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
## RabbitMQ MQTT Adapter
|
|
|
|
##
|
|
|
|
## See https://github.com/rabbitmq/rabbitmq-mqtt/blob/stable/README.md
|
|
|
|
## for details
|
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
|
|
|
|
# =======================================
|
|
|
|
# MQTT section
|
|
|
|
# =======================================
|
|
|
|
|
2019-01-08 04:31:54 +08:00
|
|
|
## TCP listener settings.
|
|
|
|
##
|
|
|
|
# mqtt.listeners.tcp.1 = 127.0.0.1:61613
|
|
|
|
# mqtt.listeners.tcp.2 = ::1:61613
|
|
|
|
|
|
|
|
## TCP listener options (as per the broker configuration).
|
|
|
|
##
|
|
|
|
# mqtt.tcp_listen_options.backlog = 4096
|
|
|
|
# mqtt.tcp_listen_options.recbuf = 131072
|
|
|
|
# mqtt.tcp_listen_options.sndbuf = 131072
|
|
|
|
#
|
|
|
|
# mqtt.tcp_listen_options.keepalive = true
|
|
|
|
# mqtt.tcp_listen_options.nodelay = true
|
|
|
|
#
|
|
|
|
# mqtt.tcp_listen_options.exit_on_close = true
|
2022-12-12 16:57:33 +08:00
|
|
|
# mqtt.tcp_listen_options.send_timeout = 120000
|
2019-01-08 04:31:54 +08:00
|
|
|
|
|
|
|
## TLS listener settings
|
|
|
|
## ## See https://rabbitmq.com/mqtt.html and https://rabbitmq.com/ssl.html for details.
|
|
|
|
#
|
|
|
|
# mqtt.listeners.ssl.default = 8883
|
|
|
|
#
|
|
|
|
# ssl_options.cacertfile = /path/to/tls/ca_certificate_bundle.pem
|
|
|
|
# ssl_options.certfile = /path/to/tls/server_certificate.pem
|
|
|
|
# ssl_options.keyfile = /path/to/tls/server_key.pem
|
|
|
|
# ssl_options.verify = verify_peer
|
|
|
|
# ssl_options.fail_if_no_peer_cert = true
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
|
|
## Number of Erlang processes that will accept connections for the TCP
|
|
|
|
## and TLS listeners.
|
|
|
|
##
|
|
|
|
# mqtt.num_acceptors.tcp = 10
|
|
|
|
# mqtt.num_acceptors.ssl = 10
|
|
|
|
|
|
|
|
## Whether or not to enable proxy protocol support.
|
|
|
|
## Once enabled, clients cannot directly connect to the broker
|
|
|
|
## anymore. They must connect through a load balancer that sends the
|
|
|
|
## proxy protocol header to the broker at connection time.
|
|
|
|
## This setting applies only to STOMP clients, other protocols
|
|
|
|
## like STOMP or AMQP have their own setting to enable proxy protocol.
|
|
|
|
## See the plugins or broker documentation for more information.
|
|
|
|
##
|
|
|
|
# mqtt.proxy_protocol = false
|
|
|
|
|
2018-01-10 02:45:14 +08:00
|
|
|
## Set the default user name and password used for anonymous connections (when client
|
|
|
|
## provides no credentials). Anonymous connections are highly discouraged!
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# mqtt.default_user = guest
|
|
|
|
# mqtt.default_pass = guest
|
|
|
|
|
2018-01-10 02:45:14 +08:00
|
|
|
## Enable anonymous connections. If this is set to false, clients MUST provide
|
|
|
|
## credentials in order to connect. See also the mqtt.default_user/mqtt.default_pass
|
|
|
|
## keys. Anonymous connections are highly discouraged!
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# mqtt.allow_anonymous = true
|
|
|
|
|
2018-06-20 18:02:37 +08:00
|
|
|
## If you have multiple vhosts, specify the one to which the
|
2016-02-01 22:27:56 +08:00
|
|
|
## adapter connects.
|
|
|
|
##
|
|
|
|
# mqtt.vhost = /
|
|
|
|
|
|
|
|
## Specify the exchange to which messages from MQTT clients are published.
|
|
|
|
##
|
|
|
|
# mqtt.exchange = amq.topic
|
|
|
|
|
2023-03-17 20:48:26 +08:00
|
|
|
## Define the maximum Session Expiry Interval in seconds allowed by the server.
|
|
|
|
## 'infinity' means the session does not expire.
|
|
|
|
## An MQTT 5.0 client can choose a lower value.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2023-07-13 22:38:47 +08:00
|
|
|
# mqtt.max_session_expiry_interval_seconds = 1800
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Set the prefetch count (governing the maximum number of unacknowledged
|
|
|
|
## messages that will be delivered).
|
|
|
|
##
|
|
|
|
# mqtt.prefetch = 10
|
|
|
|
|
2022-04-05 18:34:32 +08:00
|
|
|
## Sets the durable queue type to be used for QoS 1 subscriptions.
|
|
|
|
##
|
|
|
|
## Supported types are:
|
2022-04-05 15:16:24 +08:00
|
|
|
##
|
2022-04-05 18:34:32 +08:00
|
|
|
## * classic
|
|
|
|
## * quorum
|
|
|
|
##
|
|
|
|
## IMPORTANT: changing this setting requires all existing queues used by
|
|
|
|
## the MQTT plugin to be DELETED or clients will fail to subscribe.
|
|
|
|
## So this setting should be used for new clusters.
|
|
|
|
##
|
2022-04-05 15:16:24 +08:00
|
|
|
# mqtt.durable_queue_type = classic
|
|
|
|
|
|
|
|
|
2017-02-13 18:52:38 +08:00
|
|
|
|
2016-02-01 22:27:56 +08:00
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
## RabbitMQ AMQP 1.0 Support
|
|
|
|
##
|
2017-10-17 07:17:04 +08:00
|
|
|
## See https://github.com/rabbitmq/rabbitmq-amqp1.0/blob/stable/README.md.
|
2016-02-01 22:27:56 +08:00
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
|
|
|
|
# =======================================
|
2017-10-17 07:17:04 +08:00
|
|
|
# AMQP 1.0 section
|
2016-02-01 22:27:56 +08:00
|
|
|
# =======================================
|
|
|
|
|
|
|
|
|
|
|
|
## Connections that are not authenticated with SASL will connect as this
|
|
|
|
## account. See the README for more information.
|
|
|
|
##
|
|
|
|
## Please note that setting this will allow clients to connect without
|
|
|
|
## authenticating!
|
|
|
|
##
|
|
|
|
# amqp1_0.default_user = guest
|
|
|
|
|
|
|
|
## Enable protocol strict mode. See the README for more information.
|
|
|
|
##
|
|
|
|
# amqp1_0.protocol_strict_mode = false
|
|
|
|
|
2018-01-10 00:50:22 +08:00
|
|
|
## Logging settings.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
Switch from Lager to the new Erlang Logger API for logging
The configuration remains the same for the end-user. The only exception
is the log root directory: it is now set through the `log_root`
application env. variable in `rabbit`. People using the Cuttlefish-based
configuration file are not affected by this exception.
The main change is how the logging facility is configured. It now
happens in `rabbit_prelaunch_logging`. The `rabbit_lager` module is
removed.
The supported outputs remain the same: the console, text files, the
`amq.rabbitmq.log` exchange and syslog.
The message text format slightly changed: the timestamp is more precise
(now to the microsecond) and the level can be abbreviated to always be
4-character long to align all messages and improve readability. Here is
an example:
2021-03-03 10:22:30.377392+01:00 [dbug] <0.229.0> == Prelaunch DONE ==
2021-03-03 10:22:30.377860+01:00 [info] <0.229.0>
2021-03-03 10:22:30.377860+01:00 [info] <0.229.0> Starting RabbitMQ 3.8.10+115.g071f3fb on Erlang 23.2.5
2021-03-03 10:22:30.377860+01:00 [info] <0.229.0> Licensed under the MPL 2.0. Website: https://rabbitmq.com
The example above also shows that multiline messages are supported and
each line is prepended with the same prefix (the timestamp, the level
and the Erlang process PID).
JSON is also supported as a message format and now for any outputs.
Indeed, it is possible to use it with e.g. syslog or the exchange. Here
is an example of a JSON-formatted message sent to syslog:
Mar 3 11:23:06 localhost rabbitmq-server[27908] <0.229.0> - {"time":"2021-03-03T11:23:06.998466+01:00","level":"notice","msg":"Logging: configured log handlers are now ACTIVE","meta":{"domain":"rabbitmq.prelaunch","file":"src/rabbit_prelaunch_logging.erl","gl":"<0.228.0>","line":311,"mfa":["rabbit_prelaunch_logging","configure_logger",1],"pid":"<0.229.0>"}}
For quick testing, the values accepted by the `$RABBITMQ_LOGS`
environment variables were extended:
* `-` still means stdout
* `-stderr` means stderr
* `syslog:` means syslog on localhost
* `exchange:` means logging to `amq.rabbitmq.log`
`$RABBITMQ_LOG` was also extended. It now accepts a `+json` modifier (in
addition to the existing `+color` one). With that modifier, messages are
formatted as JSON intead of plain text.
The `rabbitmqctl rotate_logs` command is deprecated. The reason is
Logger does not expose a function to force log rotation. However, it
will detect when a file was rotated by an external tool.
From a developer point of view, the old `rabbit_log*` API remains
supported, though it is now deprecated. It is implemented as regular
modules: there is no `parse_transform` involved anymore.
In the code, it is recommended to use the new Logger macros. For
instance, `?LOG_INFO(Format, Args)`. If possible, messages should be
augmented with some metadata. For instance (note the map after the
message):
?LOG_NOTICE("Logging: switching to configured handler(s); following "
"messages may not be visible in this log output",
#{domain => ?RMQLOG_DOMAIN_PRELAUNCH}),
Domains in Erlang Logger parlance are the way to categorize messages.
Some predefined domains, matching previous categories, are currently
defined in `rabbit_common/include/logging.hrl` or headers in the
relevant plugins for plugin-specific categories.
At this point, very few messages have been converted from the old
`rabbit_log*` API to the new macros. It can be done gradually when
working on a particular module or logging.
The Erlang builtin console/file handler, `logger_std_h`, has been forked
because it lacks date-based file rotation. The configuration of
date-based rotation is identical to Lager. Once the dust has settled for
this feature, the goal is to submit it upstream for inclusion in Erlang.
The forked module is calld `rabbit_logger_std_h` and is based
`logger_std_h` in Erlang 23.0.
2021-01-13 00:55:27 +08:00
|
|
|
## See https://rabbitmq.com/logging.html for details.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
|
2019-02-13 00:56:05 +08:00
|
|
|
## Log directory, taken from the RABBITMQ_LOG_BASE env variable by default.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2018-01-10 00:50:22 +08:00
|
|
|
# log.dir = /var/log/rabbitmq
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2018-01-10 00:50:22 +08:00
|
|
|
## Logging to file. Can be false or a filename.
|
2016-02-01 22:27:56 +08:00
|
|
|
## Default:
|
|
|
|
# log.file = rabbit.log
|
|
|
|
|
2018-01-10 00:50:22 +08:00
|
|
|
## To disable logging to a file
|
2016-02-01 22:27:56 +08:00
|
|
|
# log.file = false
|
|
|
|
|
2018-01-10 00:50:22 +08:00
|
|
|
## Log level for file logging
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
# log.file.level = info
|
|
|
|
|
2018-01-25 01:39:53 +08:00
|
|
|
## File rotation config. No rotation by default.
|
2018-01-10 00:50:22 +08:00
|
|
|
## DO NOT SET rotation date to ''. Leave the value unset if "" is the desired value
|
2016-11-29 20:28:39 +08:00
|
|
|
# log.file.rotation.date = $D0
|
2016-02-01 22:27:56 +08:00
|
|
|
# log.file.rotation.size = 0
|
|
|
|
|
2018-01-10 00:50:22 +08:00
|
|
|
## Logging to console (can be true or false)
|
|
|
|
##
|
|
|
|
# log.console = false
|
|
|
|
|
|
|
|
## Log level for console logging
|
|
|
|
##
|
|
|
|
# log.console.level = info
|
|
|
|
|
|
|
|
## Logging to the amq.rabbitmq.log exchange (can be true or false)
|
|
|
|
##
|
|
|
|
# log.exchange = false
|
|
|
|
|
|
|
|
## Log level to use when logging to the amq.rabbitmq.log exchange
|
|
|
|
##
|
|
|
|
# log.exchange.level = info
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
## RabbitMQ LDAP Plugin
|
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/ldap.html.
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
|
|
|
## ----------------------------------------------------------------------------
|
|
|
|
|
|
|
|
# =======================================
|
|
|
|
# LDAP section
|
|
|
|
# =======================================
|
|
|
|
|
|
|
|
##
|
|
|
|
## Connecting to the LDAP server(s)
|
|
|
|
## ================================
|
|
|
|
##
|
|
|
|
|
|
|
|
## Specify servers to bind to. You *must* set this in order for the plugin
|
|
|
|
## to work properly.
|
|
|
|
##
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.servers.1 = your-server-name-goes-here
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## You can define multiple servers
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.servers.2 = your-other-server
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2017-10-17 07:17:04 +08:00
|
|
|
## Connect to the LDAP server using TLS
|
2016-02-01 22:27:56 +08:00
|
|
|
##
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.use_ssl = false
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Specify the LDAP port to connect to
|
|
|
|
##
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.port = 389
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## LDAP connection timeout, in milliseconds or 'infinity'
|
|
|
|
##
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.timeout = infinity
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Or number
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.timeout = 500
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Enable logging of LDAP queries.
|
|
|
|
## One of
|
|
|
|
## - false (no logging is performed)
|
|
|
|
## - true (verbose logging of the logic used by the plugin)
|
|
|
|
## - network (as true, but additionally logs LDAP network traffic)
|
|
|
|
##
|
|
|
|
## Defaults to false.
|
|
|
|
##
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.log = false
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Also can be true or network
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.log = true
|
|
|
|
# auth_ldap.log = network
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
##
|
|
|
|
## Authentication
|
|
|
|
## ==============
|
|
|
|
##
|
|
|
|
|
|
|
|
## Pattern to convert the username given through AMQP to a DN before
|
|
|
|
## binding
|
|
|
|
##
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.user_dn_pattern = cn=${username},ou=People,dc=example,dc=com
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Alternatively, you can convert a username to a Distinguished
|
|
|
|
## Name via an LDAP lookup after binding. See the documentation for
|
|
|
|
## full details.
|
|
|
|
|
|
|
|
## When converting a username to a dn via a lookup, set these to
|
|
|
|
## the name of the attribute that represents the user name, and the
|
|
|
|
## base DN for the lookup query.
|
|
|
|
##
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.dn_lookup_attribute = userPrincipalName
|
|
|
|
# auth_ldap.dn_lookup_base = DC=gopivotal,DC=com
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Controls how to bind for authorisation queries and also to
|
|
|
|
## retrieve the details of users logging in without presenting a
|
|
|
|
## password (e.g., SASL EXTERNAL).
|
|
|
|
## One of
|
|
|
|
## - as_user (to bind as the authenticated user - requires a password)
|
|
|
|
## - anon (to bind anonymously)
|
|
|
|
## - {UserDN, Password} (to bind with a specified user name and password)
|
|
|
|
##
|
|
|
|
## Defaults to 'as_user'.
|
|
|
|
##
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.other_bind = as_user
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Or can be more complex:
|
2017-02-09 18:52:36 +08:00
|
|
|
# auth_ldap.other_bind.user_dn = User
|
|
|
|
# auth_ldap.other_bind.password = Password
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## If user_dn and password defined - other options is ignored.
|
|
|
|
|
|
|
|
# -----------------------------
|
|
|
|
# Too complex section of LDAP
|
|
|
|
# -----------------------------
|
|
|
|
|
|
|
|
##
|
|
|
|
## Authorisation
|
|
|
|
## =============
|
|
|
|
##
|
|
|
|
|
|
|
|
## The LDAP plugin can perform a variety of queries against your
|
2017-10-17 07:17:04 +08:00
|
|
|
## LDAP server to determine questions of authorisation.
|
|
|
|
##
|
2019-03-20 16:21:37 +08:00
|
|
|
## Related doc guide: https://rabbitmq.com/ldap.html#authorisation.
|
2016-02-01 22:27:56 +08:00
|
|
|
|
2019-09-19 19:18:25 +08:00
|
|
|
## Following configuration should be defined in advanced.config file
|
|
|
|
## DO NOT UNCOMMENT THESE LINES!
|
2016-02-01 22:27:56 +08:00
|
|
|
|
|
|
|
## Set the query to use when determining vhost access
|
|
|
|
##
|
|
|
|
## {vhost_access_query, {in_group,
|
|
|
|
## "ou=${vhost}-users,ou=vhosts,dc=example,dc=com"}},
|
|
|
|
|
|
|
|
## Set the query to use when determining resource (e.g., queue) access
|
|
|
|
##
|
|
|
|
## {resource_access_query, {constant, true}},
|
|
|
|
|
|
|
|
## Set queries to determine which tags a user has
|
|
|
|
##
|
|
|
|
## {tag_queries, []}
|
|
|
|
# ]},
|
|
|
|
# -----------------------------
|