Pakete und Updates: Transaktion, Drift und Rückweg

Ein Update ersetzt nicht einfach eine Datei. Es zieht andere Pakete mit, tauscht Bibliotheken aus, an denen fremde Dienste hängen — und entscheidet nebenbei darüber, was mit den Konfigurationsdateien passiert, die du von Hand angepasst hast. Manchmal bleibt deine Fassung stehen, manchmal wird sie ersetzt, und in beiden Fällen sagt dir das niemand. Dieses Modul zeigt dir, was vor der Ausführung auf dem Bildschirm steht und wie du es liest, woran du erkennst, dass eine Anpassung verloren gegangen ist, und wie du den Rückweg klärst, bevor du ihn brauchst.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-03

Ein Update kopiert nicht einfach eine neue Datei

Wenn du ein Paket aktualisierst, passiert mehr, als dass eine Datei ersetzt wird. Der Paketmanager stellt eine Transaktion zusammen: welche weiteren Pakete mitkommen müssen, welche Bibliotheken sich dabei ändern, was danach neu gestartet gehört. Und er entscheidet, was mit den Konfigurationsdateien passiert, die du von Hand angepasst hast.

Transaktion — Die vollständige Liste aller Änderungen, die der Paketmanager gemeinsam ausführt — Installieren, Aktualisieren, Ersetzen, Entfernen. Sie wird dir vor der Ausführung angezeigt und ist die eigentliche Entscheidungsgrundlage.

Genau diese Anzeige überspringen die meisten. Sie ist aber der einzige Moment, in dem du siehst, was gleich passiert — und der letzte, in dem du kostenlos abbrechen kannst.

Vier Größen hinter jedem Update

Herkunft: Aus welchem Repository das Paket kommt und ob dessen Signatur geprüft wurde.
Transaktion: Was insgesamt mitkommt: Abhängigkeiten, ersetzte Pakete, nötige Neustarts.
Konfigurationsdrift: Was mit deinen lokalen Anpassungen geschieht, wenn das Paket eine neue Vorlage mitbringt.
Rückweg: Wie du zurückkommst, wenn der Dienst danach nicht mehr das tut, was er soll.

Die dritte Größe ist die, die im Betrieb am häufigsten stillschweigend schiefgeht — deshalb bekommt sie unten einen eigenen Abschnitt.

Woher ein Paket kommt und warum du ihm glaubst

Bevor irgendetwas installiert wird, steht eine Vertrauensfrage. Ein Paket kommt aus einem Repository — einer Sammlung von Paketen samt einem Verzeichnis darüber, das sagt, welche Versionen es gibt und was sie voneinander brauchen.

Repository — Eine konfigurierte Bezugsquelle für Pakete. Auf dem System steht pro Quelle eine Datei mit Adresse, Zustand und den Regeln, nach denen ihre Inhalte geprüft werden — nicht das Paket selbst wird eingerichtet, sondern die Quelle.

Dass eine Datei über eine verschlüsselte Verbindung geladen wurde, sagt nur, dass unterwegs niemand mitgelesen hat. Es sagt nichts darüber, ob der Server am anderen Ende das ausliefert, was die Distribution gebaut hat. Diese zweite Frage beantwortet die Signaturprüfung: Der Herausgeber signiert seine Pakete, das System kennt seinen öffentlichen Schlüssel und rechnet vor der Installation nach.

Warum das Abschalten so verlockend istDie Signaturprüfung meldet sich fast nur dann, wenn etwas nicht stimmt — ein fehlender Schlüssel, eine falsch gebaute Quelle, ein Paket aus zweiter Hand. Sie zu deaktivieren löst die Meldung sofort auf und verschiebt genau die Kontrolle, wegen der man sie eingebaut hat. Der richtige Weg ist, den fehlenden Schlüssel zu beschaffen und zu prüfen, nicht die Frage zu unterdrücken.

Damit hängt eine zweite Entscheidung zusammen: Fremdquellen. Ein zusätzliches Repository bringt oft genau die Version, die gerade gebraucht wird. Es bringt aber auch Pakete mit, die dieselben Namen tragen wie die der Distribution — und ab dann entscheidet die Reihenfolge, welche Fassung du bekommst. Ein System, dessen Kernpakete unbemerkt aus einer Fremdquelle stammen, ist von deren Pflege abhängig geworden.

Distributionsquelle: Wird über die Lebensdauer der Version gepflegt, Sicherheitskorrekturen kommen zurückportiert. Träge, dafür berechenbar.
Fremdquelle: Liefert Neueres, oft schneller. Pflege, Signatur und Zurückportierung hängen an einem Dritten — und werden selten mitgeplant.

Den Plan lesen, bevor du ihn ausführst

Vor der Ausführung listet der Paketmanager auf, was er vorhat. Interessant sind drei Dinge darin: Kommen weitere Pakete mit, die du nicht angefragt hast? Wird eine gemeinsam genutzte Bibliothek ersetzt, an der andere Dienste hängen? Und muss danach etwas neu gestartet werden, das gerade Kundenlast trägt?

Ein Sicherheitsupdate ist dabei kein Sonderfall, der diese Prüfung überflüssig macht — es ist nur ein Update mit höherer Dringlichkeit. Die Frage ist nie „patchen oder nicht“, sondern in welchem Tempo und mit welcher Absicherung.

MerksatzEin Paketmanager fragt „darf ich?“, nicht „ist das eine gute Idee?“. Die zweite Frage beantwortest du.

Für die Vorbereitung gibt es zwei nützliche Werkzeuge. Eine Prüfung auf verfügbare Aktualisierungen läuft ohne Rückfrage und ohne etwas zu verändern — sie eignet sich damit für Berichte und für die Planung. Und Aktualisierungen lassen sich auf sicherheitsrelevante einschränken, wenn ein System nicht jede Änderung mitnehmen soll: Dann werden nur die Pakete einbezogen, die eine Sicherheitskorrektur enthalten.

Das ist die praktische Antwort auf den Zielkonflikt zwischen Stabilität und Sicherheit. Statt „alles oder nichts“ lässt sich der laufende Betrieb auf Sicherheitskorrekturen begrenzen und der Rest in ein Wartungsfenster verschieben — zwei Geschwindigkeiten auf demselben System, bewusst gewählt.

Nach dem Update: wer benutzt noch die alte Fassung?

Eine aktualisierte Datei auf der Platte heißt nicht, dass die Korrektur wirkt. Ein Prozess, der eine Bibliothek beim Start geladen hat, benutzt weiterhin die alte — genau wie eine gelöschte Datei so lange existiert, wie jemand sie offen hat. Nach dem Austausch einer Bibliothek läuft der Dienst also unverändert mit dem alten Code weiter.

Die stille LückeGenau hier entsteht die gefährlichste Sorte Fehlannahme: Das Update ist eingespielt, das Berichtswerkzeug meldet die Schwachstelle als behoben — und der verwundbare Code läuft weiter im Speicher, bis irgendwann jemand neu startet. Der Bericht schaut auf die Paketversion, nicht auf die laufenden Prozesse.

Deshalb gehört zum Update eine dritte Frage neben „was kommt mit“ und „was passiert mit meiner Konfiguration“: wer muss neu starten. Es gibt Werkzeuge, die genau das beantworten — sie vergleichen die laufenden Prozesse mit dem, was seit ihrem Start aktualisiert wurde, und melden zusätzlich, ob ein vollständiger Neustart des Systems nötig ist.

Ein Kernel-Update ist dabei der klare Fall: Der laufende Kernel lässt sich nicht im Betrieb austauschen. Bis zum Neustart läuft das System auf dem alten, egal was installiert ist. Alles andere ist eine Abwägung zwischen der Dauer der Lücke und der Unterbrechung durch den Neustart — aber diese Abwägung sollte bewusst getroffen werden, nicht vergessen.

Was mit deiner angepassten Konfigurationsdatei passiert

Hier liegt die Falle, die man erst Wochen später bemerkt. Ein Paket bringt eine Konfigurationsvorlage mit. Du hast die Datei lokal angepasst — Endpunkte, Zertifikatspfade, Grenzwerte. Beim Update ändert sich auch die Vorlage. Was jetzt geschieht, hängt davon ab, wie das Paket die Datei markiert hat.

Auf RPM-Systemen gibt es dafür zwei Markierungen, und sie führen zu entgegengesetzten Ergebnissen:

%config(noreplace): Deine Datei bleibt, wie sie ist. Die neue Vorlage landet daneben als .rpmnew. Du behältst den Betrieb — und übersiehst neue Optionen, wenn du nicht hinschaust.
%config: Die neue Vorlage wird installiert, deine Fassung daneben gesichert als .rpmsave. Du bekommst die Neuerungen — und verlierst deine Anpassung aus der aktiven Datei.

WichtigBeide Dateien entstehen nur, wenn zwei Dinge gleichzeitig zutreffen: Das Paket hat die Vorlage geändert und du hast die Datei lokal angepasst. Hast du nichts geändert, wird still ersetzt und du siehst gar nichts. Eine .rpmnew oder .rpmsave neben einer Konfiguration ist deshalb immer ein Hinweis auf eine offene Entscheidung, nicht auf ein Problem.

Auf Debian-Systemen heißt derselbe Mechanismus anders: Dort fragt dpkg bei einem Konflikt nach. Läuft das Update unbeaufsichtigt, entscheidet eine der --force-conf…-Optionen — --force-confold behält deine Fassung, --force-confnew nimmt die neue. Die jeweils andere Fassung wird als .dpkg-dist beziehungsweise .dpkg-old daneben abgelegt.

Drift finden, bevor sie dich findet

Nach dem Update: hat die Konfiguration überlebt?

Szenario

Ein Webserver wurde aktualisiert. Er läuft, antwortet und wirkt unauffällig. Vor dem Update war die Konfiguration lokal angepasst.

Anforderungen

Feststellen, ob eine Entscheidung offen geblieben ist
Die aktive Datei gegen die neue Vorlage vergleichen, nicht raten
Das Ergebnis so ablegen, dass es beim nächsten Update nicht wieder passiert

Schritte

Im Konfigurationsverzeichnis nach Dateien mit den Endungen .rpmnew, .rpmsave, .dpkg-dist und .dpkg-old suchen — jede davon markiert eine offene Entscheidung.
Die aktive Datei gegen die danebenliegende Fassung vergleichen und die Unterschiede einzeln bewerten: eigene Anpassung, neue Option oder sicherheitsrelevante Änderung?
Die beabsichtigte Fassung bewusst zusammenführen — nicht die eine Datei über die andere kopieren.
Den Dienst nach der Zusammenführung explizit prüfen, statt anzunehmen, dass „läuft noch“ auch „liest die richtige Konfiguration“ bedeutet.
Die zusammengeführte Fassung in die Versionsverwaltung oder Konfigurationsverwaltung zurückspielen.

Merksatz: „Der Dienst läuft“ ist kein Beleg dafür, dass er deine Konfiguration benutzt. Die übrig gebliebene Datei daneben ist der Beleg für das Gegenteil.

Zwei Dinge, die beide „Upgrade“ heißen

Im Alltag werden zwei völlig verschiedene Vorgänge mit demselben Wort bezeichnet, und die Verwechslung ist teuer.

Paket-Update innerhalb einer Release: Neuere Fassungen derselben Distributionsversion. Schnittstellen bleiben stabil, Sicherheitskorrekturen werden in die vorhandene Version zurückportiert. Der Normalfall, Wochen für Wochen.
Release-Upgrade: Wechsel auf die nächste Distributionsversion. Bibliotheken springen auf neue Hauptversionen, Voreinstellungen ändern sich, Konfigurationsformate können brechen. Ein Projekt, kein Wartungsschritt.

Der entscheidende Unterschied liegt in der Erwartung an die Rückwärtskompatibilität. Innerhalb einer Release ist sie eine Zusage der Distribution — deshalb kann man dort automatisieren. Beim Release-Wechsel ist sie keine Zusage mehr, sondern eine Prüfaufgabe: Jede eigene Anwendung, jede angepasste Konfiguration und jede Fremdquelle muss vorher gegen die neue Version gehalten werden.

Woran man die Verwechslung merktWenn ein „normales Update“ plötzlich hunderte Pakete austauschen will, ist es keines. Genau an dieser Stelle ist der Transaktionsplan kein Formalismus mehr, sondern das Signal, das den Unterschied sichtbar macht — vorausgesetzt, jemand liest ihn.

Dazu kommt die Lebensdauer. Jede Distributionsversion wird nur eine begrenzte Zeit mit Sicherheitskorrekturen versorgt. Ein System, das nicht rechtzeitig auf eine unterstützte Version gehoben wird, bekommt irgendwann keine Korrekturen mehr — und das merkt man nicht an einer Fehlermeldung, sondern daran, dass nichts mehr kommt. Diese Frist gehört in die Planung, lange bevor sie erreicht ist.

Wenn ein Paket nicht mitkommen darf

Manchmal darf ein bestimmtes Paket nicht aktualisiert werden — eine Anwendung ist für genau diese Version zertifiziert, ein Treiber verträgt den neuen Kernel nicht, ein Fehler in der neuen Fassung ist bekannt. Dafür gibt es das Zurückhalten: Das Paket wird von Aktualisierungen ausgenommen und bleibt auf seinem Stand.

Das ist ein legitimes Werkzeug, und es ist eine Schuld. Ein zurückgehaltenes Paket bekommt auch keine Sicherheitskorrekturen mehr. Und weil andere Pakete Abhängigkeiten auf es haben, blockiert es mit der Zeit deren Aktualisierung gleich mit — der Rückstand wächst also nicht linear, sondern breitet sich aus.

Was Zurückhalten löst: Ein bekanntes Problem mit einer bestimmten Version trifft dich nicht. Sofort wirksam, ohne Ausfall.
Was es kostet: Keine Sicherheitskorrekturen mehr für dieses Paket, wachsende Blockade seiner Abhängigen, und ein Zustand, den niemand mehr erklären kann, wenn er nicht dokumentiert ist.

Die Regel dazuEin Zurückhalten ohne Ablaufdatum und ohne benannten Verantwortlichen ist keine Entscheidung, sondern ein vergessener Zettel. Es gehören immer drei Dinge dazu: der Grund, die Bedingung für das Ende, und wer das prüft.

Verwandt damit ist die Frage, ob Updates überhaupt unbeaufsichtigt laufen sollen. Beides sind vertretbare Wege — automatisch für Sicherheitskorrekturen auf gut überwachten Systemen, manuell für alles, dessen Ausfall teuer ist. Die schlechte Variante ist die dritte: unbeaufsichtigt laufen lassen und niemanden benennen, der die Ergebnisse ansieht.

Prüfen statt hoffen: hat das Update getan, was es sollte?

Nach dem Lauf steht die Frage, ob der Zielzustand erreicht ist — und die beantwortet weder der Exitcode des Paketmanagers noch ein laufender Prozess. Drei Prüfungen zusammen ergeben eine belastbare Aussage.

Version: Ist die erwartete Version wirklich installiert? Die einfachste und am häufigsten übersprungene Prüfung.
Dateizustand: RPM kann installierte Dateien gegen die Angaben des Pakets prüfen und meldet Abweichungen bei Inhalt, Rechten und Eigentümer — nützlich, um lokale Änderungen an Paketdateien überhaupt zu finden.
Funktion: Tut der Dienst fachlich das, wofür er da ist? Ein Prozess, der läuft, ist dafür kein Beleg.

Die zweite Prüfung ist die überraschendste. Sie deckt Fälle auf, in denen jemand eine Datei, die zu einem Paket gehört, direkt bearbeitet hat — statt über die vorgesehene Konfiguration. Solche Änderungen überleben kein Update, und niemand erinnert sich später daran, sie gemacht zu haben.

Der Rückweg gehört vor die Ausführung

Bevor du ein Update auf einem wichtigen System ausführst, sollte die Antwort auf „und wenn es schiefgeht?“ schon feststehen. Auf RPM-Systemen führt dnf ein Protokoll aller Transaktionen; über dnf history siehst du sie, und dnf history undo kehrt die Operationen einer Transaktion um.

Was ein Rollback nicht kannEin zurückgedrehtes Paket stellt Dateien wieder her, keine Datenbank-Schemata, keine migrierten Datenformate und keine Konfiguration, die du zwischenzeitlich zusammengeführt hast. Für alles, was ein Dienst beim ersten Start nach dem Update verändert hat, ist die Sicherung der Rückweg — nicht der Paketmanager.

Kurzcheck

Nach einem Update liegt neben /etc/app/app.conf eine neue Datei app.conf.rpmnew. Der Dienst läuft normal. Was bedeutet das?

Deine angepasste Datei ist noch aktiv, das Paket hat aber eine geänderte Vorlage mitgebracht, die du noch bewerten musst.
Das Update ist an dieser Datei gescheitert und muss wiederholt werden, bevor der Dienst korrekt arbeitet.
Deine Anpassungen wurden überschrieben; .rpmnew ist die Sicherungskopie deiner alten Fassung.

Treffer. Genau. .rpmnew heißt: Die Datei war als noreplace markiert, deine Fassung blieb stehen. Was in der neuen Vorlage steckt — neue Optionen, geänderte Voreinstellungen, Sicherheitsanpassungen —, hast du damit noch nicht gesehen.

Die Reihenfolge, die ein Update kontrollierbar macht

Transaktionsplan lesen: Abhängigkeiten, ersetzte Bibliotheken, nötige Neustarts→Rückweg klären, bevor etwas ausgeführt wird→Auf einer kleinen Kohorte ausführen statt auf der ganzen Flotte→Konfigurationsdrift suchen und bewusst zusammenführen→Dienstfunktion prüfen, nicht nur den Prozessstatus

Der teuerste Fehler in dieser Kette ist nicht das fehlerhafte Paket — den merkt man sofort. Es ist die stillschweigend verlorene Konfiguration, die erst beim nächsten Neustart auffällt, Wochen später, wenn niemand mehr an das Update denkt.

Was du mitnehmen solltestVier Sätze tragen dieses Modul. Ein Update ist eine Transaktion, keine Dateikopie — und die Anzeige davor ist die letzte kostenlose Abbruchmöglichkeit. Verschlüsselung ist keine Signatur: Die eine schützt den Weg, die andere den Inhalt. Eine Datei auf der Platte ist kein laufender Code — bis zum Neustart benutzt der Dienst weiter die alte Fassung. Und eine Ausnahme ohne Ablaufdatum ist keine Entscheidung, sondern ein Zustand, dessen Kosten im Stillen wachsen.

Wenn du nur eine Gewohnheit aus diesem Modul mitnimmst, dann diese: nach jedem Update im Konfigurationsverzeichnis nachsehen, ob dort eine Datei mit einer der Hinweisendungen liegt. Es kostet zehn Sekunden und ist der einzige Zeitpunkt, zu dem die verlorene Anpassung noch billig zu finden ist.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität9 Primärquellen · zuletzt geprüft: 2026-09-03