© Andrew Poplavsky / 123RF.com

Debian-Entwickler schätzen Überraschungen ebenso wenig wie Debian-Nutzer. Entsprechend verläuft ein Debian-Update weitgehend geräuschlos. Ein paar Stolperfallen erfordern aber doch Feinjustagen.

Fragt man passionierte Debian-Admins, was sie an der Distribution ihrer Wahl besonders schätzen, erhält man immer dieselben Antworten: Ein einmal als stabil freigebebenes Debian-Release verändert sich praktisch nicht mehr. Fehlerkorrekturen und Sicherheitsaktualisierungen werden durch die passenden Instanzen des Debian-Projekts handverlesen und finden erst dann ihren Weg auf die Systeme der Anwender. Überraschungseffekte gibt im Betrieb also im Grunde gar nicht. Das gilt umso mehr, seit Debian das Backports-Verzeichnis zum offiziellen Projekt ernannt hat, das Anwendern zumindest neue Kernel für die – gerade später im Release-Zyklus oft angestaubte – Software der Distribution liefert.

Folglich ist die Veröffentlichung einer neuen Version von Debian GNU/Linux (Abbildung 1) in der Debian-Welt alles andere als eine Lappalie. Vielmehr fiebern die Entwickler und das gesamte Projekt über Monate auf diesen Zeitpunkt hin, und dasselbe gilt für die Verwalter von Debian-Systemen. Letztere richten an das Projekt allerdings auch eine sehr eindeutige, explizit formulierte Erwartung, die sich mit “Keine Überraschungen!” gut zusammenfassen lässt.

Abbildung 1: Die Nutzer erwarten von Debian GNU/Linux 11 “Bullseye” vor allem eines: reibungslose Updates auf Servern und Desktops.

Historisch gewachsen

Freilich ist diese Erwartungshaltung nicht vom Himmel gefallen. Viel mehr haben die Debian-Entwickler sich in den vergangenen fast drei Jahrzehnten den Ruf erarbeitet, Upgrades von einer Hauptversion auf eine andere besonders zuverlässig abzuwickeln.

Zu einer Zeit, als es die heute üblichen LTS-Releases noch gar nicht gab und die Distributoren auch nicht zwischen Servern und Desktops unterschieden, war es Debian, das Major-Upgrades mit äußerster Zuverlässigkeit abzuwickeln vermochte. Fand man sich bei der Konkurrenz wegen schiefgelaufener Updates oft in der berüchtigten Abhängigkeitshölle wieder, war man bei Debian bereits in der Version 2.2 “Potato” in der Lage, ohne größere Umschweife auf Version 3.0 “Woody” zu aktualisieren. Dafür genügte es, in der Konfiguration des Paketverwalters Apt-get »potato« durch »woody« zu ersetzen und »apt-get update« sowie »apt-get dist-upgrade« auszuführen.

Um reibungslose Updates zu ermöglichen, haben die Debian-Entwickler beim Schreiben ihrer internen technischen Vorgaben viel Hirnschmalz einfließen lassen. Die beiden zentralen Dokumente für Paketpfleger, die Debian Policy und die Entwicklerreferenz (Abbildung 2), machen den Paket-Maintainern penible Vorgaben im Hinblick auf das Verhalten eines Pakets bei Updates. So ist zum Beispiel festgelegt, dass Pakete sich im Falle von Syntaxänderungen innerhalb einer Konfigurationsdatei nach Möglichkeit selbst um die Anpassung kümmern sollen. Auch erlauben die Richtlinien es nur im äußersten Notfall, einen auf dem System laufenden Dienst während des Updates zu deaktivieren, etwa weil es Aufgaben gibt, die der Administrator händisch vornehmen muss.

Abbildung 2: Das Debian Policy Manual, die Bibel des Paket-Maintainers, gibt diesem auf Punkt und Komma vor, wie Updates abzulaufen haben. Es ist maßgeblich für Debians Ruf verantwortlich, sich gut aktualisieren zu lassen.

All diese Regeln haben über die Jahre bei den Admins von Debian-Systemen zu einer konkreten Erwartungshaltung geführt. Grund genug, anlässlich der neuesten Debian-Version 11 einen genaueren Blick zu riskieren: Wird die neue Version den an Debian gestellten Erwartungen gerecht? Womit müssen Admins rechnen und worauf haben sie zu achten? Dieser Artikel verrät die Details.

Alles wie immer

Die gute Nachricht gleich ganz am Anfang: Wer es gewohnt ist, seine Debian-basierten Systeme wie beschrieben zu aktualisieren, muss bei der neuen Version 11 nicht umdenken. Zwar heißt das Werkzeug der Wahl mittlerweile auf der Kommandozeile nicht mehr Apt-get sondern Apt, ist jedoch nur um eine neuere Version Vorgängers. Im Handling gibt es im Hinblick auf Updates keine Unterschiede.

Der Administrator öffnet also auf einem System mit Debian GNU/Linux 10 (Buster) die »/etc/apt/sources.list« und ersetzt »buster« durch »bullseye«. Eine Ausnahme bilden die Einträge für Sicherheitsaktualisierungen. Sie waren bisher in einem Unterordner des Verzeichnisses der Distribution auf den Debian-FTP-Servern untergebracht (»buster/security/«) und wandern nun in ein eigenes Verzeichnis. Es gilt also, in der »sources.list« den Eintrag aus der zweiten Zeile durch den aus der letzten zu ersetzen. Weitere Veränderungen ergeben sich bei der Paketauswahl jedoch nicht. Ist die »sources.list« angepasst, setzt ein »apt update && apt dist-upgrade« den Update-Prozess in Gang.

# alt
deb http://security.debian.org/debian-security/ buster/updatesmain contrib
# neu
deb http://deb.debian.org/debian-security/ bullseye-security main contrib

Bevor der Administrator das tut, sollte er allerdings bei seinem System ein paar Dinge im Hinblick auf Änderungen in “Bullseye” prüfen und ein paar weitere Vorbereitungen treffen, ohne dass diese direkt mit Debian 11 assoziiert wären.

Externe Pakete handhaben

Ein regelmäßig wiederkehrendes Problem bei Debian-Updates sind Pakete, die nicht direkt aus den Quellen der Distribution stammen. Wer sich mit dem Bau von Debian-Paketen etwas auskennt und sich ansieht, was gerade große Hersteller oft an “Paketen” produzieren, wundert sich darüber nicht: Oft genug ignorieren die Firmen beim Bau eigener DEB-Pakete praktisch sämtliche Best Practices und produzieren Krempel, der nahezu sämtliche Vorgaben seitens der Policy und der Entwicklerreferenz verletzt.

Beim Update von einer Version hin zu einer anderen geraten solche Pakete zum Klotz am Bein. Der Admin tut gut daran, sie vor dem Update zu deinstallieren und im Anschluss die Pakete für die neue Distribution beim Anbieter erneut zu beziehen. Die Befehle aus Listing *2 unterstützen den Administrator dabei, sich von solchen Paketen zu trennen.

$ aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
$ apt-forktracer | sort

Grundsätzlich sollten beide Kommandos dieselbe Paketliste produzieren, in einigen Fällen können die Resultate jedoch voneinander abweichen. Sobald der Admin die Liste überprüft hat, schreitet er zur Tat und entfernt die Pakete mitsamt eventueller Abhängigkeiten idealerweise per »apt-get –purge remove Paket«. Hier liegt übrigens auch ein guter Ansatzpunkt für spätere Automation: Das erneute Einrichten eines solchen Pakets samt zugehöriger Konfiguration lässt sich später per Ansible & Co. wunderbar abwickeln.

Die beschriebene Vorgehensweise hat übrigens noch einen weiteren, äußerst praktischen Nebeneffekt: Sie spürt Debian-Pakete auf, die früher einmal Teil von Debian waren, mittlerweile aber im Archiv nicht mehr vorkommen. Das betrifft in vielen Fällen uralte Kernel-Pakete, die auf Systemen herumlungern und dort viel Platz in Anspruch nehmen, ohne noch für irgendetwas nützlich zu sein.

Nach dem Update

Hat man das Update der offiziellen Pakete erfolgreich hinter sich gebracht, steht noch einige Politurarbeit auf dem Programm. Am leichtesten haben es Admins, die den größten Teil der Arbeitsschritte in der Vergangenheit bereits automatisiert haben: Sie müssen nur noch eventuelle Änderungen an Konfigurationsdateien in ihre Automation aufnehmen. Relevante Veränderungen in der Art und Weise, wie Debian Dienste verwaltet, startet und stoppt gibt es bei “Bullseye” nicht; das Thema dürfte sich dank Systemd für die kommenden Jahre erledigt haben. In der Mehrzahl der Fälle dürfte es genügen, einmal Ansible über den gerade aktualisierten Rechner laufen zu lassen, um das System in den gewünschten Zustand zu versetzen – mit ein paar wenigen Ausnahmen.

LILO in Rente

Der Uralt-Bootloader LILO hat in Debian “Bullseye” endgültig ausgedient. Die meisten Admins reiben sich angesichts dieser Nachricht wohl verwundert die Augen und fragen sich, ob es wirklich noch Systeme gibt, auf denen LILO zum Einsatz kommt. Ja, gibt es – zum Teil handelt es sich sogar um Systeme, die ursprünglich noch mit LILO installiert und dann sukzessive immer weiter aktualisiert wurden. Das ist übrigens ein äußerst beeindruckendes Beispiel für die Update-Fähigkeiten von Debian, doch das nur am Rande. Wer allerdings noch immer mit LILO hantiert, muss in “Bullseye” umsteigen, weil er nach einem Neustart des Systems sonst nur noch eine Fehlermeldung zu sehen bekommt.

Journald nun persistent

Wer sich in der Linux-Community ein bisschen auskennt, der weiß, dass kaum ein Thema die Entwickler so polarisiert wie Systemd. Da wundert es nicht, dass eine der im Vorfeld am heftigsten diskutierten Neuerungen Journald betrifft, die Logging-Komponente von Systemd. Der Dienst aktiviert nun den sogenannten Persistent Mode, speichert also die durch ihn aufgezeichneten Log-Dateien permanent. Bisher war diese Funktion nicht aktiv, und Debian-Admins mussten auf andere Lösungen setzen, um Log-Dateien zu persistieren, etwa mittels Rsyslog.

Flugs tobten auf diversen Debian-Mailing-Listen die üblichen Diskussionen rund um vermeintliche Allmachtsfantasien Lennart Poetterings. Bei genauerer Betrachtung stellt man allerdings fest, dass das für die meisten Anwender gar keine Änderung ist: Sie haben lokale Log-Dateien einzelner Dienste schon bisher nicht per Rsyslog oder mit einem anderen Werkzeug von den Systemen abgeholt. Mehr noch: Wer tatsächlich bisher Rsyslog benutzte, kann das selbstverständlich weiterhin tun.

Das Setup hat sich noch nicht mal im Hinblick auf seine Konfiguration geändert, sodass bestehende Installationen einfach wie gehabt weiterhin funktionieren. Einmal mehr sehen sich die militanten Systemd-Gegner desavouiert. Ohnehin stellt sich die Frage, wieso sie sich nicht längst um Devuan scharen, das kürzlich ebenfalls in einer aktuellen Version auf Basis von Debian “Bullseye” erschienen ist.

Chef fehlt

Zwar gehört Chef hierzulande nicht unbedingt zu den beliebtesten Werkzeugen in Sachen Automation – Puppet und Ansible sind wesentlich weiter verbreitet. Der einstige Hauptkonkurrent von Puppet hat aber auch hierzulande eine kleine Fangemeinde. Die muss nun aufpassen, wenn sie auf Debian 11 aktualisiert, denn das Projekt hat Chef aus “Bullseye” komplett entfernt. Das liegt nicht etwa an der Technik: Chef, Inc. ist in der Community bekannt und gefürchtet, weil es die eigenen Markenrechte mit eiserner Faust durchsetzt. Alles, was nicht unmittelbar von Chef kommt, darf in den Augen der Firma auch nicht Chef heißen, selbst wenn es sich dabei um freie Software handelt. Den Debian-Entwicklern sind solche Spielchen nicht neu: So fehlte etwa lange Zeit Firefox in der Distribution, der aus ähnlichen Gründen in Iceweasel umbenannt worden war.

Für Chef ist den Debian-Entwicklern dieser Aufwand aber offensichtlich zu hoch, und so hat man sich dazu entschlossen, die Software aus der Distribution zu werfen. Ein großer Beinbruch ist das nicht. Zum einen gibt es eine freie Chef-Distribution in Form von CINC, zum anderen passende Chef-Pakete direkt vom Anbieter [1]. Der Admin muss im Rahmen eines Updates aber im Hinterkopf behalten, dass die Chef-Komponenten auf seinen Systemen zunächst fehlen, wenn er inoffizielle Pakete und solche von Drittanbietern vor dem Update wie empfohlen löscht.

Python 2

Wer die Arbeit des Debian-Projekts seit einer Weile verfolgt, weiß: Das Thema der Migration von Python 2 hin zu Python 3 zieht sich durch das System wie der sprichwörtliche Strudelteig. Schon für Debian GNU/Linux 10 lautete die offizielle Sprachregelung, dass in der Distribution zwar noch ein paar Python-2-Pakete vorhielte, sie aber nicht mehr für die Anwender bestimmt seien, sondern lediglich für interne Zwecke der Distribution. Wer die Hoffnung hegte, dass Python 2 in Debian 11 endlich Geschichte sei, sieht sich enttäuscht: Eine Rumpfversion von Python 2 liegt auch “Bullseye” noch bei. Die Anzahl der paketierten Module dafür ist allerdings so klein, dass ein praktischer Nutzen in der Realität nicht mehr gegeben sein dürfte. Wer unter “Buster” also mit Hängen und Würgen irgendwie noch Python-2-Anwendungen betrieben, muss sich in “Bullseye” endgültig von ihnen verabschieden. Das ist auch gut so.

NIS-Pakete

Wer sein Debian-System etwa mittels LDAP an eine zentrale Verwaltung für Benutzer angekoppelt hat, nutzt dafür im Hintergrund NSS, NIS oder NIS+. Die gehörten bisher zu glibc, kommen nun aber in den eigenen Paketen libnss-nis und libnss-nisplus daher. Der Admin tut insofern gut daran, diese Pakete auf allen betroffenen Systemen per Automation oder auch händisch zu installieren, damit die komplexe Benutzerverwaltung erhalten bleibt.

Keine Barrieren für XFS

Aufpassen müssen auch Administratoren, die XFS verwenden und in ihrer Fstab bisher mit den Parametern »barrier« und »nobarrier« steuerten, auf welche Art und Weise das System XFS-Dateisysteme einhängt. Die beiden Parameter, die Dateisystembarrieren aktivieren oder deaktivieren, gibt es in XFS schon seit einer Weile nicht mehr. Die Änderung schlägt nun auch auf Debian-Systeme durch. Das hat im ungünstigsten Fall drastische Konsequenzen: Sind die Parameter für zentrale Partitionen definiert, schlägt deren Einhängen fehl. Es kann dann vorkommen, dass der gesamte Startvorgang hängenbleibt.

Rsync ändert Parameter

Wer für seine Systeme keine Backup-Software von der Stange nutzt, sondern auf eine selbstgebaute Lösung zurückgreift, der nutzt unter der Haube mit einer gewissen Wahrscheinlichkeit Rsync. Das ändert in Debian 11 einige seiner Parameter: »–copy-devices« heißt nun »–write-devices«, »–noatime« wird zu »–open-noatime«. Ärgerlicherweise funktionieren die alten Parameter ab Debian 11 nicht mehr. Ein Aufruf mit den alten Parametern führt also dazu, dass Rsync mit einer Fehlermeldung den Dienst quittiert. Wer das Tool in der eigenen Installation einsetzt, sollte Aufrufe also auf die entsprechenden Parameter hin untersuchen und sie anpassen.

Container

Bei vielen IT-Setups, die dieser Tage neu entstehen, ist der Betrieb von Containern ein zentraler Faktor. Die meisten kommerziellen Linux-Distributoren haben sich klar positioniert: Red Hat propagiert die Nutzung der eigenen Container-Runtime Podman für die Kompatibilität mit CRI-O. Auch Suse setzt mittlerweile auf offene Standards. Canonical hat sich aus heutiger Sicht ebenfalls eher auf Podman eingeschossen. Bei allen Anbietern dürften die Beweggründe sich ähneln, ist Podman doch die modernere Option und ein echtes Community-Produkt, das nicht von einer einzelnen Firma abhängt.

Um Docker hingegen wurde es in den vergangenen Jahren ruhiger. Die Firma, die den Hype um Container unter Linux einst auslöste, konnte davon letztlich nicht groß profitieren. Die Container-Laufzeitumgebung Docker in der Community-Edition gibt es aber noch immer. Anders als andere Distributionen will Debian den Anwendern nicht vorschreiben, was sie zu nutzen haben (Abbildung 3). Daher liegen der Distribution sowohl Podman als auch Docker in der Community-Edition bei. Wer ein aktuelleres Docker braucht, kann es weiter direkt beim Hersteller beziehen.

Abbildung 3: Debian GNU/Linux 11 lässt Systemverwaltern die Wahl, weiter Docker zu nutzen oder auf Podman umzusteigen.

Alte Cgroups inkompatibel

Cgroups, ein zentrales Sicherheits-Feature aktueller Linux-Kernel, kommt meist in Kombination mit Namespaces daher. Es gibt zwei Versionen der Spezifikation, Debian GNU/Linux implementierte bisher die Version 1. “Bullseye” kommt nun hingegen mit Unterstützung für Cgroups v2, was besonders für die Systemverwalter eine Herausforderung darstellt, die Cgroups selbst anlegen, bearbeiten oder auswerten: Während die bestehenden Cgroups v1 in »/sys« noch anhand der laufenden Threads abgebildet waren, erfolgt das bei Cgroups v2 nun anhand der Prozesse. Zwar lässt sich das vorherige Verhalten mittels der beiden Kernel-Kommandozeilenparameter aus Listing 3 wiederherstellen. Die empfohlene Lösung ist das aber freilich nicht, und der Systemverwalter tut besser daran, das lokales Setup an die neuen Begebenheiten anzupassen. Als Lohn der Mühe winkt eine deutlich bessere Cgroups-Funktionalität in “Bullseye”.

systemd.unified_cgroup_hierarchy=false
systemd.legacy_systemd_cgroup_controller=false

mISDN ist weg

Sollte es noch Anwender geben, die auf mISDN und einen ISDN-Uplink angewiesen sind, kann man ihnen von einem Update auf Debian 11 nur dringend abraten: Die benötigten ISDN-Werkzeuge flogen ebenso aus der Distribution wie der zugehörige Treiber im Kernel. Das liegt weniger am bösen Willen der Debianer, sondern vielmehr daran, dass Linus Torvalds und seine Getreuen sich mit dieser Nischentechnik nicht mehr auseinandersetzen wollen. Hier muss also weiterhin Debian 10 herhalten, und wer sich in einer entsprechenden Situation befindet, sollte sich zeitnah nach Alternativen umsehen.

Auto-Installation

Ein paar Änderungen ergeben sich für Administratoren, die Debian mittels der Preseeding-Funktion des Debian-Installers automatisch auf ihren Systemen ausrollen. Zur Erinnerung: Der Debian-Installer (Abbildung 4) bringt schon seit über 15 Jahren Debian auf Computer, lässt sich wegen seiner modularen Art gut erweitern und leistet der Distribution nach wie vor treue Dienste. Dass Canonical mittlerweile einen eigenen Installer für Ubuntu baut und der Debian-Variante den Rücken gekehrt hat, perlt an den Debianern ab. Sie entwickeln ihr Werkzeug unbeirrt fort und sorgen so auch in Debian 11 dafür, dass Admins die lokale Konfiguration unter Umständen anpassen müssen.

Abbildung 4: Der Debian-Installer werkelt seit über 15 Jahren zuverlässig. Auch er durchläuft in Debian 11 einige Veränderungen.

In Debian 11 betrifft das insbesondere das Preseeding. Hier haben sich gegenüber der Vorversion nicht nur einige Schlüsselwörter geändert, sondern es kamen auch mehrere Features hinzu, über die sich der Endzustand des Systems nun noch feinkörniger definieren lässt (Abbildung 5). Allerdings haben die Entwickler es versäumt, eine Übersicht der Änderungen im Preseeding zur Verfügung zu stellen. Dem Administrator bleibt daher nichts anderes übrig, als die vorhandene Preseeding-Konfiguration mit dem neuen Installer zu testen und sich mittels Versuch und Irrtum an einen funktionalen Zustand heranzutasten.

Abbildung 5: Neue Preseeding-Optionen kommen hinzu, andere fallen weg: Wer Debian automatisch installiert, hat ein bisschen Arbeit vor sich.

Die Änderungen am Installer beschränken sich jedoch keineswegs nur aufs Preseeding. Besonders Desktop-Anwender dürfte interessieren, dass es nun inoffizielle Abbilder des Debian-Installers gibt, die ein Werkzeug zur automatischen Installation binärer Firmware enthalten. Dazu muss man wissen: Alles, worauf offiziell “Debian” steht, muss nach dem Willen der Entwickler den Anforderungen der Debian Free Software Guidelines (DFSG) entsprechen. Proprietäre Firmware, wie viele Hardwarekomponenten sie heute zum Funktionieren benötigen, schließen die DFSG jedoch aus. In der Vergangenheit war es oft unmöglich, Debian auf solchen Geräten auch nur zu installieren.

Die inoffiziellen Installer-Abbilder [2] lösen das Problem nun, indem sie eventuell benötigte Firwmare während der Installation nachladen (Abbildung 6). Im Gegenzug dürfen sie sich allerdings nicht mehr offiziell Abbilder zur Installation von Debian GNU/Linux nennen, auch wenn sie genau das tun. Obendrein gelten sie nicht als offiziell unterstützt. mit diesem Kompromiss können die Verfechter freier Software ebenso leben wie die Pragmatiker, die Debian einfach nur ohne gröbere Schwierigkeiten auf bestimmten Systemen installieren wollen.

Abbildung 6: Kompromiss zwischen den FL/OSS-Verfechtern und Pragmatikern: Die Non-free-Abbilder werden offiziell nicht unterstützt, bringen aber Firmware mit, ohne die sich Debian auf manchen Systemen gar nicht installieren ließe.

Sicherheit

Abschließend sei auf einen Umstand hingewiesen, der mit dem Betrieb des Systems unmittelbar nichts zu tun hat, wohl aber mit seiner Sicherheit. In den vergangenen Jahren hat die Programmiersprache Go massive Verbreitung in der IT erfahren. Sie unterscheidet sich von anderen Sprachen vor allem dadurch, dass es sich bei Go-Programmen meist um statisch gelinkte Binaries handelt, die ohne externe Abhängigkeiten laufen. Das Debian-Archiv stellt das nach Aussagen der Entwickler vor so manche Herausforderung: Einerseits brauchen statisch gelinkte Go-Binaries mehr Platz als dynamisch gelinkte Programme, andererseits frisst ihre Kompilierung mehr Ressourcen, die in der Paketbauinfrastruktur des Debian-Projekts aktuell nicht zur Verfügung stehen.

Das Sicherheitsteam von Debian hat sich daher zu einem eher radikalen Schritt entschieden und schränkt den Sicherheits-Support für Go-Programme bis auf Weiteres ein – so lange, bis es Ressourcen nachgerüstet hat. Anwender können also anders als bei anderen Teilen der Distribution nicht damit rechnen, Sicherheitsaktualisierungen mehr oder minder tagesaktuell zu erhalten. Man wolle, so das Sicherheitsteam, Go-Updates stattdessen bis auf Weiteres nur mit den Point-Releases von Debian ausliefern. Die erscheinen im Schnitt alle drei bis vier Monate.

Fazit

Debian GNU/Linux 11 erweist sich als behutsames Update, bei dem Debian die eigenen Tugenden nicht vergisst und dem Anspruch absolut gerecht wird, Überraschungen zu vermeiden. Wer ein Debian-System betreibt, kann in den allermeisten Fällen ein Upgrade mittels der gewohnten Mechanismen vornehmen. Im Test der Redaktion funktionierte das ganz hervorragend: Von drei Systemen mit exemplarischer Konfiguration und hohem Automationsgrad fiel während des Updates von “Buster” auf “Bullseye” kein einziges auf die Nase. Zugegeben: Diese Systeme waren im Wesentlichen so gepflegt, wie Debian es vorsieht, und kamen ohne externe Zusatzsoftware aus. Wer solche wie beschrieben erst vom System verbannt und dann nach dem Update als frische Version erneut aufspielt, kommt aber auch an dieser Stelle mit einiger Wahrscheinlichkeit ohne Probleme aus. Das Update auf Debian 11 kann man den allermeisten Systemverwaltern insofern wärmstens ans Herz legen. (jcb/jlu)