Warum verschwinden frühere Versionen von Debian-Paketen in den Paket-Repositories? (sehr relevant für versionskontrollierte Systemkonfiguration)


38

Szenario: In einer versionsgesteuerten Systemkonfiguration basierend auf Puppet, Chef usw. muss ein bestimmter Systemstatus reproduziert werden. Dies erfolgt durch explizite Angabe von Systempaketversionen.

Kürzlich stießen wir auf ein Problem, bei dem bestimmte Paketversionen in den Debian-Repositories fehlten. Ein Beispiel: Das "Patch" -Paket war in Version 2.7.5-1 + deb9u1 erforderlich, aber nur 2.7.5-1 + deb9u2 war verfügbar. Ein weiteres, noch schwerwiegenderes Beispiel: "linux-headers-4.9.0-9-common" ist erforderlich (da der zugehörige Kernel installiert ist) und nur "linux-headers-4.9.0-11-common" ist verfügbar.

Dies macht es unmöglich, einen bestimmten Zustand eines Systems zu reproduzieren.

Die obigen Pakete sind nur Beispiele (auf die ich tatsächlich gestoßen bin). Ich bin daran interessiert, das allgemeine Problem zu verstehen und zu lösen.

Welche Idee steckt hinter diesen Updates, verschwindenden Paketen und Paketversionen?

Wo kann ich frühere Versionen (nicht wirklich alte Versionen, aber Versionen, die ein paar Wochen alt sind) von Debian-Paketen bekommen? Es sollte möglich sein, den Installationsprozess allgemein zu automatisieren.


1
Dies hängt in gewisser Weise von der Software ab, die zur Konfiguration des Repositorys verwendet wird. Reprepro, iirc, erlaubt nur eine einzige Version jedes Pakets
muru

2
stablebleibt konsistent, zumindest bis zur nächsten Punktveröffentlichung. stable-updates, testing und unstable enthalten nur die neueste Version eines bestimmten Pakets. Für alles andere, werden Sie auf suchen, um archive.debian.org (oder snapshot.debian.org wie in SK Antwort erwähnt)
cas

5
Gibt es einen Grund, warum Sie kein eigenes Repo betreiben, auf dem Sie Ersatzrichtlinien und PIN-Versionen steuern können (was den Vorteil hat, dass zukünftige automatische Installationen lokal erfolgen)?
Eric Towers

2
Der neue linuxPaketname ist eine Ausnahme: Im Allgemeinen haben die Pakete von Debian Stable denselben Paketnamen und ändern nur die Versionsnummer. linux-image-amd64ändert nie den Namen und hängt immer vom neuesten ab linux-image-4.9.0-*. Der neue linux-image-4.9.0-*pkg-Name markiert die inkompatiblen Kernel-ABI-Änderungen, die für das Backportieren einiger Bugfixes erforderlich sind, und ermöglicht die erforderliche Neukompilierung von benutzerdefinierten Modulen (dkms usw.). Ähnliches gilt für linux-headers-*.
Ignis

1
Was ist die Idee hinter diesen Updates apt-get changelog packagename
Ignis

Antworten:


64

Es ist Ihre Anforderung, ein bestimmtes Setup bis auf die genaue Version zu reproduzieren , nicht Debians.

Debian unterstützt nur eine einzige Version jedes Binärpakets in einer bestimmten Version. Das Gegenstück dazu ist, dass sehr darauf geachtet wird, dass Paketaktualisierungen in einer bestimmten Version keine Regressionen hervorrufen, und dass, wenn eine solche Sorgfalt nicht möglich ist, diese Tatsache dokumentiert wird. Das Beibehalten mehrerer Versionen eines bestimmten Pakets würde nur den Supportaufwand und die Testanforderungen erhöhen: Beispielsweise müssten Paketbetreuer aktualisierte Pakete anhand aller verfügbaren Versionen der von ihnen verwendeten Bibliotheken testen, anstatt nur der derzeit unterstützten Versionen ... Pakete werden nur dann in einer stabilen Version aktualisiert, wenn dies wirklich notwendig ist, d. HBeheben eines schwerwiegenden Fehlers (einschließlich Sicherheitsproblemen). Im Fall des Kernels bedeutet dies manchmal, dass sich die Kernel-ABI ändert und sich der Paketname infolgedessen ändert (um die Neuerstellung abhängiger Pakete zu erzwingen). gibt es Meta-Pakete , die Sie in anstelle von Hartcodierung der ABI ziehen können ( linux-image-amd64, linux-headers-amd64usw.).

Es gibt jedoch eine Problemumgehung für Ihre Situation: Jede veröffentlichte Quelle und jedes veröffentlichte Binärpaket werden auf snapshot.debian.org archiviert . Wenn Sie ein versioniertes Setup erstellen, können Sie den entsprechenden Snapshot (z. B. einen der Snapshots vom September 2019 ) auswählen und diesen als Repository-URL verwenden:

deb https://snapshot.debian.org/archive/debian/20190930T084755Z/ buster main

Wenn Sie sich darauf verlassen, verwenden Sie bitte einen Cache-Spiegel, zum Beispiel Apt-Cacher NG . Dies reduziert nicht nur die Belastung des Snapshot-Servers, sondern stellt auch sicher, dass Sie eine lokale Kopie aller benötigten Pakete haben.

(Die Situation in Bezug auf die Source - Pakete ist etwas komplexer, und die Archive zu tun tragen mehrere Versionen einiger Quellpakete in einem bestimmten Release, aufgrund von Abhängigkeiten Lizenzierung. Aber das ist hier nicht relevant. Genau genommen bietet Debian mehrere Versionen einiger liefern Binärdateien in unterstützten Releases: Die aktuelle Version im aktuellen Point Release sowie etwaige Aktualisierungen in den Sicherheits-Repositorys und Update-Repositorys werden beim nächsten Point Release eingeklappt, sodass eine reproduzierbare, versionskontrollierte Systemkonfiguration ohne Weiteres möglich ist auf Schnappschüsse zurückgreifen, solange Sie diese bei jeder Veröffentlichung aktualisieren.)


Beachten Sie, dass manchmal einige frühere Versionen verfügbar sind. apt-cache madison packagenameDiese zeigen alle Versionen an, aptdie über konfigurierte Repositorys angezeigt werden.
Ivanivan

5
(Bitte überlasten Sie die Snapshot- / Archivserver nicht unnötig, indem Sie sie anstelle eines in der Nähe befindlichen Spiegels verwenden. Lassen Sie also Ihren normalen Spiegel in Ihrer sources.list mit höherer Priorität als den von Snapshots, damit noch verfügbare Pakete auf diese Weise abgerufen werden können .)
Peter Cordes

3
Nur um zu überprüfen, ob ich es richtig verstanden habe: In der Praxis geht es nicht um die Versionen, die ich bei der Installation von Paketen angegeben habe (da ältere Versionen möglicherweise nicht verfügbar sind), sondern um den Status der von mir verwendeten Paketablage (n). Wenn ich also ein 'frisches' Debian 9.8 möchte, brauche ich das Paket-Repository in genau diesem Zustand (z. B. einen Schnappschuss oder ein Repository, das ich selbst erstellt habe), und dann bleibt natürlich das richtige Linux-Header- * -Paket verfügbar . Wenn ich auf Debian 9.9 migrieren möchte, bringe ich das Paket-Repository in den zugehörigen Zustand und führe apt-get dist-upgrade aus. Ist das richtig?
Flo

2
Ja das ist richtig.
Stephen Kitt

3
@Flo beachte, dass Point Releases (wie Debian X.9 oder X.8) nur für herunterladbare Isos gedacht sind, so dass neue Installationen nicht Unmengen von Paketen herunterladen. In den Repositories gibt es keinen Unterschied zwischen den einzelnen Punktreleases. Sie erhalten immer das neueste Paket.
Braiam

15

Verlassen Sie sich nicht auf Server, die nicht unter Ihrer Kontrolle stehen, um einen bestimmten Systemstatus zu reproduzieren. Obwohl die Debian-Server ziemlich zuverlässig sind, wissen Sie nie, was in Zukunft passieren könnte. Dies gilt insbesondere für andere Repositorys, die Sie möglicherweise verwenden.

Sie sollten Ihren eigenen Spiegel verwalten, um reproduzierbare Systemzustände zu erhalten. Auf diese Weise können Sie sogar einen Produktionsstatus für Ihre normalen Systeme und mehrere Teststatus für neue Konfigurationen festlegen.

Das Repository - Management - Tool treffend ist in der Lage Spiegel von Endlagern zu erstellen. Sie können die zu spiegelnden Pakete auswählen, Snapshots von Repository-Inhalten zu bestimmten Zeitpunkten erstellen und mehrere Mirrors oder Snapshots in einem Repository kombinieren. Auf diese Weise können Sie vollständig reproduzierbare Systemzustände erhalten.


8

Während Stephen Kitt Antwort sicherlich eine mögliche Lösung ist, denke ich , es wäre sicherer, dass Sie Ihre eigenen Kopien der benötigten Pakete zu halten.

.debAchten Sie beim Aufzeichnen eines System-Setups darauf, Kopien der -Dateien von zu speichern /var/cache/apt/archives/. Sie können auch verwenden apt-get download.

Bei der Wiederherstellung eines System-Setups müssen Sie sehr streng vorgehen apt, um zu vermeiden, dass potenziell gefährliche automatische Aktionen ausgelöst werden.

Es wird wahrscheinlich einfacher sein, dpkgdirekt zu verwenden, um genau das zu installieren, was Sie wollen.


6
Ein noch besserer Ansatz für IMO wäre die Verwendung eines lokalen APT-Caches. Das vermeidet die Probleme in Ihrem dritten Absatz und vermeidet auch, ernten zu müssen /var/cache/apt.
Stephen Kitt

3
Es gibt zwei Varianten davon - eine ist die Verwendung von apt-mirror, um ein ganzes Repo zu klonen, die andere ist das Herunterladen nur bestimmter Pakete und Abhängigkeiten . Machen Sie dann einen Snapshot des Verzeichnisses - z. B. mit btrfs as pkgs-20190501, und veröffentlichen Sie das Snapshot-Verzeichnis als Repo. Zum Zeitpunkt der Erstellung, legen Sie die versioniert Repo - URL (zB http://debmirror/pkgs-20190501/...) in sources.list, dann apt-get update apt-get $ pkgs installieren etc.
bain
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.