Debian, du alter Greis

Debian gilt als stabil, daran besteht kein Zweifel. Doch bei Debain bedeutet das leider alt, sogar schon zum Release. Ein Wechsel steht an, in diesem Artikel möchte ich darauf etwas näher eingehen.

Abgesehen von den Alterserscheinungen bei den von der Distribution bereitgestellten Paketen läuft das System erstaunlich rund. Die meisten Probleme wurden nicht durch die Distribution, sondern durch die darauf laufenden Anwendungen verursacht.

Wenn es dann doch mal Ärger gab lag dies meist im Setupprozess verschiedener Kleinigkeiten wie z.B. systemd-resolved. Sobald ich mal eine gut funktionierende Config für etwas gefunden habe, wird diese auch auf allen Systemen genutzt/mitgeschleift. Durch die teilweise doch sehr “konservativen” Pakete gab es bei manch einer kopierten Konfigurationsdatei Zeilen, die von der Altversion nicht eingelesen werden konnten, da es diese Einstellung “damals” nocht nicht gab, der Dienst verweigerte den Start. Die Hälfte des schwarzen Peters muss ich mir auch selbst zuschieben – Konfigurationen von einem (Paket)aktuellem Fedora in ein Debian zu drücken ist vielleicht nicht ganz so fair. 😅

Warum nun der Wechsel?

Hauptsächlich wegen den alten Paketen. Um vielleicht mal Beispiele zu geben:

WordPress

Dank der PHP Version 7.4 die mit Debian ausgeliefert wird, erscheint eine Warnmeldung unter Websitezustand – es würde keine aktuelle PHP Version genutzt werden. Frustrierend, was soll man denn machen? 3rd Party Repos einbinden und Distributions-eigene Pakete ersetzen? Dafür trägt Debian nicht die alleinige Schuld, die WordPress Entwickler könnten sich ruhig mal anscheuen was aktuell supported ist und nicht gleich bei der nächsten PHP-Version das Dashboard mit Warnungen fluten.

Stand 2.9.2022 ist die Meldung verschwunden, offensichtlich wurden meine Worte noch vor Veröffentlichung erhört, erhalten bleibt es trotzdem. Mein Bauchgefühl sagt das kam bzw. verschwand mit dem Update auf WordPress 6.

Nextcloud Signaling Server

Für eine auf dem Server mitbetriebene Nextcloud, benötigte ich eines Tages den Signaling Server für Videokonferenzen mit mehr als nur zwei Teilnehmern in stark gefirewallten Netzen. Das Paket libSRTP wird mindestens in Version 2.1 benötigt, Debian bietet mir nur 1.4.5. Belieben nur zwei Möglichkeiten: Unstable oder Drittquellen, beides ist nicht schön. Es kam eine dritte Option dazu, Verzicht, Ärger und Frustration. Es wurde dann doch WebEx von Cisco.

KeePassXC

Aktuell stehen wir bei Version 2.7.1, die Paketquellen sind bei 2.6.2. Ubuntu ist hier etwas weiter mit der 2.6.6. Etwas solch sicherheitsrelevantes wie ein Passwortmanager könnte doch auch, wie Thunderbird und Firefox, vom Entwicklerteam eine Sonderbehandlung für aktuelle Versionen erhalten. Dazu sollte ein Leitfaden erarbeitet werden, welche Software sich für “aktuell/rolling” qualifiziert.

Wie man solche Probleme lösen könnte

Debian bekommt ausreichend Feedback, sei es von den Usern oder der Paketdatenerfassung. Warum wertet man das nicht in irgendeiner Form aus, zieht Rückschlüsse auf die “Most 1000 used Packages” und berücksichtigt diese im Freeze, sodass bei Release die aktuelle Version ausgeliefert wird. Es kann nicht sein das die Debian-Devs nicht wissen das ihre Distribution z.B. gern als Webserver zum Einsatz kommt, sei es nur über SSH zu steuern oder mit Panel wie z.B. Plesk.

Was machst du jetzt genau wegen den Alterserscheinungen?

Wechseln, so schade es auch ist. Im Mai war der Release von RedHat 9, lange musste ich darauf warten. Genau hier wird die Reise hingehen. Wer RedHat nicht aktiv verfolgt wird, sich jetzt zu Recht fragen, warum man von einem zweijährigen Release-Zyklus auf einen 10 Jahres Zyklus umsteigt. Seit RHEL 8 stimmt das nicht mehr für alle Teile des Systems. Mit den damals neu eingeführten AppStreams sind die für mich wichtigsten Pakete und deren Abhängigkeiten immer in aktueller Version verfügbar, während die Systembasis die gleiche bleibt. IBM hat angekündigt RedHat Enterprise Linux alle drei Jahre einem Update zu unterziehen. So ist das Basissystem alle drei Jahre aktualisierbar, der bekannte zehnjährige Support ist weiterhin gegeben. Die Versionsprobleme die “damals” CentOS 7 mit sich brachte sind dadurch nicht mehr vorhanden.

Es wird jedoch nicht RHEL 9 direkt sondern Alma Linux 9. Viel mehr hat mich das nicht abschaltbare “RHEL nach Hause telefonieren” dazu gebracht. Soblad man sich in den Customerbereich auf redhat.com einloggt, sieht man welche Systeme mit welchem Patchstand man lizensiert hat. Zusätzlich benötigt RHEL eine Aktivierung, ähnlich – aber nicht ganz so schmerzvoll – wie Windows. Mag sein das dieses Feature nützlich ist, ich vertrete die Meinung: Meine Systeme und ICH, kein anderer, entscheidet was, wann wo hin geschickt wird! Hier geht es nicht nur um Datenschutz (und Verarbeitung in Drittländern) sondern auch um das persönliche Privatsphäreempfinden. Man fühlt sich “anonym” doch etwas wohler.

Alma Linux ist auch nicht perfekt, es gibt eine Art des Trackings die auch offen Kommuniziert wird. dnf countme ist standardmäßig aktiviert und kann ohne Probleme deaktiviert werden. Countme ist ähnlich zur Debian Paketdatenerfassung, es wird gezählt welches Paket wie oft installiert wird. Als richtiges Tracking würde ich das nicht bezeichnen, man könnte so etwas auch aus den Zugriffs-Logs des Webservers auslesen. Wer sich, genau wie ich, daran stört: find /etc/yum.repos.d/ -type f -name '*.repo' | xargs sed -i 's/countme=1/countme=0/g'

Rocky Linux war spätestens mit dem Release der Version 9 raus, CentOS hatte auf seine letzten Tage Probleme kurz nach RHEL zu veröffentlichen, so auch Rocky 8. Gebessert hat sich das nicht, mit Version 9 hingen sie ebenfalls deutlich hinterher. Man denke hier mal an wichtige Sicherheitsupdates bei 0-Day Exploits, nein danke!

Eventuelle Schwierigkeiten

Grundsätzlich kann man sagen ein NGINX ist ein NGINX, ob er jetzt auf Debian oder RedHat läuft. Die Feinschmecker wissen das sich die Pfade unterscheiden, das kann man mit dem Paket httpd-filesystem an Debain (und für mich nachvollziebarere) /var/www anpassen.

Den viel größeren Brocken sehe ich bei SELinux. Abseits von der nicht abflachenden Diskussion “ist von der NSA” usw. ist es eine zusätzliche Schicht die bedacht werden muss – ein potetieller Störenfried. Nach wochenlangem Lesen, verstehen und ausprobieren ist mittlerweile ein Punkt erreicht an dem nicht nur stumpf Befehle aus dem Internet per Copy&Paste ins Terminal gehämmert werden, sondern ich verstehe immer mehr was da eigentlich passiert und kann damit umgehen. echo 0 > /selinux/enforce ist keine gute Idee. SELinux bietet definitv eine steile Lernkurve!

Abschließend bleibt mir nur noch zu sagen: Danke Debian für deine treuen Dienste, du alter Knochen!

Teilt den Beitrag, falls ihr mögt

Vielleicht gefällt Dir auch

53 Kommentare
Newest
Oldest Most Voted
Inline Feedbacks
View all comments