[gelöst] vorheriges Release aus Fremdquelle installieren - Fremdquellenfalle

[AxelMD]

Hallo Forum,

wie kann ich ein vorherige Release aus einer Fremdquelle installieren?
Es handelt sich um eine Debian 11 Bullseye System.

Mein Vorgehen am Beispiel podman:

https://wiki.debianforum.de/Pakete_auf_hold_setzen

Code: Alles auswählen

sudo apt-mark hold podman

Geünschtes Binärpaket aus der Fremdquelle direkt runterladen:

Code: Alles auswählen

wget https://download.opensuse.org/repositories/home:/alvistack/Debian_11/amd64/podman_4.1.1-1_amd64.deb

Code: Alles auswählen

sudo apt install /home/axelmd/podman_4.1.1-1_amd64.deb

Leider funktioniert das nicht vollständig.
podman 4.1.1 started, arbeitet nicht wie am eine vorherigen Systemzustandszeitpunkt.
Es werden vermutlich Updates der Abhängigkeiten aktualisiert.

Wie setze ich die mit installierten Anhängigkeiten auch auf "hold"?

Es soll der Systemzustand wie am 5. Sept 2022 hergestellt werden.

Code: Alles auswählen

dpkg -I /home/axelmd/podman_4.1.1-1_amd64.deb
 neues Debian-Paket, Version 2.0.
 Größe 17469008 Byte: control-Archiv= 1996 Byte.
     779 Byte,    15 Zeilen      control              
    1593 Byte,    22 Zeilen      md5sums              
    4958 Byte,   100 Zeilen   *  postinst             #!/bin/sh
     943 Byte,    21 Zeilen   *  postrm               #!/bin/sh
     318 Byte,     7 Zeilen   *  prerm                #!/bin/sh
 Package: podman
 Version: 100:4.1.1-1
 Architecture: amd64
 Maintainer: Wong Hoi Sing Edison <hswong3i@gmail.com>
 Installed-Size: 64958
 Depends: libc6 (>= 2.14), libseccomp2 (>= 2.5.0), catatonit, conmon, containernetworking-plugins, containers-common, iptables, oci-runtime, tzdata
 Section: devel
 Priority: optional
 Homepage: https://github.com/containers/podman/tags
 Description: Daemon-less container engine for managing containers, pods and images
  Podman is a container engine for managing pods, containers, and
  container images. It is a standalone tool and it directly manipulates
  containers without the need of a container engine daemon. Podman is able
  to interact with container images create in buildah, cri-o, and skopeo,
  as they all share the same datastore backend.

Das Fremdquellenfalle-Paket:

Code: Alles auswählen

dpkg -I /home/axelmd/podman_4.2.1-1_amd64.deb
 neues Debian-Paket, Version 2.0.
 Größe 18267100 Byte: control-Archiv= 2028 Byte.
     779 Byte,    15 Zeilen      control              
    1739 Byte,    24 Zeilen      md5sums              
    4958 Byte,   100 Zeilen   *  postinst             #!/bin/sh
     943 Byte,    21 Zeilen   *  postrm               #!/bin/sh
     318 Byte,     7 Zeilen   *  prerm                #!/bin/sh
 Package: podman
 Version: 100:4.2.1-1
 Architecture: amd64
 Maintainer: Wong Hoi Sing Edison <hswong3i@gmail.com>
 Installed-Size: 68196
 Depends: libc6 (>= 2.14), libseccomp2 (>= 2.5.0), catatonit, conmon, containernetworking-plugins, containers-common, iptables, oci-runtime, tzdata
 Section: devel
 Priority: optional
 Homepage: https://github.com/containers/podman/tags
 Description: Daemon-less container engine for managing containers, pods and images
  Podman is a container engine for managing pods, containers, and
  container images. It is a standalone tool and it directly manipulates
  containers without the need of a container engine daemon. Podman is able
  to interact with container images create in buildah, cri-o, and skopeo,
  as they all share the same datastore backend.

Leider komme ich nicht weiter.

MfG

AxelMD


podman from home:alvistack project
https://software.opensuse.org/download/ ... Aalvistack

Code: Alles auswählen

echo 'deb http://download.opensuse.org/repositories/home:/alvistack/Debian_11/ /' | sudo tee /etc/apt/sources.list.d/home:alvistack.list
curl -fsSL https://download.opensuse.org/repositories/home:alvistack/Debian_11/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home_alvistack.gpg > /dev/null
sudo apt update
sudo apt install podman

[fischig]

Meiner Meinung nach hast du dir da selbst ins Knie gesschossen:

Wenn du ein Paket auf hold setzt, wird apt es nicht aktualisieren.
ich kann mir nicht vorstellen, dass das Kommando

Code: Alles auswählen

apt install /home/axlemd/podman_4.1.1-1_amd64.deb

fehlerfrei durchgelaufen ist.
Hättest du beim apt-Befehl den Parameter -s benutzt, hätte apt dir das vielleicht auch gesagt. Der richtige Weg wäre also gewesen, das Paket gerade nicht auf hold zu setzen, wenn's aktualisiert werden soll.
Dann hätte apt bei der Installation die entsprechenden Abhängigkeiten (sofern verfügbar!) mit installiert. Für deine Entscheidung, ob du das wirklich willst (Fremdpaket!), hätte dir der genannte Parameter (bevor's ohne ihn tatsächlich Ernst wird) noch ein paar Entscheidungshilfen geliefert.

Nebenbei: Installieren via sudo halte ich für eine schlechte Angewohnheit.

[AxelMD]

Es handelt sich um ein Debian 11 System, das sudo Paket ist installiert.

als root

Code: Alles auswählen

apt install -s /home/axelmd/podman_4.1.1-1_amd64.deb
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Hinweis: »podman« wird an Stelle von »/home/axelmd/podman_4.1.1-1_amd64.deb« gewählt.
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 podman : Hängt ab von: containers-common ist aber nicht installierbar
          Hängt ab von: oci-runtime ist aber nicht installierbar
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

Die Sourcen hier nur direkt von Debian 11.

[fischig]

Sudo hatte ich nur nebenbei erwähnt. Was ich für schlecht halte, musst du nicht für schlecht halten - wenn du weißt, was du tust. Interessanter wären Rückmeldungen zum vorher Geschriebenen gewesen.

[AxelMD]

Auf hold ist nichts gesetzt, siehe zuvor.

Wie liste ich die hold Pakete auf?

Wie komme installiere ich mir den Systemzustand ( Stand 5. Sept. 2022) mit podman aus der Fremdquelle?

[JTH]

Wie liste ich die hold Pakete auf?

Code: Alles auswählen

apt-mark showhold

Wie komme installiere ich mir den Systemzustand ( Stand 5. Sept. 2022) mit podman aus der Fremdquelle?

Wenn du kein Backup des Zustands hast: Such dir von Hand die Pakete aus /var/log/apt/history.log heraus, die am oder nach dem 5.9. aktualisiert wurden und die du nicht in der neuen Version haben möchtest. Du brauchst sie dann allerdings nicht von Hand runterladen, sie sind in dem Repo anscheinend noch in älterer Version vorhanden (https://download.opensuse.org/repositor ... _11/amd64/).

Gezielt ältere, noch verfügbare Versionen installieren geht per:

Code: Alles auswählen

apt install podman=4.1.1-1

Das dann eben – am Besten in einem apt-install-Aufruf – für alle notwendigen Pakete. Anschließend, wie oben schon gemacht, auf hold setzen.

[AxelMD]

podman_4.1.1-1_amd64.deb kann ich heute installieren.
Es wird mit auch richtig angzeigt und kann gestartet werden.

Nur bekomme ich Fehlermeldungen, die ich am 5. September nicht hatte.

Fehlermledung:

Code: Alles auswählen

Got the "Error: write child: broken pipe" when starting a container with journald log driver

Daher vermute ich ein Problem in den aktualisierten Abhängigkeiten.
Wie komme in bei den Abhängigkeiten auf den Stand vom 5. Sept. 2022?

Such dir von Hand die Pakete aus /var/log/apt/history.log heraus, die am oder nach dem 5.9. aktualisiert wurden

Das kann ich nicht, das System besteht nicht mehr und ich möchte neu aufsetzen.

Die jetzt installierte podman Version funktioniert:

Code: Alles auswählen

podman version
Version:      3.0.1
API Version:  3.0.0
Go Version:   go1.15.15
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Die Neuinstallation vom 5. Sept. 2022 funktionierte mit podman 4.1.1 einwandfrei.

Ich möchte ein podman 4.x.x.

Code: Alles auswählen

https://download.opensuse.org/repositories/home:/alvistack/Debian_11/amd64/

Das habe ich jetzt: viewtopic.php?p=1308246#p1308246

[AxelMD]

Hallo Forum,

es gab einige Updates oder evtl. Serverproblem von den ich Docker Images beziehe sind behoben.

Der Fehler von podman "broken pipe error" ist nicht mehr vorhanden.
Jezt funktioniert podman 4.2.1 wieder.

Code: Alles auswählen

cat /etc/containers/registries.conf
# Note that changing the order here may break tests.
#unqualified-search-registries = ['docker.io', 'quay.io', 'registry.fedoraproject.org']

#[[registry]]
# In Nov. 2020, Docker rate-limits image pulling.  To avoid hitting these
# limits while testing, always use the google mirror for qualified and
# unqualified `docker.io` images.
# Ref: https://cloud.google.com/container-registry/docs/pulling-cached-images
#prefix="docker.io"
#location="mirror.gcr.io"

# 2020-10-27 a number of images are not present in gcr.io, and podman
# barfs spectacularly when trying to fetch them. We've hand-copied
# those to quay, using skopeo copy --all ...
#[[registry]]
#prefix="docker.io/library"
#location="quay.io/libpod"

# 2021-03-23 these are used in buildah system tests, but not (yet?)
# listed in the global shortnames.conf.
#[aliases]
#busybox="docker.io/library/busybox"
#ubuntu="docker.io/library/ubuntu"
#php="docker.io/library/php"

# https://github.com/containers/podman/issues/8896
# /etc/containers/registries.conf
unqualified-search-registries=["registry.access.redhat.com", "registry.fedoraproject.org", "docker.io"]
[[registry]]
location = "docker.io"

[[registry]]
location = "registry.fedoraproject.org"

[[registry]]
location = "registry.access.redhat.com"

Ist die Fehlermeldung evtl. von einem umtabilen Server, docker.io, registry.fedoraproject.org oder registry.access.redhat.com gekommen?

In meinem System sind Fremdquellen eingebunden.

Debian Backports und alvistack (https : / /download.opensuse.org/repositories/home:/alvistack/Debian_11/amd64/)

Wie beurteile ich vorab die Zuverlässigkeit einer Fremdquelle?
Zu AlviStack https://github.com/alvistack habe ich irgendwie gar keine Meinung. Prüft die Tätigkeiten von AlviStack opensuse.org?
Oder kann da jeder anbieten was er will?

Was sollte ich jetzt abstellen um wieder möglichst nahe die Zuverlässigkeit von einem Standarddebiansystem zu bekommen?

Meine Idee zu meiner Frage:
- podman auf hold setzen
- backports Source abschalten
- alvistack Source abschalten

Aber ist das wirklich sinnvoll?

MfG
AxelMD

[AxelMD]

Hallo Forum,

gibt es hierzu keine Erfahrungsempfehlungen?
Nutzt Ihr keine Fremdquellen?

MfG
AxelMC

[Blackbox]

Es soll der Systemzustand wie am 5. Sept 2022 hergestellt werden.

Ich habe diesen Thread einmal auf das Wesentliche zusammengefasst.

Genau hierfür wurde vor Jahren Debian Snapshot [0] geschaffen.
Damit ist es jederzeit möglich, ein älteres Paket direkt aus dem Debian Repository zu installieren.

Etwas Lesemüh' und Einarbeitung bleibt dir natürlich nicht erspart.

[0] https://snapshot.debian.org/

[AxelMD]

Ok, das kannte ich nicht.

+++
Fremdquellenhandling am Bespiele podman möglichst sicher

- podman auf hold setzen
- backports Source abschalten
- alvistack Source abschalten

Gibt es dazu weitere Hinweise?

[Blackbox]

Alle Pakete und deren Abhängigkeiten aus den Fremdquellen entfernen (purge), danach die Fremdquellen aus deiner Repo-Datei werfen.
Damit sollte dein System wieder wie vor deinem leichtfertigen Eingriff wiederhergestellt sein.
Zumindest dann, wenn du zu deinem Vorgehen nichts vergessen hast zu erwähnen.

[AxelMD]

Die Fremdquellensoftware möchte ich weiter verwenden.
Ein aktuelles podman 4.x.x hat Debian 11 nicht.
In den Backports gibt es podman nicht.

Also mit dem Risiko von Inkompatibelitäten leben?
Wie kann ich das Risiko möglichst klein halten?

Bedeuten die Backports auch ein zusätzliches Risiko?

[Blackbox]

Ein aktuelles podman 4.x.x hat Debian 11 nicht.

Das stimmt wohl.

In den Backports gibt es podman nicht.

Auch das ist richtig, podman 4 ist zu neu für Debian 11.
Ich kann aber verstehen, warum du podman einsetzen möchtest, denn podman 4 unterstützt endlich auch Docker Compose.

Also mit dem Risiko von Inkompatibelitäten leben?

Viele Optionen sehe zumindest nicht.

Wie kann ich das Risiko möglichst klein halten?

Dich ausgiebig mit podman beschäftigen.

Bedeuten die Backports auch ein zusätzliches Risiko?

Das Debian Security-Team versorgt die Backports nur niedrigpriorisiert mit Security updates.
Sollte eine Software löchrig sein, bekommt diese, wenn überhaupt, nur verspätet Security Updates.
Dieses Wissen sollte man besitzen, wenn man die Backports einsetzt.

[AxelMD]

Danke für die ausführliche Klärung.

[tijuca]

Das Debian Security-Team versorgt die Backports nur niedrigpriorisiert mit Security updates.
Sollte eine Software löchrig sein, bekommt diese, wenn überhaupt, nur verspätet Security Updates.

Das Security Team hat mit Backports gar nichts zu tun und kümmert sich auch nicht um mögliche Sicherheitsupdates in diesem Repo, das Backport Repository wurde angelegt um auch aktuellere Versionen für die Stable Veröffentlichungen zur Verfügung stellen zu können. Jeder DD kann Pakete nach Backports laden, ist dann aber auch in gewisser Weise verantwortlich für diese Pakete, sollte sich also auch um Aktualisierungen kümmern wenn es CVE relevante Probleme gibt die durch eine neuere Version beseitigt werden können.

Wenn man den Paketmaintainer freundlich fragt wird man auch eine Antwort bekommen warum es keine Version in Backports gibt. Nur fragenden Leuten kann geholfen werden.

[Blackbox]

Das Security Team hat mit Backports gar nichts zu tun und kümmert sich auch nicht um mögliche Sicherheitsupdates in diesem Repo, das Backport Repository wurde angelegt um auch aktuellere Versionen für die Stable Veröffentlichungen zur Verfügung stellen zu können. Jeder DD kann Pakete nach Backports laden, ist dann aber auch in gewisser Weise verantwortlich für diese Pakete, sollte sich also auch um Aktualisierungen kümmern wenn es CVE relevante Probleme gibt die durch eine neuere Version beseitigt werden können.

Danke für die Korrektur.
Dann waren meine Informationen falsch.

Denn die Backports FAQ sagt, etwas Ähnliches, wie du es beschreibst: https://backports.debian.org/FAQ/

Wenn man den Paketmaintainer freundlich fragt wird man auch eine Antwort bekommen warum es keine Version in Backports gibt. Nur fragenden Leuten kann geholfen werden.

@AxelMD

Schreib dem podman Maintainer eine E-Mail (in englischer Sprache) und bitte ihn eine aktuelle podman Version in den Backports bereitzustellen.

[AxelMD]

OT

Wenn man den Paketmaintainer freundlich fragt wird man auch eine Antwort bekommen warum es keine Version in Backports gibt. Nur fragenden Leuten kann geholfen werden.

Das Team hat keine Kapazitäten frei, die Teil-Antwort von rt:

Wir müssten den ganzen Stack Backporten, inklusive buildah, containers/image, containers/storage, crun, docker.io.

Das wird sicher nicht einfach

Ich würde mich freuen wenn ich Hilfe für den Upload nach unstable bekäme..

Leider habe ich die Kenntnisse nicht.

INFO:

Das Security Team hat mit Backports gar nichts zu tun und kümmert sich auch nicht um mögliche Sicherheitsupdates in diesem Repo, das Backport Repository wurde angelegt um auch aktuellere Versionen für die Stable Veröffentlichungen zur Verfügung stellen zu können. Jeder DD kann Pakete nach Backports laden, ist dann aber auch in gewisser Weise verantwortlich für diese Pakete,

Bisher hatte ich sehr großer Vertrauen in die Debian Backports, das wußte ich nicht.

MfG
AxelMD


Edit: 14. Sept. 2022

Meine jetzige Lösung:

- podman auf hold setzen

Code: Alles auswählen

sudo apt-mark hold podman
sudo apt-mark showhold

Besonders Release auf Reporsitory installieren:
sudo apt install podman=4.1.1-1

- Fremdreporsitorys bleiben aktiv um Updates zu bekommen

Da vertraue ich mal auf Herrn AlviStack, OpenSuse und Herrn Backports (KlickiBunti cockpit-podman).

KlickiBunti, so liebe ich es.

[Blackbox]

Du könntest aber auch podman 4.2 aus dem Debian Experimental Repository versuchen, natürlich ohne Gewähr und auf eigene Gefahr.
Das Experimental Repo erhält ebenfalls keinen Security-Support und Pakete werden nicht kontinuierlich mit Updates versorgt und können ohne Vorwarnung entfernt werden.
Aber dieses Repository ist zum Experimentieren gedacht, ob die Pakete daraus auch zu einem Stable-Release passen, muss jede Person selbst entscheiden.

[AxelMD]

Meine Strategie steht fest.

Das Debian Experimental Repository ist nichts für meinen Wissensstand.