Schlagwort: Red Hat

  • Fedoras Vision für den Linux-Desktop

    Fedoras Vision für den Linux-Desktop

    Christian Schaller ist bei Red Hat Senior Manager für den Desktop und arbeitet bei Fedora unter anderem an Flatpak, PipeWire, GStreamer und GNOME. In unregelmäßigen Abständen veröffentlicht er Essays zum Zustand von Fedora Workstation. Gestern veröffentlichte er einen Blogpost mit dem Titel Fedora Workstation: Our Vision for Linux Desktop.

    Red Hats Hexenküche

    Fedora ist, alimentiert durch den Support von Red Hat, zweifelsohne derzeit die innovativste Distribution auf dem Markt. Dahinter steht eine Vision für die Zukunft von Fedora und von Linux-Distributionen allgemein. Dabei soll Fedora Workstation als Hauptprodukt aber nicht nur Experimentierstube sein, sondern Entwicklern wie fortgeschrittenen Anwendern gleichermaßen als verlässliche Distribution für den Alltag dienen. Projektleiter Matthew Miller bezeichnete das Entwicklungsmodell einmal als »Leading Edge, not Bleeding Edge«.

    Neben Wayland sind die Säulen von Fedora Flatpak, PipeWire, Toolbox sowie Varianten der Workstation wie Fedora Silverblue und Kinoite, die einen guten Eindruck von der Vision von Fedora vermitteln. Flatpak ist auf gutem Weg, PipeWire desgleichen, zumindest für Audio, Video wird folgen. Anwendungsentwicklern kommt Flatpak natürlich entgegen, denn für sie ist es ein erheblicher Aufwand mit dem schnellen herkömmlichen Entwicklungsprozess und der Fragmentierung bei der Paketierung Schritt zu halten.

    Die Erkenntnis daraus war, dass ein System gebraucht wird, das es erlaubt, die Anwendung vom Host-Betriebssystem zu entkoppeln, damit die Anwendungsentwickler ihre Plattform in einem Tempo ihrer Wahl aktualisieren können und gleichzeitig die Plattform in dem Sinne vereinheitlichen, dass die Anwendung ohne Probleme auf den neuesten Fedora-Versionen, den neuesten RHEL-Versionen oder den neuesten Versionen jeder anderen Distribution läuft.

    Viele Bausteine werden zum Ganzen

    So wurde mit Docker im Sinn Flatpak konzipiert, während zufällig zu gleicher Zeit OSTree entwickelt wurde. Schaller bezeichnet den hybriden Paketmanager als »Git für Binärpakete«, da es eine einfache Möglichkeit bietet, Binäranwendungen mit wenig Aufwand zu pflegen und zu aktualisieren. Derzeit wird die Flatpak-Erstellung in die hauseigenen Werkzeuge bei Red Hat integriert, mit denen RHEL zusammengestellt wird. Das Ziel ist, auf Flatpaks als primäre Anwendungsbereitstellungsmethode für Desktop-Anwendungen in RHEL umzusteigen.

    Diese Entwicklungen werden bei Fedora derzeit mit Silverblue und Kinoite ausgelotet. Beide Varianten setzen auf Flatpak, erlauben aber auch die Installation von Anwendungen per RPM-OSTree aus den normalen Fedora-Repositories. Die Bedürfnisse der Entwickler nach CLI-Werkzeugen wird über das Container-basierte Fedora Toolbox gelöst.

    PipeWire behebt Wayland-Probleme

    Wayland und Flatpak versprachen zwar mehr Sicherheit, vor allem auch im Grafik-Stack, brachten aber gleichzeitig durch die Abkehr von X11 mit seinem Client-Server-Modell neue Probleme mit sich. So wurden bestimmte Dinge wie Desktop-Capturing, Remote- und Webcam-Zugriff erschwert. Wim Taymans, Entwickler von GStreamer, arbeitete zu der Zeit an PulseVideo. Das Modell erwies sich als flexibel genug, um auch den Anforderderungen von Audio zu genügen, sowohl als Ersatz von PulseAudio für Consumer-Zwecke als auch für die Real-Time-Ansprüche professioneller Musiker, die sich bisher bei Jack bedienten. So entstand PipeWire, dass gleichzeitig half. die erwähnten, durch Wayland entstandenen Probleme im grafischen Bereich zu beheben.

    Ein essenzieller Faktor in der Vision für Fedora sind unveränderliche Systeme, wie sie Silverblue und Kinoite darstellen. Bei diesen immutable operating systems ist das Root-FS nur lesbar, geschrieben wird auf einer Ebene darüber. Updates werden als Image eingespielt und können zurückgerollt werden. Systemd-Entwickler Lennart Poettering hat bereits 2014 viele dieser Ideen formuliert, obwohl damals noch viele Grundlagen fehlten.

    Noch nicht am Ziel

    Zusammenzufassend sieht Schaller die Vision noch nicht über die Ziellinie gekommen. Angekommen sei man erst, wenn Silverblue zur offiziellen Version von Fedora Workstation wird. Neben technischen Ursachen will man zunächst den Anwendern und Entwicklern mehr Zeit geben, sich mit den neuen Techniken zu befassen und eine höhere Akzeptanz zu erreichen. Dass diese Vision für Fedora und Red Hat Wirklichkeit wird, scheint klar. In anderen Distributionen nimmt die Akzeptanz für Wayland, Flatpak und PipeWire zu. Werden sie aber auch bereit sein, den endgültigen Schritt zu gehen und das althergebrachte Paketsystem aufzugeben, bei dem die Maintainer der Distributionen regulierend zwischen Entwicklern und Anwendern stehen?

    Wer zieht mit?

    Schallers Vision von Fedora und ähnliche Ansätze haben viele Vorteile, aber sie werfen auch gewachsene, Vertrauen stiftende Systeme über den Haufen. Vermutlich werden einige innovative Distributionen Varianten ihrer Distribution mit diesen Merkmalen ausstatten, ich sehe aber nicht, dass Debian, openSUSE oder Arch Linux dieses Modell komplett aufgreifen und umsetzen. Was denkt ihr?

  • Red Hat unterstützt EPEL künftig offiziell

    Runtime für Flatpak
    Bild: Red Hat Linux | Quelle: Leonid Mamchenkov | Lizenz: CC BY 2.0

    Wie dem Blog von CentOS aktuell zu entnehmen ist, will Red Hat das bereits seit 2007 gepflegte EPEL-Repository offiziell mit einem kleinen Team von Vollzeit-Betreuern aufwerten. Dabei soll die Çommunity-basierte Special Interest Group EPEL SIG nicht ersetzt, sondern ergänzt werden. Bisher gibt Red Hat oder das Fedora Projekt für EPEL-Pakete keine Garantien, Support oder Zertifizierungen, wie dies für Pakete im offiziellen RHEL-Repository üblich ist. Das könnte sich nun ändern.

    Was ist EPEL

    EPEL steht als Abkürzung für Extra Packages for Enterprise Linux und ist eine Fedora Special Interest Group, die eine große Anzahl von über 3.000 zusätzlichen erstellt, pflegt und verwaltet, die nicht in RHEL enthalten sind. einschließlich. Die Pakete stehen für Red Hat Enterprise Linux (RHEL), CentOS und Oracle Linux (OL) bereit, sind aber nicht auf diese beschränkt. EPEL-Pakete basieren in der Regel auf ihren Fedora-Pendants. Dabei nutzt EPEL einen Großteil der gleichen Infrastruktur wie Fedora, einschließlich Build-System, Bugzilla-Instanz, Update-Manager, Mirror-Manager und mehr. Seit Neuestem gibt es auch EPEL Next, dessen Pakete im Gegensatz zu EPEL gegen CentOS Stream gebaut werden und nicht gegen RHEL.

    Die Geschichte

    Das EPEL-Projekt entstand, als die Fedora-Maintainer erkannten, dass dieselbe Infrastruktur, die Pakete für Fedora erstellt und verwaltet, auch hervorragend für die Verwaltung von Zusatzpaketen für Enterprise Linux geeignet wäre. Ein Großteil des anfänglichen Bedarfs ergab sich aus den Anforderungen an die Fedora-Infrastruktur auf den RHEL-Maschinen, auf denen Fedora erstellt und gewartet wurde. Daraus hat sich eine große Sammlung verschiedener Pakete entwickelt.

    Das Team

    Das neue Team wird gerade zusammengestellt und es wird erwartet, dass es seine Arbeit im Oktober aufnehmen kann. Unterstellt wird es Community Platform Engineering Group kurz CPR, dem Red-Hat-Team, das IT- und Release-Engineering von Fedora und CentOS vereint.

  • Red Hat-Paketsystem RPM braucht Nachbesserung

    Photo by CHUTTERSNAP on Unsplash

    Im März 2021 hatte Dmitry Antipov, einer der Entwickler bei CloudLinux, der Firma hinter Alma Linux, entdeckt, dass die Signaturprüfung von RPM-Paketen unvollständig ist. Antipov sieht das als Sicherheitslücke, RPM-Entwickler Panu Matilainen eher als fehlende Implementierung von Teilaspekten der Signaturprüfung. Logisch, was nicht implementiert ist, kann keine Fehler enthalten. Geht aber völlig am Problem vorbei. Egal, wie man es benennen will, böswillige Akteure können dieses Verhalten ausnutzen, um einen widerrufenen oder abgelaufenen Schlüssel zur Installation schädlicher Pakete zu verwenden.

    Widerruf ist eines der vielen nicht implementierten Dinge in der OpenPGP-Unterstützung von RPM. Mit anderen Worten, Sie sehen keinen Fehler als solchen; es ist einfach überhaupt nicht implementiert, ähnlich wie es die Ablaufzeit nicht ist.

    Panu Matilainen auf GitHub

    Seit 24 Jahren unsicher

    Wie bei Debian mit DEB, werden Pakete im Paketformat RPM, was für Red Hat Package Manager steht, vom jeweiligen Maintainer mit seinem privaten Schlüssel signiert, dem die Anwender der Pakete vertrauen müssen. Seit der Einführung von RPM im Jahr 1997 durch Red Hat-Gründer Marc Ewing und Entwickler Erik Troan fehlen der Paketverwaltung sicherheitskritische Mechanismen wie die Prüfung, ob ein Schlüssel abgelaufen ist oder zurückgezogen wurde (revoked). Schlüssel werden unter anderem zurückgezogen, wenn sie kompromittiert sind. Somit passieren auch Pakete, die keinen gültigen Schlüssel mehr haben, die Sicherheitsbarriere, wie der Bugreport auf GitHub aufzeigt.

    Patch-Implementierung kann dauern

    Antipov hat einen Patch bereitgestellt, befürchtet aber, es könne aufgrund der Komplexität der Materie Monate dauern, bis der Patch angenommen, implementiert und bei den Anwendern angekommen ist. Da diese prekäre, leicht auszunutzende Lücke nun publik ist, denkt Antipov über eine CVE-Katalogisierung (Common Vulnerabilities and Exposures) bei Red Hat nach, um der Angelegenheit mehr Nachdruck zu verleihen.

  • Rocky Linux 8.3 RC1 für x86_64 und aarch64 erschienen

    Quelle: Rocky Linux

    Wenige Tage nachdem AlmaLinux, Mitanwärter auf die CentOS-Nachfolge, sein Support-Konzept vorgestellt hat, gibt die Rocky Enterprise Software Foundation (RESF) als weiterer Aspirant die erste Veröffentlichung von Rocky Linux frei. Das ist ein Projekt, dass CentOS-Initiator Gregory Kurtzer ins Leben rief, nachdem Red Hat im Dezember das baldige Ende von CentOs in seiner jetzigen Form verkündet hatte. Ab Ende 2021 wird das dem Rolling Release-Prinzip folgende CentOS Stream offiziell an die Stelle von CentOS treten und damit die Positionierung von Fedora, RHEL und CentOS/CentOS Stream in Red Hats Ökosystem neu ordnen.

    Rock Linux 8.3 RC1

    Rocky Linux, ein binärkompatibles Abbild von Red Hat Enterprise Linux (RHEL) lässt Alpha- oder Beta-Versionen aus und bietet als erste frei verfügbares Release einen Veröffentlichungskandidaten an. In den letzten vier Monaten hat das Team neben der Fertigstellung von Rock Linux 8.3 RC1 eine Infrastruktur für das Projekt aufgebaut, ein Branding entworfen und sich um das Marketing gekümmert.

    Weitere Architekturen geplant

    Der erste Veröffentlichungskandidat nutzt Linux 4.18 als Grundlage, der zwar offiziell nicht mehr unterstützt, aber von Red Hat weiterhin gepflegt wird. Als Basis dient RHEL 8.3 mit GNOME 3.32 als Desktop-Umgebung. In den nächsten Wochen und Monaten sollen weitere Architekturen hinzukommen und Rocky Linux in der Cloud verfügbar werden. Die Entwicklung findet auf GitLab statt.

    Abbilder für x86_64 und aarch64 liegen auf dem Download-Server des Projekts in jeweils drei Ausführungen bereit. Als Minimal Boot bringt Rocky Linux 8.3 RC1 600 MByte auf die Waage, Minimal Install liegt bei rund 1,7 GByte. während die DVD-Ausgabe bei rund 8 GByte liegt. Die Entwickler weisen ausdrücklich darauf hin, dass es sich um einen Release-Kandidaten handelt, der nicht für den produktiven Einsatz geeignet ist. Release Notes stehen derzeit noch aus.

  • AlmaLinux als Fork von CentOS stellt erste Beta vor

    Red Hats Ankündigung, CentOS im Rahmen einer Neustrukturierung durch CentOS Stream zu ersetzen, wurde in den Communities nicht gut aufgenommen. Quasi über Nacht sind einige Forks von CentOS initiiert worden. Neben Rocky Linux war das vor allem AlmaLinux. Während sich Rocky Linux noch in der Entwicklungsphase befindet, hat AlmaLinux gerade eine erste Beta-Version freigegeben. CentOS Linux 8, ein Rebuild von RHEL 8 wird Ende 2021 auslaufen. CentOS Stream übernimmt danach den Platz von CentOS und soll die Entwicklung von RHEL erleichtern.

    CloudLinux im Hintergrund

    AlmaLinux wurde von der Firma CloudLinux initiiert, die unter anderem mit CloudLinux OS bereits eine Distribution für Hosting-Provider im Programm haben, die ebenfalls auf CentOS basiert. Mit AlmaLinux hat die Firma somit einen Nachfolger als Unterbau für CloudLinux OS geschaffen. Während letzteres Geld kostet, wird AlmaLinux kostenfrei sein.

    Binärkompatibel zu RHEL

    Die jetzt vorgestellte Beta ist ein komplett freier 1:1 binärkompatibler Fork von Red Hat Enterprise Linux (RHEL) 8. Mit dem Release der Beta ist die Community aufgerufen, Feedback zu geben, wobei es nicht nur um das Auffinden von Fehlern geht, sondern auch um die zukünftige Ausrichtung des Betriebssystems. Das Team um AlmaLinux stellt die notwendige Infrastruktur bereit, damit die Community übernehmen kann. Der Quellcode des Projekts wird öffentlich auf Github eingestellt. Ein Wiki soll beim Aufbau der Dokumentation helfen. Fehler können im AlmaLinux Bug Tracker gemeldet werden.

    Beim Net-Install muss das Repository angegeben werden

    Zum Download

    Zurzeit stehen drei Abbilder der ersten Beta zum Download bereit. Dabei handelt es sich um ein 68 MByte kleines Netinstall-Image, ein Minimal-Image mit knapp 190 MByte und ein DVD-Image mit 870 MByte. Bei Verwendung des Net-Installers muss nach dem Start die URL des Repositories angegeben werden, von dem die Pakete gezogen werden sollen.

  • Rocky Linux: Red Hat kontert mit kostenfreien Lizenzen

    Red Hat
    Bild: Red Hat von Marc Nozell | Lizenz: CC BY 2.0

    Gastartikel von Stefan Kleyer

    Nachdem Red Hat bekannt gegeben hat, dass CentOS zukünftig durch CentOS Stream, eine Rolling-Release-Distribution ersetzt wird, gab es viel Kritik. Sofort hatten sich Projekte wie Rocky Linux gebildet oder Oracle Linux offen damit geworben, von CentOS aus per Skript zu dieser Distribution wechseln zu können.

    Kostenfreie Lizenzen für Red Hat Enterprise Linux

    Nun kontert Red Hat mit kostenfreien Lizenzen unter zwei Bedingungen: Erstens für kleinere Umgebungen von bis zu 16 Systemen, explizit erlaubt sind auch öffentliche Cloud-Instanzen. Hier ist scheinbar lediglich eine Registrierung bei Red Hat notwendig. Zweitens für Entwickler-Teams von Unternehmen, die sowieso schon ein Abonnement von Red Hat haben. Dazu müssen die Entwickler vom Unternehmen zum Abonnement hinzugefügt werden.

    RHEL gerne genutzt

    Ob das den Unmut über die Entscheidung, die stabile und viel genutzte Distribution gegen ein Rolling-Release zu tauschen, besänftigen kann, bleibt abzuwarten. Von Red Hat bleiben nun das im Support kostenpflichtige, gut gepflegte Red Hat Enterprise Linux, CentOS Stream als Rolling-Release-Pool für alle neuen Pakete, die letztlich ins nächste Release von RHEL kommen sollen, und Fedora, das belustigt gerne als Spielwiese von Red Hat bezeichnet wird und alle 6 Monate in einer neuen Version mit neuen Techniken wie Wayland oder PipeWire erscheint.

  • Der Abgang von CentOS und die Folgen

    CentOS Stream

    Kürzlich wurde verkündet, dass die beliebte Distribution CentOS in ihrer bisherigen Form als binärkompatibler Klon von Red Hat Linux Enterprise (RHEL) keine Zukunft mehr hat. Ab Ende 2021 wird das dem Rolling Release-Prinzip folgende CentOS Stream offiziell an die Stelle von CentOS treten und damit die Positionierung von Fedora, RHEL und CentOS/CentOS Stream in Red Hats Ökosystem neu ordnen. CentOS Linux 8, als ein Rebuild von RHEL 8 wird Ende 2021 auslaufen. CentOS Stream übernimmt danach den Platz von CentOS, dient aber als Upstream(Entwicklungs-)Zweig von RHEL.

    Bestürzung und Kritik

    Bisher war Fedora die Experimentierküche für RHEL und CentOS eine zu RHEL kompatible Distribution für Anwender, die keinen Support benötigen. Die Konstellation CentOS in der Entwicklung und RHEL in der Produktion wird nun für viele Anwender nicht mehr funktionieren. Hing CentOS immer etwas hinter RHEL zurück, so ist CentOS Stream der jeweiligen aktuellen Version von RHEL künftig etwas voraus.

    Die Nachricht löste Bestürzung und Kritik aus und wie bei Linux üblich ließen Pläne für Forks nicht lange auf sich warten, denn Tausende von Firmen werden bis spätestens 2024 (dem Support-Ende von CentOS 7) eine neue Linux-Distribution suchen müssen. Red Hat denkt zwar hier über eine Verlängerung nach, aber entschieden ist noch nichts. Die Unterstützung für CentOS 8 endet bereits Ende 2021 anstatt planmäßig 2029. Anwender, die hier mit 10 Jahren Unterstützung gerechnet haben, fühlen sich zu Recht betrogen. Falls Red Hat beabsichtigt hatte, diese Klientel kostenpflichtig an sich zu binden, viel Glück damit.

    Andererseits wird die Meinung vertreten, auch CentOS Stream sei stabil genug für den produktiven Einsatz. Als Argument dafür führt etwa Red Hats CTO Chris Wright an, Facebooks Millionen von Servern würden auf einem Betriebssystem auf der Basis der CentOS Stream-Repositories laufen oder seien auf dem Weg dorthin. Egal, wie man darüber denkt, Konsens ist, dass mehr Zeit hier viele Probleme hätte verhindern und den Unmut minimieren können.

    Rocky Linux is a community enterprise Operating System designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux now that CentOS has shifted direction.

    Gregory M. Kurtzer

    Bei den angekündigten Forks stechen zwei heraus. Nur Stunden nach Red Hats Ankündigung wurde die Idee zu Rocky Linux vorgestellt. Initiiert wird es unter anderem von Gregory M. Kurtzer, dem ursprünglichen Gründer und Entwickler von CentOS. Spätestens im Sommer 2021 will Kurtzer mit der Community eine erste Version veröffentlicht haben. In der FAQ auf der Webseite steht zur Einordnung der Distribution, Rocky Linux ziele darauf ab, »wie zuvor bei CentOS, als Downstream-Build zu fungieren und Releases zu veröffentlichen, nachdem sie vom Upstream-Anbieter hinzugefügt wurden, nicht zuvor.

    Der zweite Fork kommt vom etablierten Linux-Distributor CloudLinux, dessen gleichnamiges OS auf RHEL/CentOS basiert und sich an Hosting-Anbieter und Unternehmen richtet. Das vorläufig als Projekt Lenix titulierte Projekt will ein »Open-Source- und Community-getriebener RHEL-Fork« sein und im ersten Quartal 2021 ein erstes Release vorzeigen. Eine Migration von CentOS soll problemlos möglich sein. Einer Umfrage zufolge, auf die 1.500 Personen geantwortet haben, warten 61,5 Prozent der CentOS-Anwender auf einen RHEL-Fork, während die restlichen 38,5 Prozent vorhaben, sich auf Debian, Ubuntu und OpenSUSE zu verteilen. Dabei hat ein Fork den Vorteil der wesentlich leichteren Migration. Oracle und Ubuntu buhlen derweil aktiv um die verprellten CentOs-Nutzer.

    Was wird aus Fedora?

    Bleibt die Frage, welche Rolle Fedora in Red Hats Neuordnung der Dinge einnimmt, denn bisher waren es die Fedora-Hüte, die den Downstream von RHEL darstellten. Um nochmals Chris Wright zu zitieren, sitzt CentOS Stream jetzt »zwischen den Innovationen des Fedora-Projekts und der Produktionsstabilität von RHEL«. Matthew Miller Red Hats Projektleiter für Fedora beeilte sich klarzustellen, dass es keine Pläne gebe, die Stellung von Fedora im Verhältnis zu RHEL zu ändern:

    Fedora integriert Tausende von „Upstream“-Open-Source-Projekten in eine einheitliche Distribution mit einem sechsmonatigen Veröffentlichungsrhythmus, und von Zeit zu Zeit nimmt Red Hat diese Sammlung, forkt sie und produziert RHEL“.

    Matthew Miller

    Miller beschreibt die Rolle von CentOS Stream in diesem Zusammenhang als »eine kontinuierliche Weiterentwicklung von RHEL nach dem Fork von Fedora« und fährt fort: »Alles, was in CentOS Stream kommt, ist eigentlich bereits für die Freigabe an zahlende RHEL-Kunden freigegeben. Es wird nur in einem Stream veröffentlicht und nicht in einem großen Dump alle sechs Monate. Natürlich gebe es eine gewisse Lernkurve, aber die Absicht sei, dass dieser Stream so stabil ist wie das freigegebene RHEL-Produkt, weil das […] den Wert von CentOS Stream für Red Hat ausmache.«

    Fedora bleibt Red Hats Hexenküche

    Für Fedora sieht Miller keine Änderungen, da Fedora über seinen Beitrag zu RHEL hinaus eine eigenständige Distribution mit zwar vielen Schnittmengen mit RHEL sei, aber darüber hinaus auch viele Entwicklungen vorantreibe, die nicht direkt im Fokus von Red Hat lägen. In diesem Zusammenhang erwähnt Miller das neue Fedora-Projekt Fedora ELN, was für Enterprise Linux Next steht und bei Fedora als Special Interest Group (SIG) betrieben wird. Miller denkt, es sei durchaus möglich, dass im nächsten Jahr CentOS Stream 9 auf dieser Grundlage gebaut werden wird. Zudem sieht Miller durch die Neuordnung eine Chance, Fedora Server wieder neues Leben einzuhauchen.

  • CentOS veröffentlicht 8.3 und legt den Fokus auf CentOS Stream

    CentOS 8.3
    Quelle: CentOS | Lizenz: CC0 1.0 Universal

    Die Entwickler hinter der zu Red Hat Enterprise Linux (RHEL) binärkompatiblen Distribution CentOS haben die sofortige Verfügbarkeit von CentOS 8.3 bekannt gegeben. Die neue Version erbt die meisten Eigenschaften und Neuerungen von RHEL 8.3, das vor etwas mehr als einem Monat erschienen war.

    Die neue Version bringt Neuerungen hauptsächlich bei der Sicherheit und bei Container-Werkzeugen. Zudem wird die Migration zu CentOS Stream erleichtert. Dazu wurden Änderungen an der Yum-Repository-Datei implementiert, wie etwa Namensänderungen einiger Dateien in /etc/yum.repos.d .

    Neuer Fokus

    Darüber hinaus wird CentOS Änderungen an seiner Positionierung im Verhältnis zu Fedora und RHEL vornehmen. Demnach soll ab Ende 2021 der Fokus der Distribution nicht mehr auf der Binärkompatibilität zu RHEL liegen, sondern sich auf die Rolling-Release-Distribution CentOS Stream konzentrieren, die gewissermaßen neben Fedora einen zweiten, eher server-orientierten Upstream für Red Hat darstellt. CentOS 7 wird dagegen bis zum Support-Ende im Jahr 2024 unterstützt.

    CentOS wurde 2014 von Red Hat übernommen, um eine Version von RHEL für Anwender zur Verfügung zu stellen, die keinen Support durch Red Hat benötigen. Dabei ging es Red Hat darum, Unternehmenslösungen wie OpenStack, OpenShift sowie Virtualisierung und Containerisierung einem breiteren Publikum außerhalb des eigenen Distributionsmodells vorzustellen.

    CentOS Stream als Upstream

    Seit 2019 existiert die Distribution CentOS Stream, die etwas aktueller als die entsprechende RHEL-Version ist und deren Änderungen in die nächsten Minor-Versionen von RHEL einfließen. In Unternehmen wird in der Produktion oft RHEL, in der Entwicklung aber CentOS verwendet. Es mehrten sich in letzter Zeit aber Beschwerden, CentOS hänge zu weit zurück, um in der Entwicklung relevant zu sein. Die neue Ausrichtung könnte eine Reaktion auf derlei Beschwerden sein.

    The future of the CentOS Project is CentOS Stream, and over the next year we’ll be shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021. CentOS Stream continues after that date, serving as the upstream (development) branch of Red Hat Enterprise Linux.

    Rich Bowen, CentOS

    Nicht gut aufgenommen

    Im Blog von Red Hat erklärt Red-Hat-Vizepräsident Chris Right die Sicht des Konzerns, eine FAQ aufseiten von CentOS erläutert Fragen zum Umstieg. Im Blog von CentOS wird die Ankündigung in den Kommentaren scharf kritisiert. Viele Nutzer kündigen bereits ihre Abkehr von der Distribution an, da es ab Ende 2021 mit dem Ende der Unterstützung für CentOS 8.3 durch den Wegfall der stabilen Grundlage und den langen Supportzeitraum keinen Grund mehr gebe, CentOS zu benutzen. Wer Böses dabei denkt, könnte vermuten, Red Hat wolle neue zahlende Käuferschichten generieren. Auf Change.org wurde eine Petition gestartet, um das Ende von CentOS als stabiler Distribution zu verhindern.

    CentOS 8 (2011), wie das Release offiziell heißt, kann von der Webseite von CentOS für die Architekturen x86_64, aarch64 und ppc64le heruntergeladen werden. Dort steht auch CentOS Stream zum Download bereit.

  • Red Hat stellt eigene Runtime für Flatpak vor

    Runtime für Flatpak
    Bild: Red Hat Linux | Quelle: Leonid Mamchenkov | Lizenz: CC BY 2.0

    In Flatpaks verpackte Anwendungen bringen systembedingt einige Bibliotheken im Container mit. Der Großteil wird jedoch in Laufzeitumgebungen direkt auf dem Gerät gespeichert. Derer können mehrere nebeneinander installiert sein. Die Standard-Runtime ist die von FreeDesktop, doch auch KDE und GNOME bieten unter anderem eigene Runtimes, die auf das jeweilige Projekt abgestimmt sind. Runtimes erleichtern unter anderem auch Aktualisierungen bei Sicherheitslücken.

    RHEL 8.2 mit eigener Runtime

    Jetzt hat Red Hat bekannt gegeben, dass für den Desktop eine eigene Flatpak-Runtime zur Verfügung steht. Das im April erschienene Red Hat Enterprise Linux (RHEL) 8.2 bringt Flatpak, die Runtime sowie das SDK bereits mit. Die Integration einer eigenen Runtime soll es Anwendungsentwicklern erleichtern, containerisierte Desktop-Anwendungen auf der Basis von RHEL zu erstellen.

    Flatpak-Runtime zu kurz unterstützt

    Red Hats Kritik an der FreeDesktop-Runtime ist, dass jede neue Version nur für einen begrenzten Zeitraum unterstützt wird. Viele Entwickler wünschen sich eine Laufzeit, die über einen längeren Zeitraum aktuell gehalten wird. Unternehmensbenutzer möchten sicher sein, dass sie längere Unterstützung für die Kombination von Hostsystem und Runtime erhalten können.

    10 Jahre Unterstützung

    Die Runtime, die in RHEL 8.2 integriert ist, soll über den gesamten Lebenszyklus von RHEL 8.0 unterstützt werden, der noch bis zum Mai 2029 läuft. In naher Zukunft werden Laufzeit und SDK unter ähnlichen Bedingungen wie die der Red Hat Universal Base Images (UBI) verteilt. Diese Bedingungen ermöglichen es Entwicklern, Anwendungen zu erstellen, die mit vielen Linux-Distributionen funktionieren. Benutzer müssen dafür kein RHEL-Abonnement haben. Der Support ist verfügbar, solange die Runtime auf einem RHEL-Host läuft.

  • Fedora 33 soll mit Stratis 2.1.0 ausgeliefert werden

    Fedora 33 soll mit Stratis 2.1.0 ausgeliefert werden

    Erst letzte Woche hatte das Fedora-Steuerungskomitee beschlossen, dass mit Fedora 33 Btrfs das neue Standard-Dateisystem für die Desktop-Varianten der Distribution sein wird. Jetzt wurde ein weiterer recht später Vorschlag unterbreitet, Stratis 2.1.0 mit Fedora 33 auszuliefern.

    Red Hats eigene Storage-Lösung

    Der zeitliche Zusammenhang lässt darauf schließen, das Red Hat darauf drängt, das dort favorisierte Storage-System Stratis 2.1.0 ebenfalls mit auszuliefern. Da Btrfs bei Fedora nur den Desktop betrifft, können sich die Varianten Server, IoT und andere die erweiterten Möglichkeiten von Stratis 2.1.0 zugute machen. Red Hat hatte sich 2017 von Btrfs abgewandt und die Entwicklung von Stratis begonnen.

    Gut integrierte Lösung

    Stratis soll die Eigenschaften von ZFS und Btrfs mit Blick auf künftige Anforderungen an Storage abbilden. Dabei will Red Hat aber kein neues Dateisystem schreiben, sondern unter Verwendung von XFS eine Anwendung bauen, die Anwendern mit unterschiedlichsten Storage-Anforderungen eine gut integrierte Lösung mit konsistenter Konfiguration bietet.

    In Rust und Python umgesetzt

    Hauptentwickler Andy Grover beschrieb es in einem Strategiepapier als eine Kommandozeilenlösung mit einer umfassenden API, die auf bestehenden Techniken aufbaut. Stratis wird in Rust und Python umgesetzt. Die eingesetzten Komponenten sind das Dateisystem XFS als Grundlage und Device-Mapper als Schnittstelle zur Erzeugung virtueller blockorientierter Geräte.

    Verschlüsselung per Pool

    Stratis 2.1.0 bietet Verschlüsselung auf der Ebene von Pools auf der Basis von LUKS2, führt neue D-Bus-Schnittstellen ein und baut stratis-cli weiter aus. Die Verschlüsselung eines Pools schließt alle darin eingebundenen Geräte ein. Pools werden mithilfe eines Schlüssels im Kernel-Schlüsselring verschlüsselt. Jeder verschlüsselte Pool kann einen anderen Schlüssel verwenden, aber alle Geräte in einem Pool werden mit einem einzigen Schlüssel verschlüsselt.

    Nur für neue Pools

    Anwender werden die neue Verschlüsselungsmethode nur wahrnehmen, wenn sie einen neuen Pool aufsetzen. Für bestehende Dateisysteme ändert sich nichts. Ein Tutorial auf der Webseite von Red Hat, führt in die Verwendung von Stratis ein, beinhaltet aber noch nicht die neuen Möglichkeiten der Verschlüsselung mit Stratis 2.1.0.

    Prall gefülltes Release

    Das für den 20. Oktober zur Veröffentlichung anstehende Fedora 33 schickt sich an, eine der Veröffentlichungen mit den meisten Änderungen der letzten Jahre zu werden, sowohl was die Zahlen als auch die Bedeutung der Änderungen angeht.