Ondřej Surý ist so etwas wie der Rockstar für Debian-Admins, bekannt für seine Repos mit diversen PHP-Versionen und nginx-Backports. Oder genauer gesagt: „war“ – jedenfalls, was nginx betrifft. Er hat keine Lust mehr auf den Webserver. Für Admins, die dieses Repository verwendet haben, ist das womöglich ein kleines Problem. Aber es gibt (derzeit) eine relativ einfache Lösung.
Auf Codeberg hat Sury angekündigt, dass er keine Motivation mehr findet, neuere nginx-Versionen auf aktuelle Versionen von Debian (und Ubuntu) zu portieren. Da die letzte von ihm bereitgestellte Version (1.28) inzwischen geschlossene Sicherheitslücken aufweist, hat er das Repo am 26. April 2026 konsequenterweise gelöscht.
Der Wechsel auf das offizielle Repo
Die Triviallösung für dieses Problem: der Wechsel auf das offizielle nginx-Repo. Allerdings bringt das ein leicht unschönes Problem mit sich. Debian bietet eine Reihe von Modulen für nginx an, die aus der Community stammen. Module für nginx müssen stets gegen dieselbe Version kompiliert werden wie der Webserver selbst. Gleichzeitig versteckt nginx die meisten dieser Module hinter dem zahlungspflichtigen Abonnement von nginx Plus. Wenn du also Module wie brotli-filter, brotli-static oder headers-more verwendest, ist dieser Weg schlicht keine Option.
Downgrade?
Die zweite denkbare Lösung wäre ein Downgrade auf die offiziellen Trixie-Pakete. Dagegen spricht im Grunde nichts, da Debian Trixie mit nginx 1.26 eine Version im Repo offeriert, die sogar neu genug für HTTP/3 ist. Das Problem an der Sache: Diese Version ist eben nur „gerade so“ neu genug für HTTP/3. Speziell in der nächsten stabilen Version (1.28) kamen mehrere essenzielle Verbesserungen im QUIC/HTTP/3-Stack dazu (u. a. Congestion Control und Stabilität), die sich besonders unter Last bemerkbar machen.
Davon abgesehen muss ich meinen geschätzten Mit-Nerds vermutlich nicht erklären, wie uncool Downgrades sind, richtig?
Backports aus Debian Forky
Aber es gibt eine Lösung, die zumindest derzeit wie die offensichtlich „richtigste“ aussieht: Backports. Tatsächlich ist es kein echter Backport, sondern ein Ausleihen der Forky-Pakete. Ein echter Backport wäre gegen die Toolchain und die Libraries der älteren Version (also Trixie) gebaut. Wir nutzen hier hingegen stumpf die Pakete, die Forky (Testing) derzeit mitbringt – was (noch) erstaunlich gut funktioniert.
Achtung: Diese Lösung mischt Pakete aus Debian Testing in ein Stable-System (ein sogenanntes „FrankenDebian“). Das funktioniert aktuell hervorragend, kann aber in Zukunft brechen, falls neue und inkompatible Abhängigkeiten (wie z. B. OpenSSL 4) eingeführt werden.
Dafür registrieren wir zunächst Forky als mögliche Quelle für Pakete in APT:
cat >/etc/apt/sources.list.d/forky.sources <<'EOF'
Types: deb
URIs: http://deb.debian.org/debian
Suites: forky
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
EOF
Der nächste Schritt ist essenziell: Wir müssen APT mitteilen, dass es die Pakete aus dem Forky-Repo weitestgehend ignorieren soll – bis auf exakt die Pakete, die mit nginx zu tun haben:
cat >/etc/apt/preferences.d/99-forky-nginx <<'EOF'
Package: *
Pin: release n=forky
Pin-Priority: -1Package: nginx nginx-common nginx-core nginx-full nginx-extras nginx-dev libnginx-mod-*
Pin: release n=forky
Pin-Priority: 1001
EOF
Bitte beachte hier die Pin-Priority. Eine -1 bedeutet, dass APT die Pakete ignorieren soll. Die 1001 bei nginx und dessen Abhängigkeiten bedeutet, dass diese sehr wohl beachtet werden. Eine Priorität über 1000 erlaubt APT im Zweifel auch, ein formelles „Downgrade“ durchzuführen. Das ist wichtig, je nachdem, welche Zusatzmodule du verwendest.
Ein Beispiel: Der brotli-filter (libnginx-mod-http-brotli-filter) trug bei Sury die Versionsnummer 1:1.0.0~rc+1.28.1-10+0~20260118.20+debian13~1. In Forky lautet die Version 1.0.0~rc-8+b2. Nach dem Standard-Versionsvergleich ist das niedriger, weil Sury eine Epoch (1:) verwendet hat. Für APT ist das also ein Downgrade, auch wenn es faktisch ein Wechsel auf die offizielle Debian-Version ist. Da Module gegen dieselbe ABI gebaut werden müssen, müssen wir dieses „Downgrade“ erlauben.
Der nächste Schritt aktualisiert die Paketquellen:
apt update
APT sollte nun eine sehr geringe Zahl von Paketen anzeigen, die es aktualisieren wollen würde. Auf meinem System waren es exakt fünf. nginx, nginx-common und libnginx-mod-http-headers-more-filter wurden aktualisiert, während libnginx-mod-http-brotli-filter und libnginx-mod-http-brotli-static downgegraded wurden.
Dies kannst du verifizieren, indem du apt list --upgradable ausführst. Es sollten wirklich nur die nginx-Pakete sein, die APT anfassen will, und nicht dein halbes Betriebssystem. Wenn du dieselben Zusatzmodule verwendest, kannst du einen Testlauf ausführen:
apt -s install nginx nginx-common libnginx-mod-http-brotli-filter libnginx-mod-http-brotli-static libnginx-mod-http-headers-more-filter
Andernfalls solltest du deine installierten Module aufzählen. Wenn du dir nicht mehr sicher bist, welche das sind, hilft ein Blick in die installierten Pakete:
dpkg -l | grep nginx
Wenn das alles gut aussieht, kann es losgehen. Nochmals: Wichtig ist, dass apt list --upgradable vorhin wirklich nur die paar nginx-Pakete im Visier hatte!
apt-get update && apt-get dist-upgrade
Abschließend ändern wir die Priorität der nginx-Pakete aus dem Forky-Repo wieder auf eine Zahl unter 1000. Damit verhindern wir in Zukunft böse Überraschungen bei System-Updates:
sed -i 's/Pin-Priority: 1001/Pin-Priority: 990/' /etc/apt/preferences.d/99-forky-nginx && apt update
Das war es auch schon. nginx sollte jetzt wie gewohnt weiterlaufen – allerdings in Version 1.30.
Zu Risiken und Nebenwirkungen
Wenn du nginx via nginx -V fragst, was es von der neuen Situation hält, bekommst du vielleicht eine Ausgabe wie diese:
nginx version: nginx/1.30.0
built by gcc 15.2.0 (Debian 15.2.0-16)
built with OpenSSL 3.6.2 7 Apr 2026 (running with OpenSSL 3.5.5 27 Jan 2026)
Hier offenbart sich ein kleines Risiko, das in Zukunft relevant werden könnte. Debian Trixie kommt mit OpenSSL 3.5, während Debian Forky – von dem wir uns die Pakete ausgeliehen haben – bereits 3.6 ausliefert. Das ist derzeit unproblematisch, da OpenSSL garantiert, dass API und ABI innerhalb derselben Major-Version (hier 3.x) kompatibel bleiben.
Allerdings ist kürzlich OpenSSL 4.0 fertig geworden und wurde bereits in Debian Experimental integriert. Es ist noch nicht in Sid gelandet, was bedeutet, dass Hoffnung besteht, dass Forky eventuell nicht mit 4.x ausgeliefert wird – garantiert ist das aber nicht. Sobald OpenSSL 4 ins Spiel kommt, dürfte die Kompatibilität brechen, da es eine harte Abhängigkeit von nginx ist. Da praktisch alle essenziellen Server-Komponenten von OpenSSL abhängen, willst du dir den Schmerz eines OpenSSL-Backports unter Garantie nicht antun.
Kurz gesagt: Wenn Debian Forky auf OpenSSL 4 wechselt, brauchen wir eine andere Lösung für nginx. Idealerweise echte Backports, die nativ gegen die Libs und Toolchain von Trixie gebaut wurden. Aber darüber machen wir uns Sorgen, wenn es so weit ist.
Aktuell ein guter Kompromiss
Momentan ist dieser Weg ein äußerst akzeptabler Kompromiss. Du erhältst weiterhin Updates für nginx und hast einen klaren Upgrade-Pfad, sobald Forky (voraussichtlich Sommer 2027) stabil wird. Dann würdest du einfach die Dateien /etc/apt/sources.list.d/forky.sources sowie /etc/apt/preferences.d/99-forky-nginx löschen und das reguläre Debian-Upgrade wie gehabt durchführen.
Die einzige Unbekannte bleibt die Frage, ob OpenSSL 4 es in Forky schafft. Davon wird abhängen, ob unsere freundliche Paket-Leihgabe bis zum Release reibungslos funktioniert. Stand heute tut sie das tadellos.