Apt-Pinning: Kurze Einführung für Debian

Version 1.0
Autor: Falko Timme

Was ist Apt-Pinning?

Apt-Pinning ist eine Methode in Debian und Debian-basierten Distributionen (z. B. Ubuntu), mit der du bestimmen kannst, aus welchem Release ein Paket installiert werden soll. Damit lässt sich ein System primär auf der stabilen Distribution betreiben, während ausgewählte Pakete aus testing, unstable oder Drittanbieter-Repositories bezogen werden.

Kurzdefinition: Apt-Pinning legt Prioritäten für Paketquellen fest, so dass die Paketverwaltung (apt) entscheidet, welche Paketversion bevorzugt installiert wird.

Wichtig: Diese Anleitung ist eine technische Einführung und keine Garantie für Kompatibilität in allen Umgebungen.

Vorbemerkung

Ich benutze hier ein Debian Lenny (stable) System. Als Beispiel dient das Paket phpmyadmin, das zum Zeitpunkt dieses Artikels in den drei Releases unterschiedliche Versionen bietet — siehe http://packages.debian.org/search?keywords=phpmyadmin&searchon=names&suite=all§ion=all.

Beispiel der vorhandenen Versionen:

lenny (stable): Version 4:2.11.8.1-5
squeeze (testing): Version 4:3.1.2-2
sid (unstable): Version 4:3.1.3-1

Quellen eintragen

Füge testing und unstable zu /etc/apt/sources.list hinzu, sodass die Datei in etwa so aussieht:

vi /etc/apt/sources.list

deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb-src http://volatile.debian.org/debian-volatile lenny/volatile main

## Lenny / Stable
deb http://ftp2.de.debian.org/debian/ lenny main
deb-src http://ftp2.de.debian.org/debian/ lenny main

deb http://security.debian.org/ lenny/updates main
deb-src http://security.debian.org/ lenny/updates main

## Squeeze / Testing
deb http://ftp2.de.debian.org/debian/ squeeze main
deb-src http://ftp2.de.debian.org/debian/ squeeze main

deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main

## Sid / Unstable
deb http://ftp2.de.debian.org/debian/ sid main
deb-src http://ftp2.de.debian.org/debian/ sid main

Öffne dann /etc/apt/apt.conf:

vi /etc/apt/apt.conf

und füge die folgende Zeile hinzu, um dem Paketcache mehr Platz zu geben:

APT::Cache-Limit "100000000";

Ohne diese Einstellung kann beim Ausführen von apt-get update folgender Fehler erscheinen:

E: Dynamic MMap ran out of room

Anschließend update die Paketquellen:

apt-get update

Warum Pinning nötig ist

Standardmäßig würde apt stets versuchen, die neueste verfügbare Paketversion zu installieren — häufig aus testing oder unstable — was ein System durcheinanderbringen kann. Durch Apt-Pinning lassen sich Prioritäten vergeben, sodass Pakete aus unstable/testing nur dann installiert werden, wenn keine passende Version aus stable verfügbar ist.

Du kannst die aktuellen Prioritäten prüfen mit:

apt-cache policy

Beispielausgabe:

server1:~# apt-cache policy
 Package files:
 100 /var/lib/dpkg/status
     release a=now
  500 http://volatile.debian.org lenny/volatile/main Packages
     release o=volatile.debian.org,a=stable,l=debian-volatile,c=main
     origin volatile.debian.org
  500 http://ftp2.de.debian.org sid/main Packages
     release o=Debian,a=unstable,l=Debian,c=main
     origin ftp2.de.debian.org
  500 http://security.debian.org squeeze/updates/main Packages
     release v=None,o=Debian,a=testing,l=Debian-Security,c=main
     origin security.debian.org
  500 http://ftp2.de.debian.org squeeze/main Packages
     release o=Debian,a=testing,l=Debian,c=main
     origin ftp2.de.debian.org
  500 http://security.debian.org lenny/updates/main Packages
     release v=5.0,o=Debian,a=stable,l=Debian-Security,c=main
     origin security.debian.org
  500 http://ftp2.de.debian.org lenny/main Packages
     release v=5.0,o=Debian,a=stable,l=Debian,c=main
     origin ftp2.de.debian.org
 Pinned packages:
server1:~#

Wie sichtbar, haben stable, testing und unstable dieselbe Priorität (500). In diesem Fall würde apt die neueste Version auswählen — für phpmyadmin wäre das 4:3.1.3-1 aus unstable.

Prüfe das für ein Paket mit:

apt-cache policy phpmyadmin

Beispielausgabe:

server1:~# apt-cache policy phpmyadmin
 phpmyadmin:
   Installed: (none)
   Candidate: 4:3.1.3-1
   Version table:
     4:3.1.3-1 0
        500 http://ftp2.de.debian.org sid/main Packages
     4:3.1.2-2 0
        500 http://ftp2.de.debian.org squeeze/main Packages
     4:2.11.8.1-5 0
        500 http://ftp2.de.debian.org lenny/main Packages
server1:~#

Die Candidate-Zeile zeigt die Version, die installiert würde.

Prioritäten verstehen

Die Prioritäten werden in /etc/apt/preferences oder in Dateien unter /etc/apt/preferences.d/ gesetzt. Zusammengenommen sagen diese Werte apt, welche Version vorgezogen wird. Die Regeln (aus man 5 apt_preferences) lauten in Kurzform:

P > 1000: Erzwingt Installation, auch wenn das ein Downgrade wäre.
990 < P <= 1000: Erzwingt Installation, außer die installierte Version ist neuer.
500 < P <= 990: Version wird installiert, es sei denn, es gibt eine Version aus der Ziel-Distribution oder die installierte Version ist neuer.
100 < P <= 500: Version wird installiert, es sei denn, es gibt eine Version aus einer anderen Distribution oder die installierte Version ist neuer.
0 < P <= 100: Version wird nur installiert, wenn keine installierte Version existiert.
P < 0: Verhindert, dass die Version installiert wird.

Fakt: Eine sinnvolle Grundregel ist, stable eine hohe Priorität zu geben (z. B. 700), testing/unstable niedriger (z. B. 150), und für einzelne Pakete gezielte Ausnahmen zu definieren.

Beispiel: preferences-Datei

Eine einfache /etc/apt/preferences (oder /etc/apt/preferences.d/50pinning) könnte so aussehen:

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release a=testing
Pin-Priority: 150

Package: *
Pin: release a=unstable
Pin-Priority: 100

Für ein einzelnes Paket (z. B. phpmyadmin) kannst du eine Ausnahme setzen:

Package: phpmyadmin
Pin: release a=testing
Pin-Priority: 990

Damit wird phpmyadmin bevorzugt aus testing installiert, selbst wenn stable vorhanden wäre.

Alternative Ansätze

Verwende chroot/containers (debootstrap, LXC, Docker), um Pakete aus anderen Releases isoliert zu testen oder zu betreiben.
Nutze apt-get -t install , um temporär eine andere Release-Zielgruppe zu wählen, ohne dauerhaftes Pinning.
Baue ein Paket selbst aus Quellcode (apt-get source / dpkg-buildpackage) und installiere das erzeugte .deb.

Wann Apt-Pinning versagt

Paketabhängigkeiten: Wenn ein Paket aus testing/unstable Abhängigkeiten hat, die wiederum neuere Versionen erfordern, kann das zu einer Kaskade von Upgrades führen.
Kernel- oder glibc-Abhängigkeiten: Solche tiefen Systempakete sollten nicht aus unstable gezogen werden.
Sicherheitsupdates: Pinning kann dazu führen, dass wichtige Sicherheitsupdates aus security-Repositories nicht mehr automatisch angewendet werden.

Wichtig: Teste Pinning-Änderungen immer zuerst in einer Kopie oder Staging-Umgebung.

Mini-Methodik für sicheres Pinning

Dokumentieren der gewünschten Release-Strategie (welches Paket aus welchem Release).
Setze globale Prioritäten (stable höher, testing/unstable niedriger).
Erstelle gezielte Pin-Einträge nur für benötigte Pakete.
Testen in einer Nicht-Produktionsumgebung.
Überwachen von Abhängigkeitsänderungen nach jeder apt-get upgrade/ dist-upgrade.

Role-basierte Checkliste

Für Systemadministratoren:

Backup der VM oder Systemsicherung vor Änderungen.
Preferences-Datei versionieren (Git) und Change-Log pflegen.
Changelogs und Abhängigkeitsbäume prüfen (apt-cache showpkg, apt-rdepends).

Für Entwickler:

Benötigte Versionen dokumentieren (SemVer-Relevanz).
Test-Pakete in Container deployen.
Rollback-Plan parat haben (dpkg –install mit älteren .deb oder Snapshot zurückspielen).

Abnahmekriterien

Das gewünschte Paket kommt aus dem angegebenen Release (apt-cache policy zeigt die Candidate-Version).
Systemstart, Dienste und kritische Anwendungen laufen nach Upgrade-Tests.
Keine unbeabsichtigten Downgrades oder fehlende Abhängigkeiten.

Kurze Glossarzeile

Pin: Regel, die angibt, welche Release-Version eines Pakets bevorzugt wird.
Preference-Datei: Datei (/etc/apt/preferences oder /etc/apt/preferences.d/) mit Pin-Regeln.

Zusammenfassung

Apt-Pinning ist ein mächtiges Werkzeug, um gezielt Pakete aus neueren Distributionen zu nutzen, ohne das gesamte System auf testing oder unstable anzuheben. Setze globale Prioritäten, verwalte Ausnahmen gezielt, teste in isolierten Umgebungen und dokumentiere jede Änderung. Bei sensiblen Systempaketen oder komplexen Abhängigkeiten sind alternative Ansätze wie Container oft sicherer.

Wichtig: Keine Pinning-Strategie ist universell; passe Prioritäten an die Bedürfnisse deiner Umgebung an und halte einen Rollback-Plan bereit.

Ein kurzer Einstieg in Apt-Pinning