在基于RPM的Linux发行版（如Red Hat Enterprise Linux、CentOS、Fedora、openSUSE）中安装软件主要有以下方法

首先，我应该回想一下这些系统常用的包管理工具。记得RPM是这些系统的包管理基础，主要工具包括Yum和DNF，还有zypper在openSUSE中使用。

接下来，我需要整理安装软件的几种方法。通常，用户可以通过官方仓库直接安装，这是最方便的方式。比如使用yum install或者dnf install命令。另外，有时候软件可能不在官方仓库里，这时候可能需要添加第三方仓库，比如EPEL或者RPM Fusion，这些仓库提供了额外的软件包。用户可能需要先安装epel-release或者启用RPM Fusion仓库，然后再用yum或dnf安装。

第三种情况是用户直接下载了RPM包，这时候可以用rpm -i命令来安装，但需要注意依赖问题。如果依赖较多，手动处理会很麻烦，所以可能的话还是建议通过仓库安装。

还有一种方法是使用第三方提供的自动安装脚本，比如像GitLab提供的脚本，不过要提醒用户注意安全，确保来源可信。

然后，我需要结合用户提供的引用内容。引用[2]提到可以通过Yum仓库安装RabbitMQ，引用[3]提到了使用Yum仓库安装GitLab的例子。这些可以作为具体例子来说明如何添加仓库并安装软件。

此外，用户可能想知道不同发行版之间的差异。例如，openSUSE使用zypper而不是yum/dnf，所以需要单独说明。同时，收费和免费版本在稳定性上的区别，如引用[4]提到的收费版更稳定，可能影响软件安装时的选择。

还需要注意一些常见问题，比如依赖解决、GPG密钥的导入，以及更新缓存的重要性。比如在添加新仓库后，需要运行yum makecache或者dnf makecache来更新元数据。

最后，生成相关问题时要覆盖用户可能进一步关心的方面，比如如何解决依赖、第三方仓库推荐、手动安装与仓库安装的优劣比较，以及特定发行版如openSUSE的注意事项。
在基于RPM的Linux发行版（如Red Hat Enterprise Linux、CentOS、Fedora、openSUSE）中安装软件主要有以下方法：

一、通过包管理器安装

1. Yum/DNF（RHEL/CentOS/Fedora）

   • 基础命令：sudo yum install package_name（CentOS 7及以下）
     或sudo dnf install package_name（Fedora/CentOS 8+）
     例如安装Erlang RPM包：

     sudo yum install erlang  # 通过预设仓库安装
     

   • 添加第三方仓库（如EPEL/RPM Fusion）：

     sudo yum install epel-release  # 安装EPEL仓库
     sudo yum install package_name
     

2. Zypper（openSUSE）

   sudo zypper refresh  # 更新仓库元数据
   sudo zypper install package_name
   

二、直接安装RPM包

1. 下载RPM文件后安装：

   sudo rpm -ivh package.rpm  # 安装单个包
   

2. 自动解决依赖（需配置仓库）：

   sudo yum localinstall package.rpm  # 自动处理依赖
   

三、通过第三方仓库安装

• 示例：GitLab CE安装

  curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
  sudo yum install gitlab-ce  # 自动配置仓库并安装
  

四、源码编译安装（较少用）

需安装编译工具链：

sudo yum groupinstall "Development Tools"
./configure && make && sudo make install

This guide covers RabbitMQ installation on RPM-based Linux (RedHat Enterprise Linux, CentOS, Fedora, openSUSE).

RabbitMQ is included in standard Fedora and RHEL repositories. However, the versions included are usually outdated and out of support.

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

Installing the package using Yum repositories on Package Cloud or Bintray (this option is highly recommended)
Downloading the package and installing it with rpm. This option will require manual installation of all package dependencies.

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

Package installation from Yum repositories on Package Cloud or Bintray
How to install a latest supported Erlang/OTP version
Package dependencies
Supported distributions
Privilege requirements
Package downloads
How to manage the service
How to inspect node and service logs

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 8.x, 7.x and 6.x (there are three separate RPM packages: one for 8.x series, one for 7.x and one for 6.x)
RedHat Enterprise Linux 8.x, 7.x and 6.x (same packages as for CentOS)
Fedora 28 through 30 (use the CentOS 8.x or 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.
openSUSE produces Erlang packages for each distribution (openSUSE and SLES)

Zero-dependency Erlang from RabbitMQ

Zero dependency Erlang RPM package for running RabbitMQ can be installed via Yum repositories on Package Cloud and Bintray 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 packages from openSUSE

openSUSE package repositories provide Erlang so it can be installed using Zypper:

sudo zypper in erlang

Erlang versions available in the standard repositories will in practice be behind the most recent version. To use the last version with the newest features, add the openSUSE Factory repositories for Erlang:

add the openSUSE erlang factory, obs:// extracts the http url for the matching distro.

sudo zypper ar -f obs://devel:languages:erlang:Factory openSUSE-Erlang-Factory

import the signing key and refresh the repository

sudo zypper --gpg-auto-import-keys refresh

install a recent Erlang version

sudo zypper in erlang

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. The dependencies are:

erlang: a supported version of Erlang can installed from a number of repositories
socat
logrotate

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 and 8 vs. CentOS 6 vs. OpenSUSE).

The following example sets up a repository that will installRabbitMQ 3.8 and targets CentOS 8:

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

On CentOS 7 the baseurl line would be slightly different:

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

Same for CentOS 6:

[bintray-rabbitmq-server]
name=bintray-rabbitmq-rpm
baseurl=https://dl.bintray.com/rabbitmq/rpm/rabbitmq-server/v3.8.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.8.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.8.x/sles/11
gpgcheck=0
repo_gpgcheck=0
enabled=1

The following example sets up a repository that will install RabbitMQ 3.7 on CentOS 7. Note that RabbitMQ 3.7 goes out of support in 2020.

[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

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 8 version of the package.

For CentOS 7, replace “el8” with “el7”.

yum install rabbitmq-server-3.8.3-1.el8.noarch.rpm

RabbitMQ public signing key can also be downloaded from rabbitmq.com:

rpm --import https://www.rabbitmq.com/rabbitmq-release-signing-key.asc

This example assumes the CentOS 8 version of the package.

For CentOS 7, replace “el8” with “el7”.

yum install rabbitmq-server-3.8.3-1.el8.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.
Description Download Signature
RPM for RHEL Linux 8.x, CentOS 8.x, Fedora 28+ (supports systemd) rabbitmq-server-3.8.3-1.el8.noarch.rpm Signature
RPM for RHEL Linux 7.x, CentOS 7.x, Fedora 24+ (supports systemd) rabbitmq-server-3.8.3-1.el7.noarch.rpm Signature
RPM for RHEL Linux 6.x, CentOS 6.x, Fedora prior to 19 rabbitmq-server-3.8.3-1.el6.noarch.rpm Signature
RPM for openSUSE Linux rabbitmq-server-3.8.3-1.suse.noarch.rpm Signature
RPM for SLES 11.x rabbitmq-server-3.8.3-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 node is set up to run as system user rabbitmq. If location of the node database or the logs is changed, the files and directories must be owned by this user.

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)
15692: Prometheus metrics (only if the Prometheus 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 and delete 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 (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 many 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, to set the max open file handle limit (nofile) to 64000:

[Service]
LimitNOFILE=64000

See systemd documentation to learn about the supported limits and other directives.
With Docker

To configure kernel limits for Docker contains, use the “default-ulimits” key in Docker daemon configuration file. The file has to be installed on Docker hosts at /etc/docker/daemon.json:

{
“default-ulimits”: {
“nofile”: {
“Name”: “nofile”,
“Hard”: 64000,
“Soft”: 64000
}
}
}

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 /etc/default/rabbitmq-server (provided by the RabbitMQ Debian package) or 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 Service

To start and stop the server, use the service tool. The service name is rabbitmq-server:

stop the local node

sudo service rabbitmq-server stop

start it back

sudo service rabbitmq-server start

service rabbitmq-server status will report service status as observed by systemd (or similar service manager):

check on service status as observed by service manager

sudo service rabbitmq-server status

It will produce output similar to this:

Redirecting to /bin/systemctl status rabbitmq-server.service
● rabbitmq-server.service - RabbitMQ broker
Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/rabbitmq-server.service.d
└─limits.conf
Active: active (running) since Wed 2018-12-26 10:21:32 UTC; 25s ago
Main PID: 957 (beam.smp)
Status: “Initialized”
CGroup: /system.slice/rabbitmq-server.service
├─ 957 /usr/lib/erlang/erts-10.2/bin/beam.smp -W w -A 64 -MBas ageffcbf -MHas ageffcbf -MBlmbcs 512 -MHlmbcs 512 -MMmcs 30 -P 1048576 -t 5000000 -stbt db -zdbbl 128000 -K true – -root /usr/lib/erlang -progname erl – -home /var/lib/rabbitmq – …
├─1411 /usr/lib/erlang/erts-10.2/bin/epmd -daemon
├─1605 erl_child_setup 400000
├─2860 inet_gethost 4
└─2861 inet_gethost 4

Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: ## ##
Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: ## ## RabbitMQ 3.7.16. Copyright © 2007-2020 VMware, Inc. or its affiliates.
Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: ########## Licensed under the MPL. See https://www.rabbitmq.com/
Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: ###### ##
Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: ########## Logs: /var/log/rabbitmq/rabbit@localhost.log
Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: /var/log/rabbitmq/rabbit@localhost_upgrade.log
Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: Starting broker…
Dec 26 10:21:32 localhost.localdomain rabbitmq-server[957]: systemd unit for activation check: “rabbitmq-server.service”
Dec 26 10:21:32 localhost.localdomain systemd[1]: Started RabbitMQ broker.
Dec 26 10:21:32 localhost.localdomain rabbitmq-server[957]: completed with 6 plugins.

rabbitmqctl, rabbitmq-diagnostics, and other CLI tools will be available in PATH and can be invoked by a sudo-enabled user:

checks if the local node is running and CLI tools can successfully authenticate with it

sudo rabbitmq-diagnostics ping

prints enabled components (applications), TCP listeners, memory usage breakdown, alarms

and so on

sudo rabbitmq-diagnostics status

prints effective node configuration

sudo rabbitmq-diagnostics environment

performs a more extensive health check of the local node

sudo rabbitmq-diagnostics node_health_check

All rabbitmqctl commands will report the node absence if no broker is running.

See the CLI tools guide to learn more.
Log Files and Management

Server logs can be found under the configurable directory, which usually defaults to /var/log/rabbitmq when RabbitMQ is installed via a Linux package manager.

RABBITMQ_LOG_BASE can be used to override log directory location.

Assuming a systemd-based distribution, system service logs can be inspected using

journalctl --system

which requires superuser privileges. Its output can be filtered to narrow it down to RabbitMQ-specific entries:

sudo journalctl --system | grep rabbitmq

The output will look similar to this:

Dec 26 11:03:04 localhost rabbitmq-server[968]: ## ##
Dec 26 11:03:04 localhost rabbitmq-server[968]: ## ## RabbitMQ 3.7.16. Copyright © 2007-2020 VMware, Inc. or its affiliates.
Dec 26 11:03:04 localhost rabbitmq-server[968]: ########## Licensed under the MPL. See https://www.rabbitmq.com/
Dec 26 11:03:04 localhost rabbitmq-server[968]: ###### ##
Dec 26 11:03:04 localhost rabbitmq-server[968]: ########## Logs: /var/log/rabbitmq/rabbit@localhost.log
Dec 26 11:03:04 localhost rabbitmq-server[968]: /var/log/rabbitmq/rabbit@localhost_upgrade.log
Dec 26 11:03:04 localhost rabbitmq-server[968]: Starting broker…
Dec 26 11:03:05 localhost rabbitmq-server[968]: systemd unit for activation check: “rabbitmq-server.service”
Dec 26 11:03:06 localhost rabbitmq-server[968]: completed with 6 plugins.

Log Rotation

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

logrotate is the recommended way of log file rotation and compression. By default, the package will set up logrotate to run weekly on files located in default /var/log/rabbitmq directory. Rotation configuration can be found in /etc/logrotate.d/rabbitmq-server.
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 ❤️

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!
In This Section

Install: Windows
Install: Debian and Ubuntu
Install: RPM-based Linux
Install: Homebrew
Install: Windows (manual)
Install: Generic binary build
Install: Solaris
Install: EC2
Upgrade
Blue-green deployment-based upgrade
Supported Platforms
Changelog
Erlang Versions
Signed Packages
Java Client Downloads
.NET Client Downloads
Erlang Client Downloads
Community Plugins
Snapshots

RabbitMQ

Features
Get Started
Support
Community
Docs
Blog

Installing software on RPM-based Linux distributions (such as Red Hat Enterprise Linux (RHEL), CentOS, Fedora, and openSUSE) typically involves using the RPM Package Manager (rpm) or higher-level tools like DNF (Dandified YUM) or YUM (Yellowdog Updater Modified). Below is a step-by-step guide to installing software on RPM-based systems.

---

1. Using rpm Command

The rpm command is the low-level tool for managing .rpm packages. It is useful for installing, querying, and removing individual packages.

Install a Package

To install an RPM package:

sudo rpm -ivh package-name.rpm

• -i: Install the package.
• -v: Verbose output.
• -h: Show progress with hash marks.

Upgrade a Package

To upgrade an existing package:

sudo rpm -Uvh package-name.rpm

• -U: Upgrade the package (or install if not already installed).

Remove a Package

To remove an installed package:

sudo rpm -e package-name

• -e: Erase (remove) the package.

Query Installed Packages

To check if a package is installed:

rpm -q package-name

---

2. Using dnf Command (Fedora, RHEL 8+, CentOS 8+)

dnf is the modern package manager for RPM-based systems, replacing yum. It resolves dependencies automatically.

Install a Package

To install a package:

sudo dnf install package-name

Remove a Package

To remove a package:

sudo dnf remove package-name

Update Packages

To update all installed packages:

sudo dnf update

Search for a Package

To search for a package in the repositories:

sudo dnf search package-name

Enable Repositories

Some packages require additional repositories. For example, to enable the EPEL (Extra Packages for Enterprise Linux) repository:

sudo dnf install epel-release

---

3. Using yum Command (RHEL 7, CentOS 7)

yum is the older package manager used in RHEL 7 and CentOS 7. It is similar to dnf but less efficient.

Install a Package

To install a package:

sudo yum install package-name

Remove a Package

To remove a package:

sudo yum remove package-name

Update Packages

To update all installed packages:

sudo yum update

Search for a Package

To search for a package in the repositories:

sudo yum search package-name

Enable Repositories

To enable additional repositories (e.g., EPEL):

sudo yum install epel-release

---

4. Using zypper Command (openSUSE)

zypper is the package manager for openSUSE and SUSE Linux Enterprise.

Install a Package

To install a package:

sudo zypper install package-name

Remove a Package

To remove a package:

sudo zypper remove package-name

Update Packages

To update all installed packages:

sudo zypper update

Search for a Package

To search for a package in the repositories:

sudo zypper search package-name

Add Repositories

To add a new repository:

sudo zypper addrepo <repository-url> <repository-name>

---

5. Installing from Source

If a package is not available in the repositories, you can install it from source.

Steps to Install from Source

1. Download the source code:

   wget https://example.com/package.tar.gz
   

2. Extract the tarball:

   tar -xvzf package.tar.gz
   

3. Navigate to the extracted directory:

   cd package-directory
   

4. Configure, build, and install:

   ./configure
   make
   sudo make install
   

---

6. Common Repositories

• EPEL (Extra Packages for Enterprise Linux): Provides additional packages for RHEL and CentOS.

  sudo dnf install epel-release  # For RHEL 8+/CentOS 8+
  sudo yum install epel-release  # For RHEL 7/CentOS 7
  

• RPM Fusion: Offers free and non-free packages for Fedora and RHEL.

  sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
  

---

7. Troubleshooting

• Dependency Issues: Use dnf or yum to resolve dependencies automatically.
• Broken Packages: Remove and reinstall the package:

  sudo rpm -e --nodeps package-name
  sudo dnf install package-name
  

• Repository Errors: Clear the cache and retry:

  sudo dnf clean all
  sudo dnf update
  

---

Summary

• Use rpm for low-level package management.
• Use dnf (Fedora, RHEL 8+, CentOS 8+) or yum (RHEL 7, CentOS 7) for high-level package management.
• Use zypper for openSUSE.
• Enable additional repositories (e.g., EPEL, RPM Fusion) for more packages.
• Install from source if the package is not available in repositories.

By following these steps, you can easily install and manage software on RPM-based Linux distributions.