Linux: apt, yum zentral

Im Linux-Universum übernimmt die Paketverwaltung die Rolle, die im Windows-Land WSUS + MECM spielen. Distributions-Pakete enthalten Software und Patches – ein apt upgrade oder dnf update bringt sowohl Sicherheits-Fixes als auch neue Programm-Versionen. Der Vorteil: einheitliches Werkzeug. Der Nachteil: ohne Disziplin wird jedes apt upgrade zu einem Vabanquespiel, weil unbeabsichtigt Major-Version-Sprünge passieren. Diese Lektion zeigt dir die wichtigsten Paketmanager (apt für Debian/Ubuntu, yum/dnf für RHEL-Familie, zypper für SUSE), wie man sie zentral verwaltet – über lokale Mirrors oder Repository-Server wie Red Hat Satellite – und wie man Auto-Patches sicher und kontrolliert betreibt.

1) Die wichtigsten Linux-Paketmanager

Welcher Paketmanager? Hängt von der Distribution ab. Klick einen Tab:

2) Sicherheits-Repos getrennt halten

Ein eleganter Linux-Vorteil: Sicherheits-Updates sind in eigenen Repositorys – getrennt von Feature-Updates. Damit kannst du nur die kritischen Patches ziehen, ohne unbeabsichtigte Funktionsänderungen.

3) Zentrale Mirror-Architektur

Wenn 500 Server jedes apt update direkt aus dem Internet laden, ist das Bandbreiten-Verschwendung. Mit einem lokalen Mirror bzw. internen Repo-Server wird das gleiche Pattern wie bei WSUS umgesetzt:

4) Tools im Überblick

5) Auto-Patches mit unattended-upgrades

Für Linux-Server, die nicht im Cluster laufen, ist automatisches Patchen kritischer Sicherheits-Updates oft sinnvoll – aber nur mit Sorgfalt. Auf Ubuntu/Debian ist das Standard-Tool unattended-upgrades:

6) Konkrete Befehle und Workflows

Praxisrelevante Befehle für apt und dnf:

# ============================================================
# APT (Debian / Ubuntu)
# ============================================================
# Repo-Daten aktualisieren (Metadaten holen)
sudo apt update

# Sehen, was upgegradet werden würde
sudo apt list --upgradable

# Nur Security-Updates (mit unattended-upgrades-Filter)
sudo unattended-upgrade --dry-run -d

# Reguläres Upgrade (mit Bestätigung)
sudo apt upgrade

# Distro-Upgrade (auch Pakete entfernen/hinzufügen, Vorsicht!)
sudo apt dist-upgrade

# Auto-Reboot wenn nötig (z. B. nach Kernel-Update)
sudo [ -f /var/run/reboot-required ] && sudo reboot

# ============================================================
# DNF (RHEL / Rocky / Fedora)
# ============================================================
# Updates checken
sudo dnf check-update

# Nur Security-Updates installieren
sudo dnf update --security

# Alle Updates
sudo dnf upgrade

# Sehen, was passieren würde, ohne zu installieren
sudo dnf upgrade --assumeno

# Nur einen einzelnen Patch
sudo dnf update-minimal --security --advisory=RHSA-2026:0142

# Nach Reboot: was wurde geupdatet?
sudo dnf history

7) Patch-Verteilung mit Ansible

Statt einzeln auf jedem Server zu patchen, läuft ein Ansible-Playbook über alle Hosts. Beispiel:

# Playbook: patch_servers.yml
- name: Security patches rollout
  hosts: pilot_servers
  become: yes
  serial: 5  # 5 Server gleichzeitig
  tasks:
    - name: Update apt cache (Debian/Ubuntu)
      apt:
        update_cache: yes
        cache_valid_time: 3600
      when: ansible_os_family == "Debian"

    - name: Install security updates (Debian/Ubuntu)
      apt:
        upgrade: safe
      when: ansible_os_family == "Debian"

    - name: Install security updates (RHEL)
      dnf:
        name: "*"
        state: latest
        security: yes
      when: ansible_os_family == "RedHat"

    - name: Check if reboot is required
      stat: path: /var/run/reboot-required
      register: reboot_required_file

    - name: Reboot if necessary
      reboot:
        msg: "Reboot wegen Security-Patches"
        reboot_timeout: 600
      when: reboot_required_file.stat.exists

Vorteil gegenüber WSUS: Wiederholbarkeit als Code. Das Playbook ist versioniert, dokumentiert, reviewbar. Mehr in Ansible-Playbooks.

8) Live-Kernel-Patching

Eine Spezialität der Linux-Welt: Kernel-Patches ohne Reboot. Geht über kpatch (Red Hat), livepatch (Ubuntu Pro), kGraft (SUSE). Patches werden im laufenden Kernel angewendet. Sehr nützlich bei Servern mit hohen Verfügbarkeitsanforderungen, die nicht einfach durchgestartet werden können.

9) Antipatterns

• Blindes apt upgrade auf Produktion. Holt alles: Security, Feature-Updates, Major-Versionen. Kann Anwendungen brechen. Lösung: nur --security oder spezifische Pakete.
• Kein lokaler Mirror. 500 Server downloaden jedes Update aus dem Internet = Bandbreiten-Verschwendung + Single Point of Failure (was, wenn Internet weg?).
• Snapshots nie pflegen. Frozen Repo bleibt 5 Jahre stehen, keine Security-Updates mehr. Lösung: regelmäßige Mirror-Refresh-Termine.
• Reboot „später" – nie. Kernel-Patch installiert, aber Server läuft mit altem Kernel weiter. Tool zeigt Patch installiert, real ist die Lücke offen. Lösung: planmäßige Reboot-Fenster oder Live-Kernel-Patching.
• Repo-Server nicht patchen. Der Mirror selbst läuft auf einem Linux-Server – auch der braucht Patches. Sonst wird der Patch-Verteiler zur Schwachstelle.
• Repository-GPG-Keys ignorieren. Wenn die Signatur-Prüfung deaktiviert ist, kann jeder Pakete in den Mirror schieben (Supply-Chain-Angriff). GPG-Keys aktiv halten.

Zusammenfassung

Linux nutzt Paketmanager für Patch-Management: apt (Debian/Ubuntu), dnf/yum (RHEL/Fedora/Rocky), zypper (SUSE). Distros haben oft getrennte Security-Repos – apt-get -t bookworm-security upgrade bzw. dnf update --security – die nur kritische Patches ziehen, ohne Feature-Updates. Zentrale Verwaltung über lokale Mirrors: apt-mirror/aptly (Open Source), Pulp, Red Hat Satellite (kommerziell), SUSE Manager/Uyuni, Foreman. Repo-Snapshots ermöglichen Wellen-Rollout: Test → Staging → Prod zeigen auf verschiedene Zeit-Snapshots. Auto-Patches mit unattended-upgrades (Debian) bzw. dnf-automatic (RHEL) – nur Security empfohlen, mit definiertem Reboot-Fenster. Ansible-Playbooks als Code-basierte Patch-Verteilung. Live-Kernel-Patching für Reboot-freie Kernel-Updates (kpatch, livepatch, kGraft). Antipatterns: blindes apt upgrade, fehlender Mirror, nie aktualisierte Snapshots, ausstehende Reboots, fehlende GPG-Signatur-Prüfung.

Verwandte Lektionen: Linux-Paketverwaltung · WSUS · Ansible · und mehrWeitere relevante LektionenPatch-Management-ProzessCVE/CVSSsystemd-DiensteTest vs. ProduktivRollbackCI/CDChange Management