6.3 Configure Access to Flatpak Repositories

6.3 Configure Access to Flatpak Repositories

Quick Answer: Flatpak apps come from remotes (Flatpak repositories), not from /etc/yum.repos.d/. On RHEL 10, add and verify remotes with flatpak remote-add, flatpak remote-list, and related commands (often with --system and root). Configuration lives under Flatpak’s config directories (including /etc/flatpak/ for system-wide setup) and persists after reboot.

Why Flatpak appears on EX200

Red Hat’s current EX200 study points under Manage software explicitly include configuring access to Flatpak repositories and installing/removing Flatpak software. This is not optional trivia. RHEL 10 environments use Flatpak for many desktop and sandboxed applications while RPM/DNF remains the system package source for OS components.

Mental model:

You cannot dnf install a Flatpak application id, and you cannot flatpak install an RPM name interchangeably. Match the tool to the packaging system the task specifies.

Core concepts: remotes, apps, runtimes

• Remote: a named repository endpoint Flatpak can search and pull from (similar in spirit to a DNF repo).
• Application: a Flatpak app with an ID like org.videolan.VLC.
• Runtime: a shared base filesystem stack apps depend on (for example a GNOME or Freedesktop runtime). Installing an app often pulls a runtime automatically when the remote provides it.

Configuring access means the remote is defined, reachable, and listed—before you worry about which app to install (Section 6.4).

Prerequisites

rpm -q flatpak
# if missing and repos work:
sudo dnf install flatpak

Flatpak itself is an RPM-delivered tool. If flatpak is absent, install it with DNF first—an easy two-step task pattern on performance exams.

Listing remotes

flatpak remote-list
flatpak remote-list --show-details
flatpak remotes                  # synonym-style listing on many versions

Output columns typically include remote name, options (such as system/user), and sometimes title/URL. Empty output means no remotes—installs will fail until you add one.

Distinguish scopes:

flatpak remote-list --system
flatpak remote-list --user

• System remotes apply machine-wide (usually require root to change).
• User remotes apply to one account under that user’s Flatpak config.

EX200-style tasks that say “configure the system” almost always mean system remotes. Prefer:

sudo flatpak remote-add --if-not-exists --system ...

Adding a remote

From a .flatpakrepo file (very common)

Vendors and Flathub distribute a small INI-style .flatpakrepo describing the remote:

# Example: add Flathub as a system remote (URL used widely in docs/labs)
sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

# From a local file the exam provides
sudo flatpak remote-add --if-not-exists training /path/to/training.flatpakrepo

--if-not-exists prevents errors when the remote name is already defined—handy for idempotent scripts and re-runs.

From an explicit URL / OCI-style source

Depending on the remote type supported by your Flatpak build and the task instructions, you may add remotes pointing at specific repository URLs (including enterprise or OCI-distributed content). Always copy the exact URL and remote name from the exam task rather than inventing Flathub if the scenario provides a corporate remote.

sudo flatpak remote-add --if-not-exists mycompany https://flatpaks.example.lab/repo/mycompany.flatpakrepo

Useful remote-add options

sudo flatpak remote-add --if-not-exists --disabled staging https://example.lab/staging.flatpakrepo
sudo flatpak remote-modify --enable staging

Inspecting and modifying remotes

flatpak remote-list --show-details
flatpak remote-info flathub            # when supported/needed
sudo flatpak remote-modify --enable flathub
sudo flatpak remote-modify --disable flathub
sudo flatpak remote-delete flathub     # remove remote definition

Deleting a remote does not always delete already-installed applications, but it prevents updates/searches from that source—know which the task wants.

Configuration locations (persistence)

Flatpak stores remote configuration on disk so it survives reboot:

You do not need to hand-edit these on every task—the CLI is preferred—but if a task drops a file into /etc/flatpak/remotes.d/, understand that is a valid system configuration path. After adding files manually, run flatpak remote-list and, if needed, a repair/refresh workflow the man page describes for your version.

Persistence check:

flatpak remote-list
# reboot in the lab
flatpak remote-list   # same remotes should appear

Network and trust considerations

• Remotes need network access unless the task uses a local/offline repo mirror.
• Corporate exams may use internal HTTPS with custom CAs—follow provided instructions for trust.
• Do not confuse RPM GPG keys (rpm --import) with Flatpak remote trust; they are separate ecosystems.
• Firewall tasks elsewhere in the exam can block outbound access and make remote-add or update fail—if metadata download fails, verify network basics.

Verification workflow for “configure Flatpak repository access”

1. Ensure flatpak RPM is installed.
2. Add the remote with the exact name the task specifies (names matter for later flatpak install remote appid forms).
3. flatpak remote-list shows the remote (system scope if required).
4. Optionally refresh: flatpak update or search (Section 6.4) to prove metadata pulls.
5. Confirm still present after reboot in practice labs.

rpm -q flatpak
sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak remote-list --system

Exam traps

1. Adding a user remote when the task requires system-wide availability — use sudo and --system, verify with remote-list --system.
2. Assuming DNF repos cover Flatpak apps — separate system.
3. Wrong remote name — later install lines like flatpak install flathub org.example.App fail if you named it Flathub vs flathub inconsistently (names are case-sensitive identifiers you chose).
4. No network / wrong URL — remote exists but cannot fetch; fix URL or connectivity.
5. Forgetting Flatpak is not installed — install the RPM first.
6. Disabling the remote and leaving it disabled when the task expects active access.

How this differs from Section 6.1 (RPM repos)

Master both; EX200 grades both.

Section checkpoint

You should install Flatpak if needed, add a system remote from a .flatpakrepo or task URL, list and optionally enable/disable remotes, know that configuration is on-disk and reboot-safe, and avoid confusing Flatpak remotes with DNF repositories. Next, install and remove applications from those remotes.