Keyboard Shortcuts

• a - Start presentation.
• c - Show table of contents.
• Esc - Exit slide mode.
• ? - Show help.

Welcome everyone. I’m Dennis Kibbe from Mesa Community College. In this module we’ll cover how to register Red Hat systems for support, work with RPMs and DNF, enable or disable repositories, and ensure systems stay up to date. Throughout the lecture there will be guided exercises and a graded lab at the end. This slide presentation was created by B6Plus. The audio accompanying this presentation is AI-generated.

Let's review today's outline: we'll start with system registration, then move to RPMs, dive into DNF, enable repositories — all culminating in a graded lab.

By the end of this module, you'll be able to register RHEL hosts, inspect RPMs, query/install packages via DNF, enable or disable repos, and understand how backporting keeps systems secure.

Red Hat Subscription Management is the mechanism by which you tie a machine to a Red Hat account. This gives you access to updates, patches, support. We’ll talk about how to register a system, attach subscriptions, enable the correct repos, and track entitlements. All of that matters for compliance, security, and getting updates.

This slide shows where on the filesystem certain certificates are kept that reflect system registration and entitlements.

Let’s pause for a quiz on what we’ve covered about registration: what it is, how it works, what certificates are involved. Be ready to answer questions that test your understanding before moving on to RPMs.

Now we move into RPMs: Red Hat’s package management format. In this section you’ll learn how to read a package’s name, version, release, architecture, etc. We’ll look at what information an RPM contains and how you can query existing packages on your system with tools like rpm -q, etc.

Let’s break down what the naming means: the name is ‘httpd’ which is the package identifier for the Apache webserver. After that comes the version, release, architecture. We’ll define version vs. release next.

The version is the upstream software version (Apache HTTPD version), not including packaging tweaks or Red Hat’s build information.

This is Red Hat’s packaging metadata, indicating which build of the package, possibly which minor update or patch iteration it came with. It lets you distinguish among otherwise identical upstream versions that are packaged differently for different builds or for different RHEL minor versions.

This package is built for 64-bit Intel/AMD systems. Packages may also have ‘noarch’ for architecture-independent things (scripts, data, etc.), or other architectures (ARM, etc.). You must install the correct architecture for your system. The DNF package manager will select the correct package for your system.

The rpm -q command queries what version of the httpd package is currently installed. If it's installed, it returns the full package name, version, release, architecture; if not, it will tell you it’s not installed. This is useful for verification and troubleshooting.

Using rpm this way installs the RPM file you have in your local directory. One caveat: rpm does not automatically resolve or fetch missing dependencies. If the package requires others, you might have to manually install them first or use DNF for automatic dependency resolution.

Here rpm2cpio converts the RPM into a cpio archive; cpio -idv extracts files with verbose and directory info. This is useful for examining configuration files, scripts, etc., without installing. You might do this to inspect what files a package would install, or recover something from a package.

Now we’ll do a hands-on guided exercise. I’ll ask you to pick some packages, break down their name/version/release/architecture, use rpm -q to see what’s installed, maybe inspect an RPM locally with rpm2cpio, etc. Try this on your lab system so you get comfortable.

DNF is the package manager tool that handles installation, updates, dependency resolution, repository access, etc. We’ll use DNF to install, update, remove packages, list what's available, search, etc.

The dnf list 'http*' command lists packages starting with ‘http’ in their name.

That searches package names and descriptions for the phrase ‘web server’. This helps you find software based on what you think it should do, rather than exact package name.

The info directive shows detailed metadata about the package httpd: version, release, architecture, repository it comes from, size, summary, etc. Use it when you want to know more about a package before installing it or to check if a package is up-to-date.

Use dnf provides or dnf whatprovides to find which package contains a certain file. This is helpful when you know a file is missing (e.g. a library, binary), and you want to find out which package supplies it, so you can install it.

Using dnf to install software resolves dependencies, downloads the package and whatever it needs, and installs it. DNF handles more checks (signatures, dependencies, repository metadata) than rpm alone.

This will uninstall the package and, depending on options, may also remove dependencies no longer needed. Be careful: removing something that is required by something else may break dependency trees, so always review the output DNF gives before confirming.

DNF supports groups — collections of packages that serve a shared purpose (for example, “Web Server” group). Using dnf groupinstall or remove lets you manage multiple related packages in one command.

DNF keeps a history log: each install, update, or removal is recorded. You can view past transactions, roll back if needed, see what was done and when. Useful for audits, troubleshooting, or if something unexpected changed after an update.

These allow multiple versions of software to be supported in parallel. Module streams define major releases; module profiles let you pick subset of functionality. You can enable or switch between streams. This gives more flexibility, especially for developers or admins who need different versions than the base ones.

RHEL separates its content into BaseOS (the core operating system components) and Application Streams (more rapidly updated or multiple versioned userland apps). Understanding this division is key to knowing where to look for updates and how streams are managed.

Here you see how module streams are defined: a stream is like a versioned path for a certain application. For example, there might be nodejs:14 and nodejs:16 streams. You can switch streams, enable or disable them. The concept allows different customers to pick the version appropriate for their workloads, rather than being limited to a single version.

A module can offer multiple profiles, which are predefined sets of packages within that module. For example a ‘minimal’ profile, a ‘default’ profile, or a ‘devel’ (development) profile. Profiles help you install only what’s necessary. It’s a way to avoid installing unnecessary components.

This is where you use DNF commands like dnf module list, dnf module enable :, dnf module install :/ etc. We’ll show examples. This set of tools lets you pick particular streams and profiles.

We’ll now do another hands-on exercise focused on repositories. You’ll enable or disable Red Hat’s provided repos or third-party repos as needed. You’ll also look into the EPEL (Extra Packages for Enterprise Linux) repo, perhaps. We’ll do this to see how to expand what software is available on a RHEL system.

This slide introduces EPEL — a community repository for packages not shipped with Red Hat by default. We will discuss when to use EPEL, how to enable it safely, and the trade-offs (support, version stability, etc.). Enabling additional repos is useful but requires trust and understanding of compatibility.

Here we cover enabling the official Red Hat repos that correspond to your subscription, such as BaseOS, AppStream, maybe CodeReady Builder, etc. We’ll show how to list repos, enable or disable them (subscription-manager repos or dnf config-manager commands). Ensuring the correct repos are enabled is essential for updates to work reliably.

In some cases, you might add third-party repositories or local repositories (for internal use). This slide probably shows how to add a .repo file under /etc/yum.repos.d/ or use dnf config-manager --add-repo pointing to a URL. We’ll also discuss GPG keys and verifying package authenticity from those repos.

This refers to configuration packages that set up repository files, keys, etc., for you. For example, to enable EPEL, you often install an RPM that sets up the repo file and the GPG key automatically. This simplifies the setup of a repo.

There are some resources to help you understand the concepts covered in this module.

In your graded lab you will apply what you’ve learned: register a system, inspect RPMs, search and install software with DNF, enable repos, maybe use module streams, etc. Be sure to follow best practices: check dependencies, verify packages, understand what repos are enabled, ensure correct architecture.

Thank you all for your attention. If there are any questions, I’m happy to take them now. Otherwise, we’ll proceed to the exercises/lab.