Menu

Installing on RPM-based Linux (RHEL, CentOS, Fedora, openSUSE)

Overview

rabbitmq-server is included in standard Fedora and RHEL repositories. However, the versions included are usually outdated.

There are two ways to install the most recent version of RabbitMQ:

The following guide focuses on RabbitMQ installation on RPM-based distributions such as Fedora, RHEL and CentOS. It covers a number of topics:

and more.

Overview

The package is distributed via Yum repositories on PackageCloud and Bintray.

rabbitmq-server is included in Fedora. However, the versions included often lag behind RabbitMQ releases. It is recommended that you use Yum repositories from PackageCloud or Bintray.

Check the Fedora package details for which version of the server is available for which versions of the distribution.

Supported Distributions

Below is a list of supported RPM-based distributions as of RabbitMQ 3.6.3:

  • CentOS 7.x and x.x (note: there are two separate RPM packages for each series)
  • RedHat Enterprise Linux 7.x and x.x (same packages as for CentOS)
  • Fedora 23 through 25 (use the CentOS 7.x package)
The packages may work on other RPM-based distributions if dependencies are satisfied but their testing and support is done on a best effort basis.

User Privilege Requirements

RabbitMQ RPM package will require sudo privileges to install and manage. In environments where sudo isn't available, consider using the generic binary build.

Install Erlang

Before installing RabbitMQ, you must install a supported version of Erlang/OTP. There are three commonly used sources for Erlang packages on RPM-based distributions.

  • Team RabbitMQ produces a package stripped down to only provide those components needed to run RabbitMQ. It might be easiest to use if installing Erlang's dependencies is proving difficult.
  • Erlang Solutions produces packages that are usually reasonably up to date and involve installation of a potentially excessive list of dependencies.
  • EPEL ("Extra Packages for Enterprise Linux"); part of the Red Hat/Fedora organisation, provides many additional packages, including Erlang. These are the most official packages but tend to be out of date. The packages are split into many small pieces.

Zero-dependency Erlang from RabbitMQ

Zero dependency Erlang RPM package for running RabbitMQ can be installed via Yum repositories on Bintray and Package Cloud as well as a direct download.

As the name suggests, the package strips off some Erlang modules and dependencies that are not essential for running RabbitMQ.

Erlang Yum Repository from Erlang Solutions

Follow the instructions under "Installation using repository" at Erlang Solutions. Note that Erlang Solutions tend to provide cutting edge Erlang versions that may or may not be supported by RabbitMQ. Version locking (see below) is recommended when Erlang installed using this option.

Monolithic Erlang Package from Erlang Solutions

Download and install the appropriate esl-erlang RPM from Erlang Solutions.

Erlang package from the EPEL Repository

Follow the steps in the EPEL FAQ to enable EPEL on the target machine, then run the following command as root: 

yum install erlang

Package Version Locking in Yum

yum version locking plugin is recommended to prevent unwanted Erlang upgrades. This is highly recommended when Erlang is installed via the Erlang Solutions repository.

Package Dependencies

When installing with Yum, all dependencies other than Erlang/OTP should be resolved and installed automatically as long as compatible versions are available. When that's not the case, dependency packages must be installed manually. However, when installing a local RPM file via yum dependencies must be installed manually. Below is the list of dependencies of RabbitMQ server as of 3.7.0:

Install RabbitMQ Server

Using PackageCloud Yum Repository

A Yum repository with RabbitMQ packages is available from PackageCloud. A quick way to install is to use a Package Cloud-provided script. Package Cloud also can be used to install a recent Erlang version via yum.

There are more installation options available:

  • Using PackageCloud Chef cookbook
  • Using PackageCloud Puppet module
  • Manually
See PackageCloud RabbitMQ repository instructions.

Package Cloud signs distributed packages using their own GPG keys. As of late 2018 Package Cloud is undergoing a signing key migration. Instead of relying on a "master key", projects will migrate to use repository-specific signing keys. Before the migration is completed, both old and new key must be imported for forward compatibility: 

# import the new PackageCloud key that will be used starting December 1st, 2018 (GMT)
rpm --import https://packagecloud.io/rabbitmq/rabbitmq-server/gpgkey

# import the old PackageCloud key that will be discontinued on December 1st, 2018 (GMT)
rpm --import https://packagecloud.io/gpg.key

After importing both keys please follow the Package Cloud repository setup instructions.

Using Bintray Yum Repository

A Yum repository with RabbitMQ packages is available from Bintray. The package page provides a repository setup help section. Bintray also can be used to install a recent Erlang version via yum.

Before the Yum repository can be used, RabbitMQ signing key must be imported first. This makes RPM tools trust the signature on the packages provided in the repository. To do so, run rpm --import as a superuser: 

rpm --import https://github.com/rabbitmq/signing-keys/releases/download/2.0/rabbitmq-release-signing-key.asc

In order to use the Yum repository, a .repo file (e.g. rabbitmq.repo) has to be added under the /etc/yum.repos.d/ directory. The contents of the file will vary slightly between distributions (e.g. CentOS 7 vs. CentOS 6 vs. OpenSUSE). The following example targest CentOS 7: 

[bintray-rabbitmq-server]
name=bintray-rabbitmq-rpm
baseurl=https://dl.bintray.com/rabbitmq/rpm/rabbitmq-server/v3.7.x/el/7/
gpgcheck=0
repo_gpgcheck=0
enabled=1

On CentOS 6 the baseurl line would be slightly different: 

[bintray-rabbitmq-server]
name=bintray-rabbitmq-rpm
baseurl=https://dl.bintray.com/rabbitmq/rpm/rabbitmq-server/v3.7.x/el/6/
gpgcheck=0
repo_gpgcheck=0
enabled=1

The following example targets OpenSUSE: 

[bintray-rabbitmq-server]
name=bintray-rabbitmq-rpm
baseurl=https://dl.bintray.com/rabbitmq/rpm/rabbitmq-server/v3.7.x/opensuse/42.1/
gpgcheck=0
repo_gpgcheck=0
enabled=1

The following example targets SLES 11.x: 

[bintray-rabbitmq-server]
name=bintray-rabbitmq-rpm
baseurl=https://dl.bintray.com/rabbitmq/rpm/rabbitmq-server/v3.7.x/sles/11
gpgcheck=0
repo_gpgcheck=0
enabled=1

With rpm and Downloaded RPM

After downloading the server package, issue the following command as 'root': 

rpm --import https://github.com/rabbitmq/signing-keys/releases/download/2.0/rabbitmq-release-signing-key.asc
# this example assumes the CentOS 7 version of the package
yum install rabbitmq-server-3.7.9-1.el7.noarch.rpm

RabbitMQ public signing key is also available from rabbitmq.com: 

rpm --import https://www.rabbitmq.com/rabbitmq-release-signing-key.asc
# this example assumes the CentOS 7 version of the package
yum install rabbitmq-server-3.7.9-1.el7.noarch.rpm

Download the Server

In some cases it may easier to download the package and install it manually. The package can be downloaded from GitHub.

DescriptionDownload  
RPM for RHEL Linux 7.x, CentOS 7.x, Fedora 19+ (supports systemd) rabbitmq-server-3.7.9-1.el7.noarch.rpm(Signature)
RPM for RHEL Linux 6.x, CentOS 6.x, Fedora prior to 19 rabbitmq-server-3.7.9-1.el6.noarch.rpm(Signature)
RPM for openSUSE Linux rabbitmq-server-3.7.9-1.suse.noarch.rpm(Signature)
RPM for SLES 11.x rabbitmq-server-3.7.9-1.sles11.noarch.rpm(Signature)

Run RabbitMQ Server

Start the Server

The server is not started as a daemon by default when the RabbitMQ server package is installed. To start the daemon by default when the system boots, as an administrator run 

chkconfig rabbitmq-server on

As an administrator, start and stop the server as usual: 

/sbin/service rabbitmq-server start

/sbin/service rabbitmq-server stop

Configuring RabbitMQ

On most systems, a node should be able to start and run with all defaults. Please refer to the Configuration guide to learn more and Production Checklist for guidelines beyond development environments.

Note: The server is set up to run as system user rabbitmq. If you change the location of the node database or the logs, you must ensure the files are owned by this user (and also update the environment variables).

Port Access

RabbitMQ nodes bind to ports (open server TCP sockets) in order to accept client and CLI tool connections. Other processes and tools such as SELinux may prevent RabbitMQ from binding to a port. When that happens, the node will fail to start. CLI tools, client libraries and RabbitMQ nodes also open connections (client TCP sockets). Firewalls can prevent nodes and CLI tools from communicating with each other. Make sure the following ports are accessible:

  • 4369: epmd, a peer discovery service used by RabbitMQ nodes and CLI tools
  • 5672, 5671: used by AMQP 0-9-1 and 1.0 clients without and with TLS
  • 25672: used for inter-node and CLI tools communication (Erlang distribution server port) and is allocated from a dynamic range (limited to a single port by default, computed as AMQP port + 20000). Unless external connections on these ports are really necessary (e.g. the cluster uses federation or CLI tools are used on machines outside the subnet), these ports should not be publicly exposed. See networking guide for details.
  • 35672-35682: used by CLI tools (Erlang distribution client ports) for communication with nodes and is allocated from a dynamic range (computed as server distribution port + 10000 through server distribution port + 10010). See networking guide for details.
  • 15672: HTTP API clients, management UI and rabbitmqadmin (only if the management plugin is enabled)
  • 61613, 61614: STOMP clients without and with TLS (only if the STOMP plugin is enabled)
  • 1883, 8883: (MQTT clients without and with TLS, if the MQTT plugin is enabled
  • 15674: STOMP-over-WebSockets clients (only if the Web STOMP plugin is enabled)
  • 15675: MQTT-over-WebSockets clients (only if the Web MQTT plugin is enabled)
It is possible to configure RabbitMQ to use different ports and specific network interfaces.

Default user access

The broker creates a user guest with password guest. Unconfigured clients will in general use these credentials. By default, these credentials can only be used when connecting to the broker as localhost so you will need to take action before connecting from any other machine.

See the documentation on access control for information on how to create more users, delete the guest user, or allow remote access to the guest user.

Controlling System Limits on Linux

RabbitMQ installations running production workloads may need system limits and kernel parameters tuning in order to handle a decent number of concurrent connections and queues. The main setting that needs adjustment is the max number of open files, also known as ulimit -n. The default value on many operating systems is too low for a messaging broker (eg. 1024 on several Linux distributions). We recommend allowing for at least 65536 file descriptors for user rabbitmq in production environments. 4096 should be sufficient for most development workloads.

There are two limits in play: the maximum number of open files the OS kernel allows (fs.file-max) and the per-user limit (ulimit -n). The former must be higher than the latter.

With systemd (Recent Linux Distributions)

On distributions that use systemd, the OS limits are controlled via a configuration file at /etc/systemd/system/rabbitmq-server.service.d/limits.conf, for example: 

[Service]
LimitNOFILE=300000

Without systemd (Older Linux Distributions)

The most straightforward way to adjust the per-user limit for RabbitMQ on distributions that do not use systemd is to edit the rabbitmq-env.conf to invoke ulimit before the service is started. 

ulimit -S -n 4096

This soft limit cannot go higher than the hard limit (which defaults to 4096 in many distributions). The hard limit can be increased via /etc/security/limits.conf. This also requires enabling the pam_limits.so module and re-login or reboot.

Note that limits cannot be changed for running OS processes.

For more information about controlling fs.file-max with sysctl, please refer to the excellent Riak guide on open file limit tuning.

Verifying the Limit

RabbitMQ management UI displays the number of file descriptors available for it to use on the Overview tab. 

rabbitmqctl status
includes the same value.

The following command 

cat /proc/$RABBITMQ_BEAM_PROCESS_PID/limits
can be used to display effective limits of a running process. $RABBITMQ_BEAM_PROCESS_PID is the OS PID of the Erlang VM running RabbitMQ, as returned by rabbitmqctl status.

Configuration Management Tools

Configuration management tools (e.g. Chef, Puppet, BOSH) provide assistance with system limit tuning. Our developer tools guide lists relevant modules and projects.

Managing the Broker

To stop the server or check its status, etc., you can use package-specific scripts (e.g. the service tool) or invoke rabbitmqctl (as an administrator). It should be available on the path. All rabbitmqctl commands will report the node absence if no broker is running.

  • Invoke rabbitmqctl stop to stop the server.
  • Invoke rabbitmqctl status to check whether it is running.

More info on rabbitmqctl.

Logging

Output from the server is sent to a RABBITMQ_NODENAME.log file in the RABBITMQ_LOG_BASE directory. Additional log data is written to RABBITMQ_NODENAME-sasl.log.

The broker always appends to the log files, so a complete log history is retained.

You can use the logrotate program to do all necessary rotation and compression, and you can change it. By default, this script runs weekly on files located in default /var/log/rabbitmq directory. See /etc/logrotate.d/rabbitmq-server to configure logrotate.

Getting Help and Providing Feedback

If you have questions about the contents of this guide or any other topic related to RabbitMQ, don't hesitate to ask them on the RabbitMQ mailing list.

Help Us Improve the Docs <3

If you'd like to contribute an improvement to the site, its source is available on GitHub. Simply fork the repository and submit a pull request. Thank you!