http://www.rabbitmq.com/install-rpm.html
Overview
rabbitmq-server is included in Fedora. However, the versions included are often quite old. You will probably get better results installing the .rpm from our website. Check the Fedora package details for which version of the server is available for which versions of the distribution.
We also upload our RPM packages to PackageCloud and Bintray.
Supported Distributions
Below is a list of supported RPM-based distributions as of RabbitMQ 3.6.3:
- CentOS 6.x and 7.x (note: there are two separate RPM packages for 6.x and 7.x)
- RedHat Enterprise Linux 6.x and 7.x (same as for CentOS, there are two separate packages)
- Fedora 23 through 25 (use the RHEL 7.x package)
The packages may work on other RPM-based distributions if dependencies (see below) are satisfied (e.g. using the Wheezy backports repository) but their testing and support is done on a best effort basis.
Install Erlang
Before installing RabbitMQ, you must install a supported version of Erlang/OTP. We strongly recommend using a packaged version. There are three suggested sources for Erlang packages:
- We produce a package stripped down to only provide those components needed to run RabbitMQ. It may not be as up to date as Erlang Solutions' packages, but it might be easiest to use if installing Erlang's dependencies is proving difficult.
- Erlang Solutions produces packages that are usually up to date. They produce two sets of packages - ones which are split up and are more convenient to use if you can add a yum repository, and a monolithic package which might be easier if you have to download manually.
- 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, and are split into many small packages, but are not always up to date.
Install zero-dependency Erlang from RabbitMQ
- Download and install the zero dependency Erlang RPM package for running RabbitMQ. As the name suggests, the package strips off some Erlang modules and dependencies that are not essential for running RabbitMQ.
Install Erlang from the EPEL repository or
- Follow the steps in the EPEL FAQ to enable EPEL on your machine.
- Issue the following command as 'root':
yum install erlang
Install Erlang from the Erlang Solutions repository or
- Follow the instructions under "Installation using repository" at Erlang Solutions.
Install monolithic Erlang from Erlang Solutions or
- Download and install the appropriate esl-erlang RPM from Erlang Solutions.
- Download and install the esl-erlang-compat RPM (direct download) produced by Jason McIntosh.
This is needed since Erlang Solutions' monolithic packages provide "esl-erlang"; this package just requires "esl-erlang" and provides "erlang".
Install RabbitMQ Server
With rpm and Downloaded RPM
After downloading the server package, issue the following command as 'root':
rpm --import https://www.rabbitmq.com/rabbitmq-release-signing-key.asc
yum install rabbitmq-server-3.6.9-1.noarch.rpm
Our public signing key is also available from Bintray.
Using PackageCloud RPM Repository
PackageCloud installs packages via HTTPS and signs them using their GPG key. There are multiple ways to install:
- Provided installation scripts
- Using PackageCloud Chef cookbook
- Using PackageCloud Puppet module
- Manually
Run RabbitMQ Server
- Customise RabbitMQ Environment Variables
-
The server should start using defaults. You can customise the RabbitMQ environment. Also see how to configure components.
- 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 runchkconfig rabbitmq-server on.
As an administrator, start and stop the server as usual using /sbin/service rabbitmq-server stop/start/etc.
Note: The server is set up to run as system user rabbitmq. If you change the location of the Mnesia database or the logs, you must ensure the files are owned by this user (and also update the environment variables).
Port Access
SELinux, and similar mechanisms may prevent RabbitMQ from binding to a port. When that happens, RabbitMQ will fail to start. Firewalls can prevent nodes and CLI tools from communicating with each other. Make sure the following ports can be opened:
- 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 by Erlang distribution for inter-node and CLI tools communication and is allocated from a dynamic range (limited to a single port by default, computed as AMQP port + 20000). See networking guide for details.
- 15672: HTTP API clients 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 guestuser, 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.
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
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.somodule 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.