Introduction
In this lab, you will learn the fundamentals of managing software packages on RPM-based Linux distributions using the powerful rpm command-line utility. You will gain hands-on experience with essential package management tasks, including querying for detailed package information, verifying the integrity of installed packages, and inspecting the contents of RPM files.
Throughout the steps, you will use specific rpm commands to find out which package a file belongs to, list package dependencies and configuration files, and check for reverse dependencies. You will also learn how to safely simulate a package removal to understand its impact and how to examine the contents of an RPM package file before installation using tools like rpm2cpio and cpio.
Query Basic Package Information with rpm -qi and rpm -qf
In this step, you will learn how to query for information about installed packages using the Red Hat Package Manager (rpm). rpm is a powerful command-line utility for managing software on RPM-based Linux distributions like CentOS, Fedora, and RHEL. We will focus on two fundamental query options: -qi to get detailed package information and -qf to find out which package a specific file belongs to.
First, let's inspect the details of a package that is already installed on your system. The bash shell is a core component of the system, making it a perfect example. The -q flag stands for 'query', and the i flag stands for 'information'.
Execute the following command in your terminal to query for information about the bash package:
rpm -qi bash
You will see a detailed output listing various attributes of the package. The output will look similar to this (version numbers and dates may vary):
Name : bash
Version : 4.4.20
Release : 5.el8
Architecture: x86_64
Install Date: <some_date>
Group : System Environment/Shells
Size : 4989189
License : GPLv3+
Signature : RSA/SHA256, <some_date_and_time>, Key ID <some_key_id>
Source RPM : bash-4.4.20-5.el8.src.rpm
Build Date : <some_date>
Build Host : <some_build_host>
Relocations : (not relocatable)
Vendor : CentOS
URL : http://www.gnu.org/software/bash
Summary : The GNU Bourne-Again Shell
Description :
The GNU Bourne-Again Shell (Bash) is a shell or command language
interpreter that is compatible with the Bourne shell (sh). Bash
incorporates useful features from the Korn shell (ksh) and the C
shell (csh). Most sh scripts can be run by bash without
modification.
This output provides a wealth of information, including the package's version, a summary of its purpose, and a more detailed description.
Now, imagine you have a file on your system, like the bash executable located at /usr/bin/bash, and you want to know which package installed it. This is a common task when auditing a system or troubleshooting. For this, you can use the -qf flags, where f stands for 'file'.
Run the following command to find out which package owns the /usr/bin/bash file:
rpm -qf /usr/bin/bash
The command will return the full name of the package that provides this file:
bash-5.1.8-9.el9.x86_64
As you can see, the system correctly identifies that /usr/bin/bash comes from the bash package, matching the information we found earlier. You can even combine these flags to directly get information about the package that owns a file by running rpm -qif /usr/bin/bash.
List Package Dependencies and Configuration Files with rpm -qR and rpm -qc
In this step, you'll continue exploring rpm by learning how to list a package's dependencies and its associated configuration files. Understanding dependencies is crucial because most software relies on other packages to function correctly. Knowing where configuration files are located is essential for system administration and customization.
Let's start by finding out what other packages or capabilities the bash package requires. We use the -qR (or --requires) flag for this. The R stands for 'requires'.
Execute the following command to see the dependencies for bash:
rpm -qR bash
The output will be a list of packages and system capabilities that bash depends on. This list can be quite long.
/bin/sh
config(bash) = 4.4.20-5.el8
filesystem >= 3
glibc
info
libc.so.6(GLIBC_2.17)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.28)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
...
rtld(GNU_HASH)
This output shows that bash requires the glibc package (which provides the C library libc.so.6), the filesystem package, and other system-level components.
Next, let's find the configuration files that were installed as part of the bash package. This is useful when you need to modify the default behavior of the shell for new users. The -qc flag is used for this, where c stands for 'configfiles'.
Run this command to list the configuration files for bash:
rpm -qc bash
The output will show the full paths to the configuration files:
/etc/skel/.bash_logout
/etc/skel/.bash_profile
/etc/skel/.bashrc
These files in /etc/skel are template files that are copied to a new user's home directory when the user account is created.
You can also combine flags to find the configuration files related to a specific command. For example, to see the configuration files used by the passwd command, you can use -qcf. This tells rpm to first find the package for the file (-f /usr/bin/passwd) and then list its configuration files (-c).
rpm -qcf /usr/bin/passwd
This command reveals the configuration files associated with the passwd utility:
/etc/pam.d/passwd
This is a powerful way to quickly identify which files you might need to edit to change a command's behavior.
Verify Package Integrity and File Changes with rpm -V
In this step, you will learn how to verify the integrity of an installed package using rpm -V (or rpm --verify). This command is a crucial security and troubleshooting tool. It checks the files installed by a package against the information stored in the RPM database, such as file sizes, permissions, and checksums. This allows you to detect any unauthorized or accidental changes to system files.
First, let's ensure a couple of utility packages, lsscsi and at, are installed on the system. We will use them for our verification tests.
sudo dnf install -y lsscsi at
Now, let's verify the lsscsi package. Since we have just installed it and haven't made any changes, it should pass the verification test. A successful verification produces no output.
rpm -V lsscsi
As expected, the command prompt returns without any message, indicating that all files in the lsscsi package are in their original state.
Next, let's intentionally modify a configuration file and see how rpm -V reports the change. We will add a line to the /etc/at.deny file, which belongs to the at package. This file controls which users are not allowed to use the at command.
echo "labex" | sudo tee -a /etc/at.deny
Now that we've modified a file, let's verify the at package again.
sudo rpm -V at
This time, the command produces output, indicating that a change was detected:
S.5....T. c /etc/at.deny
Let's break down this output:
S: The file Size has changed.5: The MD5 checksum has changed.T: The modification Time has changed.c: This denotes a configuration file./etc/at.deny: The path to the modified file.
Each character position in the 8-character string S.5....T. represents a different test. A . means the test passed. This output clearly shows that the /etc/at.deny configuration file has been altered since its installation.
You can also verify the package that owns a specific file directly using the -qVf flags.
sudo rpm -qVf /etc/at.deny
This command will produce the same output, as it first finds the package owning /etc/at.deny (at) and then verifies it.
Check Reverse Dependencies and Simulate Package Removal with rpm -e --test
In this step, you will learn how to check for reverse dependencies and safely simulate the removal of a package. While the rpm -qR command shows what a package needs (its dependencies), rpm -q --whatrequires shows what other packages need it (its reverse dependencies). This is extremely important to know before you remove a package, as you could break other parts of the system.
To safely check the consequences of removing a package, you can use the rpm -e --test command. The -e flag stands for 'erase', and the --test flag tells RPM to perform a dry run without actually deleting any files.
Let's start by examining a core system package that many other packages depend on. The glibc package provides the GNU C Library, which is fundamental to almost all programs on a Linux system. Let's check what packages require glibc.
rpm -q --whatrequires glibc
The output will show several packages that depend on glibc:
glibc-common-2.34-168.el9_6.19.x86_64
glibc-langpack-en-2.34-168.el9_6.19.x86_64
libstdc++-11.5.0-5.el9_5.x86_64
glibc-headers-2.34-168.el9_6.19.x86_64
pam-1.5.1-23.el9.x86_64
glibc-devel-2.34-168.el9_6.19.x86_64
nscd-2.34-168.el9_6.19.x86_64
As you can see, many critical system packages depend on glibc. Now let's see what happens when we try to remove glibc. We will use the --test flag to ensure we don't actually remove it, which would break the entire system.
sudo rpm -e --test glibc
Because so many packages need glibc, RPM will report dependency errors and prevent the removal. The output will show a long list of failed dependencies:
error: Failed dependencies:
glibc = 2.34-168.el9_6.19 is needed by (installed) glibc-common-2.34-168.el9_6.19.x86_64
glibc = 2.34-168.el9_6.19 is needed by (installed) glibc-langpack-en-2.34-168.el9_6.19.x86_64
glibc >= 2.34 is needed by (installed) libstdc++-11.5.0-5.el9_5.x86_64
... (additional dependency errors)
Now let's look at a package with fewer dependencies. The lsscsi package we installed earlier is a utility package with fewer reverse dependencies. Let's check what requires it:
rpm -q --whatrequires lsscsi
You should see output indicating no packages require lsscsi:
no package requires lsscsi
Since no packages depend on lsscsi, we can safely simulate its removal:
sudo rpm -e --test lsscsi
This command should complete without errors, indicating that removing lsscsi would not break any other packages on the system.
This demonstrates how you can predict the impact of removing a package and avoid breaking your system by checking reverse dependencies first.
Inspect RPM Package Contents with rpm2cpio and cpio
In this step, you will learn a powerful technique to inspect the contents of an RPM package file without installing it. This is useful for verifying the files a package contains before installation or for extracting a single file from a package to restore a corrupted or deleted file. This process involves two commands: rpm2cpio, which converts an RPM file to a cpio archive, and cpio, which can then list or extract files from that archive.
First, you need an actual .rpm file to inspect. Let's download the package file for bash into your current directory (~/project) using the dnf package manager. The download subcommand fetches the package file without installing it.
sudo dnf download bash
You will see output indicating the file has been downloaded successfully. The filename will include the version and architecture.
Last metadata expiration check: ...
bash-<version>.<arch>.rpm
Now, use the ls command to confirm the .rpm file is in your ~/project directory:
ls bash-*.rpm
With the RPM file ready, you can now use the rpm2cpio and cpio commands together to list its contents. The rpm2cpio command reads the RPM file and outputs a cpio archive to standard output. We then pipe (|) this output to the cpio command, which reads the archive from its standard input. The -t flag for cpio tells it to list the table of contents.
rpm2cpio bash-*.rpm | cpio -t
This will produce a long list of all the files and directories contained within the bash package. The output will look something like this:
.
./etc
./etc/skel
./etc/skel/.bash_logout
./etc/skel/.bash_profile
./etc/skel/.bashrc
./usr
./usr/bin
./usr/bin/bash
./usr/bin/sh
./usr/share
./usr/share/doc
...
This technique gives you a complete view of a package's payload, allowing you to see exactly what will be placed on your system if you were to install it.
Summary
In this lab, you learned how to manage and query software packages using the RPM utility in a Linux environment. You started by retrieving detailed information about installed packages with rpm -qi and identifying which package a specific file belongs to using rpm -qf. You also practiced listing a package's dependencies with rpm -qR and locating its configuration files with rpm -qc, providing a comprehensive view of how a package integrates into the system.
Building on these query skills, you learned to verify the integrity of an installed package's files using rpm -V to check for modifications. You also explored how to safely check for reverse dependencies and simulate a package removal with rpm -e --test to understand the potential impact without making changes. Finally, you gained the ability to inspect the contents of an RPM package file before installation by using rpm2cpio and cpio to extract and list its contents.
