16.2 Install and Update Software from CDN, Remote Repos, and Local Files

16.2 Install and Update Software from CDN, Remote Repos, and Local Files

Quick Answer: From configured repos (CDN, HTTP/HTTPS, or file://), install with dnf install PKG and update with dnf upgrade / dnf update. From a lone file, use dnf install /path/package.rpm (preferred) or rpm -ivh. Ensure repos work first (dnf repolist, makecache), then prove packages with rpm -q.

Blueprint placement

Chapter 6 covered configuring RPM repositories and basic install/remove. This deploy objective emphasizes installing and updating software using multiple source types the exam may force:

1. CDN / subscription-backed Red Hat content (BaseOS, AppStream, etc.)
2. Remote repositories (HTTP/HTTPS training mirrors, extra .repo files)
3. Local filesystem (ISO mount, copied repo tree, individual .rpm files)

Same DNF engine—different where bits come from. Tasks may say “install from the local repository under /content,” “update all packages,” or “install this RPM from /root.”

Source type map

Prefer dnf over bare rpm for installs so dependencies resolve from repos.

CDN and subscription-backed content

On a registered RHEL system, subscription-manager and product certificates expose Red Hat CDN repositories. Training VMs may already be registered or may use local content servers that stand in for CDN.

# Awareness (may be limited or preconfigured in exam images)
sudo subscription-manager status 2>/dev/null || true
sudo subscription-manager repos --list-enabled 2>/dev/null | head
dnf repolist

You rarely build CDN URLs by hand on EX200. You use whatever BaseOS/AppStream (or lab equivalent) is enabled:

dnf repolist
sudo dnf makecache
sudo dnf install -y httpd
sudo dnf upgrade -y httpd
# or broader:
# sudo dnf upgrade -y

If repolist is empty or metadata fails, fix registration/repo enablement or lab mirror connectivity before blaming package names.

Modules (awareness)

AppStream may expose modules. If dnf install says no match but the package is modular, the task or docs may require dnf module enable … first. Only go there when the error or task points you—that is not the everyday path for simple packages.

Remote repositories (HTTP/HTTPS)

Chapter 6 pattern—deploy focus is using the remote repo to install/update:

# Example repo already created or you create it:
sudo tee /etc/yum.repos.d/training.repo <<'EOF'
[training]
name=Training remote
baseurl=http://materials.example.lab/rhel10/BaseOS/x86_64/os/
enabled=1
gpgcheck=0
EOF

sudo dnf clean all
sudo dnf makecache
dnf repolist
sudo dnf install -y example-package
sudo dnf upgrade -y example-package

# One-shot without permanent enable (not enough if task wants lasting access)
sudo dnf install -y --enablerepo=training example-package

For lasting use, enabled=1 in the .repo file (or dnf config-manager --set-enabled).

GPG and CDN trust

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
# gpgcheck=1 and gpgkey= in .repo when keys are provided

Signature failures mid-install mean import the key or fix gpgkey=—do not blindly disable GPG unless the task’s local unsigned tree requires it.

Local filesystem sources

A) Directory repository with repodata

Lab ISOs and content packs often unpack to trees containing repodata/:

sudo mkdir -p /mnt/disc
sudo mount -o loop /path/to/rhel.iso /mnt/disc   # if ISO file given
# or: already mounted NFS/USB at /mnt/disc
ls /mnt/disc/BaseOS/repodata 2>/dev/null || ls /mnt/disc/repodata

# /etc/yum.repos.d/local-iso.repo
[local-baseos]
name=Local BaseOS
baseurl=file:///mnt/disc/BaseOS
enabled=1
gpgcheck=0

sudo dnf makecache
sudo dnf install -y strace
sudo dnf upgrade -y

Three slashes in file:///mnt/.... Point baseurl at the repo root that holds repodata, not at a random parent or at the .iso file path itself.

Persist the mount if the repo must work after reboot (fstab entry for the ISO/device)—if the task only needs a one-time install, mounting for the transaction may suffice, but repo files under /etc/yum.repos.d/ remain and should still point at a valid path.

B) Single local RPM files

ls /root/*.rpm /var/tmp/*.rpm 2>/dev/null
sudo dnf install -y /root/example-1.0-1.el10.x86_64.rpm
rpm -q example

dnf install on a file path uses the RPM and tries to pull dependencies from enabled repos—best of both worlds.

# Weaker alternative (deps not auto-resolved from repos the same way)
sudo rpm -ivh /root/example-1.0-1.el10.x86_64.rpm
sudo rpm -Uvh /root/example-1.0-2.el10.x86_64.rpm   # upgrade
sudo rpm -e example                                 # erase

Use rpm -Uvh for upgrade-or-install of a local file; dnf reinstall / dnf upgrade when the package is in a repo.

C) Creating a local repo from a folder of RPMs (when tasked)

If you only have a pile of RPMs and need a repo:

sudo dnf install -y createrepo_c   # package name may be createrepo_c on modern RHEL
sudo mkdir -p /srv/localrepo
sudo cp /path/*.rpm /srv/localrepo/
sudo createrepo_c /srv/localrepo
# then file:// baseurl=/srv/localrepo

Only do this when the environment provides createrepo tooling and the task implies a custom local repo—not every exam item needs it.

Install vs update vs upgrade language

On modern DNF, update and upgrade are closely related; using dnf upgrade is clear for “bring packages up to date.” Always match task verbs (“install,” “update”).

sudo dnf install -y wget tree
sudo dnf upgrade -y wget
sudo dnf check-update          # report only
dnf list installed wget
rpm -q wget

Group installs (occasional)

dnf group list
sudo dnf group install -y "Development Tools"

Use when the task names a group or environment—not as a substitute for a single package name.

Verification and history

rpm -q httpd
rpm -qi httpd | head
dnf list installed httpd
rpm -V httpd                 # verify file checksums vs database
sudo dnf history
sudo dnf history info last

If an install fails:

sudo dnf clean all
sudo dnf makecache
dnf repolist -v
curl -I http://materials.example.lab/…   # if network tools allowed

Exam workflows

Workflow A — CDN/default repos: install and update

dnf repolist
sudo dnf install -y httpd
sudo dnf upgrade -y httpd
rpm -q httpd
sudo systemctl enable --now httpd   # if service objective also applies

Workflow B — Remote training repo

sudo tee /etc/yum.repos.d/extra.repo <<'EOF'
[extra]
name=Extra
baseurl=http://server.lab/extra/
enabled=1
gpgcheck=0
EOF
sudo dnf makecache
sudo dnf install -y lab-tool
rpm -q lab-tool

Workflow C — Local ISO repo

sudo mount /dev/sr0 /mnt 2>/dev/null || sudo mount -o loop /root/rhel.iso /mnt
sudo tee /etc/yum.repos.d/iso.repo <<'EOF'
[iso-appstream]
name=ISO AppStream
baseurl=file:///mnt/AppStream
enabled=1
gpgcheck=0
EOF
sudo dnf install -y python3-pip

Workflow D — Local RPM file with deps from repos

sudo dnf install -y /root/custom-agent-2.1.rpm
rpm -q custom-agent

Workflow E — System-wide update from all enabled sources

sudo dnf upgrade -y
sudo dnf needs-restarting -r 2>/dev/null || true

Kernel updates may need reboot; if a task updates kernel packages, remember bootloader/kernel selection (Section 16.3) may matter.

Common traps

1. Configuring a repo but never running install/update when the task requires packages present.
2. rpm -ivh only and leaving broken dependency chains.
3. file:// with wrong slash count or unmounted path.
4. Pointing baseurl at ISO file instead of mount point tree.
5. Temporary --enablerepo only when lasting repo access was required.
6. Disabled AppStream causing “no package” for common tools.
7. Assuming CDN works offline—use local content when the lab is air-gapped.
8. Forgetting makecache after changing .repo files.
9. Updating packages then not verifying rpm -q / version.
10. Removing the only working repo mid-exam while chasing GPG errors.

Relationship to other chapters

• 6.1–6.2: repository files and package install/remove fundamentals—this section stresses multi-source update/install in the deploy category.
• Services: installed daemons still need enable --now.
• Bootloader (16.3): kernel upgrades interact with GRUB/grubby defaults.
• Flatpak (Ch6): separate stack for apps; system tools remain RPM/DNF.

Section checkpoint

You should install and update packages from CDN/default Red Hat content, remote HTTP/HTTPS repos, local file:// repos, and individual RPM files; prefer dnf for dependency resolution; verify with repolist, makecache, and rpm -q; and leave both packages and repo configuration correct for reboot. That meets the EX200 deploy skill for software from CDN, remote repos, and local files on RHEL 10.