How to Use RedHat Satellite Server Web Portal for patching

— ny_wk

Red Hat Satellite patching from the web portal lets you review outstanding errata, apply security and bug fixes to one or many RHEL hosts, schedule changes inside a maintenance window, snapshot for rollback, and verify the result — all without touching each server by hand. This guide walks through the full workflow end to end, fixes the gotchas the built-in help glosses over, and notes the modern Satellite 6 equivalents so the procedure works whether you are on a legacy Spacewalk/Satellite 5 console or a current Foreman/Katello-based Satellite 6.x.

The problem: patching a fleet of RHEL servers safely

Logging into dozens of servers individually to run yum update or dnf update does not scale, leaves no audit trail, and makes it almost impossible to prove a security advisory was actually closed. The whole point of Red Hat Satellite patching through the web portal is centralized control: one console that shows every available erratum (Red Hat's term for a packaged fix — a Security Advisory/RHSA, Bug Fix Advisory/RHBA, or Enhancement Advisory/RHEA), lets you push it to a group of hosts, and records who scheduled what and when.

Before you start, confirm two things that are easy to skip and expensive to forget. First, any change to a production system should be tied to an approved Change Request (CR) — the portal will happily apply patches the second you click confirm, so the governance has to come from you. Second, know whether the host runs a push agent (legacy osad, or the modern goferd/remote-execution stack) so you understand how fast the action will run and how status reports back.

Step 1: View outstanding patches in the Satellite web portal

Open the Satellite web console in a browser and sign in with your account. On a legacy Satellite 5 / Spacewalk system the login page lives at a path such as https://your-satellite.example.com/rhn/Login.do; on Satellite 6 it is simply https://your-satellite.example.com/. Use the host name your organization actually published — do not assume an internal short name resolves from your workstation.

1. Go to the Systems tab (Satellite 6: Hosts → Content Hosts or All Hosts).
2. Type the server name, or just the first few letters, into the Filter by System Name / search box and run the filter.
3. Review the filtered list. The summary view shows, at a glance, how many security, bug-fix, and enhancement errata are outstanding per host — ideal when you are checking a whole group at once.

You can also use the global Search function and click an individual host name to drill into its applicable errata. That single-host view is more detailed but does not give you the cross-fleet summary, so use the filter view when you need the big picture and the search view when you are working one box at a time.

Step 2: Install selected patches on a single server

Open the host you want to patch and go to its Software tab. You will find two ways to apply changes: by Errata (the Security Advisory / Bulletin list — the recommended way, because an erratum bundles every package a fix needs) and by individual Packages.

1. Search the Errata (or Packages) list for the advisory you intend to install — for example a specific RHSA security advisory ID.
2. Tick the checkbox next to each erratum/package you want.
3. Scroll to the bottom and click Apply Errata (Satellite 6: Apply).
4. If this is a production host, confirm you have a valid CR associated with the change before you proceed.

On the confirmation screen you choose when it runs:

• Patch immediately — choose Schedule action as soon as possible (or “Execute now” on Satellite 6) and confirm. The job fires in real time.
• Schedule for a maintenance window — choose Schedule action for no sooner than, pick the date and time, and confirm. This creates a pending/scheduled job that runs at your chosen time.

Tip: scheduling “no sooner than” is a floor, not an exact start time — a legacy client that only checks in periodically may pick the job up slightly after the stated time. Plan your CR window with a little headroom.

Step 3: Apply one patch to multiple servers at once

This is the workflow you want when a monthly vulnerability report (IVA/EVA, CMRP, or any internal scan) tells you to close a specific CVE across many hosts. Instead of repeating Step 2 per server, drive it from the erratum:

1. From the home page, open Errata to see all available advisories.
2. Click the specific erratum you need to install.
3. Open its Affected Systems (Satellite 6: Content Hosts) tab and use the filter to locate your target hosts.
4. Select more than one server, then click Apply.
5. On the confirmation page, schedule it for your window or apply it right away, then verify (see verification below).

Doing it this way guarantees every selected host gets the same advisory, which is exactly what an auditor wants to see when you report a vulnerability as remediated.

Step 4: Create a snapshot and roll back (legacy provisioning)

On Satellite 5 / Spacewalk, snapshot tags give you an OS-level rollback plan for package state. This is worth doing before a risky production patch.

1. From the home page go to Systems and locate your server (as in Step 1).
2. Click the server name, then Provisioning → Snapshot Tags.
3. Choose Create a new system tag. Name it something traceable — a date plus the CR number works well (for example 2026-06-28_CR12345).
4. Click Tag Current Snapshot, then confirm the snapshot shows as ready.
5. Apply your patch.
6. To undo, open the snapshot you created and click Rollback to this snapshot after reviewing the changes.

Important reality check: a snapshot rollback reverts the recorded package profile — it is not a full filesystem or data restore, and it does not reverse application data changes, schema migrations, or anything outside RPM state. On Satellite 6, snapshot tags were removed; the modern equivalent is a hypervisor/VM snapshot, an LVM snapshot, or a filesystem snapshot (for example Btrfs/ZFS or a SAN snapshot) taken before patching. Always keep a real backup as your true safety net.

Step 5: Compare installed packages between servers

Comparing package profiles is how you spot drift between environments — DEV vs. QA, QA vs. PROD, or two members of the same cluster (say APP01 vs. APP02) that should be identical.

1. From the home page, open Systems and filter to the first host (for example APP01).
2. Open its Software → Packages → Compare Packages Profiles (also reachable via Manage Package Profiles).
3. Pick the second host from the dropdown and click Compare.
4. The result page lists every difference — version mismatches and packages present on one host but not the other — so you can close the gap deliberately.

Because PROD and non-PROD are usually segregated into separate Satellite organizations or content views for security and compliance reasons, you often cannot compare a PROD host directly against a non-PROD one inside a single view. If you need that comparison, export each host's package profile and diff them offline, or raise it with your Satellite administrators rather than weakening the segregation.

Step 6: Verify the patch actually applied

Applying a patch is only half the job; proving it ran is what closes the CR. The portal gives you several verification points.

• Schedule overview: click Schedule on the main menu to see all your jobs.
• Pending Actions: lists jobs you have scheduled that have not run yet.
• Completed Actions: lists jobs that finished successfully — and, just as usefully, Failed Actions flags anything that errored.

For real-time status, the legacy push agent matters. If the host has the osad package installed, the Satellite server can push the action and report status immediately. Without it, clients only check in roughly every four hours, so a freshly scheduled “as soon as possible” job can look stalled simply because the client has not phoned home yet.

You can force a legacy client to check in immediately by running rhn_check on the host. Inspect the push agent with service osad status; if the service does not exist it is probably not installed. To install and enable it on an older system:

1. Install it: yum install osad
2. Enable at boot: chkconfig osad on
3. Start it now: service osad start

On a Satellite 6 host this whole mechanism is different. Real-time pushes use Remote Execution over SSH (the preferred method today) or the older goferd/Katello-agent over a message bus, and the daemons are managed with systemctl (for example systemctl status goferd) rather than service/chkconfig. The Katello agent has itself been deprecated by Red Hat in favor of Remote Execution, so on current builds prefer Remote Execution. For any production CR it is still good practice to log into the client and confirm the patch directly.

Independent verification from the client host

Never trust the console alone for a production change — confirm on the box. A few quick, real commands:

• Confirm a specific package version: rpm -q openssl (or dnf list installed openssl on RHEL 8/9).
• Confirm a security advisory was applied (RHEL 8/9): dnf updateinfo list security should no longer list the RHSA you just closed.
• List recently installed/updated packages: rpm -qa --last | head.
• Check whether outstanding security errata remain: dnf updateinfo summary (modern) or yum updateinfo summary (legacy RHEL 7).

Matching the console's “Completed Action” against the actual installed version on the host is the verification an auditor will accept.

Common pitfalls to avoid

• Forgetting the reboot for kernel updates. Installing a new kernel erratum does not make the running system use it — the host keeps running the old kernel until it reboots. Bake an OS reboot (and any application/DB shutdown it requires) into the CR. You can schedule it from Systems → (host) → Schedule a reboot, or do it manually. Modern alternative: kpatch live patching can defer some kernel reboots, but it does not cover every kernel change.
• Assuming “schedule now” means instant. Without a push agent, a job waits for the next client check-in (up to ~4 hours on legacy). Use rhn_check or Remote Execution to force it.
• Patching PROD without a CR. The portal does not enforce change control — you do.
• Treating a snapshot as a backup. Snapshot tags revert package state, not data. Keep real backups.
• Selecting individual packages instead of the erratum. Picking packages by hand risks missing a dependency the advisory bundles. Apply by erratum whenever possible.
• Ignoring failed actions. A job can land in Failed Actions (locked yum/dnf, dependency conflict, full disk) while you assume it succeeded. Always check.

Legacy vs. modern: a quick reference

Red Hat Satellite 5 reached end of life, so if you are still on it, plan a migration to Satellite 6.x — but the conceptual workflow (review errata, apply to hosts, schedule, snapshot, verify) carries straight across, which is why the steps above still map cleanly to the modern console.

Key Takeaways

• Use the Systems/Hosts filter for a fleet-wide view of outstanding errata, and the per-host view for detail.
• Apply fixes by erratum, not by hand-picking packages, so dependency-complete bundles install cleanly; drive multi-host patching from the erratum's Affected Systems tab.
• Always tie production changes to a CR — the portal applies patches the moment you confirm and enforces no change control of its own.
• Verify twice: check Completed/Failed Actions in the console and confirm the installed version on the client with rpm -q or dnf updateinfo list security.
• Kernel updates require a reboot, snapshots are not backups, and Satellite 6 replaces osad/rhn_check with Remote Execution — know which version you are on.

Frequently Asked Questions

How do I check which patches are available for a server in Red Hat Satellite?

Open the Systems tab (or Hosts → Content Hosts in Satellite 6), filter by the server name, and open the host. Its Errata/Software tab lists every applicable security, bug-fix, and enhancement advisory. The filtered list view also shows a per-host count so you can scan a whole group at once.

Do I need to reboot after patching with Satellite?

Only when the update changes the running kernel or a core library that services depend on. A kernel erratum always requires a reboot to take effect — the host keeps running the old kernel until then. Most userspace package updates do not need a reboot, though long-running daemons should be restarted to load the new binaries. Use needs-restarting (from the dnf-utils/yum-utils package) to see what must be restarted.

Why is my scheduled patch not running in Satellite?

The most common cause on legacy systems is that the client has not checked in. Without the osad push agent, hosts only contact the Satellite server about every four hours, so an “as soon as possible” job waits until then. Run rhn_check on the client to force an immediate check-in, or confirm osad is running with service osad status. On Satellite 6, verify Remote Execution connectivity (SSH) or that goferd is active.

How do I roll back a patch in Red Hat Satellite?

On Satellite 5 you can create a snapshot tag before patching and roll back the package profile afterward. That reverts RPM state only — not data. On Satellite 6, snapshot tags were removed, so take a VM, LVM, or filesystem snapshot beforehand. For a single package you can also downgrade with dnf downgrade <package>, but a pre-change backup remains your only complete safety net.

For more Linux, RHEL, and sysadmin walkthroughs, subscribe on YouTube: @explorenystream.