RPM and YUM
Sean Conway explores three command-line software package managers for messing about with software and dealing with package dependencies.
Confused and bewildered? Sean Conway might not help as he’s MAD, but here he is explaining the package management used by Red Hat and its respins.
You don’t have to be mad to manage software but it helps. That’s MAD as in being aware of the three main functions involved in managing software: Modification ('M’ or updates) of software, adding ('A') software and deleting ('D') software. In this tutorial, we’ll cover the tools used for managing software on a Red Hat system, including Red Hat Package Manager ( RPM) and Yellowdog Updater Modifier ( Yum).
An easy way for a novice to understand the differences between the two package managers is to use an analogy: the difference between a manual and automatic car. A car with a manual transmission relies on the driver understanding the dependency between the vehicle direction of travel and the engine’s revolutions per minutes, so they translate that understanding into changing to the right gear. Being familiar with the sound of the car engine and knowing when a gear shift is needed is a sign of an experienced driver, while many novice drivers rely on the tachometer or speedometer to decide the gear selection for the desired speed. In contrast, there’s less driver dependency in a vehicle that has an automatic transmission. If the driver knows in what direction the car must move, it’s a simple case of choosing D for drive forward and R for reverse.
Now let’s make sense of that analogy: software package managers RPM and Yum are respectively the manual and automatic car transmissions delivering the MAD functions for an OS. RPM relies on the user knowing all the dependencies to successfully install software while Yum tries to take care of any dependencies for you to make managing software a smoother experience.
So which is better? It depends. Like any discussion on cars, what is best depends on the individual driver. Both software package managers have a role to play and what tasks you use them for will depend on how successful they are in how they do it. For the systems administrator just off the blocks, Yum is ideal because it removes the initial confusion and struggle of having to find software dependencies to successfully install software. To other sysadmins, developing the environment using specific packages is a challenge they probably enjoy as they gain a better understanding of what packages are being used for a given application.
RPM, the manual one
RPM is a legacy tool that moved Linux on from manually compiling source code to scripted installations. This package manager provides the MAD basics along with some other useful functions for managing software, and it uses a command line interface application that requires root level permissions. The format of RPM’s command syntax is: rpm -<options> <package-name> example rpm -Uvh tcpdump-4.7.4-2.fc21.x86_64
As you can see, it uses the standard command ( rpm ) followed by options ( -Uvh ) with the software package name
at the end. If you want to target more than one package, multiple package names can be included by using a space.
The command includes fifteen single letter options as well as other expression options, such as whatprovides .
Check the man pages for the full list, but out of the gate options for delivering basic MAD function are -Uvh and -e .
U will install a software package if it isn’t installed or update the package if it’s found, and vh sets verbose feedback and generates hash marks to indicate when RPM is doing something. The -e option removes, deletes or erases the package installation.
As well as the MAD basics, there are basic query options (which uses -q ). By adding some additional letters to -q you can tailor the output to be more specific.
rpm -q <package-name> A response will indicate if a package is installed. rpm -qa Lists all the packages that are installed.
rpm -qc <package-name> What configuration files are in this software package.
rpm -qi <package-name> What dependencies are in the software package name.
rpm -qf </path/file-name> What package did a particular file come in.
rpm -ql <package-name> What is installed as part of this package.
rpm -qp <package-name> Indicates what’s not installed in this package yet.
rpm -qpR <package-name> What dependencies are in this package
rpm -qa <package name> Query the install base to list the installed package. Dropping the attribute <package name> from the query will provide a list of all packages installed.
rpm -ql <package name> Lists the full path of the components installed from the package. This is a great command for finding where the configuration file for a package is installed.
RPM’s Achilles heel is that it doesn’t ensure that package dependencies are resolved during installation. If a dependency is missing the manager just exits and spits out a message identifying the software components that it can’t find. Although informative, it’s frustrating when all you want to do is, eg, play Doom and need to find a missing components called elibsecp256k1.
Yum, the automatic one
The Yum package manager reduces the amount of time spent in RPM- dependency purgatory. Under the hood, Yum relies on RPM to do some of the heavy lifting, but contains some additional smarts to assist it in resolving all the necessary dependencies for a successful install. Yum is also a command-line based utility, released under GNU General Public License, and is primarily written in Python.
Like RPM, Yum uses options followed by the package name and an account with root privileges or a sudo prefix will be required. The basic MAD functions are: yum update <package name> yum install <package name> yum remove <package name>
Yum uses its repositories (repos – these are the software libraries of packages available to it) to provide a response that the user must acknowledge before carrying out the request. Note: the yum command can be used without referencing a package name.
To list all the packages that are installed and available to the package manager simply use yum list . To update a software package that’s been installed use yum update . Adding a -y option after a yum command will run it without any acknowledgment.
The optioned command yum list installed provides a list of all packages installed. Using yum list updates will, as you may have guessed, update all installed packages if available.
To determine the package source of a particular piece of software use yum whatprovides </path/to/command> . This is helpful for software tools (eg /bin/dig) as they might be installed as part of a larger package.
Anyone who has done their own OS installation may recall being asked to select what groups of software to install. Well, the command yum grouplist will provide a list that should look similar to the software installed groups.
To kick off the installation of all the software packages contained in the group use yum groupinstall “Development
Tools” (Note: the double quotes are required). This is a powerful command as the user doesn’t have to try and determine all the packages that make up a group, just the group name.
A most convenient command option, and one that we frequently fall back on, is yum history . This gives a historical log of all recorded installs that can be referenced for rollbacks. For instance, say that an admin after ignoring six months of notifications [go on… – Ed] issues a yum -y update . After a system reboot, the GUI screen is black. In this scenario, the updated kernel hasn’t worked with the proprietary video drivers that have been installed ( RPM’d in). Restoring a command line, yum history provides a list of work that’s been done, and drilling down using, eg, yum history info 31
provides the details of the software updates and installations that resulted in the issue. To rollback the installation, all the sysadmin needs to do is use yum history rollback 31 . An excellent handy little cheat sheet for Yum commands can be found at http://bit.ly/YumCheatSheet.
Using Yum for security updates
Yum can also be used for security related software updates. The command supports querying Red Hat Advisories (RHSAs), MITRE’s Common Vulnerability and Exposure (CVE, https://cve.mitre.org), Red Hat custom CVE ( https://access.redhat.com/security/cve) and Bugzilla security-related information. To take advantage of this option In Red Hat 6 and CentOS 6, the yum-plugin-security package must be installed. The Yum security features were, initially, offered in Fedora 16 as a plugin but have been absorbed into Yum itself. There’s also supporting documentation for the security package: yum help or man yum-security provides many more details on tailoring security for Yum than just man yum .
The command yum updateinfo summary provides a short summary of security notices or bugfixes. Using yum updateinfo list provides more details on the packages involved while yum updateinfo list cve and yum updateinfo list bugzillas both selectively filter the returned list. If the listing provides a security tracking reference number (RHSA, CVE, Bugzilla or Fedora) yum updateinfo <tracking_number> (eg RHSA-2015:1834,CVE-2015-4500, FEDORA-2015-14578, 1251157) will pull in the related data if available.
DNF, on the test track
Since the release of Fedora 18, the distro project has been offering the software package manager, DNF (Dandified Yum) as well as Yum, which uses the package management libraries hawkey and libsolv for the back-end. DNF claims to be better at resolving dependencies, as it benefits from SUSE’s libsolv library as well as adding an application programming interface (API) that Yum didn’t have and a lowering of memory footprint. For Fedora 22, Yum was deprecated and DNF was made the default software package manager. If you want to try Fedora 22 64-bit out, it was included with the magazine recently [ Reviews,p19 LXF200].
Before you wonder why you’ve just learnt about package managers that are no longer current, be aware that replacing the command yum with dnf is all that’s needed to use the new – and rather dandy – package manager. If you try using the yum command in a terminal in Fedora 22, you’ll be reminded that Yum is deprecated and that you should really use the dnf command, instead. For a good reference source offering a detailed comparison of both DNF and Yum see http://bit.ly/DNFvsYum.