Fedora Modular Server

Screenshot: ft

 

Vor kurzem wurde Fedora 27 Server veröffentlicht. Eigentlich sollte dieses Release im Rahmen des Boltron-Projekts modular aufgebaut sein. Veröffentlicht wurde jedoch eine herkömmliche Server-Edition. Die Entwickler verwarfen den ursprünglichen  Ansatz, den sie vor über einem Jahr formuliert hatten und schicken das Projekt »modularer Server« wieder zurück aufs Reißbrett. Red Hats Stephen Gallagher hat jetzt die technischen Hintergründe der ursprünglichen und der überarbeiteten Version näher erläutert.

Nicht alles gelingt auf Anhieb

Fedoras Modularity-Initiative zielt darauf ab, es den Paketierern zu erleichtern, alternative Versionen von Software zu erstellen, und Benutzern die Möglichkeit zu geben, diese sogenannten Streams unkompliziert zu benutzen. Daran arbeitet Fedora bereits seit mehreren Jahren, im Sommer dieses Jahres wurde dann der Boltron-Prototyp und später eine Beta-Version zum modularen Server für Fedora 27 ausgeliefert. Die Rückmeldungen zeigten aber, dass diese Testversionen das gesetzte Ziel nicht erreichten und ein Umdenken erfordern.

In erster Linie wurde für den Neubeginn die Idee einer streng gepflegten, stabilen Wurzel aufgegeben. Herkömmliche Fedora-Builds werden ausgeführt, indem ein RPM in einem Buildroot erstellt wird, das die neuesten Pakete enthält, die im Stable-Updates-Repository für eine Veröffentlichung verfügbar sind. Mit Modularität hoffte Fedora, eine kleine und spezifische Buildroot definieren zu können, die stabil und für die gesamte Lebensdauer einer Veröffentlichung erhalten bleiben würde. Darauf sollten die einzelnen Module aufbauen.

Haupt-Repository als Plattformmodul

Das stellte sich im Verlauf der Entwicklung als nicht praktikabel heraus. Es hätte erfordert, einen Punkt zu finden, an dem die gesamte Buildroot verwendet werden konnte, um sich selbst zu bauen. Dieses Ziel wurde nicht erreicht. Stattdessen wurde entschieden, Fedoras Haupt-Repository als Plattformmodul zu behandeln. Praktisch bedeutet dies, dass die Entwickler von Modulen nicht mehr einen schwierigen Prozess durchlaufen müssen, um herauszufinden, welche Module eine Abhängigkeit bieten, die sie benötigen. Stattdessen können sie sich auf die Systemversion verlassen, die im Haupt-Repo verfügbar ist.

Problemlose Umstellung

Dies ermöglicht einen einfachen Upgrade-Pfad, da die traditionellen Repositories sowie eine Reihe von Standardmodulen beibehalten werden. Das bedeutet, dass ein Upgrade von einem aktuellen Fedora 27-System auf ein modulares Fedora 28-System ohne besondere Schritte möglich sein wird. Tatsächlich bedeutet dieser Ansatz auch, dass die Modularität nicht auf die Server-Edition beschränkt bleiben muss, sondern auch für die Workstation-Edition gelten kann.

Um den Vorgang zu vereinfachen sollen Werkzeuge zur Verfügung gestellt werden, um die Erstellung der Module zu automatisieren. Selbst für komplexere Multipackage-Module bieten die automatisch erstellten Module einen einfachen Ausgangspunkt.

Zwei Repository-Sets

Aus der Sicht des Endbenutzers wird Fedora mit zwei Sets von Repositories ausgeliefert. Zum einen die traditionellen Fedora-Repositories (Fedora, Updates und Update-Tests) und zum anderen ein neuer Satz von Repositories mit alternativen und ergänzenden Modulen. Die Bezeichnungen dieser Repositories sind noch nicht endgültig.

Mit diesem Design kann jeder, der nicht auf die zusätzlichen Versionen der von Modulen bereitgestellten Software zugreifen möchte, die modularen und modularen Update-Repositories deaktivieren, und sein System wird genau so funktionieren, wie es heute funktioniert. Pakete, die mit Fedoras traditionellem Prozess erstellt wurden, werden aus dem regulären Fedora-Repository installiert und verwaltet, ebenso wie Standardversionen von Paketen, die den neuen Prozess hinter den Kulissen verwenden.

Standard oder modular

Für alle, die Zugriff auf zusätzliche Versionen von Paketen haben möchten, werden diese neuen Modul-Repositories diese zur Verfügung stellen. Benutzer können mit diesen neuen Repositories interagieren, indem sie die Vorteile einer neuen Syntax in DNF nutzen, wie sie auch in der Modular Server Beta verwendet wurde. Wenn ein Benutzer einen bestimmten Modul-Stream installieren möchte, kann er den neuen Befehl dnf install module foo/bar benutzen.

Dieser überarbeitete Plan bietet eine verständliche und darstellbare Zukunft für Modularität. Paketierer, die keine Module erstellen wollen, können weiterhin genau so packen, wie sie es immer getan haben, ohne ihre Arbeitsabläufe zu verändern. Diejenigen, die alternative Versionen von Software in einer einzigen Version oder dieselbe Version über mehrere Versionen hinweg bereitstellen wollen, werden neue Werkzeuge erhalten, um dies zu vereinfachen. Da die Anzahl der verfügbaren Module wächst, werden die Benutzer von Fedora einen viel einfacheren Zugang zu der genauen Version der Software haben, die sie für ihre Aufgaben benötigen.

Verwandte Themen

Fedora Modular Server zurück aufs Reißbrett
views 21
Screenshot: ft   Fedora stoppt vorerst seine Bemühungen, die Fedora-Server-Edition zu modularisieren. Jetzt wurde zunächst ein reguläres R...
Fedora 27 mit GNOME 3.26.2 freigegeben
views 66
Screenshot: ft Fedora 27 wurde gestern in den Varianten Workstation und Atomic freigegeben. Die Server-Edition wurde für die 27. Ausgabe der Distr...
Fedora 27 Workstation und Server erneut verschoben
views 41
Screenshot: FThommes Das Fedora-Team hat kein Glück mit der Herausgabe von Fedora 27. Bereits vor der Beta-Version drei mal verschoben, musste jet...
Fedora 27 Workstation Beta freigegeben
views 41
Screenshot: FThommes Normalerweise gebührt die Ehre, eine neue GNOME-Version zuerst offiziell in einer Distribution vorzustellen Red Hats Experime...
Fedora 27 Beta erneut verschoben
views 31
Screenshot: FThommes Die Beta-Version zu Fedora 27 wurde bei einer Sitzung des Fedora-Steuerungskomitees FESCo wegen einiger zum Teil kritischer F...

Beitrag kommentieren

Alle Kommentare
  • Fedora 28 mit neuen Repositories | linuxnews.de linuxnews.de

    19.01.2018, 12:58 Uhr

    […] Lösung zuführen wollten. Der erste Ansatz, der die Server-Variante in Module zerlegen wollte, scheiterte. Der ursprüngliche Ansatz, der in das Projekt Boltron zusammenlief, ließ sich technisch nicht so […]

  • Debian plant Rolling Release | linuxnews.de linuxnews.de

    01.04.2018, 08:11 Uhr

    […] aufgestellt. Fedora teilte die Distribution in drei Teile für Desktop, Server und Cloud auf und arbeitet weiter an der Modularisierung. openSUSE verankerte Tumbleweed sehr erfolgreich als offizielle Rolling-Release-Variante und setzte […]