staging.inyokaproject.org

27. Mai 2022

Kontact bzw. der Akonadi-Unterbau sind so ein Thema für sich. Ein Paradebeispiel für Overengineering aber bei KDE hält man stoisch daran fest. Wer also einen konsistenten KDE-Arbeitsplatz haben möchte, kommt nicht daran vorbei. Leider sind die Abhängigkeiten bei Kubuntu 22.04 schlecht gesetzt. Eine Alternative mit PostgreSQL steht aber bereit.

Viele Fehlentscheidungen aus den frühen KDE 4-Zeiten haben die KDE-Entwickler inzwischen korrigiert – Akonadi leider nicht. Die längere Zeit in Entwicklung befindliche Alternative Kube ist eingeschlafen und auch neue Apps wie Kalendar basieren im Hintergrund leider weiter auf Akonadi. Viele grobe Bugs sind ausgeräumt, aber das vollkommen überdimensionierte Backend ist immer noch ein Garant für Probleme und Schwierigkeiten. Warum es für die Speicherung von Mails und PIM-Einträge so ein gewaltiges Backend braucht, wo doch Thunderbird und Evolution ohne auskommen, konnte nie jemand stimmig erklären. Wie so oft gilt hier vermutlich Entwicklerspaß vor Nutzerinteressen.

KDE-Anwender müssen also leider weiter mit Akonadi leben. Die Kubuntu-Entwickler haben als seit 20.04 als Standard Thunderbird vorgesehen (was schon ein Statement für sich ist), aber Kontact & Co natürlich weiter in den Paketquellen. Leider nicht besonders durchdacht. Das Paket akonadi-backend-mysql verweist nämlich auf MariaDB. Ich vermute, das hat man einfach von Debian übernommen. Leider setzt Canonical im Gegensatz zu vielen anderen Distributoren nicht auf MariaDB, sondern hält MySQL die Treue. MariaDB ist nur in Universe enthalten und hat somit einen nicht garantierten Sicherheitsstatus.

Die Derivate bzw. Universe und Sicherheit sind ein Thema für sich, das hier nicht im Detail diskutiert werden kann. Grundsätzlich ist nicht jede Software sicherheitskritisch und zumindest beim KDE-Stack verfolge ich das Thema engmaschig genug, um prüfen zu können, ob Kubuntu hier Probleme behebt. Die Basis (macht bei Installation hier circa 1200 von 1900 Paketen aus) wird ja direkt von Canonical gepflegt. Bei Software wie MariaDB hört aber bei mir die Toleranz auf, wenn es um nicht geschlossene Sicherheitslücken geht.

Zum Glück gibt es noch ein weiteres Akonadi-Backend und zwar das für PostgreSQL. Das ist nicht schlecht gepflegt, da einer der Kern-Entwickler von Kontact viele Jahre selbst PostgreSQL als Backend nutzte. Entwickler beheben Bugs ja auch gerne für sich selbst – warum also nicht davon profitieren? Der Vorteil für Kubuntu-Nutzer ist, dass PostgreSQL in main liegt und direkt von Canonical unterstützt wird.

Vorher unbedingt ein Backup machen. Das Szenario geht davon aus, dass E-Mails und PIM-Daten lediglich via IMAP und Cal-/CardDAV eingebunden sind und somit nicht verloren gehen können.

Der Umstieg ist ziemlich leicht. Zuerst Akonadi stoppen und das neue Backend installieren:

$ akonadictl stop
$ sudo apt install akonadi-backend-postgresql

Anschließend noch die Benutzerkonfiguration in der Datei ~/.config/akonadi/akonadiserverrc ändern:

[%General]
Driver=QPSQL

[QPSQL]
Host=/tmp/akonadi-<benutzername>.hash
InitDbPath=/usr/lib/postgresql/14/bin/initdb
Name=akonadi
Options=
ServerPath=/usr/lib/postgresql/14/bin/pg_ctl
StartServer=true

Nun noch die alte MariaDB-Daten löschen, indem man das Verzeichnis ~/.local/share/akonadi/db_data umbenennt in z. B. db_data_bak. Sollte die Migration erfolgreich sein, kann es später gelöscht werden.

Nun noch Akonadi wieder starten und prüfen. Sollte es Probleme geben, wird hier auch aufgelistet, wo es klemmt.

$ akonadictl start
$ akonadictl fsck

Nun läuft Akonadi mit einem offiziell supporteten Backend. Negative Erfahrungen für Stabilität und Performance kann ich nicht berichten.

openSUSE lässt sich traditionell am Ende der Entwicklungs-Roadmap viel Zeit. Am 27. April erschien die RC-Version, einen Monat später erfolgte heute der Gold-Master-Build. Früher liefen dann die CD-Pressen an. Heute wartet man noch ein wenig bevor in zwei Wochen die Version final freigegeben wird. Höchste Zeit für einen tiefen Blick in die neue Version.

Diese Version ist im Wesentlichen eine Fortentwicklung der früheren Versionen der Leap 15-Serie:

Umstürzende Änderungen sind bei den Minor-Versionen einer Hauptserie nicht geplant. Ein umfassender Test entfällt daher, genau wie bei den Vorversionen auch schon. Stattdessen möchte ich ein wenig auf das Leap-Entwicklungsmodell eingehen, das immer noch bei vielen für Verwirrung sorgt, weil es nicht der von Debian geprägten „Standardnorm“ für LTS-Distributionen entspricht.

Das Leap-Entwicklungsmodell

Die neue Version ist die jüngste Inkarnation der 15er-Serie von openSUSE Leap. Diese ist höchstwahrscheinlich die letzte traditionelle Linux-Distribution aus dem Hause SUSE/openSUSE, bevor man mit Version 16 in zwei Jahren auf die neue SUSE Adaptable Linux Platform wechselt. Die 15er Version folgt einem Wechselsystem. Auf eine sehr zurückhaltende Version – das war die letzte Version 15.3 – folgt eine Version mit mehr Aktualisierungen.

Um ein etwas schiefes Bild zu benutzen: Durch den Entwicklungsprozess von openSUSE gleicht die neue Version einem Menschen im fortgeschrittenen Lebensalter, dem man ein paar Organe erneuert und die Gesichtshaut ordentlich hinter die Ohren gezogen hat. Optisch ganz gut anzusehen und sollte noch eine Weile laufen, aber im Kern eben doch schon ein paar Jahre alt.

Der Hintergrund ist, dass jede openSUSE Leap Version sich an den Service Packs von SLE orientiert und eine Weiterentwicklung der Hauptversion darstellt. Ein solcher Zyklus kann durchaus mehrere Jahre gehen. Leap 15.0 erschien 2018, seitdem entwickelt man auf dieser Basis weiter. Die Anwender müssen dabei immer auf die neueste Minor-Version aktualisieren, um weiterhin Sicherheitsaktualisierungen zu erhalten. Das ähnlich ähnlich wie bei Red Hat, aber anders als bei z. B. Debian oder Ubuntu, wo alle zwei Jahre eine neue LTS zusammen gebaut wird, die dann 3-5 Jahre eingefroren wird und keine substanziellen Änderungen mehr erfährt.

Im Gegensatz zu den Debian-Entwicklern glaubt man bei SUSE (und mit Abstrichen auch Red Hat) diese Versionsaktualisierungen hinreichend gut testen zu können. Dahinter steht die Überzeugung, dass eine vorsichtige Aktualisierung unterm Strich mehr bringt als eine Bugsammlung über Jahre einzufrieren. Gleichzeitig sind einschneidende Änderungen neuen Hauptversionen vorbehalten. So ist bei Leap 15.4 der usr-merge ebenso noch nicht erfolgt, wie die weitere Einbeziehung von systemd-Diensten anstelle z. B. von chrony oder cronie. Den Wechsel auf Plasma 6 würde man – so er denn irgendwann mal kommt – sicherlich auch nicht in einer Minorversion vollziehen, den Sprung von 5.18 auf 5.24 aber eben schon.

Schaut man tiefer in die Paketquellen, sieht man, dass viele Pakete direkt von SUSE aus SLE kommen (Versionen enden auf 150400). Andere Pakete stammen von openSUSE (Versionen enden auf lp154 oder bp154). Ebenso gibt es unterschiedliche Updatequellen für SLE- und openSUSE-Pakete. Diese Feinheiten müssen Anwender aber eigentlich nicht interessieren.

Versionen

Das bedeutet konkret für die Versionen, dass die Desktopumgebungen von KDE Plasma 5.24 über GNOME 41 bis zu MATE 1.26 und Xfce 4.16 relativ aktuell sind und teils aktueller als bei komplett „neuen“ Distributionen wie dem vor zwei Monaten veröffentlichten Ubuntu 22.04.

Der Kernel ist mit 5.14 schon ein wenig abgehangener, ebenso systemd 249. Beides aber nicht dramatisch alt und vermutlich nur relevant für Anwender von sehr aktueller Hardware oder sehr neuen Funktionen in systemd.

Schaut man dann tief in den Kern, sind Sachen wie glibc in Version 2.31 oder auch PolKit 0.116 richtig alt. Standardmäßig kommt für den GNU C Compiler die Version 7.5 zum Einsatz, GCC 10 und GCC 11 in aber in den Paketquellen enthalten. Eingefleischte openSUSE-Anwender werden das kaum seltsam finden, aber für Außenstehende wirkt das etwas seltsam. Unerwünschte Nebenwirkungen sind in meinen Tests aber nicht aufgetreten.

Installation und Vorkonfiguration

Installation und Vorkonfiguration wurden nicht verändert. Hier ist ein neuer Test also überflüssig. Als Standarddateisystem kommt Btrfs zum Einsatz, das mittels Snapper Betriebssystemschnappschüsse bei Updates anlegt. Datenpartitionen werden standardmäßig mit XFS angelegt, was bei einer dezidierten Home-Partition auch für diese zum Einsatz kommt.

Als Bootloader nimmt openSUSE GRUB 2.06. Man unterstützt Secure Boot und mittels Trusted Boot auch ein rudimentäres TPM-Measurement für den Boot-Prozess.

Die Verschlüsselung geschieht bei der Installation immer noch mit LUKS1 und das System benötigt weiterhin einen dezidierten root-Account. Neu ist die Möglichkeit bei der Installation SELinux anstelle von AppArmor aktivieren zu können. Die SELinux-Integration steckt bei SUSE aber noch in den Kinderschuhen und ich persönlich würde bei einem Produktivsystem davon absehen.

Nutzungserlebnis

Die Entwickler haben aus manchen vergangenen Fehlern gelernt. Die SLE-Updatequellen sind so schon seit längerem eingebunden. Allerdings ist der Entwicklungsprozess immer noch etwas schwierig und die Kommunikation zwischen SLE-Teams und openSUSE klappt manchmal nicht. Das hatte in der RC-Phase durch plötzliche massive Änderungen bei SLE SP4 einige Verzögerungen ausgelöst. Trotzdem halte ich unliebsame Überraschungen direkt nach dem Release dieses Jahr für nahezu ausgeschlossen.

Im täglichen Nutzungserlebnis profitiert man von der gut abgehangenen Basis, die lediglich an relevanten Stellen wie Kernel oder Mesa behutsam modernisiert wurde und den gleichzeitig aktuellen Desktopanwendungen. Da es hier bei den Desktopumgebungen quasi von KDE Plasma bis MATE und bei den Anwendungen von LibreOffice bis Firefox in den letzten Jahren keine umstürzenden Änderungen gab, sind diese aktuell sehr ausgereift und es entsteht eine wirklich gelungene Gesamtkomposition.

Fazit

Ein rundum gelungenes Release. Bestehende Anwender von openSUSE Leap können gefahrlos und mit Vorfreude aktualisieren. Ob Wechselwillige die Version zum Anlass nehmen umzusteigen, steht auf einem anderen Blatt. Nächstes Jahr kommt planmäßig dann noch mal eine deutlich moderatere Wartungsversion, bevor 2024 dann vermutlich revolutionäre Änderungen anstehen.

Leider haben die Entwickler nicht alle notwendigen Änderungen für systemd-homed zurück portiert, weshalb ich wohl bei Tumbleweed bleibe, da ich mich sehr an die TPM-Entsperrung mit zusätzlich abgesicherten Nutzerprofilen gewöhnt habe.

26. Mai 2022

Mozilla rollt aktuell den sogenannten vollständigen Cookie-Schutz für alle Firefox-Nutzer aus und verbessert damit den Datenschutz seiner Nutzer.

Derzeit erhalten einige Nutzer von Firefox 91 und höher nach dem Start von Firefox einen Dialog mit der Option, die „leistungsstärkste Datenschutzerfahrung aller Zeiten“ zu aktivieren. Was hat es damit auf sich?

Vollständiger Cookie-Schutz in Firefox

Vollständiger Cookie-Schutz – was ist das?

Im Februar 2021 hat Mozilla mit der Veröffentlichung von Firefox 86 den sogenannten „vollständigen Cookie-Schutz“ eingeführt. Vereinfacht gesagt bedeutet dies, dass die Cookies jeder Domain in einem separaten Cookie-Container gespeichert werden – seitenübergreifendes Tracking über Cookies soll damit erschwert werden.

Vollständiger Cookie-Schutz in Firefox 86

Mehr Datenschutz für alle Firefox-Nutzer

Aktiviert war diese Datenschutz-Verbesserung bisher nur für Nutzer, welche in den Datenschutz-Einstellungen von Firefox den strengen Schutz vor Aktivitätenverfolgung aktiviert haben, sowie in privaten Fenstern.

Mit dem Dialog, den einige Firefox-Nutzer aktuell angezeigt bekommen, lädt Mozilla seine Nutzer ein, diese Datenschutz-Verbesserung auch in der Standard-Konfiguration von Firefox zu aktivieren und vorab zu testen, ehe dies irgendwann in der Zukunft vermutlich Standard für alle Nutzer werden wird.

Übrigens lässt sich die Entscheidung jederzeit über die Datenschutz-Einstellungen ändern. Nutzer, welche diesen Dialog gesehen haben, erhalten in den Datenschutz-Einstellungen auch eine zusätzliche Checkbox, über welche das Feature aktiviert respektive deaktiviert werden kann.

Vollständiger Cookie-Schutz in Firefox

Der Beitrag Firefox: Mozilla rollt vollständigen Cookie-Schutz für alle Nutzer aus erschien zuerst auf soeren-hentzschel.at.

Eine kleine Lektüreempfehlung zum Feiertag. Andreas Proschofsky hat bei DerStandard eine sehr lesenswerte Erklärung der wichtigsten Linux-Begriffe verfasst. Sachlich korrekt, ausgewogen und ab und an mit einer kleinen Prise Humor.

Sicherlich nicht nur für Neulinge im Linux-Universum eine interessante Lektüre. Vom Kernel bis zu Wayland und Pipewire wird alles, was momentan so relevant ist ausführlich erklärt. Natürlich immer ein bisschen subjektiv, aber es ist auch kleine Enzyklopädie. Wer Wahrheiten sucht und andauernd „Fakten“ brüllt, sollte auch hier woanders weiter schauen. Mich hatte der Autor an diesem Punkt:

Bonus-Hinweis für Puristen: Genau genommen ist der Kernel nicht der zentrale Teil von Linux, er ist Linux. Über die Jahre hat sich aber eingebürgert, auch (viele) ihn umgebende Systeme als Ganzes so zu benennen. Wer gerne recht hat, darf diesen Umstand also unter jedem Artikel zu Linux als System als faktische Korrektur anmerken. Oder aber man verzichtet freiwillig darauf, sich bei allen anderen unbeliebt zu machen.

Kernel? Wayland? Pipewire? Die wichtigsten Linux-Begriffe, einfach erklärt

Viel Spaß beim lesen.

25. Mai 2022

Ich nutze rsync in Verbindung mit dem rsync-time-backup für einfache Backups eines Servers. In letzter Zeit erhielt ich dort ein Problem mit bestimmten Dateien, welche ich synchronisieren wollte. rsync brach hier mit der Meldung: ab. Abhilfe schaffte es hier rsync, ohne die Option –compress zu nutzen. Hier liegt wohl ein Problem bzw. ein Bug vor, der unter Umständen zu diesem Verhalten führt.

Quelle

24. Mai 2022

Passwörter sind eine unsichere Angelegenheit. Deshalb gab es in den vergangenen Jahren viele Versuche, Passwörter zu ersetzen oder sicherer zu machen. Einer dieser Versuche, ist der Ansatz mit einem physischen zweiten Faktor zu arbeiten. Dank systemd lässt sich das nun einfacher denn je für Linux Verschlüsselung nutzen.

Die Erkenntnis, dass Passwörter unsicher sind, gehört inzwischen zum Standardsatz, mit dem man jeden Artikel dazu einleiten muss. Firmen arbeiten deshalb mit biometrischen Verfahren und vielen anderen Ansätzen. Ich persönlich schätze meinen YubiKey sehr, aber leider unterstützen den noch viel zu wenige Dienste.

Dank der tollen Entwickler im systemd-Umfeld, die stetig daran arbeiten, neue Funktionen für Linux zur Verfügung zu stellen, kann man nun aber einen FIDO-Stick wie YubiKey (Alternativen wie Nitrokey gehen natürlich auch) sehr einfach nutzen, um vollständig mit LUKS verschlüsselte Linux-Systeme zu sichern. Das geht für Arch Linux und Debian schon länger, war aber ein ziemliches „gefrickel“ und ist ein tolles Beispiel dafür, wie systemd Sachen einfach besser umsetzt und auf solidere Füße stellt. Die Funktionsweise ähnelt der Entsperrung von LUKS-gesicherten Systemen mittels TPM.

Einrichtung

Im Folgenden zeige ich die Einrichtung unter openSUSE. Sie funktioniert für openSUSE Tumbleweed und Leap 15.4. Das Verfahren dürfte aber für jede Distribution funktionieren, die systemd nutzt und keine Sonderlocken verfolgt. Arch Linux hat sie kürzlich in archinstall integriert.

Die Voraussetzung ist aktuell ein Partitionslayout mit einem vollständig verschlüsselten LUKS-System (egal, ob Root-Partition und Home-Partition getrennt sind) und eine unverschlüsselte Boot-Partiton. Der LUKS-Container muss dem LUKS2-Standard folgen. Bestehende SUSE-Installationen müssen daher erst auf LUKS2 konvertiert werden. Neue Installationen können mit der Startoption YAST_LUKS2_AVAILABLE=1 direkt als LUKS2 angelegt werden.

Nach der Umsetzung der Anleitung benötigt man für jeden Systemstart den eingesteckten YubiKey. Es gibt keinen automatischen Fallback-Mechanismus.

Zuerst ist ein Paket nachzuinstallieren. Je nach Setup ist es möglicherweise schon installiert (z. B. als Abhängigkeit von KeePassXC).

# zypper install libfido2-1

Nun steckt man den YubiKey ein. Mit folgendem Befehl führt man die Integration des YubiKey als Schlüssel für LUKS aus.

# systemd-cryptenroll --fido2-device=auto /dev/<LUKS-DEVICE>

Das Laufwerk ist natürlich anzupassen. In der Regel muss man mit dem bisherigen LUKS-Passwort bestätigen. Der YubiKey wird dann in den nächsten freien Key-Slot geschrieben.

Anschließend ist noch die /etc/crypttab zu bearbeiten und fido2-device=auto am Ende zu ergänzen. Das Ergebnis sieht dann in etwa wie folgt aus:

cr-auto-1  /dev/<LUKS-Device>  none  x-initrd.attach,fido2-device=auto

Nun noch mittels dracut den initramfs neu erstellen.

# dracut -f

Bei einem Neustart wartet das System nun auf die Betätigung des YubiKey. Mangels Implementierung in Plymouth gibt es keinen grafischen Hinweis dazu auf dem Bildschirm, aber der YubiKey blinkt und zeigt dadurch an, dass eine Interaktion notwendig ist.

20. Mai 2022

Mozilla hat Firefox 100.0.2 veröffentlicht und behebt damit zwei kritische Sicherheitslücken, welche im Rahmen des Hacking-Wettbewerbs Pwn2Own gezeigt worden sind.

Download Mozilla Firefox 100.0.2

Firefox 100.0.2 behebt Sicherheitslücken

Wieder einmal fand ein Pwn2Own-Wettbewerb im Rahmen der CanSecWest Sicherheitskonferenz in Vancouver statt. Und wie bereits im Vorfeld erwartet, hat Mozilla in Form eines schnellen Updates auf die Firefox betreffenden Ergebnisse reagiert. Firefox 100.0.2 behebt zwei Sicherheitslücken, welche Mozilla beide als kritisch einstuft. Ebenfalls in diesem Zusammenhang veröffentlicht wurden Firefox ESR 91.9.1 sowie Firefox 100.3.0 für Android. Auch Thunderbird wurde in Version 91.9.1 veröffentlicht.

Der Beitrag Sicherheits-Update: Mozilla veröffentlicht Firefox 100.0.2 erschien zuerst auf soeren-hentzschel.at.

17. Mai 2022

Mozilla hat Version 2.8 seiner VPN-Clients für das Mozilla VPN veröffentlicht. Dieser Artikel beschreibt die Neuerungen vom Mozilla VPN 2.8.

Mit dem Mozilla VPN bietet Mozilla in Zusammenarbeit mit Mullvad sein eigenes Virtual Private Network an und verspricht neben einer sehr einfachen Bedienung eine durch das moderne und schlanke WireGuard-Protokoll schnelle Performance, Sicherheit sowie Privatsphäre: Weder werden Nutzungsdaten geloggt noch mit einer externen Analysefirma zusammengearbeitet, um Nutzungsprofile zu erstellen.

Jetzt Mozilla VPN nutzen

Die Neuerungen vom Mozilla VPN 2.8

Integrierter Geschwindigkeits-Test

Das Mozilla VPN beinhaltet jetzt einen integrierten Geschwindigkeits-Test. Dieser misst den Ping sowie die Download-Geschwindigkeit und gibt darauf basierend eine Empfehlung ab, ob die Verbindung geeignet für das Surfen im Internet, Streaming von Videos und Videokonferenzen ist.

Mozilla VPN 2.8

Sonstige Neuerungen

Eine neue Option in den Netzwerk-Einstellungen erlaubt das Tunneln durch Port 53/DNS, wodurch Firewalls besser umgangen werden können.

Die Authentifizierung auf Android und iOS wurde verbessert und findet nun vollständig innerhalb der App statt. Außerdem hat das Mozilla VPN auf den Smartphone-Plattformen eine neue Einführungstour mit animierten Illustrationen erhalten.

Dazu kommen wie immer diverse Fehlerbehebungen und Verbesserungen unter der Haube.

Der Beitrag Mozilla VPN 2.8 mit Geschwindigkeits-Test veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Di, 17. Mai 2022, Lioh Möller

Nach AlmaLinux ist nun auch der Freie Red Hat Enterprise Linux (RHEL) Clone Rocky Linux in Version 8.6 verfügbar. Da es sich bei den Projekten um einen Rebuild der kommerziellen Distribution aus dem Hause Red Hat handelt und lediglich Copyright-behaftete Elemente wie das Branding entfernt werden, entsprechen die Neuerungen denen des Upstream-Produktes.

PHP ist in Version 8.0 enthalten und Perl wird in Version 5.32 ausgeliefert. Edge-Nodes lassen sich mithilfe des FIDO onboarding (FDO) Standards integrieren.

Zur Auswahl stehen drei weitere Systemrollen, zur vereinfachten Systemkonfiguration:

  • High availability (HA) cluster system role
  • Enhanced network system role
  • WebConsole role

Rocky Linux stellt Abbilder für die Architekturen x86_64 und aarch64 zur Verfügung.

Quelle: https://rockylinux.org/news/rocky-linux-8-6-ga-release/
Download: https://rockylinux.org/download/

16. Mai 2022

Mozilla hat Firefox 100.0.1 veröffentlicht und bringt damit neben vielen Korrekturen auch eine verbesserte Prozess-Isolation für mehr Sicherheit unter Windows 10.

Download Mozilla Firefox 100.0.1

Mehr Sicherheit: Verbesserte Prozess-Isolation

Mit Firefox 100.0.1 liefert Mozilla eine verbesserte Prozess-Isolation aus, welche den Zugriff der Content-Prozesse auf die mächtige win32k.sys API unterbindet, die ein beliebtes Angriffsziel darstellt. Voraussetzung hierfür ist Windows 10 mit dem Fall Creators Update (1709) oder neuer. Nutzer einer älteren Version von Windows 10 sowie von Windows 8 werden erst mit einem zukünftigen Firefox-Update davon profitieren können. Für Nutzer von Windows 7 ist dieser Schutz technisch nicht möglich, da Microsoft die Voraussetzungen dafür erst mit Windows 8 eingeführt hat.

Dass Mozilla diese Verbesserung in einem Update außer der Reihe veröffentlicht und nicht auf Firefox 101 gewartet hat, überrascht insofern nicht, als dass in dieser Woche wieder der bekannte Pwn2Own-Wettbewerb stattfindet, in dem es darum geht, Sicherheitslücken unter anderem in Browsern aufzudecken, und sich Mozilla vom sogenannten Win32k Lockdown signifikante Vorteile für die Sicherheit verspricht.

Nutzer von macOS haben eine vergleichbare Verbesserung übrigens bereits mit Firefox 95 erhalten. Seit dem haben Content-Prozesse keinen Zugriff mehr auf den WindowServer von macOS. Und für Linux-Nutzer wird seit Firefox 99 der Zugriff auf das X Window System (X11) blockiert.

Fehlerbehebungen in Firefox 100.0.1

Ansonsten bringt Firefox 100.0.1 aber auch diverse Fehlerbehebungen für alle Plattformen, darunter mehrere Bugfixes für das Bild-im-Bild-Feature (PIP) für Videos. Die bereits für Firefox 100 angekündigte Untertitel-Funktion für PIP, deren Aktivierung Mozilla für die finale Version von Firefox 100 versäumt hatte, steht nun standardmäßig zur Verfügung. Zur Erinnerung: Auf Websites, welche den WebVTT-Standard unterstützen, sowie auf den populären Video- und Streaming-Plattformen YouTube, Amazon Prime Video und Netflix, welche stattdessen eine eigene Lösung verwenden, kann Firefox jetzt die Untertitel von Videos auch im Bild-im-Bild-Modus anzeigen.

Aus Gründen der Webkompatibilität wurden WebSockets über HTTP/2 deaktiviert, da die Implementierung in Firefox fehlerhaft ist und Probleme verursachen kann. Außerdem wurde der sogenannte User-Agent für ein paar weitere Websites mit mangelhaft implementiertem User-Agent-Sniffing temporär auf den von Firefox 99 geändert. Dies betrifft unter anderem die deutsche Commerzbank, wo kein Login in den Bank-Account möglich war, nur weil die Versionsnummer von Firefox dreistellig wurde.

Des Weiteren wurde ein Fehler behoben, der verursachte, dass Lesezeichen ohne Titel nicht mehr synchronisiert worden sind.

Darüber hinaus gab es Fehlerbehebungen für die mit Firefox 100 eingeführte Unterstützung von HDR-Videos auf macOS sowie für mehrere durch Drittanbieter-Sicherheitssoftwares verursachte Absturzursachen.

Dazu kamen noch diverse Korrekturen für die bevorstehende Ausrollung des sogenannten vollständigen Cookies-Schutzes in der Standard-Konfiguration von Firefox. Diese mit Firefox 86 eingeführte Datenschutzverbesserung ist bisher nur bei Aktivierung des strengen Schutzes vor Aktivititätenverfolgung aktiv.

Der Beitrag Firefox 100.0.1 bringt verbesserte Prozess-Isolation und Bugfixes erschien zuerst auf soeren-hentzschel.at.

Mo, 16. Mai 2022, Lioh Möller

Freunde älterer Versionen von Mac OS haben mit Infinite Mac die Möglichkeit, das Betriebssystem vollständig im Browser zu emulieren. Zur Verfügung stehen Varianten mit System 7, Mac OS 8 und dem japanischen Pendant KanjiTalk.

Die Lösung basiert auf dem Emulator Basilisk II, einem Freien Emulator für Macintosh-Rechner auf Basis der Motorola-68000er-Familie. Der Quellcode des Projektes ist öffentlich zugänglich und ein Betrieb auf der eigenen Infrastruktur ist ebenfalls möglich. Über einen Ordner namens The Outside World lassen sich Dateien mit dem Host-Betriebssystem austauschen.

In einem ausführlichen englischsprachigen Blogpost beschreibt der Entwickler Mihai Parparita den Aufbau und die Funktionsweise von Infinite Mac.

Quelle: https://blog.persistent.info/2022/03/blog-post.html

14. Mai 2022

Eigentlich hätte die RC schon draußen sein sollen – ist sie aber nicht. Bei weiteren Verzögerungen gerät das Releasedatum für openSUSE Leap 15.4 in Gefahr. Auch nach einem Jahr scheint „Closing the gap“ und die direkte Zusammenarbeit mit SUSE nicht ganz harmonisch zu laufen.

Lubos Kocman äußerte sich gestern auf der Mailingliste zu den aktuellen Problemen. Die Entwicklung von Leap 15.4 hängt direkt an der Entwicklung des Service Pack 4 für SUSE Linux Enterprise 15. Hier gab es unerwartet heftige Entwicklungstätigkeiten inklusive eines umfassenden Rebuilds aller Pakete. Letzteres ist bei SUSE und openSUSE nicht so selten ist, weil man im Gegensatz zu Amateur-Distributionen mit OBS eine umfassende Build-Infrastruktur hat. Ungewöhnlich ist aber der Zeitpunkt.

Die kommende Version openSUSE Leap 15.4 erreicht mit einiger Verzögerung nun kommende Woche voraussichtlich den RC-Status. Darauf folgt in guter alter SUSE-Tradition noch die Gold Master (GM). Die openSUSE-Entwickler müssen nun darauf warten, dass SLE SP4 den Gold Master-Status erreicht, damit sie ihrerseits den Gold Master-Status für openSUSE erklären können. Sollte sich dies noch weiter verzögern, gerät die komplette openSUSE-Roadmap für 15.4 in Verzug.

Richtig gefunden scheinen sich SUSE und openSUSE noch nicht. „Closing the gap“ ist ein weiterer Weg als gedacht.

13. Mai 2022

Fr, 13. Mai 2022, Lioh Möller

Aktuell findet im openSUSE Tumbleweed Projekt ein grösserer Wechsel auf die aktuelle GCC 12 Version statt. Dazu wurde ein vollständiger rebuild des Snapshots 20220510 erstellt.

Eine Aktualisierung findet, sobald dieser auf den Spiegelservern verfügbar ist, wie üblich mithilfe von zypper dup statt.

Quelle: https://news.opensuse.org/2022/05/13/gcc-12-is-coming/

12. Mai 2022

Die MZLA Technologies Corporation hat ihren Finanzbericht für Thunderbird für das Jahr 2021 veröffentlicht. Dieser gibt Einblick in die Entwicklung des Umsatzes sowie das Vermögen des Projektes.

Wie bereits in den vorherigen Jahren hat MZLA auch im Jahr 2021 die Einnahmen durch Spenden steigern können – von 2,3 Millionen USD im vorherigen Jahr auf nun knapp 2,8 Millionen USD. Dies ist dem Finanzbericht des Jahres 2021 zu entnehmen.

Die Spenden-Einnahmen entsprechen praktisch auch dem Gesamt-Umsatz der MZLA Technologies Corporation, einer 100-prozentigen Tochter der Mozilla Foundation. Denn Gewinne aus kommerziellen Partnerschaften machen nur den Bruchteil eines Prozentes aus. Bei den E-Mail-Anbietern Gandi sowie Mailfence handelt es sich derzeit um die einzigen kommerziellen Partner der MZLA Technologies Corporation. Weitere Einnahmequellen sollen in der Zukunft aber erschlossen werden.

Personalkosten bleiben der mit Abstand teuerste Posten und machen über 78 Prozent der Ausgaben aus. Insgesamt hatte MZLA Ausgaben in Höhe von fast zwei Millionen USD, verglichen mit etwas über 1,5 Millionen USD im Jahr 2020.

Das Gesamt-Vermögen der MZLA Technologies Corporation konnte von ca. 3 Millionen USD im Vorjahr auf über 3,6 Millionen USD gesteigert werden.

Derzeit beschäftigt die MZLA Technologies Corporation 18 Angestellte. Im Jahr 2020 waren es noch 15 Mitarbeiter. Mehrere zusätzliche Stellen sind derzeit ausgeschrieben.

Für die Zukunft hat MZLA große Pläne mit Thunderbird. Nach dem bevorstehenden Update im Sommer dieses Jahres, welches unter anderem ein neues Adressbuch bringen wird, soll Thunderbird im kommenden Jahr ein neues Design erhalten. Auch wird es Thunderbird erstmals für Android-Smartphones geben.

Der Beitrag MZLA veröffentlicht Finanzbericht 2021 für Thunderbird erschien zuerst auf soeren-hentzschel.at.

10. Mai 2022

Di, 10. Mai 2022, Lioh Möller

Nachdem die Veröffentlichung von Fedora 36 aufgrund noch vorhandener Fehler (Blocker Bugs) mehrfach verschoben wurde, konnte nun die neue Version vorgestellt werden.

Die Workstation Variante, welche sich insbesondere an Nutzer wendet, die sich einen stabilen out-of-the-box Desktop wünschen, enthält GNOME in Version 42. Damit einher geht die Portierung vieler Applikationen auf GTK4. Bei einer Nutzung von NVIDIA-Grafikkarten kommt standardmässig Wayland zum Einsatz.

Die als Spins bezeichneten Varianten mit alternativen Desktopumgebungen wurden ebenfalls aktualisiert. Unter dem Namen Fedora Labs werden darüber hinaus Zusammenstellungen zu bestimmten Themengebieten, wie beispielsweise der Astronomie oder den Neurowissenschaften angeboten.

Fedora Server bietet in der grafischen Verwaltungskonsole die Möglichkeit der Einrichtung und Verwaltung von NFS und SMB Freigaben. Podman ist in Version 4.0 enthalten und nutzt einen überarbeiteten Netzwerk-Stack. Ruby 3.1, Golang 1.18 sowie PHP 8.1 sind Bestandteil der Distribution.

Vor einer Aktualisierung von einer Vorgängerversion sollte diese zunächst auf den letzten Update-Stand gebracht werden, da einige Fehler, welche in Zusammenhang mit einem Upgrade auftreten können, korrigiert wurden.

Download: https://getfedora.org/
Quelle: https://fedoramagazine.org/announcing-fedora-36/

Di, 10. Mai 2022, Ralf Hersel

Vorbei sind die Zeiten, als man nach einem Bauchklatscher vom 5-Meter-Brett im Freibad seine Ehre mit einem coolen "by the way, I use Arch" retten konnte.

Arch Linux ist als Betriebssystem für Profis bekannt, für diejenigen, die sich wirklich gut mit Linux auskennen. Wer weniger Kenntnisse hat, kann sich bei Manjaro bedienen. Möchte man jedoch ein echtes Arch Linux haben, sollte man sich der Herausforderung bewusst sein. Die Entwickler von Arch Linux haben nun ein Tool hinzugefügt, das den Installationsprozess etwas einfacher macht. Nein, es handelt sich nicht um eine schöne grafische Benutzeroberfläche, sondern um ein textbasiertes Installationsprogramm.

Ob der By-the-way-Spruch wirklich nicht mehr angebracht ist, teste ich in einer virtuellen Maschine. Zum Einsatz kommt die aktuelle ISO von Arch Linux.

Nach dem Booten in der virtuellen Maschine meldet sich Arch Linux so:

Ich wähle die erste Option und lande in einem Root-Terminal. Dort starte ich den neuen Installer mit dem Befehl archinstall. Nun kann man einige Einstellungen vornehmen:

Es empfiehlt sich, hier jeden Punkt mit den Pfeiltasten anzuwählen und mit der Enter-Taste zu öffnen. Dann werden entsprechende Optionen zu Auswahl gestellt. Manchmal muss man kurz überlegen, aber es sollte für jeden, der schon einmal eine Distribution installiert hat, machbar sein, die richtigen Optionen auszuwählen.

Dann wählt man den Menüpunkt Install aus und schon rattert der Installationsprozess durch das Terminal. Nach ein paar Minuten ist der Spuk vorbei und man hat ein fertig installiertes und lauffähiges Arch Linux. Nun startet man die virtuelle Maschine neu und landet im Anmeldedialog der gewählten Desktopumgebung.

So einfach hatte ich mir die Installation mit dem neuen Installationswerkzeug nicht vorgestellt. Jetzt dürft ihr euch für das Freibad einen neuen Spruch ausdenken; wie wäre es mit "by the way, I use Slackware".

9. Mai 2022

Mo, 9. Mai 2022, Ralf Hersel

In den vergangenen Wochen wurde bei Fedora die Abschaffung von Legacy-BIOS für Fedora 37 diskutiert. Im FESCo-Meeting am 3. Mai wurde dieser Vorschlag mit 8:0 Stimmen abgelehnt. Die Diskussion über diese Funktion zog eine ernsthafte Diskussion mit Gegenargumenten an, warum die Industrie noch nicht bereit ist, die Unterstützung für Legacy-BIOS aufzugeben.


Als innovative Distribution hat Fedora viele neue Technologien, wie z.B. Pipewire und Wayland, eingeführt. Daher war der Vorschlag, ab Version 37 nur noch UEFI zu unterstützen, durchaus nachvollziehbar. Schaut man sich jedoch den heutigen Stand der Industrie an, benötigen Millionen von Geräten, einschliesslich Laptops, PCs und Server, immer noch Legacy-BIOS-Unterstützung, um weiter zu funktionieren. Auch anderen Mainstream-Distributionen, wie Ubuntu, unterstützen es weiterhin.


Legacy-BIOS wird für virtuelle Maschinen immer noch dringend benötigt. Alle wichtigen Emulatoren für virtuelle Maschinen, wie Virtual Box und virt-manager, sind noch immer auf die Legacy-BIOS-basierte Firmware angewiesen, um das physische System zu emulieren. Obwohl UEFI-Unterstützung vorhanden ist, stossen sie manchmal auf Probleme, wenn sie in diesen virtuellen Maschinen eingesetzt werden. Die meisten Open-Source-Manager für virtuelle Maschinen verwenden zum Beispiel immer noch SeaBIOS, die Open-Source-Implementierung der x86-BIOS-Architektur.

Ausserdem braucht eine moderne Linux-Distribution, egal wie viele technische Verbesserungen wir sehen, immer noch Abwärtskompatibilität mit bestimmten Funktionen. So hat der Linux-Mainline-Kernel vor kurzem die Unterstützung für IDE-Treiber und Raw Floppy Disk entfernt. Diese Entscheidungen sind akzeptabel, weil die Industrie schon lange von diesen Methoden abgerückt ist.

Aber nicht für Legacy BIOS. Aufgrund dieser Tatsache hat das Team schliesslich den Vorschlag für die Funktion in Fedora 37 einstimmig abgelehnt. Die Legacy-BIOS-Unterstützung bleibt für Fedora Linux vorerst erhalten.

Quelle: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KCJCEQMHITAQUW4SMWU3AXIPZ65GSDSU/

8. Mai 2022

Für unser Smart Home möchten wir den aktuellen Stromverbrauch aufzeichnen. Dafür bietet sich, wie auch in meinem Artikel über die Digitalisierung des Gaszählers, Home Assistant an. In dieser mächtigen Software lassen sich Automatisierungen für das Haus erstellen, aber auch Sensoren einlesen und protokollieren. Das möchten wir mit unserem digitalen Stromzähler machen. Was wir zusätzlich noch benötigen, ist ein ESP8266, sozusagen die Home Assistant Außenstelle, die die Daten an die Zentrale weitergibt. Also, legen wir los!

Hardware: ESP8266 und TCRT5000 zum Auslesen des Stromzählers

Die Hardware lässt sich sehr günstig im Internet erwerben. Zwingend erforderlich sind folgende Bauteile:

  • ESP8266 oder ESP32, ich verwende gerne den Wemos D1 Mini
  • TCRT5000, ein Infrarotdiode zum Auslesen des Gaszählers
  • Litzen oder Jumperkabel

Nicht zwingend erforderlich, aber für den dauerhaften Einsatz gut geeignet sind folgende Bauteile

  • Lochrasterplatine
  • Schraubbare Pins um die Kabel zum TCRT5000 mit dem Wemos zu verbinden
  • Female Pins zum Auflösten auf eine Lochrasterplatine und zum Stecken auf die Pins

Den TCRT5000 muss man vorher noch präparieren. Man erkennt ja, dass dort zwei Dioden verbaut sind, eine helle und eine dunkle. Die hellere sendet ein IR-Licht aus, das die zweite Diode wieder lesen soll. Das kann beispielsweise für eine Lichtschranke verwendet werden. In unserem Fall stört die helle Diode, daher müssen wir sie entfernen. Entweder löten wir die ganze Diode aus, oder wir entfernen den Vorwiderstand. Zweiteres geht deutlich schneller. Dazu einfach den Lötkolben an den SMD-Widerstand halten, dann kann man ihn etwas verschieben.

TCRT5000 Bauteile erklärt: Die Output-LED wird wichtig, wenn man die Empfindlichkeit des Sensors mit dem Potentiometer einstellt

Die Verdrahtung findet nach folgendem Schaltplan statt. Wir verwenden keinen Pullup-Widerstand, da dieser bereits auf dem TCRT5000 vorhanden ist. Es wird die Spannungsversorgung über VCC und GND hergestellt und der D0-Pin des TRCT5000 wird mit D2 (GPIO4) des Wemos D1 Minis verbunden.

Schaltplan um den ESP8266 Wemos D1 Mini mit dem TCRT5000 zu verbinden.

Installation am Stromzähler

Die digitalen Stromzähler, hier im Beispiel von EMH, haben fast immer eine Schnittstelle für den Kunden. Manchmal muss man sie von seinem Netzbetreiber freischalten lassen. In meinem Fall war sie glücklicherweise ohne Freischaltung verfügbar.

In der Regel ist dort eine blinkende LED verbaut. Das Blinklicht ist allerdings im Infrarotbereich, für das menschliche Auge also nicht sichtbar. Mit manchen Handy- oder Digitalkameras kann man es aber sichtbar machen, wenn deren Sensoren noch keinen IR-Filter verbaut haben.

Ich habe mir also aus etwas Schaumstoff und Klebeband einen kleinen Halter gebaut. Den Lesekopf des TCRT5000 habe ich dann unmittelbar vor der blinkenden Diode des Stromzählers platziert. Das Potentiometer des TCRT5000 habe ich mit einem kleinen Schraubendreher so lange verdreht, bis die Output-LED gleichmäßig geblinkt hat.

Am Stromzähler sieht man oben eine LED als Kundenschnittstelle. Darüber wird die lesende Diode des TCRT5000 positioniert. Am Poti wird dann so lange die Empfindlichkeit verstellt, bis die Output-LED des TCRT5000 regelmäßig blinkt.

ESPHome installieren und Home Assistant konfigurieren

Die ausführliche Beschreibung, wie man ESPHome auf den Microcontroller bekommt, habe ich bereits beim Gaszähler beschrieben. Die Konfigurationsdatei für den ESP8266 sieht dann im zweiten Abschnitt, also nach dem „captive_portal“ folgendermaßen aus. Beim Gaszähler habe ich den binary_sensor verwendet. Aus Gründen, die ich nicht verstehe, funktioniert das Setup hier aber nicht. Darum verwende ich nun den Pulse_meter, der wiederum am Gaszähler nicht funktioniert.

# Voher kommt der ganze Kopf der Datei, was der Wizard generiert
# [...]

sensor:

# Stromzähler als Pulse Meter
  - platform: pulse_meter
    name: "Stromverbrauch"
    pin:
      number: GPIO4
      mode: INPUT_PULLUP
    unit_of_measurement: "kW"
    accuracy_decimals: 3
    timeout: 2 min
    filters:
      # Filter outliers
      - median:
          window_size: 3
          send_every: 1
          send_first_at: 1
      # Convert pulses/min to kW bei 10000Imp/kWh
      - multiply: 0.006
    total:
      name: "Stromzähler"
      unit_of_measurement: "kWh"
      accuracy_decimals: 3
      filters:
        - multiply: 0.0001

Diesen Code flasht man auf den ESP8266. Gegebenenfalls müssen die Konstanten verändert werden. Das hängt vom Stromzähler ab, wie viele Impulse er ausgibt und in welcher Einheit das umgerechnet werden kann. Der Pulse-Counter hat als Rohsignal „Impulse pro Minute“, bringt bei mir also die Einheit „kWh/min“.

Nebenrechnung: Ich habe einen Verbraucher, der 1.000 Watt = 1 kW verbraucht. Wenn der Verbraucher eine Stunde läuft, verbrauche ich 1 kWh Energie. Der Stromzähler blinkt also 10.000 mal innerhalb dieser Stunde bzw. 166,6 mal pro Minute (siehe Aufdruck). Also muss ich die Pulse/min mit 60/10.000 multiplizieren, also mit 0,006 um wieder auf 1 kW zu kommen. Daher kommt die Konstante in meinem Beispiel.

Im Home Assistant braucht man ebenfalls eine neue Konfiguration. Man bearbeitet dort die configuration.yaml oder, noch besser, die sensor.yaml und ergänzt dort folgende Zeilen:

- platform: template
  sensors:
    stromverbrauch_in_kwh:
      friendly_name: "Elektrische Energie in kWh"
      value_template: >
          {% if states('sensor.stromzahler') | float == 0 %}
           {{ states('sensor.stromverbrauch_in_kwh') }}
          {% else %}
           {{ states('sensor.stromzahler') | float }}
          {% endif %}
      unit_of_measurement: kWh
      device_class: energy
      attribute_templates:
        state_class: total_increasing

Damit haben wir sozusagen offiziell einen Stromzähler implementiert. Dieser kann wiederum im Energie-Dashboard angezeigt werden.

Eines Morgens habe ich mal ein paar Geräte nacheinander angesteckt und deren Stromverbrauch angesehen.

Stromverbrauch in Home Assistant: verschiedene Elektrogeräte im Haushalt im Vergleich: Wasserkocher, Kaffeemaschine, Handyladen und PC starten

The post Home Assistant: Digitalen Stromzähler mit ESPHome auslesen first appeared on bejonet - Linux | Smart Home | Technik.

VirtualBox benötigt für den Betrieb ein zusätzliches Kernelmodul, das je nach Distribution über verschiedene Wege installiert wird und immer wieder für unterschiedlichste Probleme sorgen kann. So auch bei Secure Boot unter openSUSE Leap.

Das Problem ist relativ einfach und besteht bereits seit Leap 15.3 und wird auch bei Leap 15.4 weiter bestehen, weil eine wirkliche Lösung aussteht. Secure Boot basiert auf einer Signatur bzw. Vertrauenskette, um einen verifizierten Start einzuleiten. Im Gegensatz zu anderen halte ich das für eine grundsätzlich gute Sache, die nur besser unterstützt werden muss und die man nicht pauschal abschalten sollte. Meine Geräte laufen daher fast ausnahmslos mit aktiviertem Secure Boot. In openSUSE Leap gibt es nun das Problem mit zwei unterschiedlichen Signaturen und nur eine davon wird standardmäßig ausgeliefert.

Dazu muss man sich vergegenwärtigen, wie openSUSE Leap seit 15.3 entsteht. Auf der recht schmalen Basis aus SUSE Linux Enterprise-Paketen baut die Community weitere Pakete auf und erschafft eine Community-LTS-Distribution mit mehr Desktops, mehr Programmen etc. Schaut man in YaST (oder zypper) nach, kommen Pakete aus unterschiedlichen Quellen.

Der Kernel kommt vom Anbieter „SUSE LLC“ (ist also ein SLE-Paket), VirtualBox pflegt die Community und der Anbieter ist hier „openSUSE“. Shim hat nach der Installation jedoch nur die Zertifikate von SUSE hinterlegt. Das kann man mit folgendem Kommando nachschauen:

$ mokutil -l

Dort erscheinen dann mehrere Einträge unter der Aufliste [key 1], [key 2] etc. in dieser Form:

SHA1 Fingerprint: bc:a4:e3:8e:d1:84:2b:c8:6f:f7:6d:4d:a7:49:51:f1:62:88:59:f8
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
        Validity
            Not Before: Apr 18 14:33:41 2013 GMT
            Not After : Mar 14 14:33:41 2035 GMT
        Subject: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:cd:fd:ab:d7:2a:84:f8:81:c3:36:35:50:35:2c:
                    c7:ec:04:f1:f4:d6:cc:60:4b:c8:13:b3:74:9b:bd:
                    f6:c4:3f:63:3e:66:51:f2:7e:3f:6e:7c:76:7b:71:
                    9d:69:21:2a:15:9b:aa:a5:e5:56:c8:79:98:12:35:
                    cd:7b:63:8c:b8:37:29:ee:77:50:bc:b7:64:8f:fe:
                    26:4a:e5:83:18:1c:6c:5d:b4:87:ef:d7:33:c4:f8:
                    1a:3f:29:9a:84:5a:01:e0:d9:81:6d:31:77:62:29:
                    f5:c1:65:14:df:4a:1d:fb:b7:4a:46:3b:f3:90:8b:
                    a2:b8:26:2a:0a:c3:9e:54:b5:03:60:81:e3:d9:58:
                    35:ed:b0:0b:e2:4f:6b:ef:69:ba:8b:47:df:a4:c5:
                    da:d0:d2:25:aa:85:63:3e:2f:05:db:4c:69:02:a6:
                    0e:35:b3:c2:ae:70:b0:ff:25:80:31:c7:0d:39:74:
                    a3:c0:a4:50:cd:9f:3f:85:b7:62:fb:7b:92:6d:c8:
                    1e:12:d2:ee:0f:96:f4:01:30:d1:ed:e2:10:ec:d2:
                    b2:b8:a1:e1:c5:2d:b3:b1:1e:f8:c5:fa:79:68:9d:
                    e5:a1:92:0f:5e:4f:45:42:7e:90:18:55:8c:fe:c2:
                    13:31:b8:21:de:ac:30:9d:99:e1:6b:44:61:0c:43:
                    3d:75
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                EC:AB:0D:42:C4:56:CF:77:04:36:B9:73:99:38:62:96:5E:87:26:2F
            X509v3 Authority Key Identifier: 
                keyid:EC:AB:0D:42:C4:56:CF:77:04:36:B9:73:99:38:62:96:5E:87:26:2F
                DirName:/CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build@suse.de
                serial:01

            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
         12:be:2c:85:85:5a:94:59:cd:49:51:08:17:c1:d9:63:27:29:
         d3:9e:9d:3f:15:03:99:24:14:9e:ed:77:41:18:f9:b2:f7:5f:
         b7:21:3a:ab:5e:0c:aa:a3:fd:b5:f0:a2:12:89:09:79:dd:09:
         70:a6:af:9c:22:21:91:02:26:b5:0f:ba:7b:c1:b8:3b:c2:c8:
         3e:4e:bb:74:cd:91:57:7a:cd:f4:c1:f6:2a:e6:98:df:59:a7:
         44:04:08:0d:09:f7:e4:07:3d:74:4d:28:cb:8d:0a:d5:c1:6e:
         4d:fb:25:09:32:8a:be:af:ce:37:4f:35:79:e8:7b:b2:e8:b0:
         4e:56:12:39:c9:3c:fb:5f:b8:b6:ad:22:58:7f:24:16:33:ca:
         1e:1c:b8:fc:62:5e:4c:ac:e0:7d:83:24:ee:9b:10:78:98:e2:
         e6:4a:ac:0a:cc:98:94:07:4a:69:18:fa:21:74:b5:12:48:42:
         83:76:8e:8a:48:7f:c6:8d:1e:cc:ee:e0:62:73:09:f3:c0:90:
         f7:49:57:d3:f6:7c:7d:1c:a1:76:9d:76:65:1e:fb:39:56:24:
         10:ae:ed:ea:3f:5b:5c:ea:2d:1e:5c:49:cf:4d:85:b6:fb:39:
         19:70:dd:1e:e6:21:f2:a3:31:19:1e:c3:b4:ae:f7:35:a7:a1:
         b4:61:6b:4e

Relevant ist der Punkt in Zeile 7. Das Zertifikat wurde durch SUSE ausgestellt. Das für VirtualBox ausgelieferte Kernelmodul wird folglich als ungültig erkannt und nicht geladen. Das ist ja auch sinnvoll und entspricht genau dem Konzept.

Die Lösung besteht darin, den openSUSE Schlüssel hinzuzufügen. Dazu benötigt man das Paket openSUSE-signkey-cert. Dieses sollte vorinstalliert sein, aber lässt sich sonst schnell nachinstallieren.

# zypper in openSUSE-signkey-cert

Anschließend fügt man das enthaltene Zertifikat hinzu:

# mokutil --import /etc/uefi/certs/BDD31A9E-kmp.crt'

Hier muss man nun ein Passwort festlegen, das beim nächsten Neustart der Autorisierung dient. Hierbei darauf achten keine Sonderzeichen zu nutzen oder ggf. zu wissen, wo sich diese auf einem englischen Tastaturlayout befinden, da der MOK Manager nach dem Start kein deutsches Tastaturlayout hat.

Nun führt man einen Neustart durch. Es erscheint ein Bluescreen mit dem MOK Manager. Hier importiert man den Schlüssel und gibt das eben festgelegte Passwort ein.

Danach kann man nochmal schauen, welche Schlüssel hinterlegt sind:

$ mokutil -l

Hier sollte nun ein Schlüssel von openSUSE zu sehen sein.

SHA1 Fingerprint: bd:d3:1a:9e:0f:7e:d3:12:76:84:65:e6:57:8e:0d:c0:00:64:46:16
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            fa:be:d8:bf:40:9a:5e:64
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
        Validity
            Not Before: Mar  2 13:01:54 2021 GMT
            Not After : Jan  9 13:01:54 2031 GMT
        Subject: CN=openSUSE Secure Boot Signkey, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:f2:c8:f4:01:12:b8:0d:1a:a9:72:e0:47:05:fb:
                    95:4d:6d:77:a1:e1:0b:73:a3:fa:4c:0a:24:9b:c5:
                    fe:4c:00:fb:5b:e2:5b:fd:5c:0b:8b:d2:f6:6b:a2:
                    80:51:de:dd:be:02:3f:06:7d:59:1c:5b:e5:6c:a2:
                    de:7c:4f:d5:f8:d8:c0:59:b2:80:19:ea:5a:fc:cc:
                    4f:11:99:04:5b:a1:71:04:29:48:f0:db:8d:63:84:
                    88:5b:29:55:96:ef:90:11:7b:b7:47:2e:d4:47:29:
                    29:a1:e5:fa:93:ea:55:d5:ab:87:5d:66:93:b6:d2:
                    8e:76:06:01:9d:01:14:74:37:6e:78:42:b8:7d:7e:
                    a7:83:c8:30:b0:05:64:84:50:f6:cb:96:f6:de:5c:
                    68:ea:07:2b:aa:62:7e:2b:0e:63:2f:96:47:76:bf:
                    d8:01:53:09:92:1d:64:8b:9e:56:9b:cf:1e:11:a0:
                    8c:40:e8:13:4c:27:a0:08:39:94:a0:e7:f9:20:14:
                    4b:b2:62:5b:2f:e1:75:3d:94:73:f3:a3:1f:5a:27:
                    5e:2f:7d:91:35:83:38:cc:10:03:e8:36:77:b2:40:
                    3e:d2:ee:7a:97:0a:a6:25:1b:15:a4:7e:ec:a2:58:
                    5a:19:1f:8a:de:96:63:3e:34:b0:2e:90:3c:c0:07:
                    22:3f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                9D:DF:43:D9:F1:A0:27:27:3F:52:C6:C0:77:59:08:EE:01:67:13:25
            X509v3 Authority Key Identifier: 
                keyid:68:42:60:0D:E2:2C:4C:47:7E:95:BE:23:DF:EA:95:13:E5:97:17:62
                DirName:/CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org
                serial:01

            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage: 
                Code Signing
    Signature Algorithm: sha256WithRSAEncryption
         9e:32:bb:ac:bd:d3:fc:5b:b8:e3:71:10:48:1d:dc:57:65:7c:
         e2:94:1c:39:c4:1f:dd:d0:92:c7:c5:53:d7:86:53:82:4a:75:
         44:63:38:aa:be:15:f1:fa:00:ec:5c:ab:f5:41:3e:c7:6c:c4:
         33:37:15:cb:67:99:d9:a8:a1:3b:fa:9a:43:f2:46:66:2f:1c:
         a7:5a:63:ab:49:cd:31:44:23:81:71:74:60:6c:a7:41:a9:e3:
         6f:fe:3c:57:97:8e:17:d6:75:87:fc:10:d0:72:12:4d:d9:30:
         b2:f1:94:4b:49:5e:1d:3d:cb:8d:75:8d:44:bf:50:06:9d:50:
         8b:90:39:20:4e:6d:f2:fa:57:3b:10:2f:1c:d4:ec:2a:cc:7a:
         c7:6a:7c:47:7c:95:2d:7e:eb:63:ce:31:bc:12:42:a8:70:d8:
         f6:d6:03:43:65:5b:55:7e:c2:13:0e:71:f4:57:df:a1:b6:29:
         63:fb:35:94:25:7f:7e:13:93:86:6f:ea:fe:9f:4f:af:78:72:
         77:12:8f:e0:fa:31:c7:00:6d:20:8f:e9:d3:32:53:31:61:04:
         7c:eb:0a:ff:30:12:de:ff:0b:b6:5c:fc:de:04:e4:59:7f:b6:
         a1:7a:63:fd:64:45:b1:85:88:11:74:cf:c0:49:b8:33:06:16:
         c7:0e:6b:33

VirtualBox startet nun regulär und ohne Probleme.

Warum die Entwickler es nicht hinbekommen diesen Schlüssel standardmäßig zu integrieren, ist mir nicht klar. Vermutlich eine dieser noch nicht ganz ausgestandenen Schwierigkeiten beim Zusammenspiel von SUSE und Community im Rahmen der Entwicklung von Leap.

6. Mai 2022

Mozilla Hubs ist eine Art virtueller Treffpunkt, den Mozilla im Jahr 2018 gestartet hat. Ab sofort steht die Plattform auch in deutscher Sprache bereit.

Mit dem Start von Mozilla Hubs im April 2018 ging eine Online-Plattform an den Start, welche es Nutzern ermöglicht, sich in sogenannten Räumen virtuell zu treffen. Das Besondere an Hubs: es spielt sich komplett im Web ab: keine geschlossene Plattform, keine Installation einer Anwendung, keine Abhängigkeit von einem bestimmten Gerät. Einfach eine URL teilen und miteinander treffen. Hubs funktioniert in jedem Browser, am Smartphone – und auch mit der VR-Brille, wo Hubs als virtuelle Plattform sein volles Potential entfaltet.

Mit dem nun veröffentlichten Mai-Update, welches auch diverse Fehlerkorrekturen bringt, steht Mozilla Hubs auch in deutscher Sprache zur Verfügung.

Der Beitrag Mozilla Hubs jetzt auch auf Deutsch verfügbar erschien zuerst auf soeren-hentzschel.at.

PDF ist an sich ein gutes Austauschformat. Was ich allerdings feststellen durfte: Viele Exporter sowie sog. PDF-Drucker, erzeugen relativ große Dateien die in keinem Verhältnis zum Inhalt stehen.

Das hat mich heute auch wieder überrascht, und um's kurz zu machen, es gibt mehrere Tools die das Problem beheben können. Meine Wahl fiel auf ps2pdf, ein Verkleinern von Dokumenten ist damit denkbar einfach:

ps2pdf input.pdf output.pdf

Allerdings wahrt das nicht die PDF/A-Kompatibilität. Da ps2pdf auf Ghostscript basiert, kann man auch dieses verwenden. Allerdings ist das nicht ganz einfach, weil man doch deutlich mehr Parameter mitangeben muss. Für mich hat folgendes funktioniert:

gs -dPDFA -dBATCH -dNOPAUSE -sColorConversionStrategy=UseDeviceIndependentColor -sDEVICE=pdfwrite -dPDFACompatibilityPolicy=2 -sOutputFile=output.pdf input.pdf

Je nach System, Ghostscript-Version, Eingangsdatei, etc. kann das funktionieren, muss aber nicht.

PDF ist an sich ein gutes Austauschformat. Was ich allerdings feststellen durfte: Viele Exporter sowie sog. PDF-Drucker, erzeugen relativ große Dateien die in keinem Verhältnis zum Inhalt stehen.

Das hat mich heute auch wieder überrascht, und um's kurz zu machen, es gibt mehrere Tools die das Problem beheben können. Meine Wahl fiel auf ps2pdf, ein Verkleinern von Dokumenten ist damit denkbar einfach:

ps2pdf input.pdf output.pdf

Allerdings wahrt das nicht die PDF/A-Kompatibilität. Da ps2pdf auf Ghostscript basiert, kann man auch dieses verwenden. Allerdings ist das nicht ganz einfach, weil man doch deutlich mehr Parameter mitangeben muss. Für mich hat folgendes funktioniert:

gs -dPDFA -dBATCH -dNOPAUSE -sColorConversionStrategy=UseDeviceIndependentColor -sDEVICE=pdfwrite -dPDFACompatibilityPolicy=2 -sOutputFile=output.pdf input.pdf

Je nach System, Ghostscript-Version, Eingangsdatei, etc. kann das funktionieren, muss aber nicht.

So gut wie jede Serveranwendung, die ich betreibe, läuft in einem Container. Upgrades sollten auch dementsprechend einfach sein: Aktuelles Image herunterladen, docker-compose down && docker-compose up -d ausführen, und fertig.

Leider klappt das bei PostgreSQL nur bedingt: Während Minor-Versionsupgrades genau so funktionieren, wird man bei Major-Versionsupgrades lediglich mit einer Fehlermeldung begrüßt:

FATAL:   database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 11.15, which is not compatible with this version 13.6.

Voraussetzung

Ich gehe im Folgenden davon aus, dass man:

  • Das offizielle PostgreSQL Docker Image verwendet
  • Das Volume nach /var/lib/postgresql/data eingehängt wird
  • Der Benutzer postgres heißt (auf meinen alten Systemen verwende ich noch pgadmin, aber Standard ist das wohl nicht mehr)

Upgrade durchführen

  1. Jede Anwendung, die auf die Datenbank zugreift, beenden. Wer's grafisch mag kann dafür Portainer verwenden, oder wie ich im Terminal via docker-compose down selektiv Anwendungen herunterfahren. PostgreSQL muss weiterhin laufen!
  2. Dump der Datenbank erstellen: Auch das geht via Portainer, alternativ auch via docker exec. Der Befehl für den Dump lautet pg_dumpall -U postgres > dump.sql. Dieser muss im Container ausgeführt werden!
  3. Anschließend PostgreSQL stoppen
  4. dump.sql aus dem Volume sichern
  5. Das Volume löschen, alternativ für den neuen Container ein anderes Volume verwenden. Hintergrund der Geschichte: PostgreSQL benötigt zwingend ein leeres Verzeichnis für den Start (auch die dump.sql darf sich zum Startzeitpunkt nicht im Volume befinden)
  6. Neues Image ziehen, PostgreSQL Container starten. Auch hier wieder selektiv erst einmal nur PostgreSQL starten, noch keine anderen Anwendungen!
  7. dump.sql in das Volume der Datenbank kopieren/verschieben
  8. Vorher gesicherten Daten importieren. Ich musste feststellen, dass das selbst bei kleinen Datenbanken etwas dauern kann, daher je nach Größe etwas Zeit einplanen. Analog zu Schritt 2 führt man im Container ein psgl -U postgres < dump.sql aus
  9. Nachdem die Datenbank alles import hat, kann man auch die restlichen Anwendungen wieder starten

Das war's :)

So gut wie jede Serveranwendung, die ich betreibe, läuft in einem Container. Upgrades sollten auch dementsprechend einfach sein: Aktuelles Image herunterladen, docker-compose down && docker-compose up -d ausführen, und fertig.

Leider klappt das bei PostgreSQL nur bedingt: Während Minor-Versionsupgrades genau so funktionieren, wird man bei Major-Versionsupgrades lediglich mit einer Fehlermeldung begrüßt:

FATAL:   database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 11.15, which is not compatible with this version 13.6.

Voraussetzung

Ich gehe im Folgenden davon aus, dass man:

  • Das offizielle PostgreSQL Docker Image verwendet
  • Das Volume nach /var/lib/postgresql/data eingehängt wird
  • Der Benutzer postgres heißt (auf meinen alten Systemen verwende ich noch pgadmin, aber Standard ist das wohl nicht mehr)

Upgrade durchführen

  1. Jede Anwendung, die auf die Datenbank zugreift, beenden. Wer's grafisch mag kann dafür Portainer verwenden, oder wie ich im Terminal via docker-compose down <application name> selektiv Anwendungen herunterfahren. PostgreSQL muss weiterhin laufen!
  2. Dump der Datenbank erstellen: Auch das geht via Portainer, alternativ auch via docker exec. Der Befehl für den Dump lautet pg_dumpall -U postgres > dump.sql. Dieser muss im Container ausgeführt werden!
  3. Anschließend PostgreSQL stoppen
  4. dump.sql aus dem Volume sichern
  5. Das Volume löschen, alternativ für den neuen Container ein anderes Volume verwenden. Hintergrund der Geschichte: PostgreSQL benötigt zwingend ein leeres Verzeichnis für den Start (auch die dump.sql darf sich zum Startzeitpunkt nicht im Volume befinden)
  6. Neues Image ziehen, PostgreSQL Container starten. Auch hier wieder selektiv erst einmal nur PostgreSQL starten, noch keine anderen Anwendungen!
  7. dump.sql in das Volume der Datenbank kopieren/verschieben
  8. Vorher gesicherten Daten importieren. Ich musste feststellen, dass das selbst bei kleinen Datenbanken etwas dauern kann, daher je nach Größe etwas Zeit einplanen. Analog zu Schritt 2 führt man im Container ein psgl -U postgres < dump.sql aus
  9. Nachdem die Datenbank alles import hat, kann man auch die restlichen Anwendungen wieder starten

Das war's :)

5. Mai 2022

Do, 4. Mai 2022, Lioh Möller

Mit openmediavault ist es möglich, einen eigenen NAS-Server auf Basis Freier Software zu betreiben. Die nun vorliegende Version 6 (Codename Shaitan) basiert erstmalig auf Debian GNU/Linux in der Version 11.

Darüber hinaus hat das Projekt ein vollständig überarbeitetes Webinterface integriert und ermöglicht so die einfachere Einrichtung und Verwaltung. Einige der integrierten Plugins nutzen jetzt Containertechnologien, darunter S3, OwnTone, PhotoPrism, WeTTY, FileBrowser und Onedrive.

Das Installationsprogramm wurde überarbeitet und vereinfacht für die Installation von einem USB-Speichermedium auf ein USB-basiertes Ziellaufwerk. Aufgrund von Kompatibilitätsgründen wird eine Installation grafischer Benutzeroberflächen unterbunden. Unter Umständen kann es bei einer Aktualisierung der Vorgängerversion zu Schwierigkeiten kommen. Weitere Informationen dazu finden sich in den Veröffentlichungshinweisen.

Quelle: https://www.openmediavault.org/?p=3201