# Red Hat Satellite: Das Kontrollzentrum für Enterprise-Linux

TL;DR / Management Summary Wer mehr als 100 RHEL-Server verwaltet, kommt an Red Hat Satellite (basierend auf Foreman/Katello) nicht vorbei. Es ist die zentrale Instanz für das Lifecycle-Management: Es spiegelt Red Hat Repositories lokal, verwaltet Patch-Stände über Umgebungen hinweg (Dev -> Test -> Prod) und ermöglicht die automatisierte Provisionierung von Bare-Metal und VMs. Satellite stellt sicher, dass kein Server “aus der Reihe tanzt” (Configuration Drift).

# 1. Einführung & Architektur

Die Schaltzentrale.

Satellite trennt die Außenwelt vom internen Rechenzentrum. Nur der Satellite-Server lädt Updates von Red Hat herunter.

# Die Architektur (Mermaid)

graph TD
    A[Red Hat CDN] -->|Sync| B[Satellite Server]
    B --> C[Capsule Server: Site A]
    B --> D[Capsule Server: Site B]
    subgraph "Managed Infrastructure"
        C --> E[RHEL Host 1]
        C --> F[RHEL Host 2]
        D --> G[RHEL Host 3]
    end
    H[Admin Web UI / API] --> B

• Satellite Server: Zentrale Datenbank, Web-GUI, Content-Management.
• Capsule Server: Lokale Proxy-Instanz für entfernte Standorte (DHCP, TFTP, Repo-Mirror).

# 2. Content Views: Patching mit Plan

Weg vom ‘dnf update’ Glücksspiel.

In Satellite nutzen wir Content Views, um den Software-Stand einzufrieren.

• Dev-Umgebung: Bekommt die neuesten Patches sofort.
• Prod-Umgebung: Bekommt den Stand von Dev erst 2 Wochen später, nachdem Tests erfolgreich waren.

# Der Lifecycle-Flow

Library (Red Hat) -> Content View Version 1.0 -> Environment: Development -> Environment: QA -> Environment: Production.

# 3. Provisionierung: Bare Metal & Cloud

Server auf Knopfdruck.

Satellite integriert PXE, DHCP und DNS.

1. Host-Discovery: Ein neuer Server bootet vom Netz und meldet sich beim Satellite.
2. Provisionierung: Satellite spielt via Kickstart (siehe Artikel 062) das OS auf.
3. Config: Ansible (integriert in Satellite) konfiguriert die Applikation.

# 4. Day-2 Operations: Erratas & Compliance

Sicherheit im Blick.

# Errata Management

Satellite zeigt Ihnen genau an, welche Server von einer Sicherheitslücke (CVE) betroffen sind und stellt das passende Update bereit.

• Security Erratas (Bug-Symbol): Kritische Fixes.
• Bugfix Erratas: Stabilitäts-Verbesserungen.

# OpenSCAP Scans

Führen Sie Compliance-Scans (z.B. PCI-DSS) direkt über die Satellite-GUI auf allen Servern aus und lassen Sie sich Berichte generieren.

# 5. Troubleshooting & “War Stories”

Wenn die Schaltzentrale hinkt.

# Story 1: “Der volle Pulp-Speicher”

Symptom: Satellite kann keine Repositories mehr synchronisieren. Ursache: Das Verzeichnis /var/lib/pulp ist voll. Satellite speichert dort alle Pakete und deren Versionen. Lösung: Nutzen Sie foreman-maintain content cleanup, um alte, nicht mehr genutzte Paketversionen zu löschen. Planen Sie für /var/lib/pulp mindestens 500GB bis 1TB ein.

# Story 2: “Synchronisations-Hänger”

Symptom: Ein Capsule-Server liefert veraltete Pakete aus, obwohl der Hauptserver aktuell ist. Ursache: Der Sync-Task zwischen Satellite und Capsule ist fehlgeschlagen (oft Zertifikats- oder Zeit-Probleme). Lösung: Prüfen Sie den Status via foreman-maintain service status. Stellen Sie sicher, dass die Uhren via NTP synchron laufen!

# 6. Fazit & Empfehlung

• Skalierung: Satellite lohnt sich ab ca. 50-100 Instanzen. Darunter ist der Wartungsaufwand für Satellite selbst oft zu hoch.
• Ansible: Nutzen Sie die tiefe Integration. Satellite kann Playbooks automatisch auf Hosts ausführen, wenn bestimmte Ereignisse eintreten.
• Wahl: Wer eine Open-Source Alternative ohne Red Hat Support sucht, sollte sich Orbeos oder das reine Foreman Projekt ansehen.

# Anhang: Cheatsheet