Vor Kurzem veröffentliche Red Hat mit Red Hat Enterprise Linux 9 die nächste Hauptversion der wichtigsten Linux-Distribution. Erstaunlich finde ich die geringe Resonanz. Das passt in einen längeren Trend der Entkopplung von „gefühlter“ und „realer“ Bedeutung von Distributionen.
Red Hat Enterprise Linux ist meiner Ansicht nach die wichtigste Linux-Distribution überhaupt. Die Gründe dafür sind leicht erklärt. Red Hat war vor der Übernahme durch IBM die erfolgreichste und finanzstärkste Firma im direkten Linux-Umfeld und daran hat sich seitdem nichts geändert. Alle wichtigen Weiterentwicklungen entstammen dem Red Hat-Umfeld oder werden dort ganz massiv vorangetrieben: Systemd, PulseAudio, PipeWire, Wayland, GNOME, Flatpak, Podman, Etablierung von SELinux im Linux-Bereich, viel Weiterentwicklung im Container-Segment. Bestimmt habe ich hier noch ganz viel vergessen.
Neben diesen eher harten Fakten spielt die Verbreitung noch eine wichtige Rolle. Wie immer gibt es keine harten Zahlen und Fakten im Linux-Segment und daher kann jeder nur mit seinen eigenen Beobachtungen arbeiten. Ich habe in meinem Arbeitsleben bisher beobachten können, dass auf dem Desktop der IT-Mitarbeiter alles mögliche läuft – Windows, macOS und wenn Linux dann alles von Ubuntu über Manjaro bis zu Fedora – aber im Serverbereich zwei Anbieter führen: Red Hat und SUSE. Wenn ein kostenloses System genutzt wird, dann meist ein freier Klon von RHEL. Das mag natürlich an den Branchen liegen, in denen ich bisher gearbeitet habe, aber die Umsatzzahlen der Unternehmen müssen ja irgendwelche Grundlagen haben.
Ich wunderte mich deshalb in den vergangenen Wochen, wie ruhig es rund um den Release von RHEL 9 blieb. Schaut man sich die einschlägigen IT-Portale an, dann gibt es kaum Resonanz. Weder in Form von Artikeln noch bei den Kommentaren unter den wenigen vorhandenen Meldungen. Die neue Version ist nun sicherlich auch nicht gerade vollgepackt mit Änderungen, aber wo gibt es aktuell bei Linux schon umstürzende Entwicklungen?
Abgesehen von den beiden Blogartikeln sind das größtenteils Berichte auf dem Niveau von „Agentur-Meldungen“ und in wenigen Minuten geschrieben. Das ist kein Vergleich mit dem Release einer Debian-Version (der Vergleich mit Ubuntu hinkt, weil das auch auf dem Desktop eine herausragende Bedeutung hat). Das finde ich beachtlich, da in meiner persönlichen Wahrnehmung – und das hat wirklich nichts damit zu tun, wie ich persönlich Debian finde – Debian seine primäre Bedeutung als Basis für verschiedene andere Distributionen und Enterprise-Produkte wie beispielsweise Proxmox hat. Ein Debian-Release ist eigentlich erst dann interessant, wenn es in diese Produkte einfließt.
Was steckt dahinter? Entkoppelt sich die online präsente Linux-Community zunehmend von dem, was manche abfällig „Enterpise-Linux“ nennen oder ist das Zufall?
In diesem Artikel möchte ich einen Blick auf die Linux Distributionen AlmaLinux und Rocky Linux werfen und sie ihrem Upstream-Projekt Red Hat Enterprise Linux (RHEL) gegenüber stellen. Dabei interessieren mich insbesondere die folgenden Punkte:
Wer betreibt das Projekt bzw. steht hinter dem Projekt?
Wie finanziert sich das Projekt? Gibt es ein funktionierendes Geschäftsmodell?
Welchen Eindruck hinterlässt die Dokumentation?
Wie lange wird ein Major-Release unterstützt?
Wie viele Tage liegen zwischen einem RHEL-Release und den Releases der beiden Projekte?
Wie handhaben die Projekte Sicherheits-Updates?
Aus Gründen der Transparenz weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community und System-Administrator diverser RHEL-Server bin. Dieser Text gibt ausschließlich meine persönlichen Ansichten und nicht die von Red Hat oder die meines Arbeitgebers wieder. Zwar können diese in einzelnen Punkten übereinstimmen, müssen es aber nicht.
Was haben beide Projekte gemeinsam?
Sowohl AlmaLinux als auch Rocky Linux sind nach eigener Aussage:
Produktionsreife Betriebssysteme
Binärkompatibel zu RHEL
Werden aus den RHEL-Quelltexten übersetzt
Für den Nutzer kostenlos
Bieten 10 Jahre Unterstützung für ein Major-Release
Auch Red Hat bietet 10 Jahre Support auf seine RHEL-Major-Releases (Login erforderlich), an die sich eine Extended Life Phase anschließen kann. Selbstverständlich ist auch RHEL nach eigener Aussage reif für den produktiven Einsatz. Im Unterschied zu AlmaLinux und Rocky Linux kann RHEL jedoch nur zusammen mit einer kostenpflichtigen Subskription sinnvoll betrieben werden. Je nach Größe der Umgebung und Anzahl RHEL-Instanzen können hier beträchtliche Kosten anfallen.
Wer steht hinter den Distributionen?
Bei AlmaLinux handelt es sich um ein Community-Projekt, welches von der Firma CloudLinux Inc. gestartet wurde, welche das Projekt auch mit 1 Mio. USD pro Jahr unterstützt. Entwickelt und gesteuert wird das Projekt durch die Community, zu deren Unterstützung die gemeinnützige AlmaLinux OS Foundation gegründet wurde.
Neben der jährlichen Zuwendung von CloudLinux finanziert sich das Projekt durch diverse Sponsoren.
Die Firma CloudLinux Inc. verfügt selbst über mehr als 10 Jahre Erfahrung in der Pflege eines RHEL-Klons sowie den Betrieb der dazu notwendigen Infrastruktur. Nach eigener Aussage möchte CloudLinux Inc. durch die Unterstützung des Projekts den eigenen Bekanntheitsgrad steigern und hofft auf neue Kunden für das kommerzielle CloudLinux OS und KernelCare.
RHEL wird von der Firma Red Hat entwickelt, welches eines der weltweit erfolgreichsten Open Source Unternehmen ist. Haupteinnahmequelle des Unternehmens ist der Vertrieb von Subskriptionen für RHEL und weitere Produkte aus dem Portfolio. Eine Subskription berechtigt zum Bezug von Software-Aktualisierungen und umfasst kommerziellen Support.
Rocky Linux ist ein Community-Projekt, welches vom CentOS-Mitbegründer Gregory Kurtzer gegründet wurde. Das Projekt verfolgt die gleichen Ziele wie das ursprüngliche CentOS, welches zugunsten von CentOS Stream aufgegeben wurde.
Wie oben bereits beschrieben haben alle Distributionen ein Unterstützungszeitraum von 10 Jahren. Das heißt, dass ein Major-Release wie AlmaLinux/RHEL/Rocky Linux 8 für einen Zeitraum von 10 Jahren Aktualisierungen in Form von Bug-/Security-Fixes und ausgewählter Verbesserungen erhält. AlmaLinux und Rocky Linux profitieren hier von der Vorarbeit, welche Red Hat für RHEL geleistet hat.
Hilfe für individuelle Probleme, Sorgen, Nöte und Anträge erhält man bei AlmaLinux und Rocky Linux in Foren, Chats und auf Mailinglisten. Darüber hinaus kann man kommerziellen Support für AlmaLinux bei TuxCare einkaufen. Rocky Linux listet CIQ und OpenLogic by Perforce als Support-Anbieter. Red Hat unterhält mit der Red Hat Customer Portal Community ebenfalls einen Bereich mit Disussions-Forum. Darüber hinaus bietet Red Hat im Rahmen seiner Subskriptionen Support direkt vom Hersteller.
Für alle drei Distributionen gibt es also sowohl freie/kostenlose Support-Angebote, als auch kommerzielle Support-Verträge, entweder direkt vom Hersteller oder durch Drittanbieter.
Ob man kommerziellen Support benötigt oder der Community-Support ausreicht, hängt von verschiedenen Faktoren wie z.B. den eigenen Fähigkeiten und nicht zuletzt von der eigenen Risikofreudigkeit ab. Ich persönlich habe die Erfahrung gemacht, dass in Enterprise- bzw. Provider-Umgebungen Probleme auftreten können, die im Hobbykeller, im Verein oder im SoHo ausbleiben und völlig unbekannt sind. In diesen Fällen darf man sich nicht wundern, wenn sich in den Community-Foren niemand findet, der helfen kann. Hier kann ein kommerzieller Support vorteilhaft sein, der auf diese Umgebungen ausgerichtet ist und über mehr Erfahrung in diesem Bereich verfügt.
Ich persönlich bin mit dem Red Hat Support für RHEL zufrieden. Er hat mir schon einige Male bei Problemen und Fragestellungen geholfen, wo ich im Forum vermutlich ohne Antwort geblieben wäre. Die Support-Qualität bei AlmaLinux und Rocky Linux kann ich mangels Erfahrung nicht beurteilen.
Softwareunterstützung
Alle drei betrachteten Distributionen sind zueinander binärkompatibel. Das bedeutet, dass Anwendungen, die unter RHEL ausgeführt werden können, in aller Regel auch unter AlmaLinux und Rocky Linux ausgeführt werden können und umgekehrt.
Software-Hersteller führen in ihren Systemvoraussetzungen häufig unterstützte Betriebssysteme auf. Hier finden sich manchmal nur die kommerziellen Enterprise-Betriebssysteme wie RHEL oder SuSE Linux Enterprise Server (SLES). In solch einem Fall kann es passieren, dass der Software-Hersteller den Support ablehnt, wenn man seine Anwendung auf einem RHEL-Klon ausführt statt auf dem Original. Evtl. verlangt der Hersteller auch nur, dass das Problem unter einem offiziell unterstützten Betriebssystem nachgestellt wird. Dieser Punkte sollte bei der Auswahl einer Distribution mit bedacht werden.
Dokumentation
Red Hat bietet für RHEL eine ausführliche Produkt-Dokumentation und eine umfassende Wissensdatenbank. Zwar ist auch hier nicht alles perfekt, doch hat man dies auch schon deutlich schlechter gesehen. Um die Dokumentation kontinuierlich zu verbessern, bietet Red Hat allen Kunden und Nutzern die Möglichkeit, Dokumentations-Feedback direkt in der Dokumentation zu geben. Aus eigener Erfahrung kann ich berichten, dass gefundene Fehler meist innerhalb weniger Tage behoben werden.
Bei AlmaLinux habe in hinsichtlich Dokumentation auf den ersten Blick nur ein Wiki gefunden, welches auf mich hinsichtlich Gliederung und Umfang einen enttäuschenden Eindruck macht.
Rocky Linux hat ebenfalls ein Wiki und einen gesonderten Bereich für Dokumentation. Auch hier lässt mich die Gliederung etwas verstört und hilflos zurück. Zwar finden sich auf den ersten Blick mehr Anleitungen als bei AlmaLinux, an die RHEL-Dokumentation reicht sie jedoch keinesfalls heran.
Die schwache bis mangelhafte Dokumentation bei AlmaLinux bzw. Rocky Linux mag nicht so sehr ins Gewicht fallen, da man in vielen Fällen einfach die RHEL-Doku zurate ziehen kann. Auch hier profitieren die beiden Projekte wieder von der Vorarbeit des Originals.
Release-Zyklen
Seit RHEL 8 hat sich Red Hat feste Release-Zyklen auferlegt, welche alle 6 Monate ein Minor- bzw. Point-Release und alle 3 Jahre ein Major-Release vorsehen. Da AlmaLinux und Rocky Linux als Downstream-Projekte aus den RHEL-Quelltexten gebaut werden, erscheinen deren Releases stets nach der Veröffentlichung eines RHEL-Release. Die folgende Tabelle gibt einen kleinen Überblick, wann welche Distribution ein Minor-Release veröffentlicht hat.
Bisher folgen die Releases von AlmaLinux und Rocky Linux in der Regel wenige Tage auf das RHEL-Release. Beim Major-Release 9 hing RockyLinux ca. 1,5 Monate hinterher.
Bereitstellung von Sicherheits-Updates
Alle drei Projekte stellen Produkt-Errata im Internet bereit:
Dabei werden Errata in Bugfix-, Enhancement- und Security-Advisory unterschieden.
Während Bugs und fehlende Funktionalität störend und ärgerlich sein können, stellt die schnelle Verfügbarkeit von Sicherheits-Updates einen kritischen Faktor dar, um Sicherheitslücken zeitnah schließen zu können. Nach Aussage von AlmaLinux werden Errata bei AlmaLinux und Rocky Linux mit einem Geschäftstag Verzögerung in Bezug auf das RHEL-Errata-Release veröffentlicht. Ob beide Projekte dies durchhalten können, werde ich in der Zukunft stichprobenartig kontrollieren.
Mein Open-Source-Projekt Ansible: Patch-Management für Red Hat Systeme nutzt die Red Hat Security Advisories, um sogenannte Patch-Sets zu definieren, welche zu bestimmten Stichtagen installiert werden. Es ist darauf angewiesen, dass Errata-Informationen als Meta-Informationen in den Paket-Repositorien verfügbar sind. Bei CentOS fehlten diese, sodass mein Patch-Management für CentOS nicht nutzbar ist.
Daher bin ich sehr erfreut, dass AlmaLinux und Rocky Linux diese Meta-Informationen ebenfalls in ihren Repositorien bereitstellen. Prinzipiell sollte mein Patch-Management auch mit diesen beiden Distributionen funktionieren. Ein Test steht jedoch noch aus.
Zusammenfassung
Mit AlmaLinux und Rocky Linux gibt es zwei von einer Gemeinschaft entwickelte binärkompatible RHEL-Klone, welche von unterschiedlichen Unternehmen unterstützt und gesponsort werden. Erste Unternehmen bieten kommerziellen Support für diese Distributionen an.
Mir fällt positiv auf, dass beide Projekte in ihren Repos Errata-Informationen wie z.B. ALSA oder RLSA bereitstellen. Dies erleichtert die gezielte Installation von sicherheitsrelevanten Aktualisierungen. Hier bieten beide Projekte mehr, als es CentOS in der Vergangenheit tat.
Die Dokumentation scheint bei beiden Projekten keine große Rolle zu spielen. Ich empfinde sie als unübersichtlich und lückenhaft. Hier kann man jedoch vermutlich auf die Dokumentation des Originals (RHEL) zurückgreifen, welche sich mit sehr geringer Transferleistung auch für AlmaLinux und Rocky Linux nutzen lässt.
Auf den ersten Blick scheint es sich sowohl bei AlmaLinux als auch bei Rocky Linux um zwei solide Distributionen für alle jene zu handeln, die sich RHEL nicht leisten können oder wollen.
Abseits der bevorstehenden Veröffentlichung von Thunderbird 102 plant die MZLA Technologies Corporation bereits darüber hinaus. Für das kommende Jahr steht ein neues Design an. Außerdem befindet sich mit Thunderbird Mobile erstmals eine Smartphone-App für Android in Entwicklung.
Die MZLA Technologies Corporation hat kürzlich ihren Finanzbericht für das Jahr 2021 veröffentlicht. Wie dieser zeigt, steht das Thunderbird-Projekt finanziell auf gesunden Beinen und befindet sich weiter im Wachstum.
In den nächsten Wochen wird MZLA seinen neuen E-Mail-Client Thunderbird 102 veröffentlichen. Dieser wird wieder einige interessante Neuerungen beinhalten, darunter ein neues Adressbuch, was von Thunderbird-Nutzern bereits seit Jahren gewünscht wird. Alle wichtigen Neuerungen von Thunderbird 102 werden selbstverständlich auch hier auf diesem Blog wieder vorgestellt werden, sobald die neue Version zum Download zur Verfügung steht.
Die Planungen gehen natürlich längst viel weiter. So wurde mittlerweile angekündigt, dass Thunderbird 114, welcher im Jahr 2023 erscheinen wird, eine komplett überarbeitete Benutzeroberfläche haben wird, welche auf den internen Projektnamen „Supernova“ hört. Erste Anzeichen dafür werden bereits in Thunderbird 102 sichtbar sein, wie teilweise neue (und bunte) Icons sowie eine Seitenleiste, deren Farben übrigens vom Nutzer frei wählbar sind. Dies ist allerdings erst der Anfang.
Die aber wohl mit der größten Spannung erwartete Ankündigung betrifft die Expansion von Thunderbird auf das Smartphone. Mit Thunderbird Mobile wird es erstmals eine Thunderbird-App für Android geben. Der mobile Thunderbird, der sich schon seit einiger Zeit in Entwicklung befindet, wird natürlich, wie schon Thunderbird für Windows, macOS und Linux, kostenlos und Open Source sein. Bereits in zwei Wochen sollen erste offizielle Informationen zu Thunderbird Mobile folgen.
Im Rahmen des von der Europäischen Union geförderten Bergamot Projects arbeitet Mozilla daran, eine Übersetzungsfunktion für den Browser zu entwickeln – und das vollständig ohne Online-Komponente wie Google Translate. Kurz nach Veröffentlichung einer neuen Version mit vielen Neuerungen steht diese jetzt auch für die Installation in finalen Firefox-Versionen zur Verfügung.
Vor wenigen Tagen berichtete ich über eine neue Version von Firefox Translations zur maschinellen Offline-Übersetzung von Websites mit vielen Neuerungen. Diese konnte nur in Nightly-Versionen sowie in der Developer Edition von Firefox genutzt werden, weil zwei Konfiguration-Anpassungen notwendig waren, welche in finalen Firefox-Versionen nicht möglich sind.
Nun hat das Team Firefox Translations auf addons.mozilla.org zur Installation bereitgestellt. Ein wesentlicher Vorteil: Es müssen keine Schalter in about:config mehr verändert werden, dementsprechend funktioniert die Erweiterung auch in finalen Firefox-Versionen. Außerdem erhält der Anwender durch die Bereitstellung auf addons.mozilla.org auf Wunsch automatisch Updates auf neue Versionen.
Achtung: Laut Erweiterungs-Website ist Firefox Translations kompatibel mit Firefox 79 und höher. Dies ist jedoch nicht der Fall. Selbst Firefox ESR 91 ist zu alt. Damit Firefox Translations genutzt werden kann, muss also tatsächlich eine aktuelle Firefox-Version genutzt werden, die nicht Firefox ESR ist. In weniger als einem Monat macht aber auch Firefox ESR den Sprung zu Firefox 102, womit die Erweiterung dann auch in Firefox ESR funktionieren wird.
Hinweis für Nutzer, welche Firefox Translations zuvor über GitHub installiert hatten: Die alte Version sollte deinstalliert und die Änderungen in about:config wieder rückgängig gemacht werden. Konkret heißt das, dass xpinstall.signatures.required wieder auf true und extensions.experiments.enabled wieder auf false zu setzen sind.
Neben Slackware -current auf meinem Haupt-PC nutze ich auf meinem Laptop Fedora Vauxite. Dabei handelt es sich um eine Variante von Fedora Silverblue mit Xfce als Desktopumgebung. Da bisher keine eigenständigen Installationsmedien zur Verfügung stehen, kann wahlweise Silverblue oder Kinoite als Basis gewählt werden.
Im Folgenden beschreibe ich die Einrichtung und die Anpassungen, welche ich vorgenommen habe.
Ich habe mich für Kinoite entschieden und nach der Basisinstallation mit folgenden Befehlen einen rebase auf Vauxite durchgeführt:
Nach einem Neustart mittels systemctl reboot begrüsste mich lightdm, allerdings mit dem Standard GTK-Greeter, welcher auf meinem hochauflösenden Display winzig klein dargestellt wird. Nach dem Login und dem ersten Start von Xfce fand ich trotz der miniaturhaften Oberfläche unter Erscheinungsbild / Einstellungen die Möglichkeit der 2x Skalierung des Desktops. Unter Fensterverwaltung / Stil konnte ich passend dazu die Fensterdekoration Default-xhdpi wählen. Im Bereich Maus und Touchpad habe ich im Geräte Pull-Down-Menü mein Touchpad gewählt und die Mausradrichtung umgedreht. Unter dem Reiter Touchpad konnte ich darüber hinaus den Punkt Mausklicks per Touchpad ermöglichen wählen.
Statt der bei Xfce üblichen zwei Panels habe ich mich für ein Panel am unteren Bildschirmrand entschieden und dieses nach meinen persönlichen Vorlieben hin angepasst. Dabei ist mir aufgefallen, dass Vauxite das mittlerweile übliche Whisker Menü standardmässig nicht mit ausliefert. Da ich darüber hinaus einige weitere Anwendungen benötige, habe ich diese kurzerhand mithilfe folgenden Kommandos nachinstalliert, nachdem ich das RPM Fusion Repository aktiviert habe:
Nach einem beherzten sudo rpm-ostree ex apply-live standen die Änderungen bereits zur Verfügung und ich konnte das klassische Startmenü durch das Whisker Menü ersetzen.
Nach dem Aufruf von VLC ist mir aufgefallen, dass dieses weiterhin ohne Skalierung dargestellt wird. Zur Lösung habe ich folgende Datei erstellt:
sudo vim /etc/profile.d/qt-style.sh
if [ "$DESKTOP_SESSION" = "xfce" ] || [ "$XDG_SESSION_DESKTOP" == "xfce" ]; then
# QT apps to use GTK styling
export QT_STYLE_OVERRIDE=adwaita
# QT apps HIDPI scaling
export QT_SCALE_FACTOR=2
fi
Für GIMP hingegen musste ich ein eigenes Theme erstellen.
Das Fedora Projekt hat sich vor einiger Zeit entschieden, nano als Standard-Editor einzusetzen. Da ich vim Userin bin, habe ich darüber hinaus eine weitere Profil-Konfigurationsdatei erstellt:
sudo vi /etc/profile.d/zz-default-editor.sh
export EDITOR=vim
Umgebungsvariablen des Nutzers werden bei einem Aufruf von sudo standardmässig nicht mit übergeben. Um dies zu erreichen, habe ich mithilfe von sudo visudo folgende Parameter zur sudo-Konfiguration hinzugefügt:
Defaults rootpw
Defaults env_keep += "EDITOR"
Der erste Wert stellt sicher, dass bei einem Aufruf von sudo nicht das Benutzerpasswort, sondern das Root-Passwort abgefragt wird. Dies hatte ich bereits während der Installation von Kinoite aktiviert (Silverblue bietet diese Option nicht). Andernfalls kann man in einer Root-Shell das passwd Kommando ausführen und ein entsprechendes abweichendes Passwort setzen.
Hinweis: bei grafischen Passwortanforderungen mittels PolicyKit muss dennoch das User-Passwort angegeben werden.
Der zweite Parameter stellt sicher, dass die Umgebungsvariable EDITOR auch bei sudo Aufrufen berücksichtigt wird.
Nach dem Abmelden von der grafischen Oberfläche, um zu testen, ob alle Einstellungen aktiviert werden, stellte ich erstaunt fest, dass lightdm nun den slick-greeter verwendet. Letzerer skaliert auch auf HiDPI-Displays gut und wurde als Abhängigkeit des grafischen Administrationswerkzeuges lightdm-settings mitinstalliert.
In der lightdm Konfigurationsdatei habe ich dennoch den slick-greeter fest hinterlegt, da der Displaymanager andernfalls beim ersten Start versucht einen passenden Greeter unter den verfügbaren zu wählen:
sudo vim /etc/lightdm/lightdm.conf
[Seat:*]
...
greeter-session=slick-greeter
...
Damit die Schrift auch in einer tty gut lesbar ist, habe ich die Datei /etc/vconsole.conf wie folgt angepasst:
sudo vi /etc/vconsole.conf
KEYMAP="ch"
FONT="latarcyrheb-sun32"
Einige Zusatzpakete habe ich über Flatpak aus dem Flathub Repository installiert, nachdem ich dies wie folgt aktiviert habe. Für Flatpaks entscheide ich mich aktuell dann, wenn ich weiss, dass die Pakete dort regelmässig aktualisiert und im besten Falle direkt von den Entwicklern gepflegt werden.
Darüber hinaus habe ich keine wesentlichen Anpassungen ausgeführt. Lediglich im Xfce4-Terminal habe ich die Option zur Verwendung der Systemschriftart gesetzt und im Dateimanager Thunar sowie in den Schreibtischeinstellungen habe ich Single-Klick zum Öffnen von Ordnern aktiviert. Um GNOME-Keyring automatisch bei der Anmeldung zu entsperren, habe ich die ausführliche Anleitung im Arch Linux Wiki zurate gezogen.
Zusammenfassend würde ich selbst meinen Desktop als minimalistisch bezeichnen. Ich verzichte gerne auf grafischen Schnick-Schnack, da dieser mich eher irritiert, als dass ich Gefallen daran finde. Da kommt mir die Xfce-Desktopumgebung sehr entgegen, zumal ich diese schon nutze, seitdem es sie gibt. Als darunterliegende Technologie verwende ich gerne Bleeding-Edge Software und ich interessiere mich sehr für neue Ansätze, wie sie bei Fedora Silverblue und dessen Derivaten zum Einsatz kommen.
Ich würde mich freuen, wenn euch diese Zusammenfassung animiert, dieses oder ein ähnliches Setup einmal auszuprobieren und eure persönlichen Erfahrungen damit zu teilen.
Die MZLA Technologies Corporation hat mit Thunderbird 91.10 ein planmäßige Update für seinen Open Source E-Mail-Client veröffentlicht.
Neuerungen von Thunderbird 91.10
Mit dem Update auf Thunderbird 91.10 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit aktuelle Sicherheitslücken. Darüber hinaus bringt das Update kleinere Design-Korrekturen.
Mozilla hat Firefox 101 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.
Firefox 98 brachte diverse Änderungen des Download-Verhaltens. Eine davon war, dass Downloads nun umgehend stattfinden, ohne den Nutzer noch einmal explizit um Bestätigung zu bitten. Ein häufiger gehörtes Nutzer-Feedback war es, dass einige Nutzer weiterhin gefragt werden wollen. Zwar kann dies weiterhin erreicht werden, indem Firefox für möglichst viele Dateitypen entsprechend konfiguriert wird, doch ist dies verhältnismäßig umständlich. Mozilla reagiert auf dieses Feedback mit einer neuen Einstellung in den Einstellungen, welche automatisch für alle noch nicht konfigurierten Dateitypen gilt.
Immer alten Drucken-Dialog öffnen
Mit Firefox 86 hatte Mozilla die native Drucken-Oberfläche des jeweiligen Betriebssystems standardmäßig durch eine plattformübergreifend konsistente Oberfläche ersetzt. Über einen Link im Drucken-Dialog konnte die bisherige Oberfläche jederzeit geöffnet werden. Außerdem gab es mit print.tab_modal.enabled eine Option in about:config, um immer die alte Oberfläche zu öffnen. Diese Option wurde gemeinsam mit altem Code, der damit verknüpft war, in Firefox 97 entfernt.
Auch hier hat Mozilla auf das Feedback seiner Nutzer gehört und mit print.prefer_system_dialog eine neue Option für about:config eingeführt, welche das gleiche Ergebnis hat, nämlich immer den alten Drucken-Dialog zu öffnen, ohne den obsoleten Code wieder einzuführen.
Bild-im-Bild-Verbesserungen
Nach der Unterstützung von Untertiteln im Bild-im-Bild-Modus (PIP) für Videos in Firefox 100 wurde das PIP-Fenster in Firefox 101 um eine Schaltfläche zum Stummschalten der Videos erweitert. Werden mehrere Videos in diesem Modus gestartet, werden diese außerdem nicht länger standardmäßig aufeinander positioniert.
Verbesserungen der Entwicklerwerkzeuge
Mehrere Verbesserungen hat das Inspektor-Werkzeug bekommen. Soll zu einem HTML-Element eine Klasse hinzugefügt werden, gibt es bei Verwendung des Eingabefelds hinter der .cls-Schaltfläche jetzt eine Autovervollständigung, welche alle bereits auf der Seite bestehenden Klassen-Namen vorschlägt. Jeder Vorschlag findet umgehend nach Auswahl mittels Pfeiltasten Anwendung, so dass schnell verschiedene CSS-Klassen getestet werden können.
Bei CSS-Eigenschaften, welche Größen verändern, können diese nun mittels Klicken und Ziehen verkleinert respektive vergrößert werden. Wer die Funktion nicht haben möchte, kann diese in den Einstellungen der Entwicklerwerkzeuge deaktivieren.
Die Performance der Webkonsole wurde verbessert.
Verbesserungen der Web- und Erweiterungsplattform
Bei der Verwendung einer Konferenz-Anwendung kann der Benutzer nun alle vorhandenen Mikrophone nutzen und jederzeit zwischen diesen wechseln, sofern die entsprechende Anwendung diese Möglichkeit aktiviert.
Firefox 101 unterstützt den prefers-contrast Media Query, über welchen Websites die Information erhalten können, ob Nutzer einen schwächeren oder stärkeren Kontrast bevorzugen, um die Darstellung gegebenenfalls entsprechend anpassen zu können.
Darüber hinaus wurde das WebDriver BiDi-Protokoll aktiviert, um es externen Werkzeugen wie Selenium zu erlauben, dieses für Automatisierung mittels Firefox zu nutzen.
Außerdem unterstützt Firefox 101 die neuen Viewport-Längeneinheiten svh, lvh, dvh, svw, lvw, dvw, svmax, lvmax, dvmax, svmin, lvmin und dvmin, was vor allem in Zusammenhang mit den dynamischen Toolbars moderner Smartphone-Browser relevant ist.
Weitere Verbesserungen der Webplattform sowie einige Änderungen für Erweiterungs-Entwickler, welche vor allem in Zusammenhang mit dem kommenden Manifest v3 (MV3) relevant sind, darunter eine neue Scripting-API, lassen sich in den MDN Web Docs nachlesen.
Geschlossene Sicherheitslücken
Auch in Firefox 101 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 101 daher für alle Nutzer dringend empfohlen.
Im heutigen Artikel möchte ich euch kurz ein Werkzeug vorstellen, das immer dann sinnvoll ist, wenn mehrere Dateien auf einmal nach einem bestimmten Muster umbenannt werden sollen.
Das Werkzeug heißt rename (man prename) und kann unter Debian/Ubuntu als solches aus den Repositories bezogen werden. Bei anderen Distributionen muss man darauf achten, dass man die Perl-Variante nimmt (teils auch als prename bekannt) und nicht auf die util-linux-Variante zurückgreift, die zwar simple Ersetzungen beherrscht, aber kein Regex/Perl-Expression beherrscht und nur den ersten Treffer im Dateinamen ersetzt.
Das Kommando ist relativ einfach aufgebaut:
rename OPTIONS perlexpr [ files ]
Die wichtigste Option, das möchte ich vorab schon sagen, ist -n, da hiermit ein "Trockenlauf" durchgeführt und somit überprüft werden kann, ob das Muster auch passt.
Darüber hinaus halte ich -v für die zweitwichtigste Option, da man im "scharfen" Lauf dann überwachen kann, was konkret umbenannt wurde.
Das Muster selber wird als Perl-Expression übergeben, die in vielen Fallen an die Syntax vom Kommandozeilenwerkzeug sed für die Ersetzung von Text erinnert.
Das Kommando kann dann zum Beispiel so eingesetzt werden:
rename 's/TEst/Test/g' *.txt
Hier sollen alle Stellen mit "TEst" in den Dateinamen, die auf .txt enden, durch "Test" ersetzt werden. Mit einem klassischen mv ließe sich das nicht ohne weiteres umsetzen, da dieses Werkzeug nicht kontextbezogen ersetzen/umbenennen kann.
Natürlich können auch komplexere (Regex)-Muster umgesetzt werden: soll z. B. die Dateiendung aller Dateien, die auf ".htm" enden, in ".html" umbenannt werden, geht das mit folgendem Kommando:
rename 's/\.htm$/\.html/' .htm
Weitere Beispiele und Bedienungshinweise können aus dem Ubuntuusers-Wiki bezogen werden.
Meiner Erfahrung nach spart das Werkzeug besonders viel Zeit bei Umbennungsaufgaben und ersetzt somit ggfs. eigene Skripte mit find-mv-Konstruktionen.
NixOS ist eine Linux-Distribution auf Basis des Nix-Paketmanagers. Die Distribution basiert auf dem Ansatz deklarativer Systemkonfiguration, um reproduzierbare und zuverlässige Systemkonfiguration und in Folge reibungslose Systemaktualisierungen zu erlauben. Nun gibt der Release Manager Janne Hess die Verfügbarkeit der Version 22.05 bekannt.
Die Besonderheit dieser Version ist, dass erstmalig bei dieser Distribution ein grafisches Installationswerkzeug zum Einsatz kommt. Wie man dem Bild unschwer erkennen kann, handelt es sich dabei um Calamares. Kernstück von NixOS ist der Paketmanager Nix, der in der Version 2.8 vorliegt. Damit liegt die Hürde für den Einstieg in das besondere Konzept (reproduzierbar, deklarativ, zuverlässig) von NixOS ein gutes Stück tiefer, sodass die eine oder der andere vielleicht eine Proberunde damit drehen möchte. Dafür verweise ich auch auf unsere Artikelserie zu NixOS vom Dezember 2021:
Bei AlmaLinux handelt es sich um einen Clone der kommerziellen Red Hat Enterprise Linux (RHEL) Distribution. Das als Stiftung aufgestellte Projekt entfernt dabei in erster Linie das Branding und Vorkommnisse der Bezeichnung Red Hat in Paketnamen und anderen Komponenten. Bei Wechseln der Major-Release Version, wie es von 8 auf 9 der Fall ist, fällt dabei erwartungsgemäss etwas mehr Arbeit an, da neue Pakete und weiter Bestandteile zur Upstream-Distribution hinzugefügt wurden.
Dennoch ist es dem Projekt gelungen, in kürzester Zeit eine erste Veröffentlichung auf Basis von RHEL 9 bereitzustellen.
Damit ist AlmaLinux erneut führend, gegenüber Projekten wie Rocky Linux oder semi-kommerziellen Clones wie Oracle Linux.
Aktuell werden die folgenden Architekturen unterstützt:
Zur Darstellung von Medieninhalten werden oftmals Codecs benötigt, welche aus lizenzrechtlichen Gründen nicht direkt mit vielen Linux-Distributionen ausgeliefert werden.
Dies betrifft nicht nur die Wiedergabe von Medien in darauf ausgelegten Applikationen, sondern beispielsweise auch die Integration in Webbrowser. Dort wird zumeist der Codec H.264 verwendet, welcher in Firefox aktuell über ffmpeg eingebunden wird.
Zur Installation wird zunächst das RPM Fusion Repository integriert:
Änderungen mittels rpm-ostree werden dabei erst beim nächsten Neustart des Systems aktiviert. Alternativ kann der folgende experimentelle Parameter genutzt werden, welcher bei Paketinstallationen in der Regel gut funktioniert, sofern allerdings overlays entfernt wurden, ist dennoch ein Neustart notwendig:
sudo rpm-ostree ex apply-live
Daraufhin kann ffmpeg installiert werden:
rpm-ostree install ffmpeg
Nach einem erneuten Ausführen von sudo rpm-ostree ex apply-live oder einem Neustart, sollte eine Wiedergabe von H.264 codierten Videos im Webbrowser Firefox bereits möglich sein. Prüfen lässt sich dies beispielsweise durch das Abspielen eines Trailers auf der unter Filmfans beliebten Seite IMDB.
Ein Grossteil der Multimedia-Applikationen setzt allerdings auf gstreamer als Backend. Dazu zählt beispielsweise der unter KDE Plasma beliebte Dragon Player oder auch GNOME Videos (totem). Die dafür benötigten Codecs lassen sich wie folgt installieren:
Vor zwei Wochen habe ich das menübasierte Installationsprogramm von Arch Linux vorgestellt, mit dem die Installation von Arch Linux auf für Anfänger möglich ist. Gestern wurde archinstall 2.5.0 mit einer Fülle neuer Funktionen veröffentlicht, darunter FIDO2 (HSM)-Unterstützung für systemd-boot beim Entriegeln der Festplattenverschlüsselung mit einem Master-Passwort als Backup während der Registrierung. Mit Archinstall können Benutzer nun FIDO2-Geräte als Entsperrmechanismus für eine Partition verwenden.
Das Hauptmenü von Archinstall wurde in dieser Version um eine neue Datenträger-Vorschau, eine neue Datenträger-Layout-Vorschau sowie eine Benutzer-Vorschau des Hauptmenüs erweitert. Ausserdem wurden in der Version 2.5.0 verschiedene Menütypen hinzugefügt, um die verschiedenen Rückgabearten der Menüauswahl besser handhaben zu können, sowie allgemeine Verbesserungen der Festplattenlayout-Ansicht.
Archinstall 2.5.0 verbessert auch die Benutzerverwaltung und implementiert eine neue Benutzerstruktur in --config, fügt Fernladen zu --config, --disk-layout und --creds hinzu, fügt einen retry=True-Aufruf zur Funktion Partition.format() hinzu, um die Formatierung im Falle einer Kernel-Verzögerung zu wiederholen, und fügt Unterstützung für die Codierung von pathlib.Path-Objekten zum archinstall.general.JSON-Encoder hinzu.
Neben anderen Änderungen führt archinstall 2.5.0 die Tastenkombination Strg+C zum Löschen der aktuellen Option ein, installiert automatisch das network-manager-applet, wenn ein Desktop-Profil und NetworkManager ausgewählt werden, und fügt neue Übersetzungen hinzu, darunter brasilianisches Portugiesisch, Tschechisch, Italienisch, Polnisch, Portugiesisch, Russisch, Spanisch, Türkisch und Urdu.
Archinstall 2.5.0 bringt auch viele Fehlerkorrekturen mit sich. Weitere Informationen finden ihr in den Release Notes auf der GitHub-Seite des Projekts, von der man auch den Sourcecode-Tarball zum Kompilieren herunterladen kann. Die neue archinstall-Version ist jetzt in den stabilen Software-Repositories von Arch Linux verfügbar.
Im Rahmen des von der Europäischen Union geförderten Bergamot Projects arbeitet Mozilla daran, eine Übersetzungsfunktion für den Browser zu entwickeln – und das vollständig ohne Online-Komponente wie Google Translate. Nachdem es lange ruhig schien, kann jetzt eine von Grund auf neu entwickelte Version getestet werden.
Bergamot Project: Website-Übersetzung im Browser
Bereits im Oktober 2019 berichtete ich über das Bergamot Project. Zur Erinnerung:
Hintergrund des Ganzen ist das von der Europäischen Union geförderte Bergamot Project, in dessen Rahmen Mozilla mit der University of Tartu (Estland), der University of Sheffield (England), der University of Edinburgh (Schottland) und der Charles University (Tschechien) kollaboriert, um eine vollständig clientseitige Funktion zur maschinellen Übersetzung von Websites für den Browser zu entwickeln.
Die clientseitige Durchführung der Übersetzung soll einerseits der Privatsphäre dienen, da kein Datenriese wie Google involviert ist, andererseits aber auch die Verbreitung von Sprachtechnologie in Europa fördern, und zwar in Bereichen, welche Vertraulichkeit erfordern und wo es dementsprechend keine Option ist, die Übersetzung in der Cloud durchzuführen.
Das Bergamot Project ist mit drei Millionen Euro durch die Europäische Union gefördert und auf drei Jahre ausgelegt. Damit das Projekt auch über die drei Jahre hinaus einen langfristigen Effekt hat, wird die Übersetzungsfunktion in Firefox integriert und alle Technologien, welche im Rahmen des Bergamot Projects entstehen, als Open Source veröffentlicht.
Was im letzten Jahr geschah
Ziemlich genau ein Jahr ist es her, dass ich über eine direkte Integration der damaligen Browser-Erweiterung in die Nightly-Version von Firefox berichtete. Im Juli 2021 folgte noch ein nennenswertes Update, seit dem ist es ruhig um das Projekt geworden.
Die Implementierung in der Nightly-Version war schon eine ganze Weile auf Grund von Änderungen der Mozilla-Plattform nicht mehr funktionsfähig, im März wurde die Integration in der Nightly-Version von Firefox dann entfernt. Im Hintergrund erfolgte zu dem Zeitpunkt längst eine komplette Neuentwicklung der Browser-Erweiterung.
Die Neuerungen von Firefox Translations 1.1.2
Verbesserte Performance
Eine der wichtigsten Verbesserungen gegenüber Firefox Translations 0.4.3 ist die Performance. Sowohl WebAssembly-Verbesserungen auf Seiten der Firefox-Plattform als auch die neue Architektur der Erweiterung sollten ihren Teil dazu beitragen, dass die Erweiterung gut performt, ohne die Leistung von Firefox zu sehr zu beeinträchtigen.
Unterstützung für weitere Sprachen
Unterstützte Firefox Translations bisher Übersetzungen aus dem Spanischen sowie aus dem Estnischen ins Englische und umgekehrt, sowie vom Englischen ins Deutsche (bisher allerdings nicht umgekehrt, in der neuen Version jedoch schon), stehen jetzt auch die Sprachen Bokmål (Norwegen), Bulgarisch, Italienisch und Portugiesisch zur Verfügung. Außerdem, mit einem Beta-Zusatz versehen, um deutlich zu machen, dass deren Übersetzungs-Qualität noch nicht an die anderen heranreicht: Isländisch, Nynorsk (Norwegen), Persisch sowie Russisch.
Unterstützung für Apple Silicon
Firefox Translations lief bereits plattformübergreifend auf Windows, Apple macOS und Linux – außer es wurde ein neuer Mac (November 2020 oder später) mit sogenanntem Apple Silicon Chip, also einem M1-Prozessor, verwendet. Die neue Version von Firefox Translations unterstützt auch Apples neue Prozesser-Architektur.
Zusätzliche Features
Firefox Translations unterstützt gegenüber der Vorjahres-Version zusätzliche Features. Dies schließt die Übersetzung von Formularen, die Hervorhebung von möglichen Übersetzungsfehlern durch eine rote Schlangenlinie sowie die Möglichkeit ein, Seiten beim Surfen in einem Tab automatisch zu übersetzen, ohne dass jedes Mal manuell der Übersetzungs-Prozess gestartet werden muss. Ein intergrierter Umfragen-Button bittet die Nutzer außerdem um Feedback zur Übersetzungs-Funktion.
Außerdem kann jetzt auch auf Seiten, auf denen keine übersetzbare Seite erkannt wird und die Übersetzungsleiste dementsprechend nicht automatisch eingeblendet wird, diese per Klick auf ein entsprechende Symbol in der Adressleiste aktiviert werden, wo dann manuell die Original-Sprache auszuwählen ist.
Installation von Firefox Translations
Update 2. Juni 2022: Firefox Translations kann ab sofort über addons.mozilla.org für Nutzer einer aktuellen Firefox-Version installiert werden. Firefox ESR 91 wird auf Grund seines Alters nicht unterstützt.
Ubuntu ist die am weitesten verbreitete Linux-Distribution. Das gilt für die offiziellen Varianten, aber umso mehr, wenn man sich vergegenwärtigt, dass der Ubuntu-Unterbau die Basis für Distributionen wie Linux Mint, Pop!_OS oder elementary OS bildet. Wie ist es eigentlich um die Sicherheit bei Ubuntu bestellt?
Achtung: Wer keine Kritik an Debian verträgt oder jeden Vergleich von Debian mit irgendetwas anderem als Sakrileg empfindet, bitte hier gleich aufhören zu lesen.
Einordnung
Diese Frage bzw. dieser Vorwurf erreicht mich immer wieder, da ich einerseits die Situation bei Debian sehr kritisch beurteilt habe, aber andererseits immer mal wieder erzähle, dass ich Ubuntu nutze. (Kleiner Hinweis übrigens an die Alles-Hasser in den Kommentarspalten: Ich bin kein „Ubuntu-Fanboy“, wenn ich „Fan“ irgendeiner Distribution bin, dann sicher von openSUSE. Aber um das herauszufinden, müsste man ja tatsächlich diesen Blog lesen…). Zurück zu Debian vs. Ubuntu: Tatsächlich messe ich hier mit zweierlei Maß!
Der Grund dafür ist leicht zu erklären. Wenn mich irgendetwas besonders abstößt oder auch einfach nur provoziert, dann Selbstgerechtigkeit. Debian wird von seinen Anhängern immer besondere Sicherheit zugeschrieben (siehe z. B. der eigene Abschnitt bei Wikipedia) und unter jedem Debian-Artikel taucht irgendeiner auf, der sagt, dass man genau wegen der Stabilität und Sicherheit Debian verwenden muss. Im Gegensatz dazu weiß jeder, dass Ubuntu abseits von main Probleme mit der Qualität hat. Niemand in der Ubuntu Community würde das Gegenteil behaupten und der potenziell faulige Zustand der dortigen Software wird Neulingen bei jeder Gelegenheit erzählt. Ein Artikel über die Probleme bei Ubuntu universe ist also eigentlich völlig überflüssig, weil ich darüber schreiben würde, was sowieso jeder weiß (bzw. habe ich auch schon).
Kurzum: Wer eine sichere Distribution sucht, greift sowieso nicht zu Ubuntu, sondern zu RHEL oder einem freien Klon oder Fedora, wenn man es aktueller mag. Alternativ gibt es noch openSUSE Leap bzw. SUSE Linux Enterpise bei Bedarf für einen offiziellen Supportvertrag. Hier ist dann meiner Meinung nach auch schon Ende bei den Linux-Distributionen, die ich bezüglich Sicherheit besonders empfehlen würde, wenn man von Spezialdistributionen wie Qubes etc. absieht.
Wie groß ist das Problem der eigenen Installation
Die spannende Frage ist aber, wie groß das Problem bei Ubuntu wirklich ist und ob ein normaler Desktop-Nutzer wirklich eine besonders sichere Distribution benötigt. Dazu muss man ein wenig tiefer in das jeweilige System schauen. Im konkreten Fall gehe ich von Kubuntu-Installationen aus, wie ich sie normalerweise aufsetze. Den Sicherheitsstatus kann mit folgendem Befehl abfragen.
$ ubuntu-security-status
Das Ergebnis hängt dann vom jeweiligen Setup aber und kann z. B. wie folgt aussehen:
2004 packages installed, of which:
1159 receive package updates with LTS until 4/2027
3 packages are from third parties
2 packages are no longer available for download
Packages from third parties are not provided by the official Ubuntu
archive, for example packages from Personal Package Archives in
Launchpad.
For more information on the packages, run 'ubuntu-security-status
--thirdparty'.
Packages that are not available for download may be left over from a
previous release of Ubuntu, may have been installed directly from a
.deb file, or are from a source which has been disabled.
For more information on the packages, run 'ubuntu-security-status
--unavailable'.
This machine is not attached to an Ubuntu Advantage subscription.
See https://ubuntu.com/advantage
Das bedeutet, 1159 Pakete entstammen main und erhalten Sicherheitsupdates von Canonical. Das ist das, was ich als Betriebssystem-Basis bezeichne. 840 Pakete kommen aus multiverse oder universe und haben keinen garantierten Sicherheitsstatus.
Was das genau ist, kann sehr einsteigerfreundlich bei Muon (oder Synaptic bei GTK-Oberfläche) eingesehen werden.
Kein offizieller Support – Katastrophe?
Alle Pakete mit dem blauen Kreis haben offiziellen Supportstatus. Pakete ohne entsprechendes Symbol eben nicht. Auf einem Kubuntu-System wird der überwiegende Teil davon zum KDE-Softwarestack gehören. Das ist aus mehreren Gründen nicht kritisch:
Die Kubuntu-Entwicker pflegen die Software und bringen Updates raus. Sie reichen auch Updates von KDE weiter (bei der letzten LTS wurde z. B. KDE Plasma von der Releaseversion 5.18.4 auf 5.18.8 angehoben). Um den Vergleich mit Debian wieder zu bemühen: Dort passiert das nicht und wer den KDE-Stack nach dem zumindest halben Weggang von Norbert Preining pflegt, kann ich nicht sagen. Trotzdem behauptet Debian, dass sie KDE Software umfänglich unterstützen, während Ubuntu das hier nicht tut. So viel zum Ehrlichmachen, was ich oben angesprochen habe.
Unabhängig von dem Aspekt sind Sicherheitslücken bei KDE eher selten. Das liegt nicht zuletzt an der Art, wie freie Software aufgebaut ist. Dazu kann man einfach mal das Packprogramm Ark nehmen. Sicherheitslücken treten eher selten in der Oberfläche auf, sondern betreffen meist die Kompressionsprogramme. Ark hat keinen offiziellen Sicherheitsstatus, zip, unzip, bzip etc. schon. Das kann man auf viele andere Bereiche übertragen. Akonadi hat selten Sicherheitslücken, die PostgreSQL-Datenbank im Hintergrund dagegen häufiger.
Nicht alles in universe ist zudem gleichermaßen problematisch, sondern sehr abhängig davon, wo sich Freiwillige engagieren. VirtualBox in Ubuntu bekommt z. B. sehr regelmäßig Updates durch zwei Debian-Maintainer. Ironie am Rande: In Debian ist VirtualBox rausgeflogen, weil dort keine Updates verteilt werden dürfen, die Versionsnummern anheben, selbst wenn es wirklich nur Wartungsupdates sind, wie bei VirtualBox.
Problematische Bereiche
Also gibt es keine Probleme? Leider doch:
Der komplette Multimedia-Stack hat keinen offiziellen Supportstatus und der Zustand der Codecs ist bekanntermaßen schlecht. Das ist kein exklusives Linux-Problem, sondern der Multimedia-Bereich bei z. B. Android leider auch immer wieder ein Grund für viele Sicherheitsupdates. Die Trennung in bad, ugly & Co bei GStreamer ist auf jeden Fall kein Entwicklerspaß, sondern ernst gemeint. Ich weiß nicht, wie andere Distributionen damit umgehen. OpenSUSE hat sich des Problems formell mit Packman entledigt, Red Hat / Fedora mit EPEL. Wie Debian glaubt hier Sicherheit garantieren zu können weiß ich nicht. Besonders fatal finde ich, diese Anleitungen für Einsteiger, bei denen alle Codecs installiert werden, die es gibt, anstelle nur der wirklich genutzten Formate. Hier ist für die Sicherheit weniger einfach mehr. Egal bei welcher Distribution.
Ein weiteres Problem ist der fehlende Support von Qt5. Besonders bei Qt5Webengine ist das fatal, weil Programme wie KMail oder RSS Guard diese nutzen, um HTML-Ansichten auszugeben. Das ist ein heftiges Manko (und dass Debian da nicht besser ist, hilft leider nicht) und als Anwender kann man sich da nur behelfen, indem man HTML in Programmen wie KMail standardmäßig deaktiviert lässt.
In manchen Bereichen ist man zudem sehr zurückhaltend. Das betrifft jetzt nicht Updates und Sicherheitslücken aber Prioritätensetzung. Die Funktion systemd-cryptenroll hat Canonical z. B. für Ubuntu 22.04 faktisch deaktiviert, weshalb keine TPM oder FIDO2-Unterstützung für LUKS-Entsperrung vorgesehen ist. Bei openSUSE hat man das hingegen für 15.4 implementiert.
Abschließend sei der Vollständigkeit halber zudem noch auf die offizielle CVE-Liste von Ubuntu verwiesen, die leidlich versierten Anwendern zumindest einen Blick in den Abgrund ermöglicht. Hier kann man gut nachprüfen, wie der aktuelle Zustand von Paketen ist, die man vielleicht im Verdacht hat. Anlässlich meiner jüngsten Empfehlung das Akonadi-Backend von MariaDB auf PostgreSQL umzustellen, sei hier mal exemplarisch auf die Liste von MariaDB in 22.04 „Jammy Jellyfish“ verwiesen.
Zusammengefasst
Ubuntu ist keine perfekte Distribution, wenn man einen Fokus auf Sicherheit legt. Das hat aber auch nie jemand behauptet. Als normaler Anwender kann man trotzdem sehr gut damit arbeiten, weil die Gefahr wirklich schwerwiegender Sicherheitslücken überschaubar ist. Notwendige Updates betreffen sehr oft die „Systembasis“ und neuralgische Bereiche wie den Internetbrowser. Hier bekommt man bei Ubuntu zuverlässig Updates. Das gilt aber natürlich ebenso für Debian.
Wie groß das Problem ist, hängt ganz wesentlich von der eigenen Installation und dem genutzten Derivat ab. Anwender der Hauptdistribution mit GNOME Shell dürften vermutlich noch weniger nicht-unterstützte Pakete haben als ich mit der hier gezeigten Kubuntu-Instanz. Es kann aber auch sicherlich deutlich schlimmer sein, wenn man noch viel mehr aus Universe bezieht.
Ich persönlich schätze die Ehrlichkeit hinter der Trennung in main und universe. Deshalb gebe ich Ubuntu den Vorzug vor Debian. Für wirklich hohe Sicherheitsansprüche würde ich aber sowieso keine der beiden Distributionen nutzen.
Datensparsamkeit und Schutz der digitalen Privatsphäre ist das eine Thema, Anonymität ein völlig anderes. Leider wird beides viel zu oft vermengt. Anonymität ist nicht immer notwendig und wenn, dann nur mit strenger Disziplin und den entsprechenden Werkzeugen zu erreichen. Eines dieser Werkzeuge bietet Whonix.
Umfeld von Whonix
Anonymität ist im Internet immer noch gleichzusetzen mit Tor (trotz aller Probleme). Doch obwohl sich Tor beispielsweise einfach über die Paketquellen der meisten Linux-Distributionen installieren lässt, ist es nicht einfach damit getan, seinen Datenverkehr über ein paar Tor-Knoten zu leiten. Denn erstens erfolgt Identifizierung heute über mehr Faktoren als nur die IP-Adresse und zweitens würde man bei so einem Vorgehen auch identifizierbaren Traffic mitschicken und sich damit selbst kompromittieren.
Deshalb gibt es zwei besonders bekannte Lösungen, um anonym zu surfen. Den Tor Browser und Tails. Der Tor Browser ist ein niedrigschwelliges Angebot, das einfach unter jedem Betriebssystem installiert werden kann. Dabei handelt es sich um eine modifizierte Firefox-Version, die darauf ausgelegt ist, in der Masse unterzugehen und natürlich den Datenverkehr über das Tor-Netzwerk leitet. Für den Einstieg und „kleinere“ Anonymitätsbedarfe völlig ausreichend.
Die Arbeit auf dem eigenen Desktop hat aber auch Nachteile. Downloads können manipuliert sein oder der ein oder andere Link aus Versehen doch im falschen Browser geöffnet werden. Für diese Zwecke gibt es Tails, das nur als Live-System funktioniert und somit immer eine saubere Arbeitsumgebung startet. Die Funktionsweise bedingt natürlich einen abwechselnden Betrieb zum eigenen System und die eigene Hardware sollte mit GNOME Shell flüssig laufen, denn Tails versucht im Linux-Umfeld möglichst wenig aufzufallen. Ein zufälliger Beobachter im Café soll eben nicht sehen, dass man gerade mit Tails arbeitet. Tails ist unpraktisch und will auch genau das sein.
Whonix
An diesem Punkt kommt Whonix ins Spiel. Die Entwickler haben den Anspruch ein „wasserdichtes Betriebssystem für die Privatsphäre“ zu schaffen und durchaus prominente Fürsprecher. Anders als Tails setzt man auf Virtualisierung, weshalb sich Whonix in das eigene Arbeitsumfeld einfügt, aber im Gegensatz zum Tor Browser dennoch hinreichend separiert.
Dieses Ziel erreichen die Entwickler mit Virtualisierung. Whonix gibt es für VirtualBox (Windows, macOS, Linux) und für das erste Setup ist dies auch der einfachste Weg. Linux-Anwender können aber auch eine Virtualisierung über KVM vornehmen und besonders sicherheitsbewusste Anwender können zu Qubes greifen.
Whonix verwenden
Die Installation und Einrichtung funktioniert für VirtualBox über den Download von OVA-Images. Diese können über die Schaltfläche Importieren in VirtualBox importiert werden. Dabei werden zwei virtuelle Maschinen angelegt:
Whonix Gateway
Whonix Workstation
Beide Maschinen müssen gestartet werden. Whonix Gateway ist dafür zuständig, die Verbindung zum Tor-Netzwerk aufzubauen. Ansonsten macht man als Anwender nichts in dieser Maschine. In der Workstation darf gearbeitet werden. Diese Workstation kann nur über den Gateway nach außen kommunizieren. Die Idee dahinter ist, dass selbst bei einer Kompromittierung der Workstation Informationen wie die öffentliche IP-Adresse nicht offen gelegt werden kann.
Beide Maschinen müssen über den Befehl upgrade-nonroot aktualisiert werden, um Sicherheits- und Funktionsupdates zu erhalten. Als Desktop kommt das ressourcensparsame Xfce zum Einsatz. Eine kleine Softwareauswahl ist bereits vorinstalliert. Insbesondere der zentrale Tor Browser in einer speziellen Ausfertigung.
Vor- und Nachteile
Whonix soll in einer virtuellen Umgebung laufen. Dadurch kann der Anwender das System anpassen und konfigurieren und startet anders als bei Tails nicht jedes mal mit einem blanken System. Das ist Vor- und Nachteil zugleich, weil es eben auch Spielräume zur Kompromittierung lässt. Zudem müssen Gateway und Workstation aktuell gehalten werden, weshalb eine gewisse Systempflege notwendig ist.
Der Betrieb von zwei virtuellen Maschinen zusätzlich zum Host-System erfordert zudem eine hinreichend potente Hardware.
Kontact bzw. der Akonadi-Unterbau sind so ein Thema für sich. Ein Paradebeispiel für Overengineering aber bei KDE hält man stoisch daran fest. Wer also einen konsistenten KDE-Arbeitsplatz haben möchte, kommt nicht daran vorbei. Leider sind die Abhängigkeiten bei Kubuntu 22.04 schlecht gesetzt. Eine Alternative mit PostgreSQL steht aber bereit.
Viele Fehlentscheidungen aus den frühen KDE 4-Zeiten haben die KDE-Entwickler inzwischen korrigiert – Akonadi leider nicht. Die längere Zeit in Entwicklung befindliche Alternative Kube ist eingeschlafen und auch neue Apps wie Kalendar basieren im Hintergrund leider weiter auf Akonadi. Viele grobe Bugs sind ausgeräumt, aber das vollkommen überdimensionierte Backend ist immer noch ein Garant für Probleme und Schwierigkeiten. Warum es für die Speicherung von Mails und PIM-Einträge so ein gewaltiges Backend braucht, wo doch Thunderbird und Evolution ohne auskommen, konnte nie jemand stimmig erklären. Wie so oft gilt hier vermutlich Entwicklerspaß vor Nutzerinteressen.
KDE-Anwender müssen also leider weiter mit Akonadi leben. Die Kubuntu-Entwickler haben als seit 20.04 als Standard Thunderbird vorgesehen (was schon ein Statement für sich ist), aber Kontact & Co natürlich weiter in den Paketquellen. Leider nicht besonders durchdacht. Das Paket akonadi-backend-mysql verweist nämlich auf MariaDB. Ich vermute, das hat man einfach von Debian übernommen. Leider setzt Canonical im Gegensatz zu vielen anderen Distributoren nicht auf MariaDB, sondern hält MySQL die Treue. MariaDB ist nur in Universe enthalten und hat somit einen nicht garantierten Sicherheitsstatus.
Die Derivate bzw. Universe und Sicherheit sind ein Thema für sich, das hier nicht im Detail diskutiert werden kann. Grundsätzlich ist nicht jede Software sicherheitskritisch und zumindest beim KDE-Stack verfolge ich das Thema engmaschig genug, um prüfen zu können, ob Kubuntu hier Probleme behebt. Die Basis (macht bei Installation hier circa 1200 von 1900 Paketen aus) wird ja direkt von Canonical gepflegt. Bei Software wie MariaDB hört aber bei mir die Toleranz auf, wenn es um nicht geschlossene Sicherheitslücken geht.
Zum Glück gibt es noch ein weiteres Akonadi-Backend und zwar das für PostgreSQL. Das ist nicht schlecht gepflegt, da einer der Kern-Entwickler von Kontact viele Jahre selbst PostgreSQL als Backend nutzte. Entwickler beheben Bugs ja auch gerne für sich selbst – warum also nicht davon profitieren? Der Vorteil für Kubuntu-Nutzer ist, dass PostgreSQL in main liegt und direkt von Canonical unterstützt wird.
Vorher unbedingt ein Backup machen. Das Szenario geht davon aus, dass E-Mails und PIM-Daten lediglich via IMAP und Cal-/CardDAV eingebunden sind und somit nicht verloren gehen können.
Der Umstieg ist ziemlich leicht. Zuerst Akonadi stoppen und das neue Backend installieren:
$ akonadictl stop
$ sudo apt install akonadi-backend-postgresql
Anschließend noch die Benutzerkonfiguration in der Datei ~/.config/akonadi/akonadiserverrc ändern:
Nun noch die alte MariaDB-Daten löschen, indem man das Verzeichnis ~/.local/share/akonadi/db_data umbenennt in z. B. db_data_bak. Sollte die Migration erfolgreich sein, kann es später gelöscht werden.
Nun noch Akonadi wieder starten und prüfen. Sollte es Probleme geben, wird hier auch aufgelistet, wo es klemmt.
$ akonadictl start
$ akonadictl fsck
Nun läuft Akonadi mit einem offiziell supporteten Backend. Negative Erfahrungen für Stabilität und Performance kann ich nicht berichten.
openSUSE lässt sich traditionell am Ende der Entwicklungs-Roadmap viel Zeit. Am 27. April erschien die RC-Version, einen Monat später erfolgte heute der Gold-Master-Build. Früher liefen dann die CD-Pressen an. Heute wartet man noch ein wenig bevor in zwei Wochen die Version final freigegeben wird. Höchste Zeit für einen tiefen Blick in die neue Version.
Diese Version ist im Wesentlichen eine Fortentwicklung der früheren Versionen der Leap 15-Serie:
Umstürzende Änderungen sind bei den Minor-Versionen einer Hauptserie nicht geplant. Ein umfassender Test entfällt daher, genau wie bei den Vorversionen auch schon. Stattdessen möchte ich ein wenig auf das Leap-Entwicklungsmodell eingehen, das immer noch bei vielen für Verwirrung sorgt, weil es nicht der von Debian geprägten „Standardnorm“ für LTS-Distributionen entspricht.
Das Leap-Entwicklungsmodell
Die neue Version ist die jüngste Inkarnation der 15er-Serie von openSUSE Leap. Diese ist höchstwahrscheinlich die letzte traditionelle Linux-Distribution aus dem Hause SUSE/openSUSE, bevor man mit Version 16 in zwei Jahren auf die neue SUSE Adaptable Linux Platform wechselt. Die 15er Version folgt einem Wechselsystem. Auf eine sehr zurückhaltende Version – das war die letzte Version 15.3 – folgt eine Version mit mehr Aktualisierungen.
Um ein etwas schiefes Bild zu benutzen: Durch den Entwicklungsprozess von openSUSE gleicht die neue Version einem Menschen im fortgeschrittenen Lebensalter, dem man ein paar Organe erneuert und die Gesichtshaut ordentlich hinter die Ohren gezogen hat. Optisch ganz gut anzusehen und sollte noch eine Weile laufen, aber im Kern eben doch schon ein paar Jahre alt.
Der Hintergrund ist, dass jede openSUSE Leap Version sich an den Service Packs von SLE orientiert und eine Weiterentwicklung der Hauptversion darstellt. Ein solcher Zyklus kann durchaus mehrere Jahre gehen. Leap 15.0 erschien 2018, seitdem entwickelt man auf dieser Basis weiter. Die Anwender müssen dabei immer auf die neueste Minor-Version aktualisieren, um weiterhin Sicherheitsaktualisierungen zu erhalten. Das ähnlich ähnlich wie bei Red Hat, aber anders als bei z. B. Debian oder Ubuntu, wo alle zwei Jahre eine neue LTS zusammen gebaut wird, die dann 3-5 Jahre eingefroren wird und keine substanziellen Änderungen mehr erfährt.
Im Gegensatz zu den Debian-Entwicklern glaubt man bei SUSE (und mit Abstrichen auch Red Hat) diese Versionsaktualisierungen hinreichend gut testen zu können. Dahinter steht die Überzeugung, dass eine vorsichtige Aktualisierung unterm Strich mehr bringt als eine Bugsammlung über Jahre einzufrieren. Gleichzeitig sind einschneidende Änderungen neuen Hauptversionen vorbehalten. So ist bei Leap 15.4 der usr-merge ebenso noch nicht erfolgt, wie die weitere Einbeziehung von systemd-Diensten anstelle z. B. von chrony oder cronie. Den Wechsel auf Plasma 6 würde man – so er denn irgendwann mal kommt – sicherlich auch nicht in einer Minorversion vollziehen, den Sprung von 5.18 auf 5.24 aber eben schon.
Schaut man tiefer in die Paketquellen, sieht man, dass viele Pakete direkt von SUSE aus SLE kommen (Versionen enden auf 150400). Andere Pakete stammen von openSUSE (Versionen enden auf lp154 oder bp154). Ebenso gibt es unterschiedliche Updatequellen für SLE- und openSUSE-Pakete. Diese Feinheiten müssen Anwender aber eigentlich nicht interessieren.
Versionen
Das bedeutet konkret für die Versionen, dass die Desktopumgebungen von KDE Plasma 5.24 über GNOME 41 bis zu MATE 1.26 und Xfce 4.16 relativ aktuell sind und teils aktueller als bei komplett „neuen“ Distributionen wie dem vor zwei Monaten veröffentlichten Ubuntu 22.04.
Der Kernel ist mit 5.14 schon ein wenig abgehangener, ebenso systemd 249. Beides aber nicht dramatisch alt und vermutlich nur relevant für Anwender von sehr aktueller Hardware oder sehr neuen Funktionen in systemd.
Schaut man dann tief in den Kern, sind Sachen wie glibc in Version 2.31 oder auch PolKit 0.116 richtig alt. Standardmäßig kommt für den GNU C Compiler die Version 7.5 zum Einsatz, GCC 10 und GCC 11 in aber in den Paketquellen enthalten. Eingefleischte openSUSE-Anwender werden das kaum seltsam finden, aber für Außenstehende wirkt das etwas seltsam. Unerwünschte Nebenwirkungen sind in meinen Tests aber nicht aufgetreten.
Installation und Vorkonfiguration
Installation und Vorkonfiguration wurden nicht verändert. Hier ist ein neuer Test also überflüssig. Als Standarddateisystem kommt Btrfs zum Einsatz, das mittels Snapper Betriebssystemschnappschüsse bei Updates anlegt. Datenpartitionen werden standardmäßig mit XFS angelegt, was bei einer dezidierten Home-Partition auch für diese zum Einsatz kommt.
Als Bootloader nimmt openSUSE GRUB 2.06. Man unterstützt Secure Boot und mittels Trusted Boot auch ein rudimentäres TPM-Measurement für den Boot-Prozess.
Die Verschlüsselung geschieht bei der Installation immer noch mit LUKS1 und das System benötigt weiterhin einen dezidierten root-Account. Neu ist die Möglichkeit bei der Installation SELinux anstelle von AppArmor aktivieren zu können. Die SELinux-Integration steckt bei SUSE aber noch in den Kinderschuhen und ich persönlich würde bei einem Produktivsystem davon absehen.
Nutzungserlebnis
Die Entwickler haben aus manchen vergangenen Fehlern gelernt. Die SLE-Updatequellen sind so schon seit längerem eingebunden. Allerdings ist der Entwicklungsprozess immer noch etwas schwierig und die Kommunikation zwischen SLE-Teams und openSUSE klappt manchmal nicht. Das hatte in der RC-Phase durch plötzliche massive Änderungen bei SLE SP4 einige Verzögerungen ausgelöst. Trotzdem halte ich unliebsame Überraschungen direkt nach dem Release dieses Jahr für nahezu ausgeschlossen.
Im täglichen Nutzungserlebnis profitiert man von der gut abgehangenen Basis, die lediglich an relevanten Stellen wie Kernel oder Mesa behutsam modernisiert wurde und den gleichzeitig aktuellen Desktopanwendungen. Da es hier bei den Desktopumgebungen quasi von KDE Plasma bis MATE und bei den Anwendungen von LibreOffice bis Firefox in den letzten Jahren keine umstürzenden Änderungen gab, sind diese aktuell sehr ausgereift und es entsteht eine wirklich gelungene Gesamtkomposition.
Fazit
Ein rundum gelungenes Release. Bestehende Anwender von openSUSE Leap können gefahrlos und mit Vorfreude aktualisieren. Ob Wechselwillige die Version zum Anlass nehmen umzusteigen, steht auf einem anderen Blatt. Nächstes Jahr kommt planmäßig dann noch mal eine deutlich moderatere Wartungsversion, bevor 2024 dann vermutlich revolutionäre Änderungen anstehen.
Leider haben die Entwickler nicht alle notwendigen Änderungen für systemd-homed zurück portiert, weshalb ich wohl bei Tumbleweed bleibe, da ich mich sehr an die TPM-Entsperrung mit zusätzlich abgesicherten Nutzerprofilen gewöhnt habe.
Mozilla rollt aktuell den sogenannten vollständigen Cookie-Schutz für alle Firefox-Nutzer aus und verbessert damit den Datenschutz seiner Nutzer.
Derzeit erhalten einige Nutzer von Firefox 91 und höher nach dem Start von Firefox einen Dialog mit der Option, die „leistungsstärkste Datenschutzerfahrung aller Zeiten“ zu aktivieren. Was hat es damit auf sich?
Vollständiger Cookie-Schutz – was ist das?
Im Februar 2021 hat Mozilla mit der Veröffentlichung von Firefox 86 den sogenannten „vollständigen Cookie-Schutz“ eingeführt. Vereinfacht gesagt bedeutet dies, dass die Cookies jeder Domain in einem separaten Cookie-Container gespeichert werden – seitenübergreifendes Tracking über Cookies soll damit erschwert werden.
Mehr Datenschutz für alle Firefox-Nutzer
Aktiviert war diese Datenschutz-Verbesserung bisher nur für Nutzer, welche in den Datenschutz-Einstellungen von Firefox den strengen Schutz vor Aktivitätenverfolgung aktiviert haben, sowie in privaten Fenstern.
Mit dem Dialog, den einige Firefox-Nutzer aktuell angezeigt bekommen, lädt Mozilla seine Nutzer ein, diese Datenschutz-Verbesserung auch in der Standard-Konfiguration von Firefox zu aktivieren und vorab zu testen, ehe dies irgendwann in der Zukunft vermutlich Standard für alle Nutzer werden wird.
Übrigens lässt sich die Entscheidung jederzeit über die Datenschutz-Einstellungen ändern. Nutzer, welche diesen Dialog gesehen haben, erhalten in den Datenschutz-Einstellungen auch eine zusätzliche Checkbox, über welche das Feature aktiviert respektive deaktiviert werden kann.
Eine kleine Lektüreempfehlung zum Feiertag. Andreas Proschofsky hat bei DerStandard eine sehr lesenswerte Erklärung der wichtigsten Linux-Begriffe verfasst. Sachlich korrekt, ausgewogen und ab und an mit einer kleinen Prise Humor.
Sicherlich nicht nur für Neulinge im Linux-Universum eine interessante Lektüre. Vom Kernel bis zu Wayland und Pipewire wird alles, was momentan so relevant ist ausführlich erklärt. Natürlich immer ein bisschen subjektiv, aber es ist auch kleine Enzyklopädie. Wer Wahrheiten sucht und andauernd „Fakten“ brüllt, sollte auch hier woanders weiter schauen. Mich hatte der Autor an diesem Punkt:
Bonus-Hinweis für Puristen: Genau genommen ist der Kernel nicht der zentrale Teil von Linux, er ist Linux. Über die Jahre hat sich aber eingebürgert, auch (viele) ihn umgebende Systeme als Ganzes so zu benennen. Wer gerne recht hat, darf diesen Umstand also unter jedem Artikel zu Linux als System als faktische Korrektur anmerken. Oder aber man verzichtet freiwillig darauf, sich bei allen anderen unbeliebt zu machen.
Ich nutze rsync in Verbindung mit dem rsync-time-backup für einfache Backups eines Servers. In letzter Zeit erhielt ich dort ein Problem mit bestimmten Dateien, welche ich synchronisieren wollte. rsync brach hier mit der Meldung: ab. Abhilfe schaffte es hier rsync, ohne die Option –compress zu nutzen. Hier liegt wohl ein Problem bzw. ein Bug vor, der unter Umständen zu diesem Verhalten führt.
Passwörter sind eine unsichere Angelegenheit. Deshalb gab es in den vergangenen Jahren viele Versuche, Passwörter zu ersetzen oder sicherer zu machen. Einer dieser Versuche, ist der Ansatz mit einem physischen zweiten Faktor zu arbeiten. Dank systemd lässt sich das nun einfacher denn je für Linux Verschlüsselung nutzen.
Die Erkenntnis, dass Passwörter unsicher sind, gehört inzwischen zum Standardsatz, mit dem man jeden Artikel dazu einleiten muss. Firmen arbeiten deshalb mit biometrischen Verfahren und vielen anderen Ansätzen. Ich persönlich schätze meinen YubiKey sehr, aber leider unterstützen den noch viel zu wenige Dienste.
Im Folgenden zeige ich die Einrichtung unter openSUSE. Sie funktioniert für openSUSE Tumbleweed und Leap 15.4. Das Verfahren dürfte aber für jede Distribution funktionieren, die systemd nutzt und keine Sonderlocken verfolgt. Arch Linux hat sie kürzlich in archinstall integriert.
Die Voraussetzung ist aktuell ein Partitionslayout mit einem vollständig verschlüsselten LUKS-System (egal, ob Root-Partition und Home-Partition getrennt sind) und eine unverschlüsselte Boot-Partiton. Der LUKS-Container muss dem LUKS2-Standard folgen. Bestehende SUSE-Installationen müssen daher erst auf LUKS2 konvertiert werden. Neue Installationen können mit der Startoption YAST_LUKS2_AVAILABLE=1 direkt als LUKS2 angelegt werden.
Nach der Umsetzung der Anleitung benötigt man für jeden Systemstart den eingesteckten YubiKey. Es gibt keinen automatischen Fallback-Mechanismus.
Zuerst ist ein Paket nachzuinstallieren. Je nach Setup ist es möglicherweise schon installiert (z. B. als Abhängigkeit von KeePassXC).
# zypper install libfido2-1
Nun steckt man den YubiKey ein. Mit folgendem Befehl führt man die Integration des YubiKey als Schlüssel für LUKS aus.
Das Laufwerk ist natürlich anzupassen. In der Regel muss man mit dem bisherigen LUKS-Passwort bestätigen. Der YubiKey wird dann in den nächsten freien Key-Slot geschrieben.
Anschließend ist noch die /etc/crypttab zu bearbeiten und fido2-device=auto am Ende zu ergänzen. Das Ergebnis sieht dann in etwa wie folgt aus:
Nun noch mittels dracut den initramfs neu erstellen.
# dracut -f
Bei einem Neustart wartet das System nun auf die Betätigung des YubiKey. Mangels Implementierung in Plymouth gibt es keinen grafischen Hinweis dazu auf dem Bildschirm, aber der YubiKey blinkt und zeigt dadurch an, dass eine Interaktion notwendig ist.
Mozilla hat Firefox 100.0.2 veröffentlicht und behebt damit zwei kritische Sicherheitslücken, welche im Rahmen des Hacking-Wettbewerbs Pwn2Own gezeigt worden sind.
Wieder einmal fand ein Pwn2Own-Wettbewerb im Rahmen der CanSecWest Sicherheitskonferenz in Vancouver statt. Und wie bereits im Vorfeld erwartet, hat Mozilla in Form eines schnellen Updates auf die Firefox betreffenden Ergebnisse reagiert. Firefox 100.0.2 behebt zwei Sicherheitslücken, welche Mozilla beide als kritisch einstuft. Ebenfalls in diesem Zusammenhang veröffentlicht wurden Firefox ESR 91.9.1 sowie Firefox 100.3.0 für Android. Auch Thunderbird wurde in Version 91.9.1 veröffentlicht.
Mozilla hat Version 2.8 seiner VPN-Clients für das Mozilla VPN veröffentlicht. Dieser Artikel beschreibt die Neuerungen vom Mozilla VPN 2.8.
Mit dem Mozilla VPN bietet Mozilla in Zusammenarbeit mit Mullvad sein eigenes Virtual Private Network an und verspricht neben einer sehr einfachen Bedienung eine durch das moderne und schlanke WireGuard-Protokoll schnelle Performance, Sicherheit sowie Privatsphäre: Weder werden Nutzungsdaten geloggt noch mit einer externen Analysefirma zusammengearbeitet, um Nutzungsprofile zu erstellen.
Das Mozilla VPN beinhaltet jetzt einen integrierten Geschwindigkeits-Test. Dieser misst den Ping sowie die Download-Geschwindigkeit und gibt darauf basierend eine Empfehlung ab, ob die Verbindung geeignet für das Surfen im Internet, Streaming von Videos und Videokonferenzen ist.
Sonstige Neuerungen
Eine neue Option in den Netzwerk-Einstellungen erlaubt das Tunneln durch Port 53/DNS, wodurch Firewalls besser umgangen werden können.
Die Authentifizierung auf Android und iOS wurde verbessert und findet nun vollständig innerhalb der App statt. Außerdem hat das Mozilla VPN auf den Smartphone-Plattformen eine neue Einführungstour mit animierten Illustrationen erhalten.
Dazu kommen wie immer diverse Fehlerbehebungen und Verbesserungen unter der Haube.
Nach AlmaLinux ist nun auch der Freie Red Hat Enterprise Linux (RHEL) Clone Rocky Linux in Version 8.6 verfügbar. Da es sich bei den Projekten um einen Rebuild der kommerziellen Distribution aus dem Hause Red Hat handelt und lediglich Copyright-behaftete Elemente wie das Branding entfernt werden, entsprechen die Neuerungen denen des Upstream-Produktes.
PHP ist in Version 8.0 enthalten und Perl wird in Version 5.32 ausgeliefert. Edge-Nodes lassen sich mithilfe des FIDO onboarding (FDO) Standards integrieren.
Zur Auswahl stehen drei weitere Systemrollen, zur vereinfachten Systemkonfiguration:
High availability (HA) cluster system role
Enhanced network system role
WebConsole role
Rocky Linux stellt Abbilder für die Architekturen x86_64 und aarch64 zur Verfügung.
Mozilla hat Firefox 100.0.1 veröffentlicht und bringt damit neben vielen Korrekturen auch eine verbesserte Prozess-Isolation für mehr Sicherheit unter Windows 10.
Mit Firefox 100.0.1 liefert Mozilla eine verbesserte Prozess-Isolation aus, welche den Zugriff der Content-Prozesse auf die mächtige win32k.sys API unterbindet, die ein beliebtes Angriffsziel darstellt. Voraussetzung hierfür ist Windows 10 mit dem Fall Creators Update (1709) oder neuer. Nutzer einer älteren Version von Windows 10 sowie von Windows 8 werden erst mit einem zukünftigen Firefox-Update davon profitieren können. Für Nutzer von Windows 7 ist dieser Schutz technisch nicht möglich, da Microsoft die Voraussetzungen dafür erst mit Windows 8 eingeführt hat.
Dass Mozilla diese Verbesserung in einem Update außer der Reihe veröffentlicht und nicht auf Firefox 101 gewartet hat, überrascht insofern nicht, als dass in dieser Woche wieder der bekannte Pwn2Own-Wettbewerb stattfindet, in dem es darum geht, Sicherheitslücken unter anderem in Browsern aufzudecken, und sich Mozilla vom sogenannten Win32k Lockdown signifikante Vorteile für die Sicherheit verspricht.
Nutzer von macOS haben eine vergleichbare Verbesserung übrigens bereits mit Firefox 95 erhalten. Seit dem haben Content-Prozesse keinen Zugriff mehr auf den WindowServer von macOS. Und für Linux-Nutzer wird seit Firefox 99 der Zugriff auf das X Window System (X11) blockiert.
Fehlerbehebungen in Firefox 100.0.1
Ansonsten bringt Firefox 100.0.1 aber auch diverse Fehlerbehebungen für alle Plattformen, darunter mehrere Bugfixes für das Bild-im-Bild-Feature (PIP) für Videos. Die bereits für Firefox 100 angekündigte Untertitel-Funktion für PIP, deren Aktivierung Mozilla für die finale Version von Firefox 100 versäumt hatte, steht nun standardmäßig zur Verfügung. Zur Erinnerung: Auf Websites, welche den WebVTT-Standard unterstützen, sowie auf den populären Video- und Streaming-Plattformen YouTube, Amazon Prime Video und Netflix, welche stattdessen eine eigene Lösung verwenden, kann Firefox jetzt die Untertitel von Videos auch im Bild-im-Bild-Modus anzeigen.
Aus Gründen der Webkompatibilität wurden WebSockets über HTTP/2 deaktiviert, da die Implementierung in Firefox fehlerhaft ist und Probleme verursachen kann. Außerdem wurde der sogenannte User-Agent für ein paar weitere Websites mit mangelhaft implementiertem User-Agent-Sniffing temporär auf den von Firefox 99 geändert. Dies betrifft unter anderem die deutsche Commerzbank, wo kein Login in den Bank-Account möglich war, nur weil die Versionsnummer von Firefox dreistellig wurde.
Des Weiteren wurde ein Fehler behoben, der verursachte, dass Lesezeichen ohne Titel nicht mehr synchronisiert worden sind.
Darüber hinaus gab es Fehlerbehebungen für die mit Firefox 100 eingeführte Unterstützung von HDR-Videos auf macOS sowie für mehrere durch Drittanbieter-Sicherheitssoftwares verursachte Absturzursachen.
Dazu kamen noch diverse Korrekturen für die bevorstehende Ausrollung des sogenannten vollständigen Cookies-Schutzes in der Standard-Konfiguration von Firefox. Diese mit Firefox 86 eingeführte Datenschutzverbesserung ist bisher nur bei Aktivierung des strengen Schutzes vor Aktivititätenverfolgung aktiv.
