Debian übernimmt die Steuerung der Beschleuniger
Das CERN stellt mehrere tausend sogenannte Front-End-Rechner auf Debian Linux um. Diese Systeme befinden sich unter der Erde und steuern direkt die Hardware der Teilchenbeschleuniger. Zuvor hatte das Forschungszentrum mehr als 20 Jahre lang vor allem Distributionen aus der Red-Hat-Familie eingesetzt.
Auslöser waren zwei strategische Änderungen im Red-Hat-Ökosystem. Red Hat verkürzte 2020 die geplante Unterstützung für CentOS 8 um acht Jahre. Statt Ende 2029 endete der Support bereits Ende 2021.
Hinzu kamen höhere Mindestanforderungen an die Prozessorarchitektur. Für klassische IT-Systeme ist ein solcher Technologiesprung meist planbar. Bei eingebetteten Steuerungsrechnern mit speziellen Platinen, Treibern und Verkabelungen kann daraus jedoch ein mehrjähriges Hardware-Projekt werden.
Neue RHEL-Versionen schließen vorhandene Hardware aus
RHEL 9 und CentOS Stream 9 setzen mindestens x86-64-v2 voraus. Dadurch wären 47 % der eingebetteten CERN-Steuerungsrechner inkompatibel geworden. RHEL 10 verlangt x86-64-v3 und hätte weitere 17 % der verbleibenden Systeme ausgeschlossen.
| Änderung | Auswirkung beim CERN |
|---|---|
| CentOS 8 Supportende | Verkürzung von Ende 2029 auf Ende 2021 |
| RHEL 9 mit x86-64-v2 | 47 % der Steuerungsrechner inkompatibel |
| RHEL 10 mit x86-64-v3 | Weitere 17 % der verbleibenden Rechner inkompatibel |
| Geschätzter Hardware-Umbau | Mindestens 5,4 Millionen CHF |
| Geschätzte Erfolgschance | 20 % |
| Planungshorizont | Bis zu 15 Jahre |
Ein Austausch hätte nicht nur neue Standardrechner erfordert. Das CERN hätte elf eigene Platinen neu entwickeln sowie Teile der Verkabelung und der Einbauten erneuern müssen. Einige Arbeiten hätten Grabungen in 100 Metern Tiefe notwendig gemacht.
Für das Projekt wären zwei Elektroingenieure, zwei Softwareingenieure und zwei Techniker eingeplant worden. Trotz geschätzter Kosten von mindestens 5,4 Millionen CHF bezifferte das CERN die Erfolgschance lediglich auf 20 %.
Der Wechsel zu Debian ist sinngemäß eine „Software-Lösung für ein Software-Problem“, erklärte CERN-Ingenieur Federico Vaga.
Debian wird an die CERN-Infrastruktur angepasst
Die Migration ist technisch anspruchsvoller als der Austausch einer gewöhnlichen Server-Distribution. Die Front-End-Rechner starten über das Netzwerk und binden ihr Root-Dateisystem per NFS ein. NFS ist ein Netzwerkprotokoll, über das Dateisysteme zentral bereitgestellt werden.
Für die spezielle Beschleuniger-Hardware benötigt das CERN eigene Kernel-Treiber. Diese werden für konkrete Kernel-Versionen kompiliert und gemeinsam mit eigenen Kerneln, Startabbildern und Bootloader-Konfigurationen versioniert. Eine lokale Übersetzung der Treiber auf den eingebetteten Rechnern wäre zu ressourcenintensiv.
Die bestehende Build-Infrastruktur war stark auf RPM-Pakete aus dem Red-Hat-Umfeld ausgerichtet. Deshalb ergänzte das CERN sein Koji-System um Unterstützung für Debian-Pakete. Das Werkzeug ELBE versetzt die Build-Server dafür in Debian-Umgebungen.
Wie hoch der Personalaufwand für diese Anpassungen und die Treiber-Portierung tatsächlich ausfällt, ist nicht bekannt. Auch die laufenden Kosten des kommerziellen Debian-Supports wurden nicht veröffentlicht. Ein belastbarer Gesamtkostenvergleich mit RHEL ist daher bislang nicht möglich.
Support bis 2033 kombiniert Community und Dienstleister
Das CERN plant den Debian-Einsatz bis 2033. Vorgesehen sind Debian 13 mit Extended Long Term Support, kurz ELTS, und später Debian 15. Support und Schulungen übernimmt Freexian.
Damit verzichtet das Forschungszentrum nicht auf professionellen Support. Es trennt jedoch die technische Basis stärker vom jeweiligen Dienstleister. Debian bleibt ein Community-Projekt, während Wartung und Schulung separat eingekauft werden können.
Diese Konstruktion reduziert das Risiko, dass eine einzelne Produktentscheidung kurzfristig einen umfangreichen Hardware-Austausch erzwingt. Sie verlangt im Gegenzug eigene Kompetenz für Paketierung, Treiber, Tests und Betriebsprozesse. Auch Community-Software beseitigt den Integrationsaufwand nicht.
Wie solche Projekte Verantwortung organisieren, zeigt auch die Debatte darüber, dass Debian KI-generierten Code zulässt, Entwickler aber verantwortlich bleiben. Für kritische Infrastruktur ist diese klare Zuordnung wichtiger als das verwendete Entwicklungswerkzeug.
Andere CERN-Systeme bleiben bei Red Hat und AlmaLinux
Der Wechsel betrifft nicht die gesamte IT des CERN. Die Arbeitsplätze der Physiker, intern Consoles genannt, laufen mit AlmaLinux 10 und Xfce in einem isolierten Netzwerk. Die Datacenter-Systeme verwenden derzeit RHEL 9 und sollen voraussichtlich ebenfalls auf AlmaLinux 10 wechseln.
Das CERN entscheidet damit je nach Einsatzgebiet. Standardisierte Arbeitsplatz- und Rechenzentrumssysteme können weiterhin von der bestehenden Red-Hat-Integration profitieren. Bei langlebiger Spezialhardware erhält dagegen die breite Hardware-Unterstützung von Debian Vorrang.
Lehre für Industrie und kritische Infrastruktur
Der Fall ist besonders für Maschinenbauer, Forschungseinrichtungen und Betreiber von Operational Technology relevant. Solche Organisationen planen Hardware oft für zehn Jahre oder länger. Betriebssystemanbieter können ihre Supportfristen und technischen Mindestanforderungen jedoch wesentlich schneller ändern.
Damit wird die Wahl der Distribution zu einer Investitionsentscheidung. Entscheidend sind nicht nur Lizenz- und Supportkosten, sondern auch CPU-Anforderungen, Treiberverfügbarkeit, Migrationspfade und die Kontrolle über Build-Prozesse. Wer diese Faktoren erst beim Supportende prüft, verliert Verhandlungsspielraum.
Ein ähnliches Muster zeigt sich außerhalb von Linux. So konnte Tottenham durch den Ersatz von VMware 85 % der Lizenzkosten sparen. In beiden Fällen entsteht wirtschaftlicher Druck nicht primär durch fehlende Funktionen, sondern durch veränderte Bedingungen im Ökosystem eines Anbieters.
Das CERN zeigt zugleich, dass Open Source und Self-Hosting auch für hochkritische Systeme praktikabel sein können. Voraussetzung sind reproduzierbare Builds, eigene Tests, kontrollierte Updates und langfristig gesicherter Support. Der wichtigste Vorteil liegt weniger im kostenlosen Bezug der Software als in der Möglichkeit, Hardware- und Softwarezyklen wieder selbst aufeinander abzustimmen.

