Kennisbank / Red Hat Satellite patchmanagement

Red Hat Satellite: gecontroleerd patchen met content views

Auteur: DEWOLF.IT

Red Hat Satellite patchmanagement draait om reproduceerbare content. Een gesynchroniseerde repository is nog geen goedgekeurde patchset. Met content views en lifecycle environments kun je dezelfde geteste inhoud gecontroleerd naar productie brengen.

Scope: Satellite 6.x; voorbeelden sluiten aan op de 6.17-contentworkflow. Controleer verschillen in jouw release.

Toepassing. Contentbeheer voor RHEL-hosts met Red Hat Satellite 6.x. De workflow hieronder volgt de documentatie voor 6.17; controleer bij een andere release de UI, Hammer-opties en de mogelijkheden voor meerdere content view environments.

Probleem en achtergrond: beschikbaar is niet hetzelfde als goedgekeurd

Een host kan geregistreerd zijn en toch een update missen. Een repository kan op Satellite gesynchroniseerd zijn terwijl de relevante content view-versie nog oude content bevat. En een geteste versie kan aanwezig zijn in Test, maar nog niet in Production. Onderzoek de volledige contentketen voordat je op een individuele host repositories gaat aanpassen.

Een bruikbaar beheerontwerp scheidt drie beslissingen: welke externe content komt binnen, welke combinatie wordt als release aangeboden en welke hosts mogen die release gebruiken? Benoem voor iedere stap een eigenaar. Daarmee kan een securitymelding worden vertaald naar een traceerbare release, in plaats van naar een losse serie dnf-commando’s.

1. Begrijp de contentketen

Een repository levert packages en metadata. Een content view bundelt geselecteerde repositories en eventueel filters. Publiceren levert een versie op; promotie maakt die versie beschikbaar in een lifecycle environment. Composite content views combineren versies van component views. Deze werkwijze staat beschreven in Managing content views.

Library ontvangt gesynchroniseerde content. Richt vervolgens een gecontroleerd pad in, bijvoorbeeld Development → Test → Production. Test een concrete content view-versie en promoveer diezelfde versie. Een nieuwe publicatie tijdens promotie kan een andere inhoud opleveren en ondermijnt het bewijs uit de testfase. Zie Managing application lifecycles.

Geef views een beheersbare scope, bijvoorbeeld één OS-major en een samenhangende applicatiegroep. Te veel kleine views vergroten afhankelijkheden en beheerwerk; één gigantische view maakt uitzonderingen moeilijk zichtbaar. Documenteer welke keuze past bij het patchvenster en de applicatie-eigenaren.

2. Maak de release expliciet

Een releasebeschrijving bevat ten minste de repositoryset, content view- en eventuele componentversies, de publicatiedatum, relevante errata, testresultaten en het productievenster. Bij filters hoort ook de reden waarom content is uitgesloten. Een filter kan onbedoeld afhankelijkheden of veiligheidsupdates tegenhouden; beoordeel daarom de uiteindelijke oplosbare package-set.

# Op de Satellite-beheerhost met ingerichte Hammer-authenticatie.
# Voorbeeldnamen: vervang deze door jouw organisatie en view.
hammer repository list --organization "Example Org"
hammer content-view list --organization "Example Org"
hammer content-view version list --organization "Example Org" --content-view "RHEL9-Base"
hammer lifecycle-environment list --organization "Example Org"
hammer content-view version promote --help

De laatste opdracht is alleen help. Voer publicatie of promotie uit volgens de instructies voor jouw Satellite-versie en de goedgekeurde releaseselectie. Houd het versienummer vast in automation; alleen een viewnaam selecteren maakt niet zichtbaar welke inhoud je vrijgeeft.

3. Diagnose bij ontbrekende repositories of packages

Begin op Satellite: is de vereiste repository ingeschakeld en succesvol gesynchroniseerd? Zit zij in de gepubliceerde view-versie? Is die versie naar de hostomgeving gepromoveerd? Klopt de contenttoewijzing van de host en is de benodigde content beschikbaar via de gebruikte Capsule? Controleer sync- en publicatietaken op fouten.

# Op de betrokken RHEL-host: inventarisatie, geen repositorywijziging.
sudo subscription-manager identity
sudo subscription-manager repos --list-enabled
sudo dnf repolist --enabled
sudo dnf list --showduplicates openssl
sudo dnf updateinfo list --security
sudo dnf versionlock list

De DNF-versionlockopdracht vereist de plugin. Vergelijk de host met een goed werkende host in dezelfde vrijgegeven contentomgeving. Noteer daarbij repository-ID’s en packageversies; vergelijk niet alleen de hostname of registratiestatus. Een nieuwe activation key beïnvloedt niet automatisch alle al geregistreerde hosts. Verifieer hun huidige toewijzing afzonderlijk.

Een lege of ontbrekende security-erratalijst bewijst op zichzelf niet dat een host veilig is. Controleer of de ingeschakelde repositories erratametadata aanbieden, of filters de inhoud beïnvloeden en of packages uit andere bronnen komen. Als een package zichtbaar is maar niet wordt geïnstalleerd, kijk dan naar excludes, versionlocks, afhankelijkheden en modulaire streams.

4. Pak foutmeldingen per laag aan

Package niet gevonden: vergelijk naam, architectuur, repository en view-versie. TLS of HTTP-fout: onderzoek DNS, tijd, proxy, vertrouwen in de certificaatketen en Capsule-bereikbaarheid. Dependencyconflict: vergelijk de volledige repositoryset en filters. Verouderde metadata: vernieuw de lokale metadata pas nadat is vastgesteld dat Satellite de juiste content aanbiedt.

Bewaar taak-ID’s, foutmeldingen en het tijdvenster. Een blind herhalen van synchronisatie kan de echte oorzaak verbergen en onnodige belasting geven. Deel supportbundels volgens het interne beleid: ze kunnen hostnamen en configuratie bevatten. Pas geen gegenereerde redhat.repo handmatig aan als blijvende oplossing; herstel de registratie-, repository- of contenttoewijzing.

5. Patchmanagement met acceptatie en herstel

Gebruik een canarygroep, daarna applicatiegebonden batches. Controleer na installatie niet alleen de packageversie, maar ook transacties, monitoring en eventuele rebootvereisten. Promotie maakt content beschikbaar; zij installeert geen updates op de hosts. Hostpatching, rebootplanning en applicatieacceptatie blijven afzonderlijke stappen.

Een oudere content view terug aanbieden draait geïnstalleerde packages niet automatisch terug. Package-downgrades, databasewijzigingen en rebootgedrag vragen een eigen herstelplan. Bewaar goedgekeurde contentversies zolang ze nodig zijn voor incidentanalyse of herstel, met aandacht voor storagecapaciteit en een vastgestelde opschoonprocedure.

Enterprise-aandachtspunten en valkuilen

Leg een spoedpad vast voor kritieke errata, met dezelfde identificatie van content en acceptatiebewijs als een gewone release. Zo voorkom je dat ‘spoed’ een permanente bypass wordt. Controleer ook third-party repositories: zonder passende metadata en een eigen onderhoudsafspraak zijn ze geen equivalent van de Red Hat-contentketen.

Bronnen en versiecontrole

Technische referenties geraadpleegd op 30 september 2026. Controleer bij uitvoering de documentatie en manpages van de geïnstalleerde versie.

Satellite 6.17 — content views
Satellite 6.17 — lifecycle environments
Satellite 6.18 — content view environments en releaseverschillen

Gerelateerde artikelen

RHEL 8 naar 9 met Leapp: voorbereiding, lifecycle en migratie
Ansible voor RHEL: idempotent beheer met inventory en roles
Enterprise Linux-beheer: tmp, journald, NFS en versionlock

Ondersteuning bij jouw platform

Wil je deze aanpak vertalen naar jouw omgeving? Bekijk Red Hat Enterprise Linux of neem contact op met DEWOLF.IT.