Discover Satellite Content on RHEL 9

Check which RHEL content your Satellite-registered host can see and use.

Introduction

30 Second Summary

An upgrade can look ready on paper while the machine itself is missing the content it needs. The quickest reality check comes from asking the machine what it can actually see.

In this project, you will use read-only client commands on a registered Red Hat Enterprise Linux 9 host to build a content readiness report. You will compare what is installed with what Red Hat Satellite exposes to the host.

What You'll Build

When someone asks whether this host is ready for a RHEL 9 to RHEL 10 upgrade, you will be able to show terminal evidence that proves what the host can see and use.

By the end of this project, you'll have:

An installed host baseline that shows the machine's exact RHEL release and hardware architecture.
A registration record that proves the host's identity and organization. You will also interpret Simple Content Access status correctly.
A content readiness verdict that shows whether RHEL 9.6 is offered. It also identifies which RHEL 9 and RHEL 10 BaseOS and AppStream repositories are visible or currently enabled through DNF.
Secret Mission: A precise Satellite administrator request that names any missing content and lists the content-delivery checks required for this host.

Do I need Satellite administrator access?

You need shell access to a RHEL 9 host that is already registered to Red Hat Satellite. You do not need a Satellite login or administrator access because every command in this project is read-only.

Before We Start

Before you collect evidence, lock in which registered RHEL 9 host you are checking. You will use only read-only client-side commands, so the host configuration and Red Hat Satellite content stay unchanged.

Record the Host Baseline

Repository names depend on the installed Red Hat Enterprise Linux generation. They also depend on the host's hardware architecture.

A release installed on the host describes what runs there today. This client-side fact gives every later content result the right context.

A release offered by Red Hat Satellite describes what the client may access. Your report keeps offered releases separate from the installed release.

In this step, get ready to:

Access the target RHEL host through your organization's VPN and jump server.
Record the host's installed operating system name, version, and hardware architecture.
Separate installed host facts from Satellite-offered releases in your report.

Access the host and record its release

From home, your computer needs an encrypted VPN path into the organization's network before the jump server can reach the RHEL host. Your organization-issued profile and credentials authorize that path.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type the name of your organization's approved VPN client in the search bar.
Press Enter to open the VPN client.
Select the organization connection profile supplied by your administrator.
Sign in with your organization credentials if prompted.
Approve any MFA request if prompted.
Click Connect.

You should see a connected status in the VPN client. Your computer now has the private network route needed to reach the jump server.

The SSH connection may request a key passphrase, MFA approval, or host-key confirmation. Your administrator's approved fingerprint is the source for checking a new host key.

Connect to the target RHEL host through the jump server by running this command:

ssh -J [[JUMP_USERNAME="your jump-server username"]]@[[JUMP_HOST="your jump-server hostname"]] [[TARGET_USERNAME="your target-host username"]]@[[TARGET_HOST="your target-host hostname"]]

How does the jump work?

The -J option tells ssh to route the connection through the jump server.
The first username and hostname identify the jump server.
The final username and hostname identify the target RHEL host.

Confirm that the session reached the intended RHEL host by running this command:

hostname

You should see the target host's configured hostname. Compare it with your target-host hostname before continuing.

Can't reach the target host?

If the VPN does not reach a connected state, confirm that your home internet works. Reconnect with the approved organization profile.
If authentication stops, confirm the requested username and approved SSH key. Complete any pending MFA request before retrying.
If the jump server is unreachable, compare its hostname with the value supplied by your administrator. Reconnect the VPN if the hostname is correct.
If the jump server connects but the target host remains unreachable, compare the target hostname with your access record. Ask your administrator to confirm your authorization if the value is correct.
If hostname prints an unexpected name, run exit and correct the target hostname before retrying.

Need help narrowing down the failed hop? Help me diagnose my VPN or jump-server connection.

The /etc/os-release file stores operating system identification data. Two values give you the installed release baseline.

Read the host's operating system record by running this command:

cat /etc/os-release

What does this command show?

The cat command prints the file without changing it.
The PRETTY_NAME value gives you the human-friendly installed release.
The VERSION_ID value gives you the installed major and minor version.

You should see a RHEL release in PRETTY_NAME. You should also see its installed version in VERSION_ID.

Record the value beside PRETTY_NAME in your client-side content readiness report.
Record the value beside VERSION_ID in your client-side content readiness report.

Identify the hardware architecture

The architecture determines which repository builds can run on this host. Recording it prevents you from requesting content for the wrong hardware type.

Read the host's hardware type by running this command:

uname -m

What does this command show?

The uname command reads system information.
The -m option selects the hardware type.
The printed value identifies the architecture required by matching repositories.

You should see an architecture such as x86_64, aarch64, ppc64le, or s390x.

Record the printed architecture in your client-side content readiness report.

Build the baseline report

Raw output becomes useful when each value has a clear source. Your report now connects the checked host to its installed operating system facts.

Add the checked hostname from your prompt to the report.
Place the recorded PRETTY_NAME under installed client facts.
Place the recorded VERSION_ID under installed client facts.
Place the recorded architecture under installed client facts.
Reserve a separate report area for release versions that Satellite offers later.

Report checkpoint

Your initialized report contains the checked hostname. It also contains the installed OS PRETTY_NAME.

The report records the installed OS VERSION_ID alongside the hardware architecture. Satellite-offered releases remain separate from this installed baseline.

Before you run the final check, which installed release and architecture do you expect this host to print?

Rerun both read-only checks with these commands:

cat /etc/os-release
uname -m

What does this final check prove?

The first command confirms the installed operating system values recorded in your report.
The second command confirms the hardware architecture recorded in your report.
Neither command changes client configuration or Satellite content.

You should see a RHEL VERSION_ID containing a major and minor release. You should also see the host's architecture.

Compare the fresh PRETTY_NAME value with the report entry.
Compare the fresh VERSION_ID value with the report entry.
Compare the fresh architecture with the report entry.
Confirm that Satellite-offered releases remain in their own report area.

Do the values differ from your report?

Rerun the first command if the report's PRETTY_NAME or VERSION_ID differs from the terminal output.
Rerun the second command if the recorded architecture differs from the terminal output.
Update each report entry from the latest output on this host.

Still unsure how to interpret the values? Help me reconcile my RHEL baseline output.

You have the baseline locked in. Every later content result can now be tied to the host that produced it.

Next, you'll use identity evidence to prove the host's registration.

Verify Registration Identity

Your report already anchors the host to its installed release and architecture. The next question is whether Red Hat Satellite recognizes this exact system.

Red Hat Subscription Manager can show Overall Status as Disabled when Simple Content Access is active. Successful identity output becomes your primary registration proof. The complete status message supplies the supporting context.

In this step, get ready to:

Read the complete subscription status message.
Capture the host identity and organization details.
Add a registration verdict based on successful identity output.

Read the full subscription status

Subscription status describes the client's current content access context. Under Simple Content Access, an Overall Status value of Disabled can coexist with valid registration.

Inspect the complete Subscription Manager status by running this read-only command:

subscription-manager status

What does this command show?

The subscription-manager status command prints the host's subscription status context.
The complete message explains how Subscription Manager is interpreting content access for this client.
The surrounding Simple Content Access wording gives meaning to the Overall Status value.

Record the complete status output in your client-side content readiness report.
Read the wording around Overall Status.
Add a note that Disabled alone does not mean registration failed when the message mentions Simple Content Access.

Good progress. Your report now preserves the full status context instead of drawing a registration conclusion from one value.

Status command not working?

Confirm that your terminal is still connected to the registered RHEL host. Check that you entered the command exactly as shown.

If the command still fails, help me diagnose the Subscription Manager status check.

Prove registration with identity

Identity output ties the client to its registered system record and organization. This evidence provides the registration verdict even when the status wording looks unclear.

Before you run the identity check, which registration details do you expect Satellite to return for this host?

Request the host's registration identity by running this read-only command:

subscription-manager identity

What does this command prove?

The subscription-manager identity command asks for the registered identity associated with this client.
Successful output connects the host to its system identity and organization record.
An environment name may also appear when the client exposes that information.

A registered host prints its system identity, name, org name, and org ID. Some Satellite clients also print an environment name.

Record the system identity in your client-side content readiness report.
Record the name as the registered name.
Record the org name.
Record the org ID.
Record the environment name if the command exposes one.
State that the environment was not exposed by this command if the field is absent.
Add a registration verdict that uses successful identity output as the primary proof.
Preserve the complete status text as supporting context.

Review the completed report. You should see the hostname, installed release, architecture, full subscription status context, identity details, organization details, any exposed environment name, and an evidence-based registration verdict.

Identity details missing?

Confirm that you ran the identity command on the same host recorded in your report. An absent environment name can be documented as not exposed by the client.

If the command does not return identity evidence, help me interpret the missing registration identity.

That settles the registration question. Your report now separates a valid identity from potentially misleading status wording.

Your host identity and organization are documented. Next, you can compare the installed release with the minor releases Satellite offers to this client.

Check Offered Minor Releases

Your report already records the host baseline. It also proves that this RHEL host is registered with Red Hat Satellite.

The installed VERSION_ID answers which release runs on the host today. The offered release menu answers which minor releases Red Hat Subscription Manager exposes to this client.

These results answer separate questions. Repository IDs for standard RHEL 9 content usually identify the major release without spelling out 9.6.

In this step, get ready to:

Record the current release preference without changing it.
Capture the minor releases offered to this client.
Add an evidence-based RHEL 9.6 verdict to the report.

Record the current release preference

The release preference is displayed separately from the installed operating system release. Your report keeps both values as distinct evidence.

Display the current release preference by running this read-only command:

subscription-manager release --show

What does this command show?

The --show option displays the release preference currently set for Subscription Manager. This command leaves the client configuration unchanged.

Copy the complete terminal output into your client-side content readiness report.
Label the copied output as the current release preference.

Good progress. Your report now separates the client's release preference from the operating system installed on the host.

No preference returned?

Preserve the complete empty or error result in your report.

Need help understanding the result? Help me interpret the release preference output from my registered RHEL host.

List the releases offered to this client

The offered release list is client-scoped evidence. It reflects the operating system versions currently offered to this registered host.

Before you run the check, consider whether 9.6 will appear for this host.

Display the offered release menu by running this read-only command:

subscription-manager release --list

What does this command show?

The --list option displays the operating system versions offered to this registered client. The result can contain listed versions, no release versions, or an error.

You can now see whether 9.6 appears in the client response. The terminal may instead contain an empty or error result.

Copy the complete terminal output into the offered releases section of your report.
Mark the RHEL 9.6 offered verdict as Yes only if 9.6 appears in the output.

A visible 9.6 entry supports a Yes verdict for this client.

Mark the RHEL 9.6 offered verdict as No when 9.6 does not appear.
Preserve an empty or error result exactly as the terminal displays it.

An absent 9.6 entry supports a No verdict for this client. It does not establish what source content exists across Satellite.

Seeing no release versions?

An empty list or error describes the response available from this client. It does not prove that Satellite lacks RHEL 9.6 source content.

Red Hat documents the no-release-versions outcome on RHEL 9.4 or later. Keep the exact result for the administrator handoff.

Need help separating evidence from conclusions? Help me interpret my offered release list without assuming Satellite content is missing.

Verify the report evidence

A defensible readiness report keeps raw evidence beside the conclusion drawn from it. This makes the boundary of the client-side check clear.

Before the final check, consider whether a missing 9.6 entry supports any conclusion beyond this client's current view.

Scroll to the earlier --show result in your terminal.
Compare that result with the current release preference entry in your report.

The saved release preference should match the terminal output character for character.

Compare the current --list result with the offered releases entry in your report.
Check that the explicit RHEL 9.6 verdict follows the presence or absence of 9.6 in that result.

The offered releases entry should match the terminal output exactly. The verdict should say Yes only when the output contains 9.6.

Confirm that any empty or error result remains preserved as client evidence without becoming proof that the source content is absent.

Your report now contains the exact release preference output. It also contains the exact offered-release output plus an explicit RHEL 9.6 verdict.

That gives you a release verdict backed by raw client evidence. Next, you'll compare visible repositories with the repositories DNF can use now.

Compare Visible and Enabled Repositories

Your report already captures this RHEL 9 host's baseline plus release evidence exposed through Red Hat Satellite. You now need a repository comparison to finish the readiness verdict.

Red Hat Subscription Manager shows which repositories are visible to the client. DNF shows which repositories are currently enabled.

Checking only one list can produce the wrong readiness verdict. This comparison keeps client visibility separate from current DNF use.

In this step, get ready to:

Capture repository details visible through Red Hat Subscription Manager.
Use GNU grep to isolate BaseOS plus RHEL 9 and RHEL 10 repository identifiers.
Compare client-visible repositories with repositories currently enabled for DNF.

Inspect client-visible repositories

A repository can be visible to the client even when it is disabled. This first inventory captures every repository that Subscription Manager exposes to this host.

Display every repository visible to this client by running this command:

subscription-manager repos --list

How to read each repository block

Presence in this inventory means the repository is visible to this client.

The Repo ID identifies the repository.
The Repo Name provides its readable name.
The Repo URL records its content location.
The Enabled: 1 value marks the repository as enabled.
The Enabled: 0 value marks the repository as visible but disabled.

You'll see repository blocks containing identity, location, and enablement details for content visible to this host.

Add each relevant repository block to the client-side content readiness report from earlier.

Repository inventory missing?

Confirm that you entered subscription-manager repos --list exactly.
Preserve any empty result or client-reported error in the report.

Help me understand why the repository inventory is missing.

Filter the repository inventory

A pipe sends the Subscription Manager output into GNU grep. Case-insensitive matching finds BaseOS text even when the letter case differs.

Filter the repository inventory for BaseOS lines by running this command:

subscription-manager repos --list | grep -i 'baseos'

What does this filter do?

The | sends the repository inventory into grep.
The -i option performs a case-insensitive match.
The 'baseos' value supplies the text that grep searches for.

You'll see only lines containing BaseOS text. A blank result means this filter found no BaseOS lines in the client-visible inventory.

Add the exact BaseOS filter result to your report.

BaseOS filter looks wrong?

Check that the pipe appears between the two commands.
Check that 'baseos' remains inside single quotes.

Help me troubleshoot the BaseOS filter.

An extended regular expression can test several repository patterns in one pass. This filter keeps matching RHEL 9 or RHEL 10 BaseOS and AppStream RPM Repo ID lines.

Narrow the inventory to the target repository identifiers by running this command:

subscription-manager repos --list | grep -E '^Repo ID:.*rhel-(9|10)-.*(baseos|appstream).*rpms'

How does the expression work?

The -E option enables extended regular expressions.
The ^Repo ID: pattern requires each match to start on a repository identifier line.
The rhel-(9|10)- pattern selects RHEL 9 or RHEL 10.
The (baseos|appstream) pattern selects BaseOS or AppStream.
The .* pattern permits intervening characters.
The rpms pattern limits the results to RPM repository identifiers.

You'll see only matching repository identifier lines. A blank result means no client-visible repository identifiers matched the complete expression.

Add the exact extended-expression filter result to your report.

Regular expression not matching?

Check that the expression remains inside single quotes.
Check every parenthesis plus each vertical bar against the command shown above.

Help me troubleshoot the repository expression.

Compare visibility with DNF enablement

The Subscription Manager inventory proves client visibility. The DNF output proves current enablement.

Before you run this check, which repositories do you expect DNF to show as enabled?

List the repositories currently enabled for DNF by running this command:

dnf repolist

How to build the final verdict

The dnf repolist command lists repositories currently enabled for DNF. A repository found through Subscription Manager but absent here remains visible to the client.

One verdict states whether RHEL 9 BaseOS and AppStream are visible.
One verdict preserves whether RHEL 9.6 is offered.
One verdict states whether RHEL 10 BaseOS and AppStream are visible.
One verdict states whether the required repositories are currently enabled.

You'll see the repository identifiers that DNF can currently use on this host.

Compare each repository identifier in the DNF output with the Subscription Manager inventory.
Complete the report's final repository verdict section using evidence from both lists.

Unsure how to classify a repository?

Classify a repository found in both outputs as visible and enabled.
Classify a repository found only in Subscription Manager as visible but not enabled.
Keep every command read-only.

Help me classify my repository results.

Before your final review, do you expect all four verdicts to be supported by command output?

Review the completed client-side content readiness report from the checked hostname through the final repository verdicts.

What should the completed report show?

The earlier host baseline plus registration evidence remains intact.
The earlier release preference plus offered-release evidence remains intact.
Relevant repository blocks preserve Repo ID, Repo Name, Repo URL, and Enabled values.
The case-insensitive BaseOS output appears in the repository section.
The extended-expression RHEL 9 and RHEL 10 repository identifier output appears in the repository section.
The dnf repolist output identifies the repositories currently enabled.
The four host-specific verdicts distinguish client-visible content from DNF-enabled content.

That's the comparison complete: your report now separates repositories the host can see from repositories DNF can use.

Secret mission

Write the Satellite Admin Request

Turn your client-side evidence into a factual handoff for the Satellite administrator. Write either a passed result or a targeted request that names every missing content-delivery check.

Clean Up Your Resources

Your checks used only read-only commands on the registered host. No client configuration or Red Hat Satellite content was changed, so there are no ongoing costs or infrastructure resources to clean up.

Resources you used:

No project-created resources, local project directories, or configuration changes require teardown.

Keep everything running

No action is needed. Choose this option if you want to keep your evidence ready for an upgrade assessment or administrator review.

Keep the client-side content readiness report as evidence of what the host could see during your checks.
Keep the Satellite administrator handoff for your next conversation with the infrastructure team.
Leave the existing host configuration unchanged.

Pause - I'll come back to this later

A paused state here means ending your current shell connection while preserving the report and administrator handoff.

Close the terminal window that holds your current host connection.
Keep the client-side content readiness report for your next session.
Keep the Satellite administrator handoff with the report so both records stay together.

Delete - I don't want to use this again

There are no project-created infrastructure resources to remove. The registered host and Satellite content existed before this project.

Leave the existing host registration unchanged.
Discard the client-side content readiness report if your organization no longer needs the evidence.
Discard the Satellite administrator handoff if you do not plan to raise the request.
Close the terminal window that holds your current host connection.

Nice Work!

Excellent work. You built a read-only client-side content readiness report for an RHEL 9 host registered to Red Hat Satellite.

You learned how to:

Record the installed RHEL release in a host baseline. Add the hardware architecture needed to interpret repository IDs. Prove registration through identity plus organization evidence.
Interpret Simple Content Access status without declaring a registered host invalid. Check the offered release menu to determine whether RHEL 9.6 is available to this client.
Distinguish visible repositories in Red Hat Subscription Manager from DNF-enabled repositories. Use targeted filters to find RHEL 9 or RHEL 10 BaseOS or AppStream repository IDs. Turn the combined evidence into host-specific readiness verdicts.
Secret Mission: Convert client-side evidence into a precise Satellite administrator handoff. Write a passed result when the required content is visible. Name missing content when an administrator check is needed. Limit activation-key work to planned registration or re-registration.

Ready to quiz yourself?