Ex-Ubuntu

Ein Rant.

Irgendwie finde ich gerade keine einleitenden Worte, um zu beschreiben, wie stark mein Hass auf Ubuntu , gerade als Server-Betriebssystem, im Moment ist. Als Debian-Derivat bezeichne ich es gerne als old-old-stable, und das aus gutem Grund. Während manche Pakete durchaus auf einem halbwegs aktuellen Stand sind, hinken andere um Jahre hinterher. Beispiele?

Ubuntu 22.04 LTS, veröffentlicht Mitte 2022, Standard-Support bis Mitte 2027
- libewf2, eine Bibliothek, um mit forensischen Images umzugehen
  Version 20140807 (aktuell ist die Version 20240506 von Mitte 2024)
- mbuffer, ein Tool, um Daten vor dem Wegschreiben im RAM zu buffern, um schwankende Schreibraten zu vermeiden
  Version R20210328 (aktuell ist die Version 20241007)

Jetzt mag man argumentieren, dass LTS nicht nur längeren Support bedeutet, sondern auch gleichzeitig heißt, dass die ausgelieferte Software nur Sicherheits- und keine Programm-Updates bekommt. Sprich: Wird in der LTS eine Version 1.2.7 ausgeliefert, wird man keine 1.3.0 bekommen. Das mag aus Stabilitätssicht für einige Firmen sinnvoll sein, aus meiner Sicht ist es allerdings ein Klotz am Bein, da auch mit den LTS-Versionen oft hoffnungslos veraltete Versionen ausgeliefert werden, die schon zum Zeitpunkt der Integration mehrere Versionen zurückliegen. Da hilft es auch nicht, wichtige Security-Bugfixes in die Versionen zu backporten.

Warum mich das gerade wieder so nervt? Ich erläutere es an den beiden Beispielen von oben, die allerdings nur die Spitze des Eisbergs darstellen.

libewf2

Wie beschrieben wird libewf2 verwendet, um forensische Images, die im EWF-Format vorliegen, zu lesen und zu schreiben. Die in Ubuntu nach wie vor ausgelieferte Version hat einen Versionsstring, der mit 201408 beginnt. Dieser Versionsstring bezieht sich eigentlich auf die libewf (ohne 2), also die Legacy-Version. Offenbar wird hier also statt der modernen libewf2-Version (Versionsstring 20231119 oder 20240506) die alte Version unter falschem Namen ausgerollt. Richtig, die Legacy-Version , deren Changelog den letzten Eintrag 2014 hatte.

Warum ist das nun so relevant? Nun, versucht einfach mal, ein forensisches Image einer Partition oder eines Datenträgers im EWF-Format zu erstellen, das größer als 1TB ist. Das kommt heutzutage relativ häufig vor, denn die Plattenkapazität wächst ständig und ist bei Storage-Platten derzeit (Ende 2024) bei 20TB und mehr angekommen. Also sind Images dieser Größe gar nicht mal so unüblich.
Nun wird der Image-Erstellungsprozess vermutlich durchlaufen, entweder weil man dafür ein System mit aktueller libewf2 bzw. einer aktuellen ewfacquire-Binary verwendet, oder weil es beim Schreiben keine Größenbegrenzungen gibt - ich habe mich nicht tief genug in den Quellcode eingegraben, um zu sehen, auf welcher Seite es letztendlich genau scheitert. Egal wie, wir haben jetzt ein Image, das 1TB oder mehr an Daten fasst. Nun versuchen wir, es mittels einem alten ewfmount (oder anderen Tools aus dem Paket) zu laden. Und dann kommt das böse Erwachen: Klappt nicht. Die Datei kann nicht eingelesen bzw. eingebunden werden, weil irgendwelche Header in den Images kaputt sind. Mit neueren libewf2-Versionen existiert der Fehler nicht, doch die finden sich selbst im aktuell verfügbaren Ubuntu 24.04 LTS nicht. Es bleibt also nur das selber Kompilieren…

mbuffer

Gerade wenn man Archiv-Tapes (also wirklich auf Band) schreiben möchte, die außer Haus eingelagert werden, zum Beispiel in einem Bankschließfach, möchte man sicherstellen, dass die Daten auf den Bändern geschützt sind. Ein auf dem Weg zum Schließfach oder zurück verlorenes Band oder ein anderweitiger unberechtigter Zugriff auf die Datenträger sollte in keinem Fall dazu führen, dass sensible Daten im Klartext auslesbar sind. Well, das ist heute zum Glück ein gelöstes Problem, encryption to the rescue!
Nun stehe ich allerdings vor einem Problem. Während ich die Daten mit tar problemlos auf ein oder mehrere Bänder wegschreiben kann, unterstützt das Tool keine inline-Verschlüsselung. Ich muss also den Datenstrom, nachdem er von tar verarbeitet wurde, direkt an gpg oder openssl weiter pipen, die dann blockweise die Daten verschlüsseln. Heraus kommt wie zu erwarten ein reversibler Datensalat, aber bei den Datenmengen, mit denen ich hantiere, möchte ich den nicht erst einmal irgendwo ablegen müssen, um ihn dann von da auf das Band zu schreiben. Also pipe ich die Ausgabe von openssl weiter an mbuffer, das sich gleichzeitig um das Buffern der Daten im RAM kümmert und nebenher auch noch die Tape-Verwaltung (was passiert, wenn ein Tape voll ist und gewechselt werden muss, etc.).

Und hier entsteht wieder ein Problem. Die veraltete 2021er Version von mbuffer unterstützt das selbstständige Tapewechseln nur rudimentär. Auch die in Ubuntu 24.04 LTS enthaltene Version R20230301 beherrscht die wichtige Umgebungsvariable MBUFFER_VOL nicht. In dieser Variable übergibt mbuffer analog zu der aus tar bekannten TAR_VOLUME-Variable einen mit jedem Tapewechsel im aktuellen Prozess hochzählenden Integer, startend mit 1. Das ermöglicht es, dem Tapewechsel-Befehl (der meistens aus einer selbstgeschriebenen Scriptdatei besteht), das jeweils richtige nächste Band zu laden. Ich übergebe dem Script beispielsweise eine Liste der zu verwendenden Tape-Slots im Tapewechsler, beginnend mit dem ersten geladenen Tape und endend mit dem letzten freien Tape im Gerät. Nun soll das Wechselscript je nachdem, wie oft es schon gelaufen ist, immer jeweils das nächste Tape laden. Beim ersten Wechsel also das Tape mit dem Index 1, beim darauffolgenden das mit Index 2, und so weiter. Da aber den veralteten Versionen in Ubuntu die Variable fehlt, mit der mbuffer automatisch diesen Index hochzählt, funktioniert der Tapewechsel-Mechanismus nicht sauber und man muss umständlich einen eigenen Mechanismus schreiben, der beispielsweise alle Tape-Indices in eine Datei schreibt und bereits geladene Indices herauslöscht - ein sperriger und fehleranfälliger Mechanismus.

Weg mit Ubuntu, her mit Alma

Der mit einem Augenzwinkern verwendete Begriff old-old-stable für “komplett veraltete Software” täuscht darüber hinweg, dass man sich im Endeffekt, wenn man nicht gerade darauf angewiesen ist, legacy-Software zu betreiben, oft mehr Probleme ins Haus holt als man damit löst. Sicher, es mag unklug sein, bleeding-edge-Software auf Produktivsystemen zu betreiben, aber man kann es auch übertreiben. Fedora-basierte Systeme machen beispielweise vor, wie man eine gute Balance zwischen frischer Software und Stabilität realisieren kann. Alte Software ist vor allem eins: Alt. Nicht mehr den modernen Anforderungen gewachsen. Und Betriebssysteme, die alte Software ohne Alternative in den Paketquellen ausliefern, sind aus meiner Sicht in nahezu keiner IT-Umgebung sinnvoll, ausgenommen einige ganz wenige Nischen, die man sich aber wirklich suchen muss und auch da überlegen sollte, ob eine Modernisierung nicht weniger schmerzhaft als eingeschränkte Software wäre.

Als Ausweg sehe ich in meinen Anwendungsfällen (Forensik und Archivierung) Alma Linux . Es basiert auf Fedora und positioniert sich als eine offene Alternative zu Red Hat Enterprise Linux (RHEL). Und mit der Fedora-Abstammung kommt unter anderem auch das Geschenk der ziemlich aktuellen Paketquellen. Ich muss mich nicht mehr mit nicht lesbaren Images herumärgern, die entweder neu erstellt oder umständlich anderweitig konvertiert werden müssen. Ich muss mich nicht verbiegen und fehleranfällige Lösungen bauen, nur um verschlüsselt auf mehrere Tapes schreiben zu können. Und so viel mehr.