1. Home
  2. Training Library
  3. Cloud Computing Fundamentals
  4. Courses
  5. LPIC-1 101 Linux certification - Boot and Package Management (3 of 5)

RPM/YUM package management

The course is part of this learning path


Linux Package Management
Start course


"Linux Installation and Package Management" is the third course in this Linux certification series. You'll learn how to control the Linux boot process, how to understand and manage disk partitions and filesystems, and how Linux uses kernel libraries to manage hardware peripherals. We'll also take a closer look at the two most widely used Linux software package management systems: dpkg and rpm.

The previous course in the series covered System Architecture. Next up will be GNU and Unix Commands.

If you have thoughts or suggestions for this course, please contact Cloud Academy at


We're going to continue discussing the topic of package managers, a topic the LPI considers more important than most.

Interestingly, the job description for the first full-time Linux sysadmin job I got demanded familiarity with Linux package management more than anything else. Many months later, I asked my boss why he focused on that the way he did, especially considering how many other skills I had to draw on for the day-to-day work I'd been doing. He replied he'd done it that way for two reasons. Because package management is, in fact, a major foundation for so much else in Linux administration, and because being comfortable with apt and yum was a particularly good indication of good general experience. I now agree. As with the dpkg system that we discussed in the previous video, RPM software packages that already exist locally can be installed and removed directly using, in this case, the RPM program.

Working with RPM and Yum package management

The file naming conventions for RPM work much the same way as for dpkg as we can see from this package I downloaded to my Fedora machine. In case you're wondering, it's ApacheDS, an LDAP and Cerberus server. Here, ApacheDS is the package name. The number is the package version, X86_64 is the architecture it was built for. This time, it's 64-bit, and the .rpm extension tells our system that it's an RMP package.

As the root user, we would install the package using rpm -i. We can also install - or upgrade it - using rpm -U ...which, if you ask me, can be a bit dangerous, as, under the circumstances, you'd normally associate u with uninstall. rpm -q will query the existence of a package. We'll run that against our ssh server to make sure it's there. Of course, since I'm currently logged into Fedora using ssh, I'd definitely assume it is. rpm -i --test will test a package for dependencies. In this case, it's a good thing we checked, because apacheds is a 64-bit package and the machine Fedora is running on is - if you can believe it - only 32 bit. rpm -e will remove a package. Running rpm -e with the --nodeps argument will only remove files that aren't dependencies elsewhere.

You can (and should) get the checksum from an rpm package using rpm -vK (where v adds more verbose messages). You should then compare the output to the checksum provided by your package source. rpm -V will verify a package. In our case, we're correctly told it's not yet installed.

Let's review. rpm packages place the package name first, the version next, followed by the architecture and the .rpm extension. rpm -i or -U will install a package. -U will also upgrade the package. rpm -q queries the existence of a package. rpm -i --test returns a package's dependencies. rpm -e will remove a package, and adding --nodeps will respect other package's dependencies. rpm -K returns a checksum. And rpm -V will verify a package.

Like apt-get on the Debian system, yum provides a powerful front end for rpm. The folder /yum.repos.d/ will contain repo files for each repo that's currently in use on your system. Here, rather than throwing them all into a single file the way apt does it, yum provides a separate file for each software category. Repo information can also be stored in the /etc/yum.conf file.

Using yum to work with packages is straightforward. You can install a package using yum install xboard. xboard, by the way, is a chess game. If you're already bored with that, you can remove it using yum remove. To update a package, use yum update. And to search for an installed program, use yum search. yum list will list all available programs. Although, since there are bound to be lots of them, you might prefer to use grep to narrow down your search. yum list installed will list installed programs. You can also directly download packages from online repositories without installing them using yumdownloader, where --resolve will take care of dependencies.

Since rpm files are usually compressed using the cpio file archiver, if you ever want to access all or some of the files from an rpm archive, you'll need to use rpm2cpio. In this example, we'll pipe the contents of the apacheds package to cpio itself, and where i tells cpio to restore the archive, and d tells it to create leading directories where needed.

By way of review, the folder /etc/yum.repos.d/ or the /etc/yum.conf file will contain pointers to repo sources. Yum is really simple: install will install a package, yum update will update, yum remove will remove, and yum search will search. yum list and yum list installed will display packages according to your needs. You download packages without installing them using yumdownloader

Working with Yum on AWS Linux

AWS Instances using the Amazon Linux distribution use rpm and yum for file management. By default, the /etc/yum.repos.d directory contains links to specially managed Amazon repos like amzn-main. Of course, if you choose an Ubuntu-based instance, you will find everything through dpkg and apt. The software installed on AWS instances can also be provisioned by script using deployment services like Elastic Beanstalk.

About the Author

Learning paths2

David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.

Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.

Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.

His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.

Covered Topics