DNF auf RHEL/CentOS 7 installieren: Ein vollständiger technischer Leitfaden

DNF (Dandified YUM) ist der Paketmanager der nächsten Generation für RPM-basierte Linux-Distributionen, der als vollständiger Ersatz für YUM konzipiert wurde. Er bietet schnellere Abhängigkeitsauflösung durch die `libsolv`-Bibliothek, geringeren Speicherverbrauch und eine stabile Python-API. Während RHEL/CentOS 7 standardmäßig mit YUM ausgeliefert wird, kann DNF vollständig über das EPEL-Repository installiert werden und parallel zu YUM oder als transparenter Ersatz für YUM auf demselben System betrieben werden.

Diese Anleitung führt durch den vollständigen Installationsprozess, erläutert die architektonischen Unterschiede zwischen YUM und DNF, behandelt reale Sonderfälle und bietet eine produktionsreife Befehlsreferenz.

Warum DNF YUM auf RHEL/CentOS 7 übertrifft

Bevor Sie das Terminal öffnen, hilft das Verständnis *warum* das Upgrade sinnvoll ist, eine fundierte Entscheidung zu treffen – insbesondere in einer langfristig betriebenen VPS Hosting-Umgebung, in der die Zuverlässigkeit der Paketverwaltung entscheidend ist.

Grundlegende architektonische Unterschiede

YUM basiert auf einem Python-basierten Abhängigkeitsauflöser, der bei großen Abhängigkeitsbäumen bekannte Leistungsprobleme aufweist. DNF ersetzt diesen Auflöser durch `libsolv`, eine SAT-Solver-basierte Abhängigkeitsauflösungs-Engine, die ursprünglich von SUSE entwickelt wurde. Die praktischen Konsequenzen sind erheblich:

• Geschwindigkeit der Abhängigkeitsauflösung: DNF löst komplexe Abhängigkeitsketten in einem Bruchteil der Zeit auf, die YUM benötigt – besonders merklich bei der Auflösung von Konflikten in großen Paketsätzen.
• Speicherbedarf: YUM lädt vollständige Repository-Metadaten in den Speicher. DNF verwendet Lazy Loading und aggressiveres Caching, was den maximalen RAM-Verbrauch reduziert.
• API-Stabilität: Die Python-API von YUM änderte sich zwischen Nebenversionen unvorhersehbar. DNF stellt eine dokumentierte, versionierte Python-API bereit, auf die Plugin-Autoren sich verlassen können.
• Plugin-Architektur: DNF verwendet ein sauberes Hook-basiertes Plugin-System. YUM-Plugins beeinflussen sich aufgrund loser Kopplung häufig gegenseitig.
• Transaktionsverlauf: DNF pflegt eine umfangreichere Transaktionsverlaufsdatenbank, was Rollbacks und Audits präziser macht.

YUM vs. DNF: Funktionsvergleich

Voraussetzungen

Bestätigen Sie vor dem Fortfahren Folgendes:

• Eine laufende Instanz von RHEL 7 oder CentOS 7 (Bare Metal, VM oder ein Cloud-VPS).
• Root- oder sudo-Zugriff — alle Installationsbefehle erfordern erhöhte Rechte.
• Aktive Internetverbindung — das EPEL-Repository muss erreichbar sein.
• Mindestens 500 MB freier Speicherplatz für DNF, seine Abhängigkeiten und den Repository-Metadaten-Cache.

Wenn Sie eine minimale CentOS 7-Installation auf einem Dedicated Server betreiben, überprüfen Sie, ob `curl` und `wget` verfügbar sind, da sie in abgespeckten Images gelegentlich fehlen.

Schritt 1: Vorhandene Systempakete aktualisieren

Die Synchronisierung Ihrer Paketdatenbank vor der Installation neuer Software verhindert Versionskonflikte und stellt sicher, dass das EPEL-Release-Paket sauber gegen Ihren aktuellen RPM-Datenbankzustand installiert wird.

“`bash

sudo yum update -y

“`

Was dies bewirkt: Lädt alle verfügbaren Updates für aktuell installierte Pakete herunter und wendet sie an, aktualisiert Repository-Metadaten und erstellt die RPM-Transaktionssperre neu. Planen Sie dies auf einem Produktionssystem während eines Wartungsfensters – Kernel-Updates erfordern einen Neustart, um wirksam zu werden.

Sonderfall: Wenn `yum update` mit einem `Multilib version problems`-Fehler fehlschlägt, führen Sie `sudo yum update –setopt=protected_multilib=false -y` als einmalige Problemumgehung aus und untersuchen Sie dann die konfliktierenden Pakete, bevor Sie fortfahren.

Schritt 2: Das EPEL-Repository aktivieren

DNF ist in den Standard-CentOS/RHEL 7-Basis-Repositories nicht verfügbar. Das Extra Packages for Enterprise Linux (EPEL)-Repository, das vom Fedora-Projekt gepflegt wird, stellt es bereit.

“`bash

sudo yum install epel-release -y

“`

Überprüfen Sie, ob das Repository aktiv ist:

“`bash

yum repolist | grep epel

“`

Die erwartete Ausgabe sollte `epel/x86_64` mit einer Paketanzahl größer als null anzeigen (typischerweise 13.000+). Wenn das Repository als deaktiviert erscheint, aktivieren Sie es erzwungen:

“`bash

sudo yum-config-manager –enable epel

“`

Sicherheitshinweis: EPEL-Pakete werden vom Fedora-Infrastrukturteam erstellt und signiert. Das `epel-release`-Paket installiert den GPG-Schlüssel automatisch. Sie können den Schlüssel-Fingerabdruck gegen den offiziellen Fedora-Schlüsselserver verifizieren, bevor Sie Paketen aus diesem Repository vertrauen – ein Schritt, der sich auf gehärteten Produktionssystemen lohnt.

Hinter einem Proxy oder einer Firewall? Wenn Ihr Server die Fedora-Mirrors nicht direkt erreichen kann, konfigurieren Sie `/etc/yum.conf` mit Ihren Proxy-Einstellungen:

“`ini

proxy=http://your-proxy-server:port

proxy_username=user

proxy_password=pass

“`

Schritt 3: DNF installieren

Mit aktivem EPEL installieren Sie DNF und seine Kernabhängigkeiten mit einem einzigen Befehl:

“`bash

sudo yum install dnf -y

“`

Dies zieht `dnf`, `dnf-data`, `python-dnf`, `libcomps`, `librepo` und `libsolv` als automatische Abhängigkeiten ein. Die Gesamtdownloadgröße beträgt typischerweise zwischen 3–8 MB, abhängig davon, was bereits installiert ist.

Was installiert wird:

• `dnf` — die Hauptbinärdatei und Befehlszeilenschnittstelle
• `libsolv` — der SAT-basierte Abhängigkeitsauflöser
• `librepo` — die parallele Download-Bibliothek
• `libcomps` — comps-XML-Parser für Paketgruppen
• `python-dnf` — Python-Bindungen und die DNF-Kernbibliothek

Schritt 4: Die Installation überprüfen

Bestätigen Sie, dass DNF betriebsbereit ist, und überprüfen Sie die Version:

“`bash

dnf –version

“`

Eine erfolgreiche Installation erzeugt eine Ausgabe ähnlich wie:

“`

4.0.9.2

Installed: dnf-0:4.0.9.2-1.el7.noarch at …

Built : CentOS BuildSystem <http://bugs.centos.org> at …

“`

Führen Sie eine tiefere Plausibilitätsprüfung durch, indem Sie die verfügbaren Repositories auflisten, wie sie von DNF gesehen werden:

“`bash

dnf repolist

“`

Die Ausgabe sollte widerspiegeln, was `yum repolist` anzeigt, und bestätigen, dass DNF Ihre bestehende Repository-Konfiguration aus `/etc/yum.repos.d/` korrekt übernommen hat.

Wichtig: DNF auf CentOS 7 liest dieselben Repository-`.repo`-Dateien wie YUM. Es ist keine Repository-Migration erforderlich. Beide Tools teilen sich `/etc/yum.repos.d/` und `/var/cache/` (in separaten Unterverzeichnissen).

Schritt 5: DNF-Befehlsreferenz

DNF ist absichtlich befehlskompatibel mit YUM. Die folgende Tabelle deckt die am häufigsten verwendeten Operationen ab:

DNF-Transaktionsverlauf und Rollback

Dies ist eines der operativ wertvollsten Features von DNF und eines, das YUM schlecht handhabt. Jede Installation, Aktualisierung oder Entfernung wird in `/var/lib/dnf/history/` aufgezeichnet. So prüfen Sie aktuelle Transaktionen:

“`bash

dnf history list

“`

So sehen Sie genau, was sich in einer bestimmten Transaktion geändert hat:

“`bash

dnf history info <transaction-id>

“`

So machen Sie eine Transaktion rückgängig (z. B. Rückgängigmachen eines fehlerhaften Updates):

“`bash

sudo dnf history undo <transaction-id>

“`

Diese Funktion ist besonders nützlich auf einem VPS mit cPanel, wo ein Paket-Update mit Control-Panel-Abhängigkeiten in Konflikt geraten kann.

DNF-Konfigurationsdatei

Die globale Konfiguration von DNF befindet sich unter `/etc/dnf/dnf.conf`. Wichtige Optimierungsparameter für den Produktionseinsatz:

“`ini

[main]

gpgcheck=1

installonly_limit=3

clean_requirements_on_remove=True

best=True

skip_if_unavailable=False

“`

• `installonly_limit=3` — behält nur die letzten 3 Kernel-Versionen und verhindert, dass `/boot` sich füllt.
• `clean_requirements_on_remove=True` — entfernt verwaiste Abhängigkeiten automatisch bei der Paketentfernung.
• `best=True` — installiert immer die neueste verfügbare Version und gibt einen Fehler aus, anstatt stillschweigend ein Downgrade durchzuführen.

Schritt 6: DNF als Standard-Paketmanager konfigurieren

Auf RHEL/CentOS 7 bleibt YUM der Systemstandard. Sie haben zwei Möglichkeiten, DNF als primäre Schnittstelle einzurichten.

Option A: Shell-Alias (Benutzerebene, nicht destruktiv)

Fügen Sie Folgendes zu `~/.bashrc` (für den aktuellen Benutzer) oder `/etc/bashrc` (systemweit) hinzu:

“`bash

alias yum='dnf'

“`

Sofort anwenden:

“`bash

source ~/.bashrc

“`

Einschränkung: Dieser Alias gilt nur für interaktive Shell-Sitzungen. Skripte, die `yum` direkt über ihren absoluten Pfad (`/usr/bin/yum`) aufrufen oder unter anderen Benutzern ausgeführt werden (z. B. Cron-Jobs, systemd-Units), sind nicht betroffen.

Option B: Symbolischer Link (Systemebene)

Für einen umfassenderen Ersatz erstellen Sie einen symbolischen Link, der die `yum`-Binärdatei auf `dnf` umleitet:

“`bash

sudo mv /usr/bin/yum /usr/bin/yum.bak

sudo ln -s /usr/bin/dnf /usr/bin/yum

“`

Kritische Warnung: Dieser Ansatz betrifft alle Benutzer und alle Skripte systemweit. Testen Sie dies gründlich in einer Nicht-Produktionsumgebung. Einige Systemskripte und Drittanbieter-Tools (einschließlich bestimmter cPanel/WHM-Komponenten) rufen `/usr/bin/yum` explizit auf und verhalten sich möglicherweise unerwartet, wenn die Binärdatei ersetzt wird. Sichern Sie immer die Originalbinärdatei wie oben gezeigt.

Option C: DNF als YUM-Plugin (Empfohlen für Server)

Der sauberste Ansatz für Produktionsserver ist es, YUM intakt zu lassen und `dnf` explizit in Ihren eigenen Workflows und Automatisierungsskripten zu verwenden. Dies vermeidet jedes Risiko, System-Tooling zu beschädigen, während Sie vollen Zugriff auf die Fähigkeiten von DNF haben.

Praktische Fallstricke und Sonderfälle

Dies sind Probleme, die in realen Deployments auftreten und in grundlegenden Tutorials selten behandelt werden.

GPG-Schlüsselkonflikte: Wenn Sie Pakete aus mehreren Drittanbieter-Repositories installieren, kann DNFs strengere GPG-Durchsetzung (wenn `gpgcheck=1`) Pakete ablehnen, die YUM zuvor stillschweigend akzeptiert hat. Importieren Sie Repository-GPG-Schlüssel immer explizit mit `sudo rpm –import <key-url>`.

Plugin-Inkompatibilität: Einige YUM-Plugins (z. B. `yum-plugin-fastestmirror`) haben kein direktes DNF-Äquivalent oder verhalten sich anders. DNF hat sein eigenes `fastestmirror`-Plugin (`dnf-plugin-fastestmirror`), aber es ist standardmäßig nicht aktiviert. Installieren Sie es mit `sudo dnf install python3-dnf-plugin-fastestmirror`.

Abweichung des Cache-Speicherorts: YUM cached Metadaten in `/var/cache/yum/`. DNF verwendet `/var/cache/dnf/`. Wenn der Speicherplatz knapp ist, können beide Caches nebeneinander existieren und erheblichen Speicherplatz verbrauchen. Führen Sie `sudo dnf clean all` und `sudo yum clean all` unabhängig voneinander aus, um Speicherplatz freizugeben.

RHEL-Abonnementverwaltung: Auf registrierten RHEL 7-Systemen (im Gegensatz zu CentOS) integriert sich das `subscription-manager`-Plugin mit YUM. DNF auf RHEL 7 honoriert möglicherweise abonnementgeschützte Repositories ohne zusätzliche Konfiguration nicht vollständig. Überprüfen Sie dies mit `subscription-manager repos –list-enabled` nach dem Wechsel.

Python-Versionsempfindlichkeit: DNF auf CentOS 7 verwendet Python 2-Bindungen (`python-dnf`). Wenn Sie auf Ihrem System auf Python 3 aktualisiert haben, stellen Sie sicher, dass Sie nicht versehentlich die `python-dnf`-Abhängigkeitskette beschädigen. DNF 4+ auf RHEL 8+ verwendet Python 3 nativ.

Planung Ihres Migrationspfads über CentOS 7 hinaus

CentOS 7 hat am 30. Juni 2024 das End-of-Life erreicht. Die Installation von DNF ist eine nützliche betriebliche Verbesserung, ändert jedoch nicht die grundlegende Sicherheitslage einer EOL-Distribution. Wenn Sie noch CentOS 7-Workloads betreiben, sollte ein Migrationsplan zu AlmaLinux 8/9, Rocky Linux 8/9 oder RHEL 8/9 auf Ihrer Roadmap stehen. Alle diese Distributionen verwenden DNF nativ, sodass die Vertrautheit, die Sie jetzt aufbauen, direkt übertragbar ist.

Für Teams, die mehrere Dienste auf veralteter Infrastruktur betreiben, können VPS Control Panels die Verwaltung paralleler Umgebungen während eines Migrationsfensters erheblich vereinfachen.

Wenn Ihre Workloads Web-Hosting-Stacks umfassen, ermöglicht die Migration zu einer modernen Distribution auch die vollständige Nutzung der Automatisierung von SSL-Zertifikaten über Certbot und ACME, die auf RHEL 8+ und seinen Derivaten deutlich besser unterstützt wird.

Schnellreferenz-Entscheidungsmatrix

Verwenden Sie diese Checkliste vor und nach der Installation, um ein sauberes, produktionssicheres Setup zu bestätigen:

• [ ] `yum update -y` ohne Fehler abgeschlossen, bevor EPEL installiert wurde
• [ ] EPEL-Repository über `yum repolist | grep epel` als aktiv verifiziert
• [ ] `dnf –version` gibt eine gültige Versionszeichenkette zurück
• [ ] `dnf repolist`-Ausgabe stimmt mit `yum repolist`-Ausgabe überein
• [ ] `/etc/dnf/dnf.conf` überprüft und für Ihre Umgebung optimiert
• [ ] `installonly_limit` gesetzt, um Überfüllung der `/boot`-Partition zu verhindern
• [ ] Entscheidung über Alias vs. Symlink vs. Koexistenzstrategie getroffen
• [ ] YUM-Binärdatei gesichert, wenn der Symlink-Ansatz verwendet wird
• [ ] Cron-Jobs und Automatisierungsskripte auf fest codierte `yum`-Pfade geprüft
• [ ] CentOS 7 EOL-Migrationszeitplan dokumentiert

FAQ

Können DNF und YUM auf demselben CentOS 7-System ohne Konflikte koexistieren?

Ja. Beide Tools lesen aus `/etc/yum.repos.d/` und pflegen separate Cache-Verzeichnisse. Sie teilen sich die RPM-Datenbank (`/var/lib/rpm`), sodass eine von einem Tool abgeschlossene Transaktion sofort für das andere sichtbar ist. Das gleichzeitige Ausführen beider Tools (z. B. zwei gleichzeitige Installationen) führt zu einem RPM-Sperrkonflikt, aber die sequenzielle Nutzung ist vollständig sicher.

Wird die Installation von DNF auf CentOS 7 bestehende YUM-Plugins beschädigen?

Nein. DNF wird als unabhängige Binärdatei installiert und modifiziert die YUM-Installation nicht. Ihre bestehenden YUM-Plugins bleiben intakt. DNF lädt jedoch keine YUM-Plugins – wenn Sie auf bestimmte YUM-Plugins angewiesen sind, müssen Sie deren DNF-Äquivalente separat suchen und installieren.

Unterstützt DNF auf CentOS 7 DNF-Module (Modul-Streams)?

Nein. DNF-Modul-Streams sind ein Feature, das in DNF 4 und RHEL/CentOS 8 eingeführt wurde. Die Version von DNF, die über EPEL für CentOS 7 verfügbar ist, ist DNF 4.x, aber die Unterstützung von Modul-Streams erfordert die AppStream-Repository-Infrastruktur, die auf CentOS 7 nicht existiert.

Warum liefert `dnf update` manchmal andere Ergebnisse als `yum update` auf demselben System?

DNFs `libsolv`-Auflöser wendet eine strengere Abhängigkeitslogik an und kann Versionsauswahlen anders auflösen als YUMs interner Auflöser. In den meisten Fällen ist das Ergebnis identisch, aber in Umgebungen mit komplexen oder konfliktierenden Abhängigkeiten kann DNF andere Paketversionen auswählen oder Transaktionen ablehnen, die YUM stillschweigend zugelassen hätte. Dies ist ein Feature, kein Fehler – das Verhalten von DNF ist vorhersehbarer und prüfbarer.

Ist es sicher, DNF auf einem CentOS 7-Server zu verwenden, der Produktions-Webanwendungen hostet?

Ja, mit dem Vorbehalt, dass Sie den Koexistenzansatz verwenden (YUM intakt lassen, DNF explizit verwenden) anstatt die YUM-Binärdatei zu ersetzen. Überprüfen Sie, ob Control-Panel-Software oder Deployment-Automatisierung auf Ihrem Server keine fest codierten Annahmen über das YUM-Verhalten hat, bevor Sie Ihren primären Workflow auf DNF umstellen.