Aktualisierter Unterbau

ArchivistaBox neu mit 'Debian Jessie'

Egg, 29.9.2016: Die bisherigen Versionen der ArchivistaBox arbeiten sehr stabil. Trotzdem gilt es nach mehr als fünf Jahren von den aktuellen Versionen allmählich Abschied zu nehmen. Dies deshalb, weil das darunterliegende Betriebssystem Debian langsam aber sicher veraltet. Der nachfolgende Blog gibt über das Warum und Wie Auskunft und gibt einen guten Überblick, warum die ArchivistaBox nur 'Debian Jessie' like in Anführungszeichen ist. Für all diejenigen, welche technisch nicht interessiert sind, kann hier als Zusammenfassung gesagt werden, es bleibt alles beim alten.

Neue Hardware verlangt nach neuer Software

Der technologische Fortschritt bei der Hardware ist zuweilen immens. Dazu sei gerne an die neue Hardware für ArchivistaVM erinnert, die vor vier Wochen vorgestellt wurde. Diese Boxen arbeiten um einige Faktoren performanter als die bisherigen Boxen, obwohl die Grösse der Gehäuse faktisch halbiert wurde. Nun liegt es in der Natur der Sache, dass eine neue Hardware nicht immer mit einer alten Software arbeiten kann, weil die alte Software die neue Hardware z.B. ja noch nicht einmal kennt.

Dazu ein Beispiel: Die neuen 10-GBit-Netzwerkkarten, die neu im Standardumfang von ArchivistaVM enthalten sind, erfordeten neuen Treiber. Diese hätten zwar auf dem alten Betriebssystem Debian eingepflegt werden können, doch wurde die entsprechende Debian-Version dieses Jahr faktisch archiviert, d.h. jede neue Software hätte von Hand eingepflegt werden müssen. Über kurz oder lang wäre der Aufwand für die Pflege des 'alten' Unterbaus damit immer höher geworden. Zeit für ein Upgrade.

Debian Jessie mit vielen 'Neuerungen'

Debian rühmt sich, ein laufendes System könnte mit 'apt-get dist-upgrade' (d.h. mit einem Befehl) auf den aktuellen Stand gebracht werden. Allerdings ist dem faktisch nicht so, zu gross sind die Änderungen bzw. Inkompatiblitäten. Das beginnt bei Apache 2.4 und geht weiter zum Fakt über, dass anstelle von MySQL neu MariaDB ausgeliefert wird. Und wenn Debian versprochen hat, neben System-D würde SysInitV zum Starten des Betriebsystemes weiter unterstützt, so entspricht dies leider bestenfalls der halben Wahrheit.

System-D kann zwar einfach ersetzt werden, doch wurde der Dienst UDEV, welcher die Geräte (Festplatten, Tastatur, Maus etc.) verwaltet mit System-D verschmolzen. Auch wenn die System-D-Entwickler/innen ursprünglich versicherten, UDEV würde unabhängig von System-D fortentwickelt, so konnte/musste in der Praxis beim Upgraden der ArchivistaBox das Gegenteil beobachtet werden. Wenn exhorbitant viele Segfaults (unkontrollierte Programmabbrüche) auftreten, kann nicht von Kompatiblität und schon gar nicht von Stabilität gesprochen werden.

Es ist erstaunlich, wie wenig ernst die zahlreichen Mahner/innen, die vor der unbedingten Übermacht von System-D gewarnt haben, genommen werden. Nichts gegen System-D, der Vorteil liegt ja gerade darin, dass die Hardware komplett automatisch erkannt wird, doch wenn nicht einmal die grafische Umgebung (Xorg-Server) ohne System-D alias System-D-UDEV gestartet werden kann, dann ist Debian damit faktisch abhängig von System-D.

Unabhängigkeit der ArchivistaBox

Nun wird die ArchivistaBox unabhängig von einem bestimmten Betriebssystem entwickelt. Dies bedeutet, dass – obwohl Debian verwendet wird – der Installer und der Kernel selber 'gebacken' werden. Mit dem bedingungslosen Einsatz von System-D-UDEV wäre genau dies passiert, was 2005 (Wegfall der Abhängigkeit von Windows) und 2010 (Unabhängigkeit an ein bestimmtes Linux-System) vermieden wurde. Daher wurde System-D-UDEV vom Installer verbannt, sodass nicht auf dieser untersten Stufe der ArchivistaBox eine Abhängigkeit geschaffen wird, welche die Unabhängigkeit, vorallem aber die Stabilität der ArchivistaBox, gefährden würde.

Zur Erinnerung, eine jede ArchivistaBox (Ausnahme ARM-basierte Systeme) wird zunächst in den Hauptseicher (RAM) kopiert, womit direkt ohne einen Neustart nach der Installation gearbeitet werden kann. Dies hat in der Verangenheit zwar nicht dazu geführt, dass defekte Festplatten nicht dann und wann im Support erschienen, wohl aber, dass jederzeit nagelgenau aus der Fernwartung heraus gesagt werden konnte, ob die Platte hinüber ist.

Derartige Funktionen mögen für die Anwender/innen auf den ersten Blick nicht von Belang sein, doch gilt es die defekte Platte z.B. von einer vollen Disk zu unterscheiden, genauso wie defekte SATA-Kabel, wenn auch selten, mit dem Betriebssystem im Hauptspeicher deutlich einfacher festzustellen sind, ohne dass z.B. zu einer Live-CD gegriffen werden muss. Mit dem einzigartigen RAM-Modus der ArchivistaBox konnten Support-Einsätze vor Ort in den letzten fünf Jahren massiv verringert werden. Ferner im übrigen auch defekte Platten, denn bis 2010 machten defekte Sektoren auf Betriebssystemebene etwa zwei Drittel aller Ausfälle aus.

Darum die Anführungszeichen bei 'Debian Jessie'

Nun kann es nicht Sinn und Zweck sein, dass ein neuer Debian-Unterbau die Stablität unseres Installers bzw. der ArchivistaBox gefährdet, nur weil System-D-UDEV, das ohne System-D betrieben wird, nicht stabil arbeitet. Dies umso mehr, als die Entwickler von System-D nicht Müde werden zu betonen, dass sie Supportfälle bei System-D-UDEV ohne System-D gar nicht erst begutachten würden. Es fragt sich diesbezüglich schon, warum sich in der Debian-Community System-D durchzusetzen vermochte. Die Ahängigkeit von Debian Jessie zu System-D ist exhorbitant. Die Zukunft wird zeigen, ob die Entscheidung bei Debian für System-D richtig war, gewisse Zweifel scheinen aber schon angebracht.

Der neue Unterbau der ArchivistaBox wird bis 2020 mit 'Debian' arbeiten. Bis dahin wird sich weisen, wohin der Weg führt. Neben Debian stünden für die ArchivistaBox ja auch andere Linux-Derivate zur Verfügung, derzeit gut ohne System-D unterwegs sind ArchLinux und Gentoo. Keine Alternative darstellen würde aktuell der Debian-Fork Devuan, der angbit, ein Debian ohne System-D auszuliefern. Ganz einfach deshalb, weil Devuan derzeit nur als Beta verfügbar ist und Devuan ohne System-D-UDEV gar nicht betrieben werden kann.

ArchivistaBox bleibt sich treu

Im Grundsatz führt der neue Unterbau nicht dazu, dass die ArchivistaBox in anderer Form als bisher daherkommt. Einzig die Downloads dürften ca. 20 bis 30 Prozent länger dauern, um diese Spannbreite grösser sind die aktuellen Softwarepakete, die im Grundumfang der ArchivistaBox enthalten sind. Optimiertere Varianten hätten sich angeboten (z.B. QPDF mit 5 anstelle von PdfTk mit 50 MByte), doch wurde aus Kompatibilitätsgründen darauf verzichtet.

Das heisst nun nicht, dass es in Zukunft keine solchen Änderungen geben wird, doch werden diese zuächst intern intensiv getestet. Weiter sei hier angefügt, mit aktuell 500 MByte ist die ArchivistaBox 2016 noch immer deutlich kleiner als die erste CD des Jahres 2005, die es auf ca. 600 MByte brachte.

Der neue Unterbau der ArchivistaBox wird derzeit (Ausnahme ArchivistaVM) und bis 31.12.2016 auf Anfrage ausgeliefert. Per 1.1.2017 wird der neue Unterbau im Standard bei neuen Versionen aktiviert, es sei denn, Kunden erfragen explizit die alten Versionen. Die alten Releases können bis 31.12.2017 angefordert werden, sofern keine neuen Features benötigt werden. Zuletzt bleibt anzumerken, dass der neue Unterbau (wie oben erwähnt) zwar ca. 30 Prozent mehr Speicher benötigt, doch dass die On-Time-Komprimierng mit ZRAM plus/minus eine gleiche Verringerung im Hauptspeicher bewirkt, sodass die gesamte Hardware auch mit dem neuen Unterbau arbeitet.

Eingespielt wird der neue Unterbau bequem über die bisherigen Menupunkte (z.B. 'Online-Update' in WebConfig), es bleibt alles wie bisher. Dies trifft auch auf die Kern-Applikationen ArchivistaVM, ArchivistaDMS und ArchivistaERP zu, denn im Unterschied zum Betriebssystem bleiben diese Komponenten faktisch gleich. Es gibt im gesamten Code nur einige wenige Stellen, wo beim neuen Unterbau ein leicht anderes Verhalten notwendig ist. In diesem Sinne bleibt sich die ArchivistaBox auch mit neuem Unterbau ganz einfach treu.

« SwissRocket en miniatureVortrag linuxday.at »