Unter dem internen Projektnamen Fission arbeitet Mozilla bereits seit langer Zeit an einer Seiten-Isolation für Firefox. In Firefox 91 Beta testet Mozilla Fission erstmals auch unter Linux in einer Beta-Version von Firefox.
Firefox läuft nun schon seit mehreren Jahren mit einer sogenannten Multiprozess-Architektur. Diese unter dem internen Projektnamen Electrolysis, oder auch kurz: e10s, entwickelte Architektur trennt den Browser- von seinen Content-Prozessen, was eine verbesserte Sicherheit durch Sandboxing, Performance sowie Stabilität bringt, da seit dem ein Website-Absturz nicht mehr den kompletten Browser mit abstürzen lässt. Zu den standardmäßig maximal acht Content-Prozessen kommen noch ein paar spezialierte Prozesse wie einer für Firefox-Erweiterungen sowie ein weiterer für den Aufruf lokaler Dateien.
Seit mittlerweile mehr als drei Jahren arbeitet Mozilla unter dem internen Projektnamen Fission an der logischen Weiterentwicklung dieses Konzeptes, einer Seiten-Isolation. Vereinfacht gesagt bedeutet dies, dass damit jeder Tab in einem eigenen Prozess läuft. Genauer wäre zu sagen, dass es einen Prozess pro Ursprung gibt, sprich zwei Tabs von der selben Domain können sich einen Prozess teilen. Auf der anderen Seite kann ein einzelner Tab auch mehrere Prozesse beanspruchen, nämlich dann, wenn auf der Seite Frames von anderen Domains eingebettet sind.
Neben der standardmäßigen Aktivierung von Fission für einen größeren Teil der Nightly-Nutzer testet Mozilla Fission bereits seit Firefox 88 mit einem kleinen Teil der Beta-Nutzer. Voraussetzung neben aktiviertem WebRender war bisher allerdings noch die Verwendung von Windows oder Apple macOS als Betriebssystem. Mit Firefox 91 Beta wurde nicht nur die Anzahl der Nutzer erhöht, bei denen Fission bereits standardmäßig aktiviert ist, womit nun 15 Prozent der Beta-Nutzer angepeilt werden; Erstmals sind auch Linux-Nutzer für den Beta-Test der Seiten-Isolation in Firefox qualifiziert.
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. Die Übersetzungsfunktion von Firefox kann jetzt auch Tschechisch übersetzen und hat weitere Verbesserungen erhalten.
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.
Die Neuerungen von Firefox Translations 0.4.3
Seit Ende Mai wird die Nightly-Version von Firefox mit einer (standardmäßig noch deaktivierten) Übersetzungs-Funktion für Websites ausgeliefert. Diese ermöglicht Übersetzungen aus dem Spanischen sowie aus dem Estnischen ins Englische und umgekehrt, sowie vom Englischen ins Deutsche (allerdings nicht umgekehrt).
Mit dem mittlerweile erfolgten Update von Firefox Translations 0.4.0 auf Firefox Translations 0.4.3 sind jetzt auch Übersetzungen aus dem Tschechischen ins Englische und umgekehrt möglich.
Nachdem die Größe von Firefox Translations in der vorherigen Version bereits von 124 MB auf 3,7 MB reduziert werden konnte, indem die benötigten Sprachmodelle jetzt bei Bedarf zur Laufzeit heruntergeladen werden, konnte die Größe der Erweiterung jetzt noch einmal auf mittlerweile nur noch 1,0 MB reduziert werden.
Das Übersetzungs-Icon wird jetzt immer in der Adressleiste angezeigt, allerdings ausgegraut, wenn für die aktuelle Seite keine Übersetzung angeboten wird. Die Möglichkeit, die Sprache zu ändern, nachdem bereits eine Übersetzung stattgefunden hat, wurde vorerst entfernt, um Probleme zu vermeiden, die damit aktuell noch existieren.
Das Übersetzungs-Limit wurde erhöht, so dass jetzt auch längere Websites übersetzt werden. Außerdem wurden die DOM-Interaktionen reduziert, die erfolgen, bevor die Übersetzung stattfindet, was die Performance vor allem auf komplexen Websites verbessern soll.
Dazu kommen diverse kleinere Korrekturen und Verbesserungen unter der Haube.
Aktivierung von Firefox Translations
Standardmäßig ist die Übersetzungsfunktion derzeit noch deaktiviert und muss manuell aktiviert werden, indem über about:config der Schalter extensions.translations.disabled per Doppelklick auf false gesetzt wird. Wie der Name dieser Option bereits andeutet, ist die Übersetzungs-Funktion intern als Erweiterung implementiert. Darum erscheint Firefox Translations anschließend auch im Add-ons Manager von Firefox, worüber die Erweiterung dann auch jederzeit wieder deaktiviert (aber nicht deinstalliert) werden kann. Wer die Übersetzungsfunktion über about:config nicht manuell aktiviert hat, sieht die Erweiterung natürlich auch gar nicht erst im Add-ons Manager.
In den Firefox-Einstellungen darf die Sprache, aus der übersetzt werden soll, nicht als bevorzugte Sprache eingestellt sein. Ist Firefox beispielsweise so konfiguriert, dass Englisch verstanden wird, dann erscheint natürlich auch keine Übersetzungsleiste bei einer englischsprachigen Website.
In diesem Beitrag möchte ich euch das Red Hat Accelerators Programm vorstellen und einige Beispiele geben, was wir dort so tun. Ich selbst bin seit 2019 Mitglied dieser Gemeinschaft und freue mich, mit IT-Experten aus verschiedensten Branchen und Red Hat selbst austauschen zu können. Dieser Artikel gibt meine persönliche Meinung und Sicht auf die Red Hat Accelerators wieder. Diese kann mit der von Red Hat übereinstimmen, muss es aber nicht.
Das Programm selbst beschreibt sich als globale Gemeinschaft, bestehend aus IT-Experten unter den Red Hat Kunden/Partnern, welche ihr Wissen und ihre Leidenschaft für Red Hat Produkte und Open Source Projekte mit Fachkollegen und Red Hat teilen und sich darüber austauschen mögen. Dem Einzelnen verspricht das Programm dabei folgenden Nutzen.
Netzwerken
Kurz gesprochen sind die Red Hat Accelerators ein Slack Channel voller interessanter Menschen. Diese stammen aus den verschiedensten Branchen, wie z.B. dem Gesundheitswesen, der Automobilindustrie, Versicherungen und Banken, um nur einige zu nennen. Dazu gesellen sich auch einige „Rote Hüte“, darunter Technical Account Manager, Mitarbeiter:innen aus verschiedenen Produkt-Teams und selbstverständlich die Community-Managerinnen Andi und Lili.
Wenn man seit vielen Jahren im gleichen Unternehmen arbeitet und stets nur zu den eigenen Kollegen Kontakt hat, stellt sich häufig eine gewisse Betriebsblindheit ein. Bei den Red Hat Accelerators bietet sich die Gelegenheit, mit Fachkollegen aus der gleichen, aber vor allem auch aus anderen Branchen in Kontakt zu treten und sich auszutauschen, um über den Tellerrand schauen zu können und der Betriebsblindheit entgegen zu wirken.
Ganz nebenbei lernt man neue Anwendungsfälle für bekannte oder weniger bekannte Produkte kennen. Gleiches gilt für Fehler in bzw. Probleme mit eben diesen Produkten. So bilden sich im Chat häufig so etwas wie spontane Arbeitskreise, die Probleme in der allerneusten Version eines Produktes adressieren. Hier wird sich gegenseitig geholfen. Und sollte einmal noch keine Lösung existieren, nimmt meist einer der anwesenden TAMs (steht wahlweise für Technical Account Manager oder The Almighty Moderator) das Problem/die Frage mit, um eine Lösung zu finden.
Mir hat sich durch diesen Austausch schon einige Male ein neuer Blickwinkel eröffnet, wodurch sich neue Lösungswege auftaten. Und das selbst über Red Hat Produkte hinaus.
Zugang zu Produkt-Teams und zukünftigen Releases
Für mich persönlich ist dies der größte Nutzen, den ich aus dem Red Hat Accelerators Programm ziehe. Ich habe hier die Möglichkeit, frühzeitig Kenntnis über (geplante) Neuerungen in Red Hat Produkten zu erlangen und durch qualifizierte Beiträge die Produktentwicklung mit zu beeinflussen.
Die Produkt-Teams stellen ihre Ideen und Pläne in gemeinsamen Videokonferenzen mit den Accelerators vor und diskutieren mit uns über Anwendungsfälle sowie Vor- und Nachteile der Änderungen.
Diese Form der Kommunikation hat Vorteile sowohl für Red Hat selbst, als auch für uns Kunden. Red Hat erfährt von seinen Kunden, wo der Schuh drückt, was sich diese wünschen, um ihren Arbeitsalltag effizienter zu gestalten. Als Kund erfährt man frühzeitig von geplanten Entwicklungen und Ideen und kann diese in gewissem Rahmen mit beeinflussen. Dazu möchte ich drei Beispiele geben.
Umfragen
Regelmäßig werden Umfragen zu Produkten aus dem Red Hat Portfolio und IT-Themen durchgeführt, die viele von uns im Arbeitsalltag betreffen. Red Hat nutzt diese Fragen dazu, um seine Kunden besser kennen zu lernen. Basierend auf diesen Umfragen werden weitere Sitzungen geplant, um einzelne Punkte in kleineren Arbeitsgruppen besprechen zu können.
Umfragen werden z.B. als webbasierte Formulare durchgeführt oder als Live-Interviews mit den Produkt-Teams.
Produktvorstellungen
Hier stellt ein Produkt-Team geplante Neuerungen, Änderungen oder neue Funktionen vor und stellt sich direkt der Kritik der Accelerators. Es wird dabei darauf geachtet, dass Kritik konstruktiv geäußert wird. Ein einfaches „Das ist Mist.“ oder „Das finde ich doof.“ ist dabei nicht gern gesehen. Ein konstruktives „Ich würde mir dieses oder jenes aus folgenden Gründen wünschen.“ wird gern entgegengenommen.
Als Accelerator hat man hier die Möglichkeit, seine Wünsche mitzuteilen. Es besteht keine Garantie und kein Anspruch, dass diese Berücksichtigung finden. Auch kann man die Entwicklung nicht direkt bestimmen. Doch hat Red Hat selbstverständlich ein Interesse daran, möglichst viele seiner Kunden bei der Stange und bei Laune zu halten. Denn ein glücklicher Kunde kauft gern nochmal, während ein unglücklicher Kunde vermutlich etwas neues ausprobiert.
Schön finde ich bei diesen Veranstaltungen auch, dass man erfahren kann, warum einige Wünsche nicht berücksichtigt werden oder auf der Roadmap sehr weit hinten anstehen müssen. Dies schafft Transparenz und ist in meinen Augen sehr zu begrüßen.
Doch auch für Red Hat kann es hier manchmal eine Enttäuschung geben, wenn z.B. ein Design-Entwurf von einer großen Mehrheit abgelehnt (im Sinne von: „Wir mögen das wirklich nicht und wünschen es uns wie folgt.“) wird.
Fokus-Gruppen
In den sogenannten Fokus-Gruppen bietet sich für ausgewählte Accelerators die Chance, eng mit einem Red Hat Produkt-Team zusammen zu arbeiten.
So hatte ich im Sommer 2020 das Vergnügen, in der Fokus-Gruppe Red Hat Insights unter Leitung von Mohit Goyal (Senior Principal Product Manager, Red Hat) mitzuarbeiten. Hier bot sich mir die Möglichkeit, die besonderen Anforderungen an den Einsatz einer solchen Lösung in Deutschland und in meiner Organisation zu vertreten und dafür zu sensibilisieren. Durch den Einfluss mehrerer Red Hat Accelerators wurde die geplante automatische Registrierung von RHEL-Systemen in Red Hat Insights auf unbestimmte Zeit verschoben.
So viel Einfluss auf eine laufende Produktentwicklung hatte ich bisher bei keinem anderen Hersteller. Und ich wünsche mir deutlich mehr davon.
Welche Vorteile hat Red Hat davon?
Selbstverständlich profitiert auch Red Hat von dem Accelerators-Programm. Wie bereits erwähnt, bekommt der Hersteller hier wertvolle Rückmeldungen von vertrauten Kunden, direkt aus der Praxis. Darüber hinaus stehen die Accelerators bereit, Produktneuheiten zu testen, zu validieren und den Einsatz in der eigenen Umgebung zu prüfen, bevor diese veröffentlicht werden. Dadurch kann bei Problemen noch rechtzeitig gegengesteuert werden.
Das Programm hilft Red Hat, seine Kunden und deren Bedürfnisse besser zu verstehen und die eigenen Produkte noch besser am Bedarf der Kunden auszurichten.
Und natürlich verfügt Red Hat mit den Accelerators über ein Heer aus Enthusiasten, Evangelisten und Missionaren, welche die Open Source Botschaft in die Welt hinaus tragen. Und wir alle wissen doch, dass Mund-zu-Mund-Propaganda die wirksamste Form der Werbung ist.
Wie kann man Mitglied werden?
Ihr seid bereits Red Hat Kunde und mein Beitrag hat euch neugierig gemacht, so dass ihr ebenfalls zu den Red Hat Accelerators dazustoßen möchtet? Das ist gut, denn die EMEA-Region und besonders der deutschsprachige Raum ist aktuell noch etwas unterrepräsentiert.
Ich selbst darf übrigens keinerlei Geschenke von Red Hat oder dem Accelerators-Programm annehmen. Wenn ihr im letzten Feld des Bewerbungsformulars also meinen Namen angebt, ist mir nicht mehr und nicht weniger gewiss, als der ewige Dank von Andi und Lili.
Vor ein paar Wochen habe ich hier im Blog kritisiert, dass mich Gnome 40 zu einem horizontalen Dock zwingen will, dass noch dazu zumeist ausgeblendet wird. Mag sein, dass manche dies auf einem kleinen Notebook-Monitor zweckmäßig finden, für mich ist es keine Option. Ich will ein ständig sichtbares Dock, und ich will es am linken Bildschirmrand. Und mittlerweile ist mein Wunsch auch erfüllbar, wie ich in diesem Beitrag anhand von drei Distributionen (Fedora 34, Manjaro, Ubuntu 21.10) zeige.
Das Gnome Entwickerteam vertritt zwar die Ansicht, Shell extensions are always going to be a niche thing, aber da Ubuntu und einige andere Distributionen solche Extensions per Default installieren, wird die Nische womöglich größer als das Original …
Anmerkung: Die Gnome-Nomenklatur nennt das Dock übrigens »Dash«, aber ich bleibe in diesem Artikel bei dem etablierteren Begriff »Dock«.
Ubuntu 21.10 (Entwicklerzweig)
Während Ubuntu 21.04 bekanntlich Gnome 40 ignoriert und stattdessen Version 3.38 ausgeliefert hat, enthält der Entwicklerzweig von Ubuntu 21.10 mittlerweile durchgängig Gnome-40-Pakete. Um dennoch wie in bisherigen Versionen ein vertikales Dock anbieten zu können, ist unter Ubuntu das Paket gnome-shell-extension-ubuntu-dock vorinstalliert. Es enthält eine modifizierte, zu Gnome 40 kompatible Variante der Gnome-Erweiterung Dash-to-Dock. Die Konfiguration kann bequem in den Gnome-Einstellungen erfolgen. Die wenigen Optionen sollten für die meisten User ausreichen. Anders als im originalen Gnome 40 kann das Dock links, rechts oder unten platziert werden. Außerdem kann die Breite eingestellt werden. Für mich reicht das aus.
Der Default-Desktop im Entwicklerzweig von Ubuntu 21.10
Manjaro
Auch Manjaro hat kürzlich auch Gnome 40 umgestellt. Genaugenommen bot das Update-System schon längere Zeit Gnome-40-Pakete an. Nur mit dem Update der Gnome-Shell hat man relativ lange gewartet, wohl um vorher das Manjaro-spezifische Programm Manjaro Hello Gnome-40-tauglich zu machen. Dieses Programm bietet die Möglichkeit, unkompliziert zwischen verschiedenen Desktop-Layouts zu wechseln. Intern werden die Layouts ähnlich wie bei Ubuntu durch verschiedene Gnome Shell Extensions realisiert. Für das Layout Manjaro Legacy mit vertikalem Dock kommt wie unter Ubuntu die Erweiterung Dash-to-Dock zum Einsatz. Dennoch sieht das Dock ein wenig anders aus, weil andere Default-Einstellungen zum Einsatz kommen.
Manjaro Linux mit Gnome 40 und dem »Manjaro Legacy« Layout mit Dash-to-Dock
Fedora 34
Bei meiner Fedora-34-Installation habe ich anstelle von Dash-to-Dock die mir bis dahin unbekannte Erweiterung Dash-to-Panel eingesetzt. Sie bietet ähnliche Funktionen wie Dash-to-Dock aber womöglich noch mehr Konfigurationsmöglichkeiten. Der größte Vorteil besteht darin, dass diese Erweiterung schon seit Wochen out of the box, also ohne Rückgriffe auf irgendwelche Testzweige oder Forks, unter Gnome 40 stabil funktioniert. Ich habe damit sehr gute Erfahrungen gemacht, wenngleich die Optionsfülle selbst für meine Begriffe ein wenig über das Ziel schießt. Aber egal, alles besser als gar keine Optionen …
Freie Android ROMs und F-Droid als Store hatten immer eine besonders problematische Leerstelle: Textdokumente lesen und bearbeiten. Die neue Version von OpenDocument Reader schließt diese Lücke ein bisschen.
Im Bereich der Basisanwendungen ist das Angebot an freier Software über F-Droid seit einiger Zeit ausreichend. Lediglich Textdokumente sind ein Problem.
Zwar gibt es SoftMaker Office für Android und hier auch eine tolle neue Version, aber das gibt es nur über den Play Store. Das ist schon eine herbe Enttäuschung, da SoftMaker auch problemlos Android-Pakete nach einem Kauf zum Download anbieten könnte. LibreOffice und Collaboras Office sind mobil ein schlechter Witz. Es gibt dazu nahezu keine guten Testberichte, außer jene Autoren, die das Potenzial betonen. Die Variante von Collabora gibt es zudem nur im Google Play Store. So lange die an ihrer morschen Basis kleben, wird da auch nicht viel passieren.
Natürlich möchten die wenigsten auf ihrem Smartphone ganze Romane verfassen, aber in der echten Welt bekommt man eben nicht nur PDF-Dateien zugesandt, sondern auch gerne mal Textdokumente im Format von OOXML (DOCX, XLSX etc.) oder OASIS (ODT, ODS etc.). Bisher war da nicht viel zu machen.
Diese Lücke wird mit der Verfügbarkeit von OpenDocument Reader im F-Droid Store wenigstens teilweise geschlossen.
Die App fokussiert die freien Formate von LibreOffice, aber bietet daneben auch einen mehr oder minder guten Support für folgende Dateitypen:
Microsoft Office: Word (DOC, DOCX), Excel (XLS, XLSX), PowerPoint (PPT, PPTX)
Apple: Pages, Numbers, Keynote
LibreOffice: ODF* (ODT, ODS, ODP, ODG)
PostScript
AutoCAD
Photoshop (PSD)
Die Darstellung klappte bei meinen Tests nicht immer perfekt, aber um einen Überblick über die Inhalte zu bekommen, genügt es vollkommen. Mehr möchte man ja oft am Smartphone gar nicht haben. Damit ist OpenDcoument Reader eine Art Schweizer Taschenmesser für Dateien.
Es ist schön zu sehen, dass sich hier was tut und freie AOSP + F-Droid Systeme eine Lücke weniger haben.
Die MZLA Technologies Corporation hat mit Thunderbird 78.12 ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht.
Neuerungen von Thunderbird 78.12
Mit dem Update auf Thunderbird 78.12 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht. Neben den üblichen kleineren Fehlerbehebungen schließt die neue Version auch wieder die aktuellen Sicherheitslücken. Ein Update ist daher für alle Nutzer empfohlen.
Mit dem Update auf Firefox 90.0.2 behebt Mozilla ein Problem, welches verursachen konnte, dass beim Ausdruck von manchen Websites der Inhalt abgeschnitten wurde. Außerdem wurden Darstellungsprobleme von Menüs behoben, welche in Zusammenhang mit manchen GTK-Themes unter Linux auftreten konnten.
Die Standard-Startseite von Firefox zeigt jetzt wieder ein Zahnrad-Symbol anstelle der Beschriftung „Anpassen“, um in die Einstellungen der Startseite zu gelangen.
Darüber hinaus gab es mehrere Änderungen, welche in Zusammenhang mit der Ausrollung von DNS over HTTPS (DoH) in Kanada stehen.
Mit dem Update auf Firefox 90.0.1 behebt Mozilla eine mögliche Absturzursache in Zusammenhang mit manchen Barrierefreiheit-Tools auf Windows. Außerdem wurde ein selten auftretender Absturz beim Beenden von Firefox behoben. Eine dritte behobene Absturzursache betrifft die Neuimplementierung des Local Storages, welche standardmäßig noch deaktiviert ist, aber im Laufe des Firefox 90-Zyklus für manche Nutzer testweise aktiviert werden soll.
Ebenfalls behoben wurde, dass Firefox beim Verarbeiten einer HTTP/3-Anfrage in eine Endlosschleife geraten konnte, was dann zu einer hohen CPU-Auslastung und schließlich dazu führen konnte, dass Firefox keine Websites mehr laden konnte.
Ein Fehler bei der Authentifizierung mit einigen Smartcards wurde ebenso behoben wie ein Problem, welches verursachen konnte, dass about:support beim ersten Start nach dem Update auf Firefox 90 nur eine weiße Seite zeigte.
Die Data Loss Prevention von McAfee, welche von Firefox seit einem halben Jahr blockiert wird, weil sie Abstürze in Firefox verursachte, wird in aktuellen Versionen, welche einen Bugfix von McAfee beinhalten, nicht länger blockiert.
Außerdem wurde das eBay-Logo für die Kacheln auf der Firefox-Startseite aktualisiert, so dass dieses nicht mehr so klein erscheint.
Mozilla hat vergangene Woche Firefox 90 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.
Ab Firefox 90 ist es für Nutzer von Windows möglich, Firefox im Hintergrund aktualisieren zu lassen. Firefox prüft dann bei aktivierter Option alle sieben Stunden, ob es eine neue Version gibt, und installiert diese gegebenfalls, ohne dabei den Nutzer zu stören. Dies kommt inbesondere den Nutzern zu Gute, denen Updates direkt beim Programmstart lästig sind.
Dieses Feature wird schrittweise ausgerollt. Wer es bereits vorher aktivieren möchte, kann dazu den Anweisungen von Mozilla folgen.
SmartBlock 2.0
Der mit Firefox 87 eingeführte SmartBlock-Mechanismus, welcher in privaten Fenstern sowie in allen Fenstern für jene Nutzer aktiviert ist, welche den strengen Schutz vor Aktivitätenverfolgung aktiviert haben, verbindet Privatsphäre mit Web-Kompatibilität. Dabei ersetzt Firefox die Scripts bekannter Tracking-Dienste durch eine Art Ersatz-Script, welches sicherstellt, dass die Website-Kompatibilität nicht beeinträchtigt wird, während die eigentliche Funktionalität außer Kraft gesetzt wird. So können beispielsweise seitens Website Funktionen aufgerufen werden, welche Google Analytics voraussetzen, ohne dass diese tatsächlich ausgeführt werden und ohne dass es, anders als ohne SmartBlock, Script-Fehler gibt, weil Google Analytics von Firefox blockiert wird.
Firefox 90 bringt SmartBlock 2.0, eine verbesserte Version dieses Mechanismus. So werden Facebook-Scripts auf Websites weiterhin blockiert, aber in dem Moment für die entsprechende Website erlaubt, in dem sich der Nutzer dazu entscheidet, den auf vielen Websites implementierten Facebook-Login zu nutzen. Bisher hätte der Facebook-Login nicht genutzt werden können, ohne den Schutz vorher abzuschalten.
Nur-HTTPS-Modus: Ausnahmen in Einstellungen verwalten
Firefox besitzt einen Nur-HTTPS-Modus, in welchem Firefox ausschließlich Seiten über HTTPS lädt, nicht über eine unverschlüsselte HTTP-Verbindung (Ausnahmen sind möglich). Dieser kann wahlweise immer, nur in privaten Fenstern oder gar nicht aktiviert wird. Ab Firefox 90 ist es möglich, Ausnahmen für diesen Modus direkt in den Firefox-Einstellungen zu verwalten.
Verbesserungen der Webplattform und Entwicklerwerkzeuge
HTTP/3-Unterstützung
Firefox 90 unterstützt mit HTTP/3 den Nachfolger von HTTP/2 und die damit neueste Version des HTTP-Protokolls.
Fetch Metadata Request Headers
Firefox 90 unterstützt die Fetch Metadata Request Headers, welche es Webanwendungen ermöglichen, sich und seine Nutzer besser vor verschiedenen Cross-Origin-Angriffsszenarien zu schützen.
Sonstige Verbesserungen der Webplattform
Firefox setzt nun die intrinsische Größe und Auflösung eines Bildes basierend auf den EXIF-Informationen, sofern vorhanden. Dies ermöglicht es beispielsweise einem Server, ein Platzhalterbild mit geringer Qualität zu senden, um das Laden zu beschleunigen.
In Firefox 90 wurde die Unterstützung für private Felder und Methoden in JavaScript hinzugefügt. Neu ist ebenfalls die Unterstützung für die at()-Methode für Arrays, TypedArrays und Strings. Die 2D-Canvas-API wurde um eine createConicGradient()-Methode erweittert.
Das Netzwerk-Panel zeigt im Antwort-Reiter jetzt eine Vorschau für Schriftart-Anfragen an.
Eine Übersicht über alle Verbesserungen der Webplattform wie neue unterstützte Webstandards gibt es wie immer in den MDN web docs.
Geschlossene Sicherheitslücken
Natürlich hat Mozilla auch in Firefox 90 wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 90 daher für alle Nutzer dringend empfohlen.
Sonstige Neuerungen in Firefox 90
Wird eine Website als PDF-Datei gespeichert, waren darin ggfs. enthaltene Links nicht anklickbar. Ab Firefox 90 funktionieren Links in den von Firefox erzeugten PDF-Dateien.
Der Kontextmenü-Eintrag „Grafik in neuem Tab öffnen“ öffnet Bilder jetzt, wie andere Browser, standardmäßig im Hintergrund. Wer das alte Verhalten bevorzugte, kann in den Firefox-Einstellungen die Option „Tabs im Vordergrund öffnen“ aktivieren, welche nun auch das Verhalten dieses Kontextmenü-Eintrags einschließt.
Wird Firefox via Profilmanager gestartet, dauerte das in der Vergangenheit etwas länger. Dieses Performance-Problem wurde behoben.
Mit Firefox 90 wird Software-WebRender für weitere Nutzer ausgerollt, welche kein Hardware-beschleunigtes WebRender als Grafik-Backend erhalten. Damit bekommen bereits mehr als 95 Prozent der Desktop-Nutzer WebRender. Außerdem wurde die Software-WebRender-Performance verbessert.
Auf Windows gibt es mit about:third-party eine neue Seite, welche Module von Drittanbietern anzeigt, die in Firefox installiert wurden. Die Seite dient dazu, Kompatibilitätsprobleme zu identifizieren, welche durch Anwendungen von Drittanbietern verursacht werden.
Die Unterstützung für das unverschlüsselte und unsichere FTP-Protokoll wurde bereits in Firefox 88 standardmäßig deaktiviert. In Firefox 90 wurde die Unterstützung komplett entfernt, eine Aktivitierung über about:config ist damit nicht länger möglich.
In der Add-ons-Verwaltung verweist ein Link nun auf die Erweiterungs-Website addons.mozilla.org, wenn der Nutzer noch keine Erweiterungen installiert hat.
Die Einführungstour about:welcome bietet auf macOS jetzt auch die Option an, Firefox im Dock zu behalten, ähnlich wie man unter Windows Firefox an die Taskleiste anheften kann.
Wie immer kamen auch in Firefox 90 Fehlerbehebungen und sonstige Verbesserungen unter der Haube dazu. Auch die Unterstützung weiterer Unternehmensrichtlinien wurde ergänzt.
Beim Arbeiten mit Docker besteht oft der Wunsch, einen Container automatisch bei jedem Rechnerstart auszuführen, z.B. um einen Netzwerkdienst anzubieten. In diesem Text stelle ich Ihnen drei Wege vor, wie Sie diesen Wunsch realisieren können. Die ersten beiden Varianten setzen voraus, dass es einen systemweiten Docker-Dienst gibt (dockerd), dass Sie also mit einer »normalen« Docker-Installation arbeiten (nicht rootless oder mit mit Podman).
Variante 1: docker run --restart always
Wenn Sie beim Start eines Docker-Containers mit docker run die Option --restart always übergeben, dann wird dieser Container in Zukunft automatisch gestartet:
Für die Option --restart gibt es vier mögliche Einstellungen:
--restart no gilt standardmäßig. Wenn der Container endet, egal aus welchem Grund, wird er nicht neu gestartet.
--restart always bewirkt, dass der Container automatisch neu gestartet wird, sobald er endet. Diese Neustartregel gilt auch für einen Reboot des Rechners! Dabei wird im Rahmen des Init-Prozesses der Docker-Dienst gestartet; dieser startet wiederum alle Container, die zuletzt mit der Option --restart always liefen. Aber Vorsicht: --restart always gilt auch für ein Programmende aufgrund eines Fehlers. Wenn der Container einen Fehler enthält, kann es passieren, dass der Container immer wieder gestartet wird. Die einzige Ausnahme ist ein manueller Stopp (docker stop): In diesem Fall wird der Container nicht unmittelbar neu gestartet. Wenn Sie aber Ihren Rechner herunterfahren, dann wird der Container beim nächsten Docker-Neustart wiederum gestartet.
--restart unless-stopped funktioniert ganz ähnlich wie --restart always. Der Unterschied besteht darin, dass ein mit docker stop beendeter Container beim nächsten Docker-Neustart nicht mehr automatisch gestartet wird.
--restart on-failure führt zu einem automatischen Neustart nach einem Fehler im Container, aber zu keinem Autostart bei einem Neustart des Docker-Systems.
Das für einen Container eingestellte Restart-Verhalten können Sie mit docker inspect ermitteln:
Die vier zulässigen Einstellungen lauten no (gilt per Default), always, unless-stopped und on-failure. Die Bedeutung der Schlüsselwörter ist wie bei der vorhin erläuterten Option --restart von docker run. Die Einstellung restart: always gilt solange, bis die durch die Datei docker-compose.yml beschriebenen Dienste explizit durch compose down wieder beendet und gelöscht werden.
Achten Sie darauf, dass Sie das Schlüsselwort restart in der richtigen Ebene angeben, also direkt bei den Einstellungen des jeweiligen Containers (im vorigen Beispiel db)! Zuletzt habe ich mich wochenlang gewundert, warum bei der folgenden Datei docker-compose.yml das Restart-Verhalten nicht funktionierte:
# Vorsicht, die restart-Einstellung ist hier fehlerhaft!
services:
db:
image: mariadb:latest
volumes:
- vol-db:/var/lib/mysql
environment:
MYSQL_USER: wpuser
MYSQL_PASSWORD: geheim
restart: always
Die Fehlerursache sollte klar sein: Die Option restart ist zu weit eingerückt und bezieht sich nicht auf den Container db, sondern auf dessen environment~~Einstellungen. Dort wird restart einfach ignoriert. Die falsch platzierte Option führt aber zu keiner Warnung oder gar Fehlermeldung.
Variante 3: systemd
Anstatt den Start von Containern durch Docker zu steuern, besteht auch die Möglichkeit, dies durch Funktionen des Betriebssystems zu erledigen. Diese Vorgehensweise ist relativ umständlich und wird in der Praxis daher nur recht selten gewählt. Sie hat aber den Vorteil, dass ein Container wie ein Dienst des Betriebssystem behandelt werden und mit den gleichen Kommandos gesteuert kann.
Ich gehe im Folgenden davon aus, dass Sie eine Linux-Distribution mit systemd verwenden. Sobald die Konfiguration einmal funktioniert, können auf den betreffende Container Kommandos wie systemctl restart oder systemctl enable --now angewendet werden.
Der Ausgangspunkt des folgenden Beispiels ist ein MySQL-Container, der zuerst testweise eingerichtet wurde und der nun dauerhaft gestartet werden soll. Das Volume mit den Datenbanken befindet sich in /home/kofler/docker-mysql-volume. Beim erstmaligen Einrichten des Containers wurde das MySQL-Root-Passwort festgelegt. Es ist in einer Datenbank im Volume-Verzeichnis gespeichert und muss deswegen nicht mehr mit -e MYSQL_ROOT_PASSWORD=... übergeben werden.
Eine eigene Servicedatei
Damit sich systemd selbstständig um den Start kümmert, muss im Verzeichnis /etc/systemd/system eine *.service-Datei eingerichtet werden. Für dieses Beispiel sieht die Datei so aus:
# Datei /etc/systemd/system/docker-mysql.service
[Unit]
Description=starts MySQL server as Docker container
After=docker.service
Requires=docker.service
[Service]
RemainAfterExit=true
ExecStartPre=-/usr/bin/docker stop mysql-db-buch
ExecStartPre=-/usr/bin/docker rm mysql-db-buch
ExecStartPre=-/usr/bin/docker pull mysql
ExecStart=/usr/bin/docker run -d --restart unless-stopped \
-v /home/kofler/docker-mysql-volume:/var/lib/mysql \
-p 13305:3306 --name mysql-db-buch mysql
ExecStop=/usr/bin/docker stop mysql-db-buch
[Install]
WantedBy=multi-user.target
Der Unit-Abschnitt beschreibt den Dienst. Die Schlüsselwörter Requires und After stellen sicher, dass der Dienst nicht vor Docker gestartet wird.
Der Service-Abschnitt legt fest, welche Aktionen zum Start bzw. zum Stopp des Diensts erforderlich sind. Die drei ExecStartPre-Anweisungen stellen sicher, dass der Container mit dem Namen mysql-db-buch gestoppt und gelöscht wird und dass die neueste Version des MySQL-Images heruntergeladen wird. Das Minuszeichen vor den stop– und rm-Kommandos bedeutet, dass ein Fehler beim Ausführen dieser Kommandos einfach ignoriert wird. (Wenn das Image bereits zuvor gestoppt und/oder gelöscht wurde, dann ist das kein Grund zur Sorge.)
Die über mehrere Zeilen verteilte ExecStart-Anweisung startet schließlich den Container, wobei das Volume-Verzeichnis /home/kofler/docker-mysql-volume und der Host-Port 13306 verwendet werden.
ExecStop gibt an, was zu tun ist, um den Dienst zu stoppen.
RemainAfterExit=true bedeutet, dass sich systemd den gerade aktivierten Status merkt. Ohne diese Option würde systemd nach der erfolgreichen Ausführung von docker run glauben, der Dienst sei bereits wieder beendet. Tatsächlich wird der Container aber im Hintergrund weiter ausgeführt.
WantedBy im Install-Abschnitt legt fest, dass der Dienst Teil des Multi-User-Targets sein soll. (Dieses Target beschreibt den normalen Betriebszustand eines Linux-Servers.)
Selbstverständlich können Sie in der Service-Datei anstelle von docker auch docker compose aufrufen. Das ist zweckmäßig, wenn der gewünschte Dienst nicht aus nur einem Container besteht, sondern aus einer ganze Gruppe von Containern. Denken Sie daran, dass Sie beim Aufruf von docker compose den vollständigen Ort der Datei docker-compose.yml mit der Option -f explizit angeben müssen.
Den Service starten und beenden
Damit systemd die neue Servicedatei berücksichtigt, müssen Sie einmalig das folgende Kommando ausführen:
systemctl daemon-reload
Sollten Sie in der Servicedatei einen Fehler eingebaut haben und ihn später korrigieren, vergessen Sie nicht, das obige Kommando neuerlich auszuführen!
Mit den folgenden Kommandos testen Sie, ob der manuelle Start und Stopp des Docker-Containers funktioniert:
systemctl start docker-mysql
systemctl status docker-mysql
docker-mysql.service - starts MySQL server as Docker container
Loaded: loaded (/etc/systemd/system/docker-mysql.service;
disabled; vendor preset: enabled)
Active: active (exited) since 19:28:20 CEST; 3min 41s ago
...
systemctl stop docker-mysql
Sofern alles klappt, müssen Sie den automatischen Start des Dienstes nun noch dauerhaft aktivieren:
systemctl enable --now docker-mysql
Sollten Sie den Dienst später nicht mehr brauchen, beenden Sie ihn wie folgt dauerhaft:
Nach dem Deutschland-Start im April ist das Mozilla VPN ab sofort auch in Österreich, der Schweiz sowie weiteren Ländern verfügbar.
Mozilla VPN startet in Österreich und Schweiz
Worüber ich vergangenen Monat bereits exklusiv berichtete, ist nun offiziell: Ab sofort kann das Mozilla VPN auch in Österreich und der Schweiz gebucht werden. Nutzer in Deutschland können das Mozilla VPN bereits seit April nutzen. Auch Nutzer in Belgien, Italien und Spanien können das Mozilla VPN seit heute nutzen.
Das Mozilla VPN kostet 9,99 Euro / 10,99 CHF für einen Monat. Bei Bindung für sechs Monate beträgt der Monatspreis 6,99 Euro / 7,99 CHF, bei Bindung für ein Jahr werden 4,99 Euro / 5,99 CHF pro Monat fällig. Eine Rückerstattung ist innerhalb von 30 Tagen nach dem Kauf möglich.
Das Mozilla VPN
Für das Mozilla VPN arbeitet Mozilla mit dem schwedischen VPN-Anbieter Mullvad zusammen 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 besteht aus über 400 Servern in mehr als 30 Ländern, hat keine Bandbreiten-Beschränkung und erlaubt die Verbindung auf bis zu fünf Geräten. Es stehen Apps für Windows 10, Apple macOS, Ubuntu, Android sowie Apple iOS zur Verfügung.
Ende April ist Mozillas Virtual Private Network, das Mozilla VPN, auch in Deutschland gestartet, der Start in Österreich und der Schweiz steht bevor. Vor wenigen Wochen hat Mozilla Version 2.3 seiner VPN-Apps veröffentlicht. Dieser Artikel beschreibt die Neuerungen.
Seit April kann das Mozilla VPN von Nutzern in Deutschland genutzt werden. Der Start in Österreich und der Schweiz steht kurz bevor (ich berichtete exklusiv). In der Zwischenzeit wurde von Mozilla das Mozilla VPN 2.3 veröffentlicht.
Die Neuerungen vom Mozilla VPN 2.3
Mit dem Mozilla VPN 2.3 liefert Mozilla diverse Verbesserungen seines VPN-Clients aus. So sind nach der Verbindung mit dem VPN nun schneller Netzwerk-Anfragen möglich. Die durch eine Animation verursachte CPU-Last wurde reduziert. Auf iOS kommt es nicht länger zu einem Leak der IP-Adresse beim Wechsel des Servers. Gefundene Probleme, welche im Rahmen einer Sicherheitsüberprüfung von cure53.de entdeckt worden sind, wurden behoben.
Die Länder im Bildschirm zur Auswahl des Server-Standorts sind nun übersetzt. Ein ggfs. vorhandenes „Captive Portal“ (Netzwerk, das eine Benutzeraktion mit bestimmten Bedingungen erfordert, bevor eine Internetverbindung zugelassen wird) wird jetzt erkannt. Außerdem wurde die Unterstützung für Umfragen hinzugefügt, um den Nutzer um Feedback bitten zu können. Darüber hinaus nutzt das Mozilla VPN jetzt Glean für die Erhebung anonymisierter Interaktionsdaten. Beim ersten Start zeigt das Mozilla VPN einen entsprechenden Opt-Out-Bildschirm an.
In vielen meiner Blogartikel sortiere ich eine Gruppe von Administratoren und Anwendern unter die Graubärte ein. Damit bediene ich mich eines Begriffs von der FOSDEM, um eine Entwicklung in der Community zu skizzieren.
Graubärte – Was soll dieser Begriff eigentlich aussagen. Graubärte (auf der FOSDEM-Präsentation humoristisch mit Gandalf aus Herr der Ringe illustriert) bezeichnet Männer in einem fortgeschrittenen Lebensalter und ihre Haltung zu Veränderungen.
Mit Zahlen und Fakten ist es in der Community ja immer so eine Sache. Es gibt keine repräsentative Erhebung über „den Linux-Anwender“ oder „den Linux-Administrator“ oder „den typischen Community-Aktivist“. Meine folgenden Beobachtungen sind Schlussfolgerungen aus dem, was man in großen Foren und Kommentarspalten so an Informationen nebenbei abgreifen kann.
Relativ unstrittig dürfte das Geschlecht sein. Die überwiegende Mehrheit der Administratoren, Anwender und Community-Aktivisten ist männlich. Anteil vermutlich >90%.
Bart ist damit schon mal eine zutreffende Sache. Warum aber nun Graubärte? Nun, nicht nur Linux Torvalds oder Greg Kroah-Hartman sind mit ihrem Produkt mit gealtert, das trifft auch auf viele Projekte zu. GNOME und KDE haben das beide kürzlich transparent dargestellt und gezeigt, dass ein großer Sockel an Entwicklern seit vielen Jahren dabei ist. Dazu kommen natürlich auch immer wieder neue Entwickler, aber diese dominieren die Projekte nicht.
Das betrifft aber nicht nur die Entwickler, sondern auch die Administratoren und einfachen Endanwender. Wenn man die Diskussionen und Erfahrungsberichte bei Plattformen wie Heise, Golem oder in vielen Foren beobachtet, dann werden dort Erfahrungen geteilt, die sich datieren lassen. Wenn von SuSE 9.3 oder Debian Etch die Rede ist, sind damit Jahreszahlen verknüpft. Plakativ gesagt: So mancher Bachelor-Student der Informatik im Jahr 2021, hat gerade das Laufen gelernt als diese Kommentatoren ihre prägenden Erfahrungen mit Linux machten. Man muss kein Rechenkünstler sein, um die meisten dieser Anwender heute jenseits der 40 Lebensjahre zu sehen.
Bei einer organisch wachsenden Community ist das nur logisch. Warum sollte auch jemand, der 2004 auf Linux wechselte, 2021 etwas anderes nutzen. Ein zweites Problem verstärkt das aber noch: Nachwuchsmangel. Ein ganz erheblicher Teil der heutigen Linux-Nutzer wechselte spätestens rund um den Netbook-Hype und die Veröffentlichung Windows Vista. Diese Erfahrung findet sich immer wieder in den Kommentaren. Windows 10 und die Datenschutz-Problematik hat keinen vergleichbaren Schwung erzeugt.
Die Ursache dürfte in der sinkenden Bedeutung der Geräteklasse liegen. Linux ist für Privatnutzer auf dem klassischen Notebook und Desktop-PC festgenagelt und der verliert als Privatgerät sukzessive an Bedeutung. Natürlich bleibt es als Arbeitsgerät wichtig, aber hier hat man nur selten die Hoheit über das Betriebssystem. Mangelnde Bedeutung und mangelnde Beschäftigung mit dem System führen ganz automatisch zu weniger Umsteigern. Zumal Linux hier auch noch in direkter Konkurrenz zu macOS steht, das sich vor allem bei der jüngeren, akademisch geprägten Zielgruppe in den letzten Jahren fest verankern konnte. Das kann man auf allen Diskussionsplattformen der Community beobachten.
Diese Entwicklung kann man nur begrenzt beeinflussen, aber man sollte zur Kenntnis nehmen, dass sie Auswirkungen hat. Ein 20-Jähriger hat andere Erfahrungen gemacht als ein 40-Jähriger oder ein 60-Jähriger. Die Lern- und Veränderungsbereitschaft wandelt sich ebenfalls im Laufe der Zeit und die meisten Menschen machen irgendwann nicht mehr alle (technischen) Trends mit. Gewohnheit wird gerne mit Funktionsfähigkeit gleichgesetzt und Veränderungen gefährden naturgemäß die eigene Kompetenz.
Eine Gemeinschaft, die altert und eben nicht mehr im Schnitt aus 25-Jährigen, sondern eher aus 45-Jährigen besteht (männlich dominiert, bleibt sie dennoch…) reagiert anders auf Herausforderungen und Veränderungen. Progressive Haltungen nehmen zugunsten einer konservativen Grundhaltung ab. Nicht umsonst hat die CDU bei Wählern im fortgeschrittenen Lebensalter immer höhere Stimmanteile als bei Unter-30-Jährigen. Diese Grundeinstellung gilt nicht nur für Politik, sondern auch für Technik.
Die Kunst besteht darin, sich trotz dieser Entwicklung weiterhin zu erneuern und zu Innovation fähig zu bleiben. Vor der Herausforderung stehen Firmen genau so wie Communitys. Es wird sich zeigen, ob die Linux-Gemeinschaft das kann oder ob sie mit ihren Anwendern und Geräteklassen veraltet.
Um unter Linux das hochkonfigurierbare Audiosystem zu verstehen, braucht man gerade am Anfang ein paar Stichwörter, damit man weiß wo man nachschauen muss. Das mag gerade zu Beginn für professionelle Anwender sehr komplex erscheinen, dafür ermöglicht es aber Audioroutings und Konfigurationen Out Of The Box, wofür sie von Anwendern aus der Windows und Apple Welt sehr beneidet werden.
Audio Routing
Für professionelles Audio unter Linux nutzt man normalerweise den Jack Audio-Server https://jackaudio.org/ . Um dann komfortabel die Ein- und Ausgänge und die Programme miteinander zu verbinden (Routing) gibt es Tools wie QJackCTL, Cadence, Claudia und Catia. Kurz zu den einzelnen Tools
QJackCTL ist ein Programm mit dem man den Jack Audioserver konfigurieren, starten und stoppen kann. Ebenso kann man dort die “Strippen ziehen". In der allerneusten Version vom 07.07.2021 ist das Interface mit dem man die Strippen ziehen kann wesentlich überarbeitet worden, so dass sie der 2D Ansicht der ehemaligen LADISH Konfigurationstools entspricht.
Cadence ist das Programm um Jack zu konfigurieren. Das Programm stammt von dem Macher von kx.Studio und ist bereits abgekündigt vermerkt. Das heisst, es wird nicht weiter entwickelt.
Claudia und Catia sind sogenannte LADISH Frontends und auch bereits abgekündigt.
LADISH - LADI Session Handler - wobei LA für Linux Audio steht, aber ich leider nicht erkunden konnte wofür das DI steht? Direct Interface?
Audio Server unter Linux
Das kann für einen Neueinsteiger sehr verwirrend sein. Denn man muss erstmal verstehen, dass es unter Linux nicht nur einen einzige Audiokonfiguration gibt, sondern dass da gleich mehere Dinge (Audio Server) existieren.
ALSA - Das ist die Basis für Audio unter Linux. Hier sind die Treiber und rudimentäre Soundprogramme. Die Konfiguration geschieht meist automatisch und wird in Textdateien im System abgespeichert.
PulseAudio - Das ist für normale Desktopanwender, quasi das Consumer Audiosystem. Die Konfiguration passiert automatisch und die Einstellungen sind in den verschiedenen Desktopoberflächen, wie KDE/Plasma oder GNOME integriert.
Jack - Ist ein sogenannter Low Latency Audio Server für Professionelle Anwendungen. Die Konfiguration erfolgt etnweder auf dem harten Weg per Textdateien, oder mit grafischen Programmen wie QJackCTL, Cadence, Claudia oder Catia.
Pipewire - Ist das zukünftige Audiosystem für Linux, das die Vorteile und Bequemlichkeit von PulseAudio und die professionellen Anforderungen von Jack miteinander vereint. Nach einer Übergangszeit, sähe eine Installation so aus, dass ALSA mit den Treibern immer noch die Grundlage bildet und darüber liegt dann Pipewire und regelt den Rest. Und das sogar noch Latenzärmer, als Jack es sowieso schon macht.
Pipewire Status: Mitte 2021 fangen die Distributionen an Pipewire zu integrieren. Man kann es auch selbst installieren, muss sich aber darauf gefasst machen ein wenig basteln zu müssen. Vermutlich haben alle wichtigen Distributionen Pipewire Ende 2022 komplett integriert.
Zukünftige Audio- und Routingkonfigurationen werden statt mit dem LADISH Protokoll mit dem NSM (Non Session Management) Protokoll konfiguriert. Dazu wird es aber noch einen eigenen Artikel geben.
Entsprechende Tools sind:
RaySessionhttps://raysession.tuxfamily.org/en/manual RaySession ist ein Audio-Session-Manager für GNU / Linux. Er ermöglicht es, mehrere Audioprogramme in der gleichen Sitzung zu starten, Projekte gemeinsam zu speichern und so vermeidbare Doppelkonfigurationen und Schritte wezulassen, um zu einer bestimmten Konfiguration zurückzukehren.
Agordejohttps://www.laborejo.org/documentation/agordejo/english.html Agordejo (Esperanto: ‘Ort, um Dinge einzurichten’) ist ein Session-Manager für die Musikproduktion. Er dient dazu, Programme zu starten, sich deren (JACK-)Verbindungen zu merken und das Leben im Allgemeinen zu erleichtern.
Vorige Woche habe ich die Installation von Arch Linux beschrieben. Ein Leser hat mich nun darauf hingewiesen, dass es zur rein manuellen Installation eine Alternative gibt: Das Script archinstall, das im Live-System von Arch Linux mittlerweile standardmäßig enthalten ist.
Beachten Sie, dass das ArchWikiarchinstall als noch »experimentell« bezeichnet und darum bittet, bei Fehlerberichten auf die Verwendung von archinstall hinzuweisen.
Installation starten
Die Installation beginnt wie bei der manuellen Variante: Sie laden von https://archlinux.org/download das Live-Image herunter und booten damit Ihren Rechner bzw. Ihre virtuelle Maschine. Wenn Sie wollen, können Sie ein root-Passwort festlegen, sich dann per SSH im Live-System anmelden und die weitere Installation via SSH durchführen.
Danach gibt es zwei Varianten: Die eine besteht darin, archinstall sofort auszuführen. Das ist dann zweckmäßig, wenn Arch Linux den gesamten Datenträger nutzen darf, z.B. in virtuellen Maschinen. Bei der zweiten Variante kümmern Sie sich zuerst selbst um die Partitionierung, um das Einrichten des Dateisystems (optional samt LVM und RAID) und binden das Root-Dateisystem unter /mnt in den Verzeichnisbaum ein. Beim anschließenden Start von archinstall berücksichtigt das Script /mnt.
archinstall stellt während der Installation diverse Optionen zur Auswahl (Sprache, Tastatur, Desktop-System etc.), die Sie durch die Angabe des Namens oder der fortlaufenden Nummer auswählen. Die eigentliche Installation beginnt erst nach einer Anzeige aller Einstellungen und einer letzten Rückfrage.
Bootloader
Auf Rechnern mit EFI haben Sie beim Bootloader die Wahl zwischen GRUB und systemd-boot.
In virtuellen Maschinen mit BIOS installiert archinstall immer GRUB.
Automatische Partitionierung
Ich empfehle Ihnen, die Partitionierung nur dann archinstall zu überlassen, wenn das Script den gesamten Datenträger nutzen darf und Sie keine Rücksicht auf vorhandene Daten oder Betriebssysteme nehmen müssen. Ich habe keine klare Beschreibung gefunden, wie archinstall bei der Partitionierung vorgeht. Bei meinen Tests bin ich zu folgenden Ergebnissen gekommen:
BIOS: Eine Systempartition füllt den ganzen Datenträger mit Ausnahme des ersten MiB. GRUB wird in die ersten Sektoren installiert, es gibt keine eigene /boot-Partition.
EFI: Hier richtet das Script eine gemeinsame boot- und EFI-Partition ein (vfat-Dateisystem, 500 MB). Den Rest des Datenträgers füllt die Systempartition.
Beispiellauf
Das folgende Listing zeigt einen (etwas gekürzten) Ablauf des Frage- und Antwort-Spiels von archinstall.
archinstall
...
4: de
...
Select one of the above keyboard languages (by number or full name): 4
...
11: Germany
...
Select one of the above regions to download packages from (by number or full name): 11
0: /dev/loop0 (('638.7M', '/run/archiso/copytoram/airootfs.sfs', None))
1: /dev/sr0 (('774.3M', None, 'ARCH_202106'))
2: /dev/vda (('25G', '/dev/vda', None))
Select one of the above disks (by name or number) or leave blank to use /mnt: 2
0: btrfs
1: ext4
2: xfs
3: f2fs
Select which filesystem your main partition should use (by number or name): 1
Enter disk encryption password (leave blank for no encryption): <return>
Would you like to use GRUB as a bootloader instead of systemd-boot? [y/N] y
Desired hostname for the installation: archinstalltest
Enter root password (Recommendation: leave blank to leave root disabled): <return>
Create a required super-user with sudo privileges: kofler
Password for user kofler: ********
And one more time for verification: ********
Enter a username to create a additional user (leave blank to skip & continue): <return>
0: desktop
1: minimal
2: server
3: xorg
Enter a pre-programmed profile name if you want to install one: 0
0: awesome
1: budgie
2: cinnamon
3: deepin
4: enlightenment
5: gnome
6: i3
7: kde
8: lxqt
9: mate
10: sway
11: xfce4
Select your desired desktop environment: 5
0: AMD / ATI (open-source)
1: All open-source (default)
2: Intel (open-source)
3: Nvidia
4: VMware / VirtualBox (open-source)
Select your graphics card driver: 4
Would you like to install pipewire instead of pulseaudio as the default audio server? [Y/n] y
0: >> linux 1: linux-hardened
2: linux-lts
3: linux-zen
Choose which kernels to use (leave blank for default: linux): <return>
If you desire a web browser, such as firefox or chromium, you may specify
it in the following prompt. Write additional packages to install (space
separated, leave blank to skip): nano firefox
0: Copy ISO network configuration to installation
1: Use NetworkManager to control and manage your internet connection
2: enp1s0
Select one network interface to configure (leave blank to skip): 1
Enter a valid timezone (examples: Europe/Stockholm, US/Eastern)
or press enter to use UTC: Europe/Berlin
Would you like to use automatic time synchronization (NTP) with the
default time servers? [Y/n]: y
This is your chosen configuration:
{
"!root-password": "******",
"audio": "pipewire",
"bootloader": "grub-install",
"filesystem": "ext4",
"harddrive": {
"model": null,
"path": "/dev/vda",
"size": "25G"
},
"hostname": "archinstalltest",
"kernels": [
"linux"
],
"keyboard-language": "de",
"mirror-region": {
"Germany": {
"https://appuals.com/archlinux/$repo/os/$arch": true,
"https://arch.jensgutermuth.de/$repo/os/$arch": true,
...
"https://pkg.fef.moe/archlinux/$repo/os/$arch": true
}
},
"nic": {
"NetworkManager": true,
"nic": "Use NetworkManager to control and manage your internet connection"
},
"ntp": true,
"packages": [
"nano",
"firefox"
],
"profile": {
"path": "/usr/lib/python3.9/site-packages/archinstall/profiles/desktop.py"
},
"script": "guided",
"superusers": {
"kofler": {
"!password": "******"
}
},
"sys-encoding": "utf-8",
"sys-language": "en_US",
"timezone": "Europe/Berlin",
"users": {}
}
Praktische Erfahrungen
Bei meinen Tests, die ich allerdings ausschließlich in virtuellen Maschinen durchgeführt habe, hat archinstall durchwegs gut funktioniert. Ich habe mich allerdings nicht getraut, archinstall auf meine echten Rechner loszulassen, auf denen diverse andere Linux-Distributionen installiert sind.
Die Konfiguration des deutschen Textlayouts für die Konsole hat nur teilweise funktioniert. Die Eingabe deutscher Sonderzeichen war unmöglich. Abhilfe: Öffnen Sie im neu installierten System /etc/vconsole.conf mit einem Editor und ersetzen Sie KEYMAP=de durch KEYMAP=de-latin1.
Wie stellt man die Integrität der Paketverwaltung als zentrales Instrument der Softwareverwaltung unter Linux sicher. Diese Frage müssen sich gegenwärtig alle Distributionen stellen lassen, die auf RPM aufbauen, weil die dortige OpenPGP-Implementierung unzureichend ist.
In diesem Blog beklage ich mich gerne über die Berichterstattung bei Heise. Darum möchte ich heute die Gelegenheit nutzen, um auf einen lesenswerten Artikel hinzuweisen. Dort wird zu Recht die Frage diskutiert, welchen Lehren eigentlich aus dem RPM-Problem zu ziehen sind.
Die RPM-Entwickler möchten aktuell die fehlende Funktionalität nicht nachrüsten, weil das ihrer Meinung nach nicht die Aufgabe von RPM ist. Viele logische Folgeprobleme einer Implementierung, wie z. B. der Umgang mit bereits installierten Paketen, deren Schlüssel nachträglich zurückgezogen wurde und weitere Hürden unterstützen diese Position.
Jürgen Schmidt stellt daher berechtigterweise die Frage, ob OpenPGP als „Eierlegende Wollmilchsau“ überhaupt das geeignete Werkzeug für die Signatur von Paketen ist oder ob dafür nicht Alternativen wie das OpenBSD-Tool signify klüger wären.
Meiner Meinung nach ist es gut, dass diese Debatte geführt wird und sie reicht über den Kreis der RPM-Distributionen hinaus. Die Verwaltung aller Betriebssystembestandteile – vom Kernel bis zum Browser – machen die Paketverwaltung zum Kern jeder Distribution. Weil keine verbreitete Linux-Distribution hier zwischen Betriebssystem und Anwendungen trennt und einmal installierte Anwendungen in kein nennenswertes Rechtesystem – abgesehen von Administratorrechten und Dateirechten – eingebunden sind, ist die Integrität der Paketverwaltung umso wichtiger.
Das mag im Servereinsatz keine so große Rolle spielen, weil versierte Administratoren ihre Systeme pflegen und dank Containern & Co längst neue Technologien Einzug gehalten haben. Niemand installiert heute noch einen Linux-Server auf normaler Hardware und betreibt auf diesem direkt zig Dienste ohne Abschirmung gegeneinander und stellt den direkt ins Internet.
Beim Desktop ist die Situation aber viel prekärer, als es nach außen den Anschein hat. Dabei geht es nicht nur um die Paketquellen der Distributoren (über deren Integrität man als Außenstehender auch nur mutmaßen kann), sondern die meisten Anwender binden mehr oder minder vertrauenswürdige Paketquellen von Dritten ein, importieren deren Schlüssel und viel zu wenige verbinden dieses Verhalten mit kluger Priorisierung der Paketquellen. Meiner Ansicht nach retten nur die geringen Marktanteile von Linux auf dem Desktop hier das Ökosystem vor seinem ersten richtig großen Unfall.
Wenn die Linux-Gemeinschaft am Prinzip der Paketverwaltung als Allzweckwaffe festhalten möchte – und das ist mein Eindruck angesichts der verbreiteten Ablehnung von Flatpak und Snap – muss die Integrität dieses zentralen Bestandteils über jeden Zweifel erhaben sein.
Mein Linux-Freund Niki Kovacs hat mich heute kontaktiert: Soll man als CentOS-Ersatz Rocky Linux oder doch eher Oracle Linux empfehlen? Ich habe per Mail schon geantwortet, aber ich will die Frage hier ein wenig ausführlicher diskutieren und lade Sie ein, in den Kommentaren Ihre eigene Sichtweise zu präsentieren.
Prinzipiell geht es um die Frage: Welcher RHEL-Klon ist der beste, wenn kein Geld für eine RHEL-Lizenz da ist? CentOS 8 scheidet aus, der RHEL-Klon schlechthin hat ja für Ende 2021 die Einstellung von Updates angekündigt (siehe auch meinen Nachruf auf CentOS). Es gibt aber mittlerweile eine Menge Alternativen (hier in alphabetischer Reihenfolge):
AlmaLinux
CentOS Stream
Oracle Linux
Red Hat Enterprise Linux (RHEL) mit einem Developer Account kostenlos nutzen
Rocky Linux
Update 7.7.2021: Gerade habe ich noch einen RHEL-Klon entdeckt: Virtuozzo VzLinux
RHEL kostenlos nutzen
Beginnen wir mit dem Original. Natürlich ist es schön, dass Open-Source-Lizenzen das Angebot von RHEL-Klonen überhaupt möglich machen; aber wozu einen Klon verwenden, wenn Red Hat jetzt 16 kostenlose RHEL-Installationen im Produktiveinsatz erlaubt (FAQs for no-cost Red Hat Enterprise Linux)?
Ich habe es ausprobiert. Ein paar Mausklicks reichen aus, um einen Red Hat Developer Account einzurichten — aber in der Folge ist von der kostenlosen Red Hat Developer Subscription for Individuals in der Red-Hat-Weboberfläche nichts zu sehen. Auch die Registrierung einer neuen RHEL-Installation scheitert mit unklaren Fehlermeldungen.
Schließlich habe ich den Red-Hat-Support per Mail kontaktiert. Sehr freundlich hat man mir dann einen halben Tag später die RHEL-Subscription freigeschaltet. Anscheinend gibt es da keinen Automatismus. Das kostenlose Angebot ist allerdings auf ein Jahr limitiert und muss dann verlängert werden. (Mangels eigener Erfahrung kann ich nicht sagen, ob dazu wieder ein E-Mail-Kontakt erforderlich ist.)
Die Weboberfläche zur Verwaltung von RHEL-Subskriptionen
Nach der manuellen Freischaltung ist die Aktivierung von RHEL-Systemen dann möglich. Die Verwaltung der Subskriptionen bleibt allerdings unübersichtlich. Die dafür vorgesehene GUI innerhalb von Red Hat habe ich schon in der Vergangenheit als recht fehleranfällig erlebt.
GUI zur Subskriptionsverwaltung innerhalb von RHEL
Immerhin lässt sich die Verwaltung auch per Kommando erledigen:
subscription-manager register --username <yourname> --password <pw>
Das System wurde mit ID registriert: 764c...
Der registrierte Systemname lautet: <hostname>
subscription-manager role --set="Red Hat Enterprise Linux Server"
role set to "Red Hat Enterprise Linux Server".
subscription-manager service-level --set="Self-Support"
service_level_agreement set to "Self-Support".
subscription-manager usage --set="Development/Test"
usage set to "Development/Test".
subscription-manager attach
Aktueller Status der installierten Produkte:
Produktname: Red Hat Enterprise Linux for x86_64
Status: Subskribiert
Fazit: Red Hat ist mittlerweile durchaus großzügig und erlaubt die kostenlose Nutzung von bis zu 16 RHEL-Installationen im Produktivbetrieb. Allerdings ist das Handling der Lizenzen mühsam und für Open-Source-verliebte Linux-Anwender ungewohnt. Ein wenig stellt sich die Frage nach dem Nutzen. Letzlich bleibt nur ein Argument: Paket- und Versions-Updates erfolgen beim Original in der Regel ein paar Tage schneller als bei den Klonen.
CentOS Stream
Red Hat bewirbt CentOS Stream als Nachfolger von CentOS. CentOS Stream ist wie CentOS kostenlos verfügbar. Ansonsten gibt es aber zwei gewichtige Unterschiede:
Zum einen ist CentOS Stream nicht mehr vollständig RHEL-kompatibel. Vielmehr werden für RHEL geplante Updates zuerst für CentOS Stream freigegeben. Das kann man durchaus als Vorteil sehen — vor allem, weil die lahme Update-Versorgung in der Vergangenheit ein großes CentOS-Problem war. Andererseits ist klar, dass CentOS Stream für Red Hat damit zur Testumgebung wird: Sollte bei einem Update doch ein Problem auftreten, werden die CentOS-Stream-Anwender dieses feststellen, bevor die zahlenden RHEL-Kunden damit beglückt werden.
Zum anderen hat CentOS Stream eine viel kürze Lebenszeit als RHEL. Während für CentOS in der Vergangenheit wie RHEL 10 Jahre Updates versprach, wird es diese für CentOS Stream nur ca. vier bis fünf Jahr geben. (Dieser Zeitraum ist nicht in Stein gemeißelt. Er hängt davon ab, wir rasch Red Hat die jeweils nächste RHEL-Version fertig stellt.)
Persönlich könnte ich mit Punkt 1 leben. In aller Regel sind die Paket-Updates absolut ausgereift (siehe auch diesen Artikel in der CentOS-Mailing-Liste), wenn sie für CentOS Stream freigegeben werden. CentOS Stream ist nicht Fedora und schon gar nicht Debian unstable. Aber aufgrund von Punkt 2 ist CentOS Stream aus meiner Sicht weitgehend uninteressant für den produktiven Server-Einsatz.
Oracle Linux
Damit kommen wir zu den Klonen. Seit über 15 Jahren am Markt etabliert ist Oracle Linux. Oracle vermarktet sein Linux primär als kommerzielles Angebot und versucht, sich mit Zusatzfunktionen von RHEL abzuheben: Dazu zählen ein neuerer Kernel (im Marketing-Jargon: »Unbreakable Enterprise Kernel«), Ksplice-Kernel-Updates im laufenden Betrieb sowie eine bessere Unterstützung des von Oracle mitentwickelten Dateisystems btrfs.
Anfänglich war Oracle Linux wie RHEL ausschließlich für zahlende Kunden zugänglich, wenn auch zu günstigeren Preisen als bei RHEL. Seit 2012 kann Oracle Linux inklusive aller Updates kostenlos bezogen werden und steht damit auf einer Ebene mit AlmaLinux und Rocky Linux. Oracle verspricht, dass Linux auch weiterhin frei zugänglich bleiben wird.
Für Oracle spricht, dass die Update-Versorgung in den letzten 15 Jahren ausgezeichnet (viel besser als bei CentOS) funktioniert hat. Dagegen spricht, dass Oracle in der Vergangenheit keine glückliche Hand mit Open-Source-Projekten hatte. Java, MySQL, OpenOffice führen die Liste der von Oracle übernommenen Projekte an, die prompt Konflikte mit der Community und Forks verursacht haben.
Eine Oracle-Linux-Installation in einer virtuellen Maschine
AlmaLinux und Rocky Linux
Wenige Tage nach der Ankündigung vom Ende von CentOS haben der ehemalige CentOS-Gründen Greg Kurtzer und die Firma CloudLinux jeweils einen eigenen RHEL-Klon angekündigt. Mittlerweile sind beide Produkte unter den Namen Rocky Linux (in Gedenken an ein weiteres CentOS-Gründermitglied) und AlmaLinux fertig und stehen jeweils für zwei Architekturen (x86 und ARM) zur Auswahl. Ich habe beide Klone kurz angetestet und keinerlei Probleme festgestellt.
Cloud Linux hat die weitere Verantwortung für AlmaLinux in die Hände der neu geschaffenen AlmaLinux OS Foundation gelegt, und verspricht außerdem, pro Jahr eine Million Dollar für das Projekt zur Verfügung zu stellen. Zumindest im ersten halben Jahr hinterließ AlmaLinux als Distribution wie als Organisation einen äußerst professionellen Eindruck.
Rocky Linux war mit der Fertigstellung etwas langsamer. Das Ende Juni 2021 vorgestellte Release unterstützt zudem noch kein UEFI Secure Boot. Dieses Feature soll aber in naher Zukunft nachgereicht werden. Rocky Linux genießt immerhin bereits die Unterstützung durch Amazon, Google und Microsoft. (Lesen Sie auch dieses Interview mit dem Greg Kurtzer.)
Machen Sie sich keine Illusionen: Eine echte Beurteilung von AlmaLinux bzw. von Rocky Linux ist aktuell schlicht unmöglich. Die Wartung einer Enterprise-Distribution verlangt einen langen Atem. Die regelmäßige Update-Versorgung über einen Zeitraum von 10 Jahren kostet richtig viel Arbeit (= Geld)! Das gilt umso mehr, wenn demnächst zwei und in ferner Zukunft womöglich drei Major-Versionen (RHEL 8 + 9 + 10) parallel laufen.
Das Überleben von Rocky Linux und AlmaLinux wird also letztlich von der langfristigen Unterstützung durch Sponsoren abhängen. Dementsprechend zeigen beide Projekte auf ihrer Website eine lange Liste von Sponsoren-Logos an :-) Aber ob bzw. welche der beiden Projekte in 10 Jahren noch aktiv sind, kann heute niemand seriös vorhersehen. Den großartigen Ruf, den das CentOS-Projekt hatte und den Red Hat vorigen Dezember quasi über Nacht verspielte, müssen sich AlmaLinux und Rocky Linux erst mühsam erarbeiten.
Das Installations-Programm von AlmaLinux ist nur an der optischen Gestaltung der Seitenleiste vom Original bzw. von den anderen RHEL-Klonen unterscheidbar.
Die Qual der Wahl
Damit sind wir bei der eingangs gestellten Frage: Welcher Klon soll es nun sein?
Selbst habe ich aktuell kein Projekt, wo ich einen RHEL-Klon produktiv einsetzen will. Dafür habe ich im Linux-Unterricht auf der FH Kapfenberg dieses Sommersemester mit Oracle Linux 8 gearbeitet. Ich habe dutzendweise virtuelle Maschinen mit Oracle Linux erzeugt und wieder gelöscht. Das hat vollkommen klaglos funktioniert.
Vielleicht liegt es daran, dass meine Empfehlung am ehesten in diese Richtung geht: Oracle hat schon bewiesen, dass es langfristig einen RHEL-Klon warten kann. Oracle hat die Ressourcen und die Erfahrung. Natürlich könnte Oracle den kostenlosen Zugang zu Oracle Linux jederzeit einstellen — aber persönlich erwarte ich das nicht. Dagegen spricht schon der Umstand, dass Oracle mit dem kostenlosen Angebot den großen Linux-Mitbewerber Red Hat (letztlich also IBM) ein wenig ärgern kann.
AlmaLinux und Rocky Linux machen aus meiner Sicht ebenfalls einen sehr vielversprechenden Eindruck. Ich denke eigentlich nicht, dass Sie mit der Wahl für eine der beiden Distributionen viel falsch machen können. Das liegt auch daran, dass es Migrations-Scripts gibt, die einen Umbau von einen RHEL-Klon in einen anderen bewerkstelligen. Diese Scripts sind vielleicht nicht frei von Problemen, aber sie sollten doch garantieren, dass Sie im Fall der Fälle nicht komplett in der Sackgasse landen.
Vielleicht haben Sie schon eigene Erfahrungen gemacht. Ich freue mich über Ihre Meinung in den Kommentaren!
Nachdem ich die letzte Release-Runde ausgelassen hatte, möchte ich die aktuelle wieder mitnehmen und ein paar Worte über Kali Linux, NST und Parrot verlieren.
Kali Linux 2021.2
Das neueste Release stellt einen Mix aus Verbesserungen des vorhandenen Systems und der Einführungen einiger Neuerungen dar.
Kaboxer
Das CLI Tool soll in Zukunft eine Paketierung von Programmen mit vielen Abhängigkeiten erleichtern. Dazu werden Kaboxer/Docker Images erstellt. Alles, was es dazu braucht, ist einen Nutzer, welcher Mitglied in der Kaboxer/Docker Gruppe ist, ein Dockerfile und eine kaboxer.yaml.
Damit lassen sich nun Images bauen, welche die gewünschten Abhängigkeiten enthalten. Auch eine Einbindung in das Kali Startmenü ist zum Beispiel möglich. Hier ein grobes Beispiel.
Dockerfile erstellen
FROM debian:stable-slim
RUN apt update && apt install -y \
python3 \
python3-prompt-toolkit
COPY ./hello /usr/bin/hello
RUN mkdir /kaboxer \
&& hello version > /kaboxer/version
kaboxer.yaml erstellen
application:
id: hello-cli
name: Hello World for Kaboxer (CLI)
description: >
hello-kbx is the hello-world application demonstrator for Kaboxer
packaging:
revision: 1
components:
default:
run_mode: cli
executable: /usr/bin/hello cli
Ein praktisches Tool, welches sicherlich das Tool Spektrum der Distribution erweitern wird.
Auch wenn beispielsweise Greenbone Vulnerability Management bereits mit Kali ausgeliefert wird, würde sich dieses Tool sehr gut für einen Kaboxer Container eignen.
Drei Tools bringt Kali Linux bereits auf diese Weise mit:
Covenant - Daemon using server/client network model
Eine weitere Neuerung sind Kali Tweaks. Diese erlauben es das System auf die eigenen Bedürfnisse besser anzupassen. So lassen sich damit Repositorys verwalten, Virtualisierungseinstellungen anpassen oder Metapakete installieren.
Auch hierzu haben die Entwickler einen eigenen Artikel angelegt.
Sonstiges
Die restlichen Meldungen beziehen sich auf die Unterstützung neuer Systeme wie Raspberry Pi 400 oder den Support von Nethunter für Android 11. Für ersteres gibt es nun mit kalipi-config eine eigene Config Oberfläche speziell für Kali Linux.
Neben den kosmetischen Anpassungen wurden ebenfalls neue Tools integriert. So ist unter anderem das Reverse Engineering Tool Ghidra und Visual Studio (OSS) Code mit an Bord oder der Webserver Verzeichnis Scanner Dirsearch, sowie Cloudbrute für eine Dateisuche in der Cloud.
Alle Neuerungen, Tools und Co finden sich ebenfalls im Release Log.
NST 34
Das Network Security Toolkit hat ebenfalls ein Update auf eine neue Version erhalten.
Bei der Fedora basierten Distribution halten sich die Neuerungen in Grenzen. Die Weboberfläche NST WUI bindet nun lft (Layer-4 Traceroute) und Ntopng REST API ein. Der Verzeichnisscanner dirble beherrscht nun die Ausgabe in Tabellenform. Das alles läuft auf dem Linux Kernel 5.12.10.
Weitere Änderungen können direkt im Changelog nachgelesen werden.
Parrot OS 4.11.2
Der Vollständigkeit halber sei hier noch das Release vom März erwähnt, welches einen neuen Kernel 5.10 und viele Updates auf der Tooling Seite erhalten hat. Auch hier lässt sich alles im Release Log nach recherchieren.
Da ist jetzt schon eine ziemliche Bombe geplatzt. Das neben dem DEB/APT wichtigste Paketmanagerformat RPM unterstützt die OpenPGP-Signierung nur lückenhaft. Es sieht keine Überprüfung abgelaufener oder ungültiger Schlüssel vor.
Was ist das Problem?
Gestern berichtete bereits Golem über das Problem. Die Paketverwaltung RPM hat ein Problem mit der Signatur von Paketen. Die Software unterstützt schlicht keine abgelaufenen oder zurückgezogenen Schlüssel. Mit solchen Schlüsseln signierte Pakete werden einfach weiter akzeptiert.
Aufgebracht hatte das Problem ein Linux-Entwickler von Cloudlinux, die mit Alma nun einen Klon von RHEL erschaffen haben und sich anschicken, die Nachfolge von CentOS anzutreten. Es handelt sich hierbei streng genommen um keinen Fehler, da die Funktion schlicht und ergreifend nicht implementiert ist.
Inwieweit diese Implementierung jetzt nachgeholt wird, bleibt abzuwarten. Vor allem ist fraglich, wie schnell das wirklich flächendeckend ausgerollt wird, da Upstream-Änderungen bei RPM oft erst mit viel Verzögerung in den Distributionen landen.
Warum ist das ein Problem?
Angreifer können dieses Problem ausnutzen, um mit abgelaufenen oder zurückgezogenen Schlüsseln schädliche Pakete zu signieren und zur Installation verwenden. RPM hat weder einen guten Schlüsselspeicher, noch gibt es die Möglichkeit, diese Schlüssel zentral zu verwalten und ggf. bei Kompromittierung zurückzuziehen.
Ein konkretes Angriffsszenario ist jetzt erst mal damit nicht verbunden, aber es beschädigt das Vertrauen in die Paketverwaltung. Das ist natürlich ein bisschen abstrakt, deshalb muss man noch mal einen Blick auf die Bedeutung der Paketquellen werfen.
Die Integrität der Paketverwaltung ist ein wesentlicher Baustein in der Linux-Sicherheit. Software ist bei Linux (abgesehen von Flatpak und Snap) nicht in irgendwelche Sandboxen eingesperrt oder durch ein ausgefeiltes Rechtesystem isoliert. Anwender vertrauen darauf, dass die Integrität der Paketquellen gewährleistet ist und gültig signierte Pakete vertrauenswürdig sind.
Das ist kein Problem in der Kategorie „Ferner liefen“, denn RPM ist der Standard bei den beiden wichtigsten Enterprise-Distributionen RHEL und SLE. Mit Fedora und openSUSE greifen auch populäre Community-Distributionen darauf zurück.
Warum Baustelle Linux-Sicherheit?
Der Vorfall passt in eine Reihe von Problemen und Beobachtungen. Linux-Anwender und Linux-Entwickler sind in den letzten Jahren oft in eine Haltung bräsiger Selbstzufriedenheit verfallen. Probleme mit Sicherheit hatten schließlich immer nur die anderen.
Die Welt hat sich seitdem weiter gedreht und in anderen Betriebssystemen wurden Sicherheitskonzepte eingebaut, die es für Linux so in der Form nicht gibt. Matthew Garrett hat deshalb bereits 2017 auf der Guadec versucht, die Linux-Gemeinschaft aufzurütteln. Die Auswirkungen waren eher bescheiden.
Das traurige ist: Mit OpenPGP für die Signierung, AppArmor, SELinux, guten Firewall-Lösungen, Sandbox-Konzepten und all diesen Sachen hat Linux starke Lösungen. Nur leider werden die wenigsten davon standardmäßig durch die großen Distributionen eingesetzt und auch konsequent genutzt.
Wie sehr hier Linux in der Aufmerksamkeit unter dem Radar läuft und wie wenig Problembewusstsein bei den Entwicklern und Anwender vorherrscht, kann man sich leicht vor Augen führen, wenn man sich vorstellt ein vergleichbares Problem hätte macOS oder Windows getroffen. Häme und Aufschrei wären sicher gewaltig gewesen.
Zusammengefasst
Ein bisschen weniger Selbstzufriedenheit täte im Bereich der Linux-Sicherheit ganz gut. Es ist keine Katastrophe und dieses konkrete Problem sicher auch nicht, aber es sollte ein Weckruf sein, die Leerstellen anzuschauen und Abhilfe zu schaffen. Viele Lösungen sind da, sie müssen nur konsequent und konsistent genutzt werden.
Arch Linux ist eine unter Linux-Profis sehr beliebte Rolling-Release-Distribution. Arch Linux zählt zu den wenigen Distributionen, die auf eine eigene Paketverwaltung außerhalb der Debian- und RPM-Welt setzen. Arch Linux betreibt schließlich ein großartiges Wiki, wo Sie technische Informationen zu kniffeligen Setup-Fragen finden (ganz egal, unter welchem Linux Sie arbeiten). Beim Recherchieren für mein Linux-Buch lande ich unweigerlich immer wieder im Arch Linux Wiki. Oft hört die Suche dort auf.
Arch Linux spricht explizit technisch versierte Linux-Anwender an. Wenn Sie nicht wissen, wie Sie Festplatten/SSDs manuell partitionieren, Dateisysteme selbst einrichten, mit chroot andere Verzeichnisse zum Root-Verzeichnis machen, ist Arch Linux nicht die richtige Wahl. Wenn Sie aber schon ein, zwei Jahre Linux-Erfahrung haben, ist Arch Linux für Desktop-Installationen definitiv einen Versuch wert. Einmal installiert erhalten Sie eine solide, schnelle und sehr moderne Linux-Distribution.
Arch Linux lohnt sich auch aus didaktischer Sicht: Da Sie sowohl bei der Installation als auch später im Betrieb viel mehr selbst machen müssen, lernen Sie Linux besser verstehen.
Dieser Blog-Beitrag fasst die wichtigsten Schritte zur Installation in einer virtuellen Maschine sowie auf einem echten Rechner zusammen. Natürlich gibt es im Internet noch mehr Anleitungen (siehe die Liste der Quellen am Ende dieses Artikels), aber nachdem ich selbst ein, zweimal über Details gestolpert bin, habe ich mir gedacht: Noch eine Anleitung kann nicht schaden!
Für diese Anleitung gilt wie für Arch Linux: Die Zielgruppe sind Leute, die mit Linux bereits gut umgehen können. Wenn Sie einen benutzerfreundlichen Einstieg in die Arch-Welt suchen, sollten Sie Manjaro ausprobieren. Dabei handelt es sich um eine Arch-Variante mit grafischer Installation. Und Linux-Einsteiger sind mit Ubuntu, Mint, openSUSE etc. besser bedient.
Sollten Sie noch nie Arch Linux installiert haben, empfehle ich Ihnen dringend, zuerst eine Probeinstallation in einer virtuellen Maschine durchzuführen, bevor Sie Arch Linux auf reale Hardware installieren.
Update 7.7.2021: Dieser Text beschreibt die manuelle Installation von Arch Linux. Eine Alternative dazu ist die Verwendung des noch experimentellen Scripts archinstall. Meine praktischen Erfahrungen damit habe ich hier zusammengefasst.
Installation im Live-System starten
Bevor Sie loslegen können, müssen Sie sich das ISO-Image von Arch Linux herunterladen:
Bei einer Installation in eine virtuelle Maschine verwenden Sie das Image als virtuelle DVD. Für eine »richtige« Installation übertragen Sie das Image mit Etcher oder dd auf einen USB-Stick.
Mit dem Start des Rechners bzw. der VM wird ein Arch-Linux-Live-System im Textmodus gestartet. Sie sind sofort als root eingeloggt und müssen nun die Installation manuell durch das ausführen von Linux-Kommandos ausführen.
Die Installation von Arch Linux erfolgt durch Kommandos im Textmodus
Tastaturlayout einstellen
Anfänglich gilt das US-Tastaturlayout. Wenn Sie mit einer deutschen Tastatur arbeiten, aktivieren Sie mit dem folgenden Kommando das richtige Tastaturlayout:
loadkeys de-latin1
Netzwerk- und Internetzugang
Sofern Ihr Rechner mit einem Ethernet-Kabel an das lokale Netzwerk angeschlossen ist, funktioniert der Netzwerkzugang dank DHCP auf Anhieb. Das gilt natürlich auch für virtuelle Maschinen. Testen Sie, ob ping google.com funktioniert!
Schwieriger ist die Sache bei Notebooks, deren Netzwerkzugang ausschließlich per WLAN hergestellt werden kann. In diesem Fall müssen Sie das Kommando iwctl zu Hilfe nehmen (siehe diese Anleitung).
Sie machen sich das Leben leichter, wenn Sie ein Netzwerkkabel verwenden, zur Not per USB-Adapter. Dann können Sie mit der WLAN-Konfiguration warten, bis Ihnen unter Arch Linux eine grafische Benutzeroberfläche zur Verfügung steht.
Installation via SSH
Im Live-System zur Arch-Linux-Installation läuft ein SSH-Server. Wenn Sie möchten, können Sie alle weiteren Kommandos via SSH ausführen. Das hat den Vorteil, dass Sie Kommandos per Cut&Paste in Ihr Terminal kopieren können. Allerdings müssen Sie zuerst ein root-Passwort festlegen und dann die IP-Adresse des Live-Systems ermitteln:
passwd
New password: *********
Retype new password: *********
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue ...
...
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu ...
inet 192.168.122.131/24 brd 192.168.122.255 ...
Von einem Rechner im lokalen Netzwerk führen Sie nun das folgende Kommando aus (wobei Sie natürlich Ihre IP-Adresse verwenden!):
ssh root@192.168.122.131
BIOS oder EFI?
Wenn Sie nicht wissen, ob Ihr System ein herkömmliches BIOS verwendet (viele virtuelle Maschinen) oder ein neueres EFI (nahezu alle handelsüblichen PCs), testen Sie einfach, ob das Verzeichnis /sys/firmware/efi existiert. In diesem Fall liegt ein EFI-System vor, sonst handelt es sich um BIOS.
Diese Information ist später zweimal relevant:
Partitionierung: Bei einem EFI-System müssen Sie eine EFI-Partition vorsehen bzw. diese, wenn sie schon vorhanden ist, in /mnt/boot/efi einbinden. Bei einem BIOS-System in Kombination mit einer GUID Partition Table (GPT) brauchen Sie hingegen eine winzige BIOS-GRUB-Partition.
Boot-Loader: Die Kommandos zur Installation des Boot-Loaders unterscheiden sich ein wenig, je nachdem, ob ein BIOS- oder ein EFI-System vorliegt.
Datum und Uhrzeit
Mit date können Sie überprüfen, ob Datum und Uhrzeit eingestellt wurden. In aller Regel ist das der Fall, sofern Sie über eine Netzwerkverbindung verfügen. Zur Not holt timedatectl set-ntp true die Zeiteinstellung nach. Mit der Konfiguration der Zeitzone warten Sie ab, bis Arch Linux installiert ist.
Partitionierung/Formatierung des Datenträgers
Als nächsten Schritt müssen Sie auf dem Datenträger eine oder mehrere Partitionen erzeugen und diese mit Dateisystemen initialisieren. Dazu verwenden Sie die Programme parted und mkfs, bei Bedarf auch LVM-, RAID- und CryptSetup-Tools.
Zuerst sollten Sie lsblk ausführen, damit Sie wissen, unter welchen Device-Namen Sie SSDs, Festplatten etc. ansprechen können. In einer virtuellen Maschine sieht das Ergebnis z.B. so aus:
lsblk
loop0 ... (Boot-System von Arch Linux)
sr0 ... (ISO-Image von Arch Linux)
vda 20G disk (virtuelle Disk der VM)
Der einfachste Fall liegt vor, wenn Sie Arch Linux in eine VM mit BIOS installieren und auf eine Swap-Partition verzichten. Dann reicht es aus, im Datenträger der VM zwei Partition einzurichten, eine winzige BIOS-GRUB-Partition und eine Root-Partition. Ich empfehle, dort ein ext4-Dateisystem zu erzeugen, aber Sie haben natürlich die Wahl zwischen allen erdenklichen anderen Dateisystemen:
parted /dev/vda
(parted) mklabel gpt
(parted) mkpart biosgrub 1mib 2mib
(parted) set 1 bios_grub on
(parted) mkpart rootpart 3mib -1mib
(parted) unit mib
(parted) print
Partition Table: gpt
Number Start End Size File system Name Flags
1 1.00MiB 2.00MiB 1.00MiB biosgrub bios_grub
2 3.00MiB 10239MiB 10236MiB root
(parted) quit
mkfs.ext4 /dev/vda2
Optional können Sie natürlich auch noch eine Boot- und/oder eine Swap-Partition einrichten.
Bei der Installation auf reale Hardware ist die Sache komplizierter. Wenn es schon andere Partitionen gibt, deren Inhalt erhalten bleiben soll, dürfen Sie diese nicht anrühren. Gibt es keine Partitionen, benötigen Sie zumindest eine EFI-Partition und eine Root-Partition. Auch eine Trennung von Root-, Boot-, Swap- und Home-Partitionen macht oft Sinn. Wenn jetzt noch LVM, RAID und/oder ein Crypto-Setup ins Spiel kommen, wird die Angelegenheit relativ unübersichtlich und erfordert sehr gutes Wissen über die diversen Kommandos zur Dateisystem-Administration.
Bei meiner EFI-Testinstallation war /dev/sda4 eine schon existierende EFI-Partition (keine Formatierung erforderlich) und /dev/sda6 die Root-Partition. Auf eigene Boot- und Swap-Partitionen habe ich verzichtet.
mkfs.ext4 /dev/sda6
Zieldateisystem mit /mnt verbinden
Nun verbinden Sie das Dateisystem der root-Partition mit dem bereits existierenden Verzeichnis /mnt. (Verwenden Sie anstelle von /dev/vda2 den richtigen Device-Namen Ihres Systems!)
mount /dev/vda2 /mnt
Wenn Sie weitere Dateisysteme eingerichtet haben, erzeugen Sie in /mnt entsprechende Unterverzeichnisse und binden dort die weiteren Dateisysteme ein. Die folgenden Zeilen zeigen die Vorgehensweise, um eine boot-Partition aus /dev/vda3 einzubinden:
mkdir /mnt/boot
mount /dev/vda3 /mnt/boot
Vergessen Sie bei EFI-Systemen nicht auf die EFI-Partition:
mkdir -p /mnt/boot/efi
mount /dev/sda6 /mnt/boot/efi
Basissystem installieren
Nach diesen Vorbereitungsarbeiten installieren Sie mit pacstrap das Basissystem inklusive des Linux-Kernels und der Firmware-Dateien in das /mnt-Verzeichnis. pacstrap lädt die erforderlichen Pakete aus dem Internet herunter, erfordert also eine funktionierende Netzwerkverbindung. Bei einer Installation in eine virtuelle Maschine können Sie auf die Firmware-Dateien verzichten; sie werden nicht gebraucht.
pacstrap /mnt base linux linux-firmware
/etc/fstab erzeugen
Das Kommando genfstab erzeugt /etc/fstab und wertet dabei die UUIDs der relevanten Dateisysteme aus.
genfstab -U /mnt >> /mnt/etc/fstab
Konfiguration des Basissystems
Mit arch-chroot, einer Variante zum gewöhnlichen chroot-Kommando, machen Sie /mnt zum aktiven Root-Verzeichnis. Von nun an werden alle Kommandos relativ zu diesem Verzeichnis gesucht bzw. ausgeführt.
arch-chroot /mnt
Zeitzone: Jetzt folgen diverse Konfigurationsarbeiten. Ein simples ln-Kommando stellt die gewünschte Zeitzone ein:
Uhrzeit:hwclock richtet die Datei /etc/adjtime ein. Das Kommando setzt voraus, dass die Hardware-Uhr des Rechners auf UTC eingestellt ist.
hwclock --systohc
Lokalisierungsdateien: Als nächstes öffnen Sie mit einem Editor die Datei /etc/locale.gen und entfernen die Kommentarzeichen bei den von Ihnen gewünschten Sprachen bzw. Ländercodes. Üblicherweise ist es sinnvoll, dass die folgenden Zeilen auskommentiert sind:
# in der Datei /etc/locale.gen
de_DE.UTF-8 UTF-8
en_US.UTF-8 UTF-8
Anfänglich steht als einziger Editor vi zur Verfügung. Wenn Sie sich damit nicht ärgern wollen, installieren Sie zuvor einen anderen Editor, z.B. nano oder emacs-nox.
pacman -S nano
nano /etc/locale.gen
Mit locale-gen erzeugen Sie schiesslich die Sprachdateien für die von Ihnen gewünschten Sprachen:
locale-gen
Sprache: Mit Ihrem Lieblingseditor erzeugen Sie nun die Datei /etc/locale.conf und tragen dort die gewünschte Default-Sprache ein. Vor und nach dem Zeichen = dürfen Sie keine Leerzeichen einfügen!
# Datei /etc/locale.conf
LANG=en_US.UTF-8
Oder:
# Datei /etc/locale.conf
LANG=de_DE.UTF-8
Tastaturlayout: Analog richten Sie die Datei /etc/vconsole.conf ein und geben passend zu Ihrer Tastatur das erforderliche Layout an:
# Datei /etc/vconsole.conf
KEYMAP=de-latin1
Hostname: Mit einem Editor tragen Sie in /etc/hostname den gewünschten Hostnamen ein.
/etc/hosts: Mit Ihrem Lieblingseditor richten Sie die Datei /etc/hosts ein, die drei Einträge entsprechend dem folgenden Muster haben sollte. (Ersetzen Sie archtest durch den tatsächlichen Hostnamen und local durch den Namen der Domäne Ihres lokalen Netzwerks.)
root-Passwort: Vergessen Sie nicht, mit passwd Ihr root-Passwort festzulegen:
passwd
Weitere Pakete: Wenn Sie Arch Linux demnächst erstmalig starten, verfügt das neue System über keine Netzwerkverbindung. Deswegen ist es eine gute Idee, schon jetzt alle erforderlichen Werkzeuge zu installieren, die Sie dann brauchen werden:
pacman -S dhclient networkmanager
Standardmäßig ist man nicht installiert. Abhilfe schafft:
pacman -S man
Wenn Sie wollen, können Sie natürlich auch andere Pakete schon jetzt installieren. In der Regel ist es aber zweckmäßiger, zuerst die Basisinstallation abzuschließen und weitere Pakete erst dann zu installieren, wenn alles funktioniert.
Boot-Konfiguration
Sofern Ihr Rechner exotische Hardware verwendet, für die schon während des Bootprozesses Kernelmodule erforderlich sind, oder wenn Sie LVM und/oder RAID und/oder Verschlüsselungsfunktionen nutzen, brauchen Sie eine initrd-Datei (genaugenommen eine initramfs-Datei). Diese erzeugen Sie wie folgt:
mkinitcpio -P
BIOS: Jetzt ist noch die Installation des Boot-Loaders ausständig. Ich gehe hier davon aus, dass Sie dazu das Programm GRUB verwenden. (Eine andere Option wäre systemd-boot.) Die GRUB-Installation ist davon abhängig, ob Sie (eine virtuelle Maschine mit) BIOS oder (einen realen Rechner mit) EFI verwenden. Beginnen wir mit BIOS, wo GRUB in die ersten Sektoren der Festplatte bzw. SSD installiert wird. (Das setzt voraus, dass Sie bei der Partitionierung das erste MiB freigelassen haben! Ersetzen Sie /dev/vda durch das Device des ersten Datenträgers laut lsblk!)
EFI: Auf einem EFI-System müssen Sie zusätzlich das Paket efibootmgr installieren. Sofern in /boot/efi die EFI-Partition zugänglich ist, funktioniert grub-install ohne weitere Parameter.
Microcode-Updates: Bei einer Installation auf echter Hardware sollten Sie entweder jetzt oder später, sobald das Grundsystem läuft, automatische Microcode-Updates für die CPU einrichten. Die Vorgehensweise ist natürlich im Arch-Wiki beschrieben.
Der erste Bootprozess
Damit ist es an der Zeit, einen erster Versuch zu machen, ob sich das frisch installierte starten lässt. (Haben Sie daran gedacht, das root-Passwort einzustellen?)
Dazu verlassen Sie die chroot-Umgebung mit Strg+D oder exit und führen reboot aus. Vergessen Sie nicht, bei virtuellen Maschinen die CD/DVD »auszuwerfen« (also das mit dem Laufwerk verbundene ISO-Image zu entfernen).
Wenn alles gut geht, erfolgt der erste Bootprozess verblüffend schnell: Knapp zwei Sekunden nach dem Verschwinden des GRUB-Menüs erwartet das System auch schon Ihren Login. Die Geschwindigkeit hat damit zu tun, dass das System noch komplett leer ist. Nicht einmal eine Netzwerkverbindung wird hergestellt.
Reparaturarbeiten
Wenn sich das frisch installierte Arch-Linux-System nicht starten lässt, müssen Sie die Installation nicht gleich komplett neu starten. Sie können auch versuchen, nochmals das Live-System des Installations-Images zu starten und dort Reparaturarbeiten durchzuführen. Im Wesentlichen stellen Sie zuerst das gewünschte Tastaturlayout ein, führen dann die für Ihr System passenden mount-Kommandos durch, wechseln mit arch-chroot in das unvollständig konfigurierte Zielsystem. Im einfachsten Fall genügen die folgenden Kommandos:
loadkeys de-latin1
mount /dev/vda1 /mnt
arch-chroot /mnt
Jetzt können Sie fehlende Pakete installieren, die GRUB-Installation wiederholen, das root-Passwort (neu) einstellen usw.
Weitere Konfigurationsarbeiten
Sie haben es sich vermutlich schon gedacht: Nun ist es Zeit für weitere Konfigurationsarbeiten.
Netzwerk aktivieren: Der erste Schritt ist natürlich die Herstellung einer Netzwerkverbindung, wobei ich weiterhin davon ausgehe, dass diese über ein Ethernet-Kabel erfolgt. In diesem Fall ist die Aktivierung des Netzwerks denkbar einfach:
systemctl enable --now NetworkManager
Dieses Kommando aktiviert den NetworkManager dauerhaft. Ein, zwei Sekunden später sollte Ihr Arch-Linux-System mit den lokalen Netzwerk und dem Internet verbunden sein. (Testen Sie dies z.B. mit ping google.de.)
Eine WLAN-Verbindung können Sie bei Bedarf mit nmtui einrichten. Alternativ warten Sie darauf, bis Sie eine Desktop-Umgebung (z.B. Gnome) installiert haben — dann stehen komfortablere Werkzeuge zur Verfügung.
SSH-Server: Damit Sie sich von außen bei Arch Linux anmelden können, brauchen Sie einen SSH-Server. Der lässt sich rasch installieren und aktivieren:
pacman -S openssh
systemctl enable --now sshd
Standardmäßig ist ein SSH-Login nur mit Key-Authentifizierung erlaubt. Wenn Sie auch einen gewöhnlichen Login akzeptieren wollen (was zumindest anfangs zweckmäßig ist), entfernen Sie in /etc/ssh/sshd_config vor der schon vorhandenen Zeile PasswordAuthentication yes das Kommentarzeichen #. Soll sich auch root direkt anmelden dürfen, bauen Sie außerdem PermitRootLogin yes in die Datei ein. Damit die Änderung wirksam wird, führen Sie systemctl reload sshd aus.
Benutzer mit sudo-Rechten: Als Nächstes sollten Sie einen zweiten Benutzer mit sudo-Rechten einrichten. Dazu führen Sie die folgenden Kommandos aus, wobei Sie kofler durch den gewünschten Benutzernamen ersetzen. Das usermod-Kommando fügt kofler zur wheel-Gruppe hinzu.
Mit einem Editor müssen Sie nun in /etc/sudoers eine Zeile auskommentieren, damit alle wheel-Mitglieder sudo-Rechte erhalten:
export EDITOR=/usr/bin/nano
visudo
# Datei /etc/sudoers
# Kommentarzeichen bei der folgenden Zeile entfernen
%wheel ALL=(ALL) ALL
Gnome installieren
Sofern Sie keine Server-Installation geplant haben, sehnen Sie sich vermutlich inzwischen schon nach einer Desktop-Umgebung. Die nächsten Kommandos installieren und aktivieren das Grafiksystem samt Gnome. pacman zeigt einige Fragen an, welche optionalen Pakete es installieren soll bzw. welche Varianten von Paketen es berücksichtigen soll. Sie machen nichts verkehrt, wenn Sie sämtliche Rückfragen mit Return bestätigen. (Ein kompakteres System erhalten Sie, wenn Sie nur die wirklich erforderlichen Zusatzpakete installieren, indem Sie deren Nummern ohne Kommas aufzählen. Dabei besteht aber die Gefahr, dass Sie ein essenzielles Paket übersehen.)
pacman -S xorg gnome
systemctl enable --now gdm
Sobald Gnome läuft, können Sie in dessen Systemeinstellungen die gewünschte Sprache (Modul Region & Language) und das Tastaturlayout neuerlich einstellen — diesmal für Gnome.
Arch Linux mit Gnome 40, ausgeführt in einer virtuellen Maschine (virt-manager + KVM)
Auf einem Notebook ist jetzt der ideale Zeitpunkt, um über das Systemmenü bzw. in den Systemeinstellungen die WLAN-Konfiguration zu starten.
Software-Verwaltung
Anstelle von apt, dnf, yum oder zypper gibt es bei Arch Linux pacman. Das wichtigste Kommando haben Sie schon kennengelernt: pacman -S <name> installiert das angegebene Paket. (Die Option -S steht übrigens für synchronize. Wenn das Paket bereits installiert ist, wird es neu installiert. Das können Sie mit der Option --needed verhindern.) Die folgende Aufzählung nennt ein paar weitere Kommandos, die Sie oft brauchen:
pacman -y liest die Paketquellen neu ein.
pacman -Sy <name> aktualisiert zuerst die Paketquellen und installiert dann das gewünschte Paket.
pacman -Syu aktualisiert zuerst die Paketquellen und dann sämtliche installierten Pakete, führt also ein Komplett-Update durch. Beachten Sie, dass Arch Linux das Running Release-Modell realisiert. Sie erhalten also jederzeit die neueste, von den Arch-Entwicklern als ausreichend stabil betrachtete Version.
pacman -R <name> entfernt das installierte Paket.
pacman -Q listet alle installierten Pakete auf (query).
pacman -Ql <name> listet die Dateien des angegebenen Pakets auf.
pacman -Qo <filename> zeigt an, welches Paket die angegebene Datei zur Verfügung stellt.
pacman -Ss <pattern> sucht Pakete, die dem Suchbegriff entsprechen.
Noch mehr Informationen gibt’s wie immer im Arch Wiki.
Sofern Sie bei der Installation von Gnome nicht explizit darauf verzichtet haben, wurde auch Gnome Software installiert. Dieses Programm ist aber nicht pacman-kompatibel und daher funktionslos. (Generell bin ich der Meinung, dass dieses Programm unter der Würde jedes Arch-Linux-Nutzers ist.) Entfernen Sie es mit pacman -R gnome-software.)
Die Paketauswahl für Arch Linux ist groß, aber kleiner als z.B. bei Debian oder Ubuntu. Dafür gibt es unzählige von der Community verwaltete Installations-Scripts im Arch User Repository. Ein Beispiel für den Umgang mit AUR-Paketen folgt gleich.
Webbrowser
Standardmäßig ist unter Gnome der Webbrowser Web (Paketname epiphany). Firefox ist in der Regel eine bessere Wahl. Entfernen Sie also das eine Paket, installieren Sie das andere samt der deutschen Lokalisierung:
Statt Firefox können Sie mit pacman -S chromium auch Chromium installieren. Etwas komplizierter wird die Sache, wenn Sie Google Chrome verwenden wollen. Dafür gibt es kein fertiges binäres Paket, sondern ein Installation-Script im Arch User Repository (AUR). Bevor Sie AUR-Scripte installieren, sollten Sie sich einen AUR-Helper einrichten, also ein Kommando, das Sie bei der Verwaltung von AUR-Paketen unterstützt.
Die folgenden Kommando sind mit User-Rechten auszuführen (nicht als root). Damit installieren Sie zuerst ein paar Entwickler-Tools und laden das AUR-Script für yay herunter. mkpkg lädt dann den weiteren Code herunter, kompiliert das Tool zu einem Paket und installiert dieses. Beim letzten Schritt werden Sie nach Ihrem Passwort gefragt (für sudo). mkpkg weigert sich aber, gleich mit root-Rechten ausgeführt zu werden.
Kurzer Tipp: in der Linux-Welt ist häufig, wenn es um Zeitangaben geht, die sog. Unixzeit anzutreffen. Hierbei werden die Sekunden nach dem 01.01.1970 00:00 Uhr UTC angegeben. So kann einfach eine Datumsangabe abgespeichert werden und anschließend mit den richtigen Methoden wieder umgerechnet werden. Möchte man den aktuellen Zeitstempel im Terminal anzeigen, kann man folgenden Aufruf nutzen:
date +%s
Nicht intuitiv zu finden, aber doch effektiv. So muss man nicht den Umweg über Webseiten oder eigens dafür entwickelte Programme gehen.
Seit etwas über einem Jahr besitze ich ein „Acer Swift 3„-Notebook mit einer Ryzen 4500U-CPU. Die erste Handlung direkt nach der Anschaffung war das Löschen von Windows 10 und die Installation von Ubuntu 20.04.
Leider habe ich es bis heute nicht geschafft den S2RAM-Modus zuverlässig zum Laufen zu bringen. Zuverlässig heißt, dass das Notebook bei jedem Zuklappen des Deckels einschläft und bei jedem Aufklappen wieder aufwacht. Das liegt vor allem daran, dass die meisten Ryzen-Notebooks (Inkl. meinem) nur den sogenannten „Modern Standby“ (Kurz „s0ix“) unterstützen und nicht den „klassischen“ S3-Modus. Normalerweise half in der Vergangenheit (z.B. bei meinem alten Lenovo T460) ein Kernel-Update auf die neueste Version, nur hier eben leider nicht, da die Kernelentwickler hier noch massiv am Nacharbeiten sind. Ich warte also seit einem Jahr darauf, dass eine Grundfunktionalität eines modernen Notebooks endlich fehlerfrei funktioniert.
Und eventuellen Fragen vorzugreifen:
Ja, ich habe auch andere Distributionen ausprobiert, wie z.B. Fedora 34. Gebracht hat es aber nichts.
Ein paar Hersteller (z.B. Lenovo) bieten in den BIOS-Einstellungen ihrer Ryzen-Notebooks an den Suspendmodus auf S3 zu wechseln, aber leider gibt es diese Option bei meinem Swift-Notebook nicht. Es gibt zwar eine Anleitung wie man die ACPI-Tabelle des Notebooks so patchen kann, dass der S3-Modus unterstützt wird, das funktioniert aber mehr schlecht als recht:
Man sollte maximal Linux 5.10.x einsetzen, da neuere Kernelversionen bei Ryzen-CPUs auf „s0ix“ ausgelegt sind. Alle Optimierungen die Linux danach für Ryzen-CPUs erhalten hat, bleiben dabei außen vor.
Trotz S3-Modus wacht das Notebook nicht zuverlässig aus dem Tiefschlaf auf. Je nach Lust und Laune kann es ein paar Mal gut gehen oder auch sofort abstürzen. Das ist insofern problematisch, da LUKS es einem sehr übel nehmen kann, wenn das System einfach mal abstürzt. Bei der ersten Installation von Ubuntu 20.04 hat die Installation nur bis zum ersten Suspend-Versuch überlebt. Danach war das Dateisystem irreparabel beschädigt.
Ich habe diesen Zustand jetzt knapp ein Jahr ertragen. Ich habe mir sogar die Mühe gemacht ein Kernel-Image aus gepatchten Quellen zu kompilieren (Siehe hier), aber nichts hat geholfen.
Aus diesem Grund habe ich heute Tabula rasa gemacht, Ubuntu von der Platte geworfen und Windows 10 installiert. Wahrscheinlich wird das Problem irgendwann mit einer neuen Kernelversion verschwinden, aber ich bin jetzt in einem Alter, in dem ich auf langwierige Basteleien keine große Lust mehr habe. Dazu ist mir meine Freitzeit zu kostbar geworden.
Ich finde das persönlich sehr schade, da ich seit ca. 20 Jahren Linux als mein primäres System einsetze (Seit Oktober 2004 primär Ubuntu) und in den letzten Jahren kaum noch Probleme mit Notebooks unter Linux hatte. Mein altes Thinkpad T460 (Das letztes Jahr in den Fundus meines Arbeitgebers gewandert ist und mir dort als Surf-Notebook dient) läuft seit Jahren 100% zuverlässig, ebenso das Acer-Notebook meiner Frau mit einer Ryzen 3700U-CPU. Beruflich arbeite und entwickle ich nur unter Linux und selbst die neuesten Tiger-Lake-Notebooks laufen dort vollkommen problemlos unter Linux. Gerade deshalb wurmt mich dieser Zustand auch besonders.
Aktuell spiele ich mit dem Gedanken das Swift-Notebook zu verkaufen und mir ein neues Linux-kompatibleres Notebook zuzulegen. Die Frage die sich mir stellt ist aber dabei folgende:
Ist mir das Betriebssystem meines Notebooks so wichtig, dass ich bereit wäre mindestens 800€ für ein gutes, leichtes Notebook auszugeben? Soviel würde nämlich die Tiger-Lake-Variante des Swift 3 kosten. Oder lebe ich einfach mit Windows 10 und arrangiere mich damit? Dadurch dass sich meine Anforderungen an ein Notebook in den letzten zwei Jahren massiv gewandelt haben, könnte ich prinzipiell mit Windows leben.
Android und Custom ROMs sind eine Welt für sich. Selbst erfahrene Linux-Anwender verlieren sich da gerne mal im Dschungel der Begriffe, Plattformen und Entwicklungen. Dieser Artikel stellt alle relevanten Informationen zusammen.
System & Basis
AOSP
Mit AOSP bezeichnet die Community das Android Open Source Project. Google entwickelt Android nach dem Open Core Prinzip – so wie es auch Chrome oder ChromeOS konzipiert. Um einen quelloffenen Kern legt Google viel proprietäre (also geschlossene) Google-Software und Google-Dienste. Das machen auch andere Konzerne so. Apples macOS basiert beispielsweise auf einem freien Unix-Kern, genannt Darwin.
Das besondere an AOSP ist, dass dieser freie Kern so komplett ist, dass er ohne die proprietären Erweiterungen läuft bzw. diese durch quelloffene Pendants ersetzt werden können.
Stock ROM
Im Gegensatz zu AOSP steht die Stock ROM. Darunter versteht die Community die Android-Version des Herstellers, so wie sie beim Kauf des Gerätes vorinstalliert war. Das kann eine sehr minimalistische Variante sein, die sich oberflächlich kaum von AOSP unterscheidet oder mit vielen Veränderungen und einer eigenen Oberfläche versehen sein.
Kernel & Firmware
AOSP läuft allerdings nicht „einfach so“ auf jedem Smartphone, weil die Hardware von Smartphones und Tablets nicht so normiert ist wie z. B. die Hardware von Desktop-PCs oder Notebooks. Mit einem normalen Linux-Kernel bekommt man kein Smartphone zum Laufen. Google versucht hier seit Jahren Verbesserungen zu erzielen, aber wirkliche Fortschritte gab es da bisher nicht.
Um das System lauffähig zu bekommen, benötigt man also den Kernel der Stock ROM und die so genannte Firmware. Dazu gehören Sachen wie Modem, Bootloader oder WiFi-Schnittstelle. Dabei handelt es sich um binäre Dateien, sogenannte „Blobs“, die direkt vom Hersteller bereitgestellt werden und nicht quelloffen sind.
Updates für Kernel und Firmware gibt es so lange wie der Hersteller für sein Stock ROM verteilt. Die Firmware kann bei Custom ROMs nicht über OTA-Updates verteilt werden, sondern muss vom Anwender manuell aktualisiert werden. Die Verfahren dazu unterscheiden sich je nach Hersteller.
Stellt der Hersteller den Support ein, gibt es keine Updates mehr für die Firmware und den Kernel. Meistens können auch danach noch neuere AOSP-Varianten auf altem Kernel ausgerollt werden, aber diese haben dann natürlich Sicherheitsprobleme.
Recovery
Mit Recovery bezeichnet man das Wiederherstellungssystem des Gerätes. Die Hersteller liefern meist eine funktional sehr eingeschränkte Variante aus. Einer der ersten Schritte auf dem Weg zu einem Custom ROM besteht daher aus dem Austauschen des Stock Recovery durch ein Custom Recovery. Am weitesten verbreitet sind hier TWRP und LineageOS-Recovery.
Rooten
Normale Smartphones lassen den Anwender nur mit eingeschränkten Benutzerrechten arbeiten. Im Gegensatz zum Desktop-Betriebssystem sind keine Administratorrechte (Root) für Anwender vorgesehen. Früher war Custom ROM und rooten gleichbedeutend und es wird heute noch fälschlicherweise von vielen als Synonym benutzt.
Aktuelle Custom ROMs bieten in der Regel keine Root-Rechte und das ist auch gut so, weil Root-Rechte das Gerät unsicherer machen.
Ein offenen Bootloader und eine Custom Recovery bieten aber grundsätzlich die Möglichkeit, ein Gerät zu rooten. Das kann man allerdings sowohl mit der Stock ROM als auch mit einer Custom ROM machen. Das Werkzeug hört auf den Name Magisk.
OTA
OTA bezeichnet Updates Over The Air. Damit gemeint sind Updates, die über ein integriertes Tool ausgeführt werden können, ohne das Gerät mit einem Notebook oder Desktop-PC zu verbinden oder das Update manuell über das Recovery Tool einzuspielen. Die meisten Custom ROMs bieten heute solche Update-Routinen.
Community & Projekte
LineageOS
Theoretisch kann jeder aus Recovery, AOSP und Firmware seine eigene Custom ROM erzeugen. Praktisch ist das in den letzten Jahren immer komplexer geworden und heutige Custom ROMs bestehen aus einer abgestimmten Komposition vieler Komponenten. Deshalb gibt es nur noch wenige große Projekte, die Custom ROMs entwickelt.
Das größte, älteste und wichtigste Projekt ist LineageOS, das auf CyanogenMod zurückgeht. LineageOS bildet die Basis für viele weitere Custom ROMs. Es gibt heute nur noch sehr wenige ROMs, die direkt auf AOSP aufsetzen, die meisten basieren auf LineageOS.
Damit ein Gerät auf LineageOS offiziell zur Verfügung steht, muss ein Maintainer dafür Verantwortung übernehmen. In den letzten Jahren wurde das mehr und mehr zu einem Problem, weshalb die Zahl der offiziell unterstützten Geräte kontinuierlich rückläufig ist.
GrapheneOS / CalyxOS
GrapheneOS und CalyxOS sind die zwei wichtigsten ROMs neben LineageOS. Während LineageOS eine Basis für möglichst viele Geräte bieten möchte, streben die Entwickler dieser beiden Alternativen möglichst sichere ROMs an. Die beiden ROMs werden fast ausschließlich für Google-Hardware der Pixel-Serie angeboten.
XDA Developers
XDA Developers ist die wichtigste Plattform, über die sich die Android-Community organisiert. Im Forum gibt es einzelne Unterforen für jedes auf dem Markt verfügbare Gerät. In diesen Unterforen werden Themen zur Stock ROM und Custom ROMS diskutiert.
Wenn man wissen möchte, wie verbreitet ein Gerät in der Community ist und die Unterstützung dafür abschätzen möchte, lohnt sich ein Blick in die entsprechenden Foren bei XDA.
In den Foren finden sich inoffizielle Portierungen von Custom ROMs für einzelne Geräte und Modifikationen von Stock ROMs und Custom ROMs. Das Angebot kann je nach Gerät erheblich variieren. Es ist eine kleine Community, meist bieten 3-5 Contributors pro Gerät ihre ROMs an.
Die meisten der auf XDA angebotenen ROMs sind Portierungen von LineageOS auf die jeweilige Hardware. Manchmal ist ein solcher Port auf XDA die Vorstufe zu einer offiziellen Variante, meistens bleibt es jedoch bei dem inoffiziellen Status, weil die Contributors nicht formell die Verantwortung für das Gerät übernehmen möchten.
Ob die Patches und Änderungen an LineageOS zurückgereicht werden, hängt vom einzelnen Contributor ab. Manche schätzen und pflegen die Gepflogenheiten von Open Source, andere werkeln lieber im Hinterzimmer.
Ich hoffe diese kleine Übersicht hilft bei der Orientierung im Custom ROM-Universum. Wenn irgendwas nicht verständlich ist oder ich etwas vergessen habe, schreibt gerne ein Kommentar, dann überarbeitete ich den Artikel.
Kurz notiert: wer eine AMD GPU mit VEGA-Technologie nutzt, wird wenig Freude mit Linux 5.12.13 haben. Nach dem Kernelupdate fiel mir auf, dass der GPU-Lüfter durchgängig lief und sensors einen durchgängig hohen Stromverbrauch, auch bei abgeschaltetem Display Manager, angab. Komischerweise war der Google-Vorschlag bei "linux 5.12.13" auch sofort "gpu usage". Ein kurzer Blick ins 5.12.13 shortlog zeigt, dass es tatsächlich Änderungen an den amdgpu-Treibern gab.
Bis jetzt, denn dafür gibt es ein schönes, praktisches Helferlein in Form einer Gnome shell extension.
