rpm = RPM Package Manager.
Es ist das Low-Level-Werkzeug zur Verwaltung einzelner .rpm-Dateien in der Red-Hat-Familie — also unter Fedora, RHEL, CentOS Stream, Rocky, AlmaLinux und openSUSE.
In der Debian-Welt ist dpkg das Pendant: Beide arbeiten unterhalb der höheren Paketmanager und kümmern sich um genau ein Paket auf der Festplatte, ohne Repositories zu kennen oder Abhängigkeiten aufzulösen.
Was rpm macht
rpm ist das Basiswerkzeug zur Verwaltung von Paketen in Distributionen der Red-Hat-Familie. Es installiert, entfernt, verifiziert und durchsucht einzelne .rpm-Archive sowie die lokale RPM-Datenbank, in der alle installierten Pakete und ihre Dateien registriert sind.
rpm selbst kennt keine Repositories, lädt nichts aus dem Netz und löst keine Abhängigkeiten auf. Wenn ein Paket andere Pakete benötigt, listet rpm die fehlenden Abhängigkeiten lediglich auf und bricht ab. Für Repository-Operationen mit automatischer Auflösung der Abhängigkeitsketten gibt es dnf (bzw. das ältere yum), die rpm im Hintergrund nutzen.
rpm vs. dnf vs. yum
Im Alltag arbeitest du fast immer mit dnf. Direkt zu rpm greifst du, wenn du eine konkrete .rpm-Datei abfragen oder einzelne Pakete inspizieren willst — und nicht mit dem ganzen Repository-System hantieren möchtest.
| Werkzeug | Ebene | Auflösung von Abhängigkeiten | Repositories | Typischer Einsatz |
|---|---|---|---|---|
| rpm | Low-Level | nein | nein | Einzelne .rpm-Dateien abfragen, verifizieren, im Notfall installieren |
| dnf | High-Level | ja | ja | Tagesgeschäft: installieren, aktualisieren, entfernen, suchen |
| yum | High-Level (Vorgänger) | ja | ja | RHEL/CentOS 7 und älter — auf modernen Systemen ein Symlink auf dnf |
Faustregel: Wenn du eine manuell heruntergeladene .rpm-Datei installieren willst, nimm trotzdem dnf (sudo dnf install ./paket.rpm) — dnf löst dann die Abhängigkeiten aus den Repositories nach. rpm -i springt nur dort ein, wo dnf nicht verfügbar ist (Rescue-System, Container-Build, Kickstart-Skript).
Wichtige Optionen
rpm arbeitet mit Modus-Schaltern: Du wählst einen der Hauptmodi (-i, -U, -e, -q, -V, -K) und kombinierst ihn bei Bedarf mit Sub-Optionen.
| Option | Bedeutung |
|---|---|
-i | Install — installiert ein neues Paket aus einer .rpm-Datei |
-U | Upgrade — aktualisiert ein installiertes Paket oder installiert es neu |
-F | Freshen — aktualisiert nur, wenn das Paket bereits installiert ist |
-e | Erase — entfernt ein installiertes Paket |
-q | Query — fragt die RPM-Datenbank oder eine Paketdatei ab |
-V | Verify — vergleicht installierte Dateien mit den Soll-Werten |
-K | Check Signature — prüft GPG-Signatur und SHA-Hashes einer .rpm-Datei |
Innerhalb des Query-Modus (-q) gibt es weitere Sub-Schalter:
| Query-Modus | Was er liefert |
|---|---|
-qa | Alle installierten Pakete (Liste) |
-qi PAKET | Detail-Info (Version, Lizenz, Beschreibung, Build-Host) |
-ql PAKET | Alle Dateien, die zum Paket gehören |
-qf /pfad/zu/datei | Welches Paket besitzt die angegebene Datei? |
-qp datei.rpm | Query auf eine .rpm-Datei statt auf die Datenbank |
-q --scripts PAKET | Pre-/Post-Install/Uninstall-Skripte des Pakets anzeigen |
-q --changelog PAKET | Changelog des Pakets ausgeben |
Query-Operationen
Die Query-Modi sind der mit Abstand häufigste Einsatzzweck von rpm im Alltag — sie funktionieren rein lesend und sind für Forensik, Debugging und Paket-Recherche unentbehrlich.
Alle installierten Pakete auflisten
rpm -qaLiefert eine vollständige Liste mit Name, Version und Release. Praktisch in Kombination mit grep, etwa rpm -qa | grep kernel.
Detail-Informationen zu einem Paket
rpm -qi httpdZeigt Version, Release, Lizenz, Architektur, Build-Datum, Signatur, Quell-RPM und die vollständige Paketbeschreibung — alles aus der lokalen RPM-Datenbank.
Welche Dateien gehören zum Paket?
rpm -ql httpdListet jeden Pfad, den das Paket auf der Platte angelegt hat — von Binaries über Manpages bis zu Konfigfiles und systemd-Units.
Welches Paket besitzt eine Datei?
rpm -qf /usr/bin/python3Die häufigste Frage in der Praxis: „Woher kommt diese Datei?” rpm -qf durchsucht die RPM-Datenbank und liefert das zuständige Paket inklusive Version.
rpm-Datei prüfen vor Installation
Bevor du ein Drittanbieter-RPM installierst — etwa von einer Hersteller-Website — solltest du es prüfen. Die -qp-Variante hängt sich an eine Datei statt an die Datenbank, -K validiert die Signatur.
Info aus einer .rpm-Datei lesen
rpm -qpi paket.rpmZeigt Name, Version, Vendor, URL, Lizenz und Beschreibung — ohne das Paket zu installieren.
Welche Dateien würde das Paket installieren?
rpm -qpl paket.rpmListet alle Pfade, die das Paket bei der Installation anlegen würde — wichtig, um Konflikte mit bestehenden Dateien frühzeitig zu erkennen.
Signatur und Integrität prüfen
rpm -K paket.rpmPrüft die SHA-Hashes des Headers und der Payload sowie — falls ein passender GPG-Key importiert ist — die Signatur des Vendors. Ausgabe digests signatures OK bedeutet: Datei unverändert, Signatur passt.
Verify
rpm -V PAKET vergleicht jede vom Paket installierte Datei mit den Soll-Werten aus der RPM-Datenbank — also mit Hash, Modus, Eigentümer, Größe und Mtime, wie sie zum Build-Zeitpunkt festgelegt wurden. Veränderte Dateien werden zeilenweise mit einem Code-Präfix gemeldet.
rpm -V httpdEin typischer Output sieht so aus:
S.5....T. c /etc/httpd/conf/httpd.conf
.M....... /usr/sbin/httpdJede Position im Code steht für einen geprüften Aspekt. Ein Punkt heißt „unverändert”, ein Buchstabe markiert eine Abweichung.
| Code | Bedeutung |
|---|---|
S | Size — Dateigröße weicht ab |
M | Mode — Berechtigungen oder Dateityp wurden geändert |
5 | MD5/SHA — Inhalt wurde verändert (Hash stimmt nicht) |
D | Device — Major/Minor-Nummer einer Gerätedatei abweichend |
L | Link — Ziel eines Symlinks geändert |
U | User — Eigentümer ist nicht mehr der ursprüngliche |
G | Group — Gruppe weicht ab |
T | Time — Modification-Time abweichend |
P | Capabilities — POSIX-Capabilities geändert |
c (Spalte 9) | Datei ist als Konfigurationsdatei markiert |
rpm -V ist der klassische Forensik-Befehl nach einem mutmaßlichen Einbruch: Welche System-Binaries wurden manipuliert? Welche Konfigfiles wurden verändert?
Praxis-Patterns
Manuelle .rpm-Datei sauber installieren
Lokale .rpm-Datei mit aufgelösten Abhängigkeiten installieren — der richtige Weg führt nicht über rpm -i, sondern über dnf:
sudo dnf install ./paket.rpmdnf erkennt die lokale Datei am ./-Präfix, liest die Abhängigkeiten aus dem Header und zieht alles Fehlende aus den konfigurierten Repositories nach. Mit rpm -i müsstest du jede Abhängigkeit von Hand auflösen.
Welches Paket gehört zu einer Datei?
rpm -qf /usr/bin/python3Hilft, wenn du wissen willst, woher eine Binary, Bibliothek oder Konfigdatei stammt — Pflichtfrage bei jedem unklaren Logeintrag.
Alle Dateien eines Pakets auflisten
rpm -ql httpdZeigt jeden Pfad, den das Paket installiert hat — nützlich, um Konfigdateien, Manpages oder systemd-Units zu finden.
Wann wurde was installiert?
rpm -qa --last | head--last sortiert die installierten Pakete nach Installationszeitpunkt — die jüngsten zuerst. Praktisch, um nach Updates oder Eingriffen zu schauen, was zuletzt am System geändert wurde.
Veränderte Konfigdateien finden
rpm -V httpd | grep ^..5....T.cFiltert die Verify-Ausgabe auf Konfigdateien (c in Spalte 9), deren Inhalt (5) und Mtime (T) sich geändert haben. So siehst du auf einen Blick, was lokal angepasst wurde — etwa um die Anpassungen vor einem Reinstall zu sichern.
Skripte aus einer .rpm-Datei extrahieren
rpm -qp --scripts paket.rpmListet alle Pre- und Post-Install- sowie Uninstall-Skripte. Pflichtcheck bei Drittanbieter-RPMs: Lies die Skripte, bevor du installierst — hier landen oft kreative Anpassungen am System.
Häufige Stolperfallen
rpm -i installiert ohne Dependencies — fast immer dnf nutzen
Der häufigste Anfängerfehler: Eine heruntergeladene .rpm-Datei mit rpm -i paket.rpm installieren wollen. rpm kennt keine Repositories und löst keine Abhängigkeiten auf. Fehlen Bibliotheken oder Pakete, bricht die Installation mit einer langen Fehlerliste ab. Richtiger Weg: sudo dnf install ./paket.rpm — dnf liest dieselbe Datei, holt aber die Abhängigkeiten aus den Repositories nach. rpm -i ist nur dann angebracht, wenn dnf nicht zur Verfügung steht (Container-Build, Rescue-System, Kickstart-Skript).
rpm -e weigert sich bei Abhängigkeiten — und --nodeps ist gefährlich
Versucht man ein Paket zu entfernen, von dem andere Pakete abhängen, bricht rpm -e mit einer Warnung ab. Der Verlockung, mit rpm -e --nodeps PAKET durchzudrücken, sollte man widerstehen: Abhängige Pakete funktionieren danach nicht mehr, die RPM-Datenbank wird inkonsistent und Folge-Updates können fehlschlagen. Sauberer Weg: sudo dnf remove PAKET — dnf zeigt vorher, welche Pakete mit entfernt werden, und führt die Aktion atomar aus.
RPM-Datenbank kann korrupt werden — rpm --rebuilddb als Notfall
Die RPM-Datenbank (/var/lib/rpm/) ist eine Berkeley-DB bzw. SQLite-Datenbank. Sie kann in seltenen Fällen korrupt werden — typische Symptome sind hängende rpm-Aufrufe, sinnlose Fehlermeldungen oder fehlende Einträge. Als Notfall-Reparatur dient sudo rpm --rebuilddb: Der Befehl baut die Indizes aus den Header-Daten neu auf. Dauert je nach Anzahl installierter Pakete einige Minuten und sollte ohne parallel laufende dnf/rpm-Prozesse erfolgen.
Verify zeigt Drift bei Konfigfiles — meist OK für /etc/...c-Files
rpm -V meldet jede Abweichung — auch erwünschte. Konfigdateien (Spalte 9 mit c) werden vom Admin angepasst und tauchen daher fast immer als verändert auf (S.5....T.c). Das ist kein Sicherheitsproblem, sondern Normalbetrieb. Spannend wird Verify erst dann, wenn unter /usr/bin/, /usr/sbin/ oder /lib/ Dateien als verändert gemeldet werden — also dort, wo eigentlich nichts angefasst werden sollte.
rpm -K NOT OK kann fehlender GPG-Key bedeuten
Die Signaturprüfung mit rpm -K paket.rpm setzt voraus, dass der GPG-Key des Vendors importiert ist. Ist der Key unbekannt, meldet rpm „NOT OK” oder „Header V4 RSA/SHA256 Signature, key ID xxx: NOKEY” — auch bei legitimen Paketen. Bevor du dem RPM misstraust, importiere den passenden Key mit sudo rpm --import KEYFILE (Fedora/RHEL liefern die offiziellen Keys unter /etc/pki/rpm-gpg/). Erst danach ist „NOT OK” wirklich ein Warnsignal.
Relocatable Packages und --prefix sind die Ausnahme
rpm kennt die Option --prefix /eigener/pfad zum Installieren in ein abweichendes Verzeichnis. In der Praxis funktioniert das nur bei Paketen, die der Maintainer explizit als relocatable markiert hat — was extrem selten ist. Bei normalen Paketen wird die Option ignoriert oder schlägt fehl. Wer Software in ein eigenes Präfix legen will, ist mit Containern, Flatpak oder selbst gebauten Tarballs besser bedient.
Source-RPMs (.src.rpm) sind ein anderer Stil — gebaut mit rpmbuild
Eine .src.rpm ist kein installierbares Binär-Paket, sondern ein Build-Rezept: Tarball mit Quellcode plus Spec-Datei plus Patches. Versucht man rpm -i paket.src.rpm, landet das Quellmaterial unter ~/rpmbuild/SOURCES/ und ~/rpmbuild/SPECS/ — installiert wird nichts. Aus einem Source-RPM wird ein Binär-RPM mit rpmbuild --rebuild paket.src.rpm erzeugt. Wer das nicht braucht, lässt Source-RPMs ungeöffnet.
Weiterführende Ressourcen
Externe Quellen
- rpm(8) – Manpage (man7.org) — Offizielle Manpage mit allen Modi und Optionen
- rpm.org – RPM Reference Manual — Dokumentation des RPM-Projekts
- Fedora Packaging Guidelines — Wie Fedora-Pakete gebaut und gepflegt werden
- Red Hat Documentation: Managing software with RPM — RHEL-spezifische Dokumentation zur Paketverwaltung
- openSUSE Wiki: RPM — Praktische Übersicht aus der openSUSE-Welt
Verwandte Artikel
- dnf – Pakete installieren und aktualisieren — Das High-Level-Werkzeug der Red-Hat-Familie
- dpkg – Pendant in der Debian-Welt — Low-Level-Paketverwaltung für
.deb-Dateien - Linux Shell — Grundlagen der Kommandozeile
- Linux Berechtigungen — Dateirechte und sudo
- Linux Verzeichnisstruktur — Wo installierte Pakete im FHS landen