staging.inyokaproject.org

25. November 2021

Do, 25. November 2021, Niklas

Am 31. Januar 2021 wurde ein neues Betriebssystem-Projekt gestartet. Helium, so hiess airyxOS am Anfang, sollte ein freier Nachbau von Apples proprietärem macOS werden, der viel weiter geht, als die vielen Open-Source Docks oder Themes für KDE und GNOME. Es soll tatsächlich auch original macOS Programme ausführen können, während die Unterstützung für FreeBSD Programme beibehalten wird. Linux Programme sollen über FreeBSDs Linux-Kompatibilitätsschicht ebenfalls unterstützt werden.

Damit geht das Projekt mehr in die Richtung dessen, was ReactOS für Windows ist - allerdings ohne komplett eigenen Kernel, was die Entwicklungszeit von airyxOS hoffentlich beschleunigen dürfte. Stattdessen will das Projekt auf FreeBSD aufbauen. Da Apple selbst Teile von FreeBSD für seinen Darwin Kernel verwendet, dürfte eine Kompatibilitätsschicht hier einfacher machbar sein, als beispielsweise mit Linux.

Erst vor wenigen Tagen hat airyxOS mit Version 0.3.0 "Tanuki" seine erste Beta-Version veröffentlicht. Ich habe sie ausprobiert und bin angesichts des sehr frühen Entwicklungsstadiums noch nicht voll überzeugt, aber ich denke, das Projekt hat Potenzial. Die durchaus gelungene Erfahrung mit der Bedienoberfläche wird überschattet von diversen Bugs und Treiberproblemen.

Der Desktop von airyxOS basiert auf KDE Plasma, aber das ist kaum noch zu erkennen. Das komplette Design wurde macOS nachempfunden. Einzig die KDE-typischen Systemeinstellungen und einige der Pop-ups, die beim Klick auf Tray Icons erscheinen, verraten noch, welche Software hier läuft. Alles in allem wirkt das sehr stimmig und durchdacht.

Mit dem Dock fehlt allerdings noch eine wichtige Komponente des macOS UI. Es ist so nicht ganz einfach, Programme zu starten. Es gibt nur einen Applications Ordner im Filer, von dem aus man Programme starten kann. Um geöffnete, minimierte Programme wieder hervorzuholen, gibt es ein Hot Corner in der oberen linken Ecke.

Der Filer ist der Dateimanager von airyxOS. Er wurde vom helloSystem Projekt geforkt, das wir bereits vorgestellt haben. Die beiden Systeme haben bezüglich ihrer Bedienoberfläche ja sehr ähnliche Ziele, auch wenn sie zum Teil sehr unterschiedlich umgesetzt wurden. Der erste Eindruck ist gut, ein sehr simples Programm, in dem man sich schnell zurechtfindet. Nur ein schwerwiegender Bug ist mir hier aufgefallen: Wenn man im Root Verzeichnis auf Get Info klickt, stürzt das komplette System ab und startet neu. In anderen Ordnern funktioniert das korrekt.

Die Auswahl an vorinstallierten Programmen ist noch eher klein. Hier finden sich nur Kate als Texteditor und Firefox als Browser. Mit diesen beiden hat man auf jeden Fall eine gute Wahl getroffen. Der Firefox bringt bei mir leider nach ein paar Sekunden das ganze System zum Hängen, nur ein Neustart hilft. Ich gehe aber davon aus, dass das noch behoben wird.

Bis jetzt handelt es sich bei der vorinstallierten Software komplett um native FreeBSD Programme, wie sie auch im FreeBSD Repository verfügbar wären (allerdings teilweise ins airyxOS-eigene .app Format verpackt). airyxOS soll auch quelloffene Cocoa Programme, also native macOS Programme ausführen können, wenn man diese auf airyxOS neu kompiliert. Zu gerne hätte ich das ausprobiert, aber das scheitert am nicht funktionierenden Internet, wodurch ich mir keine Repositorys zum Testen clonen kann.

Zu einem späteren Zeitpunkt will airyxOS auch Binärpakete von macOS ausführen können, wodurch auch proprietäre Software genutzt werden kann. Ob das langfristig funktionieren kann, ist fraglich, nachdem Apple auf die ARM Architektur gewechselt hat und airyxOS weiterhin auf x86_64 setzt. Solange noch Software für Intel Macs erscheint, sollte es aber machbar sein.

Ich halte airyxOS für ein höchst interessantes Projekt, das nach nicht mal einem Jahr Entwicklungszeit schon etwas auf die Beine gestellt hat, was man fast als nutzbar bezeichnen könnte. Die Version wird zwar Beta genannt, fühlt sich aber eher nach pre-Alpha an. Wenn wir airyxOS noch ein oder zwei Jahre Zeit geben, kann ich mir gut vorstellen, dass hier etwas entstehen wird, was sich insbesondere für weniger technisch versierte Nutzer gut im Alltagsgebrauch eignet.

Zur Hardwareunterstützung: Hier wird FreeBSD 12.3 eingesetzt, also sollte airyxOS mit jedem Gerät funktionieren, das auch mit FreeBSD 12.3 funktioniert. In der Praxis sieht das nicht ganz so aus, aber es kann als Anhaltspunkt dienen. Auf meinem Testlaptop, ein Lenovo 3000 N200, mit dem ich bereits einige Systeme auf FreeBSD 12 Basis erfolgreich getestet habe, will airyxOS gar nicht. Einmal bootet es in einen schwarzen Bildschirm mit Mauszeiger, beim zweiten Versuch in einen schwarzen Bildschirm ohne Mauszeiger. Ich habe dann aufgegeben.

Auf meinem Computer, ein HP Compaq aus dem Jahre 2009, bekomme ich kein Internet (weder WLAN-Stick noch Handy mit Tethering werden erkannt) und die Bildschirmauflösung ist zu gering. Mit dem neueren FreeBSD 13, das ich auf diesem Gerät normalerweise nutze, funktioniert Internet, aber die Bildschirmauflösung... ist halt einfach Nvidia... Hier konnte ich die Tests mit gewissen Einschränkungen (keine Downloads, keine Programme installieren, keine Repositorys clonen, ...) durchführen.

Natürlich behalte ich die Entwicklung von airyxOS im Blick und werde berichten, was sich mit der nächsten Version verändert und was jetzt funktioniert, womit ich heute noch Probleme hatte. Über Kommentare mit eigenen Testberichten würde ich mich freuen, vielleicht kommt der eine oder andere ja schon weiter mit dem System.

Quellen:

Do, 25. November 2021, Ralf Hersel

Endless OS 4.0 ist eine Hauptversion, die zahlreiche neue Funktionen und Verbesserungen einführt, beginnend mit einer verbesserten App-Grid-Navigation mit anklickbaren Pfeilen, die es dem Benutzer ermöglichen, einfacher zwischen den App-Seiten zu navigieren, mit Punkten, die die Gesamtzahl der Seiten und die Seite anzeigen, auf der man sich gerade befindet.


Mit dieser Version wird ein schneller Benutzerwechsel eingeführt, der es ermöglicht, einfach zu einem anderen Benutzer zu wechseln, während ein anderer Benutzer noch angemeldet ist. Die neue Funktion wurde sowohl in das Benutzermenü als auch in den Sperrbildschirm implementiert. Die Standard-Desktop-Umgebung basiert auf der GNOME 3.38-Serie.

Ebenfalls neu in Endless OS 4.0 ist das treiberlose Drucken, eine Funktion, die das Internet Printing Protocol verwendet, um Drucker im lokalen Netzwerk automatisch zu erkennen. Wird ein Upgrade von Endless OS 3.9 durchgeführt, so werden alle konfigurierten Drucker entfernt, dann wieder automatisch erkannt, können aber auch manuell wieder hingezufügt werden.

Neben anderen Änderungen enthält diese Version den Rhythmbox-Musikplayer und den Cheese-Webcam-Viewer als Flatpak-Applikationen, das Standard-Icon-Thema von GNOME sowie getrennte Repositories für Flatpak-Applikationen und den Rest des Betriebssystems, um die Leistung und Zuverlässigkeit der App-Installationen zu verbessern.

Interessant ist auch die Tatsache, dass Endless OS 4.0 nun ein optionales Metriksystem enthält, das automatisch anonyme Nutzungsstatistiken und Problemberichte an die Endless-OS-Entwickler speichert und sendet. Hierbei handelt es sich um eine optionale Funktion, die bei der Ersteinrichtung oder unter Einstellungen > Datenschutz > Metriken deaktiviert werden kann.

"In Endless OS 4 werden übermittelte Datenpunkte nicht mehr mit dem jeweiligen Computer in Verbindung gebracht, der sie übermittelt hat, sondern mit dem Vertriebskanal für diesen Computer, der durch die Build-ID des Installations-Images identifiziert wird, das in der Regel von Tausenden von Systemen gemeinsam genutzt wird", erklären die Entwickler.

Unter der Haube basiert Endless OS 4.0 auf Debian GNU/Linux 11 "Bullseye" und wird von der Linux 5.11 Kernel-Serie angetrieben. Bei dieser Version handelt es sich um eine langfristig unterstützte (LTS) Veröffentlichung, die für mehrere Jahre Software- und Sicherheitsaktualisierungen erhalten wird, sogar nach der Veröffentlichung von Endless OS 5.

Mit dieser Version können Benutzer ihr eigenes Endless OS-Installations-Image anpassen, sie unterstützt den Einplatinencomputer Raspberry Pi 4 Model B mit 8 GB RAM, L2TP und OpenConnect/AnyConnect VPNs sowie den neuen SBAT Secure Boot-Widerrufsmechanismus.

Verschiedene Funktionen, die in früheren Endless OS-Versionen vorhanden waren, wurden entfernt, z. B. die Funktion "Gemeinsames Konto", die App "Remote Desktop Viewer", integrierte Desktop-Verknüpfungen für Websites, der automatische Google Chrome-Downloader, die chinesische Zhuyin-Eingabemethode und die Unterstützung für Computer mit einer "Split-Disk"-Konfiguration.

Endless OS verwendet eine Technologie namens OSTree, um das Basissystem zu verwalten und ein read-only Root-Dateisystem zu ermöglichen. Anwendungen werden als Flatpaks installiert und verwaltet. OSTree funktioniert in etwa so, wie ein Git-Repository aktualisiert wird; das gesamte System wird synchronisiert und in einem Zug aktualisiert, so wie ein "Git Pull"-Befehl ein Quellcode-Repository aktualisiert.

Wer Endless OS ausprobieren möchte, kann die Distribution von der Website herunterladen. Es werden Live- und Installations-Images für verschiedene Sprachen und Plattformen bereitgestellt. Weitere Einzelheiten zu dieser Version finden sich in den Release Notes:

Quelle: https://support.endlessos.org/en/endless-os/release-notes/4-0

Beim Betrieb eines Servers wird der Nutzer schnell feststellen, dass er nicht der einzige ist, der gerne Zugriff auf den Ser­ver hätte. Um zu häu­fige Log­in­ver­su­che abzu­blo­cken, gibt es Fail2ban. Die­ses Pro­gramm­pa­ket durch­sucht die ent­spre­chen­den Logs und blockiert bös­wil­lige Ver­su­che, in das Sys­tem ein­zu­bre­chen. Damit gehört Fail2ban zu den Intru­sion Preven­tion-Sys­te­men. Damit kann es auch zur Auswertung von Login-Versuchen auf die eigenen WordPress-Installationen genutzt werden. Wer in die Logs schaut, wird dort ähnliche Zeilen finden:

18.217.216.181 – – [23/Nov/2021:19:32:40 +0100] „POST /wp-login.php HTTP/1.1“ 200 8408 „https://seeseekey.net/wp-login.php“ „Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0“

Um WordPress mit Fail2ban zu verheiraten muss ein einsprechender Jail und ein Filter angelegt werden. Was mich im Vorfeld in Bezug auf WordPress irritierte war der Statuscode 200, wenn ein Login in WordPress fehlschlägt. Hintergrund ist hier das WordPress bei einem erfolgreichen Login stattdessen den Statuscode 302 (Found) nutzt. Damit kann im ersten Schritt der Jail für Fail2ban erstellt werden:

nano /etc/fail2ban/jail.d/wordpress.conf

Diese Datei wird nun wie folgt befüllt:

[wordpress]
enabled = true
port = http,https
filter = wordpress
logpath = /var/log/nginx/access.log
maxretry = 3

Anschließend muss der genutzte Filter ebenfalls angelegt werden:

nano /etc/fail2ban/filter.d/wordpress.conf

Der entsprechende Filter sieht wie folgt aus:

# Filter for WordPress login

[INCLUDES]

before = common.conf
 
[Definition]

failregex = <HOST>.*POST.*(wp-login\.php|xmlrpc\.php).* 200

datepattern = %%d/%%b/%%Y:%%H:%%M:%%S %%z

Nach einem Neustart von Fail2ban mittels:

service fail2ban restart

ist der neue Jail aktiv. Über das Log kann die Arbeit desselben betrachtet werden:

tail -f /var/log/fail2ban.log

Damit sind die WordPress-Installationen gegen den Versuch unbefugter Logins besser abgesichert. Nach drei Fehlversuchen, wird die entsprechende IP-Adresse gesperrt, sodass weitere Verbindungsversuche von dieser IP-Adresse vom Server nicht mehr beantwortet werden.

Do, 25. November 2021, Ralf Hersel

Alpine Linux ist ein von der Community entwickeltes Betriebssystem für Router, Firewalls, VPNs, VoIP-Boxen und Server. Es wurde mit Blick auf die Sicherheit entwickelt; es verfügt über proaktive Sicherheitsfunktionen wie PaX und SSP, die verhindern, dass Sicherheitslücken in der Software ausgenutzt werden können. Die verwendete C-Bibliothek ist musl und die Basis-Tools befinden sich alle in BusyBox. Diese sind normalerweise in eingebetteten Systemen zu finden und sind kleiner als die Werkzeuge, die in GNU/Linux-Systemen zu finden sind.

Fünf Monate nach der letzten Version 3.14 ist gestern ein grosses Update dieser auf Sicherheit fokussierten GNU/Linux-Distribution erschienen. Alpine Linux 3.15 wartet mit dem Linux Kernel 5.15 LTS auf.

Zu den Highlights dieser Version gehören die Unterstützung für UEFI Secure Boot auf der 64-Bit-Architektur (x86_64), Festplattenverschlüsselung im Installationsprogramm, Support für Out-of-Tree-Kernelmodule über AKMS (inspiriert von DKMS), gzip-komprimierte Kernelmodule und SimpleDRM als standardmässiger In-Kernel-Framebuffer-Treiber für einen flackerfreien Start.

Zusätzlich zu diesen neuen Funktionen enthält Alpine Linux 3.15 einige der neuesten GNU/Linux-Technologien und Open-Source-Software, darunter die Desktop-Umgebungen GNOME 41 und KDE Plasma 5.23 (zur Installation in den Archiven verfügbar), LLVM 12, XOrg Server 21.1, Rust 1.56, Ruby 3.0, Kea 2.0, Node.js 16.13, OpenLDAP 2.6, PostgreSQL 14 sowie OpenJDK 17.

Neben anderen Änderungen fügt Alpine Linux 3.15 Unterstützung für die gleichzeitige Installation mehrerer Hauptversionen von PostreSQL hinzu, um Upgrades zu erleichtern, entfernt qt5-qtwebkit und zugehörige Pakete, verabschiedet sich vom MIPS64-Port, verwendet neue 4096-Bit-RSA-Schlüssel für Paketsignaturen und aktiviert nicht länger IPv6-Weiterleitung für radvd.

Alpine Linux 3.15 kann ab sofort von der offiziellen Website heruntergeladen werden, wo man zwischen den Varianten Standard, Extended, Netboot, Raspberry Pi, Generic ARM, Mini Root Filesystem, Virtual und Xen für die Architekturen 64-bit, 32-bit, AArch64 (ARM64), PowerPC 64-bit Little Endian (ppc64le) und IBM System z (s390x) wählen kann.

Bestehende Benutzer von Alpine Linux 3.14 können ihre Installationen mit dem Befehl apk upgrade --available auf die neue Version aktualisieren. Weitere Details finden Sie auf der Seite mit der Ankündigung der neuen Version:

Quelle: https://alpinelinux.org/posts/Alpine-3.15.0-released.html

24. November 2021

Das hyperblog wird heute 17 Jahre alt und wir feiern das im Stillen mit euch zusammen. Danke dass ihr immer mal wieder vorbei geschaut habt und gerade auch zu den Themen Linux und Computing zu meinem Senf euren Senf dazu beigetragen habt.

Mittlerweile sind wir auch mit dem Musikproduktionsblog “Klangwerk” ein wenig größer geworden, was uns alle sehr freut. Bleibt uns treu und schreibt uns ab und zu mal in die Kommentare. Ist immer schön, was von euch zu hören.

Macht’s gut und esst nicht so viel Fisch.

Das hyperblog wird heute 17 Jahre alt und wir feiern das im Stillen mit euch zusammen. Danke dass ihr immer mal wieder vorbei geschaut habt und gerade auch zu den Themen Linux und Computing zu meinem Senf euren Senf dazu beigetragen habt.

Mittlerweile sind wir auch mit dem Musikproduktionsblog “Klangwerk” ein wenig größer geworden, was uns alle sehr freut. Bleibt uns treu und schreibt uns ab und zu mal in die Kommentare. Ist immer schön, was von euch zu hören.

Macht’s gut und esst nicht so viel Fisch.

Mi, 24. November 2021, Niklas

Das freie Betriebssystem Haiku richtet sich speziell an normale Desktop Computer und konnte schon lange bei einigen Alltagsaufgaben punkten - Das Surfen im Web gehörte allerdings nicht dazu. Mit HaikuWebKit und QtWebKit standen eine fehlerhafte aktuelle und eine hoffnungslos veraltete, aber für den damaligen Stand voll funktionsfähige Version der Apple WebKit Engine zur Verfügung.

Seit dem 20. November ist endlich auch QtWebEngine verfügbar. Die Bibliothek nutzt eine stark angepasste Version der Chromium Browser Engine und macht sie für Qt Programme nutzbar. Davon profitiert unter anderem der KDE Falkon, der gleichzeitig mit der QtWebEngine als erster darauf basierender Browser für Haiku veröffentlicht wurde.

Bis auch weitere QtWebEngine-basierte Browser verfügbar sind, dürfte es nicht lange dauern. Ein Port der Python-Bindings für QtWebEngine ist inzwischen auch vorhanden, womit der tastaturgesteuerte Qutebrowser auf Haiku portiert werden kann. Der Otter Browser, der sich auf Haiku schon lange mit der alten QtWebKit Engine grösster Beliebtheit erfreut, kann ebenfalls QtWebEngine nutzen und damit neuere Webstandards unterstützen, müsste dazu allerdings neu kompiliert werden.

Vom guten alten Konqueror, der mit seiner eigenen KHTML Engine den Grundstein für alle modernen Browser ausser Firefox gelegt hat, gibt es sogar schon einen Screenshot auf Twitter, wie er auf Haiku läuft. Konqueror nutzt standardmässig schon seit einigen Jahren QtWebEngine, das eigene KHTML wird kaum noch gepflegt.

Für Haiku ist diese Entwicklung ein riesiger Meilenstein, erlaubt es doch vielen Nutzern, jetzt komplett auf Haiku als Hauptbetriebssystem umzusteigen. Die Browsersituation wurde im Forum immer wieder als Grund genannt, weshalb man damit noch warten wollte.

Zum jetzigen Entwicklungsstand ist der QtWebEngine Port noch nicht ganz stabil. Er stürzt immer mal wieder ab, wenn man versucht, eine Webseite aufzurufen. Das ist hier allerdings nicht mehr so schlimm: QtWebEngine nutzt für jeden Tab einen eigenen Prozess. Stürzt ein Tab ab, so laufen der Browser und die anderen Tabs problemlos weiter und das Problem kann behoben werden, indem man einfach den einen Tab neu lädt. Bei HaikuWebKit und QtWebKit verhält sich das anders, ein Absturz betrifft den ganzen Browser.

Nachdem bereits so viel Arbeit und Zeit investiert wurde, um die grosse und anspruchsvolle Chromium Engine erstmal zum Laufen zu bekommen, ist es vermutlich ohnehin nur noch eine Frage von wenigen Tagen, bis auch die Abstürze behoben werden.

Ein Test auf HTML5Test.com beweist die enormen Vorzüge von QtWebEngine im Vergleich zu den verfügbaren Alternativen. Aber auch im alltäglichen Gebrauch spürt man eine erhöhte Geschwindigkeit und eine stark verbesserte Kompatibilität mit modernen Webseiten. Mit QtWebKit funktionierte zuletzt nicht einmal mehr Haikus eigenes Forum, nachdem die Forensoftware ein Update erhalten hatte.

Wer auf einen Mainstream Browser wie Brave, Edge oder Firefox wartet, muss sich allerdings weiterhin gedulden: Der Code von QtWebEngine hat erhebliche Unterschiede zum normalen Chromium, also müssten alle Anpassungen nochmal neu gemacht werden. Firefox nutzt zudem eine komplett unterschiedliche Codebasis und benötigt die GTK Bibliothek, die auf Haiku nicht verfügbar ist.

Der KDE Falkon mit QtWebEngine ist bereits im Repository von Haiku angekommen und kann bequem über das HaikuDepot oder im Terminal mit dem Befehl pkgman install falkon installiert werden.

Mi, 24. November 2021, Lioh Möller

Der Hersteller Amazon bietet seit längerem eine hauseigene Linux-Distribution zur Nutzung auf AWS an.

Diese basierte bis anhin auf einer Mischung aus Fedora und Red Hat Enterprise Linux Komponenten. Mit der nun angekündigten Preview Version 2022 ändert sich die Ausrichtung dahingehend, dass in Zukunft lediglich Fedora als Upstream zum Einsatz kommen soll. Diese Neuerung ist unter anderem dem langjährigen Fedora Community Mitglied Tom "spot" Callaway zu verdanken, der aktuell beruflich bei Amazon in der Entwicklung tätig ist.

In diesem Zusammenhang wird auch das Release Modell von Amazon Linux angepasst. Neue Hauptversionen sollen von nun an in einem 2-jährigen Rhythmus erscheinen, wobei eine Version bis zu 5 Jahre lang mit Sicherheitsaktualisierungen versorgt wird. Vierteljährlich sollen zudem Minor-Releases erscheinen, analog zu Fedora.

Unter AL2022 wird darüber hinaus SELinux standardmässig aktiviert sein.

Kunden des Clouddienstleisters werden weiterhin die Möglichkeit haben, alternative Distributionen wie Ubuntu oder Debian nutzen zu können.

23. November 2021

Di, 23. November 2021, Norbert Rüthers

Vielleicht ist es dem einen oder anderen schon aufgefallen, das neue Raspberry Pi OS (Bullseye) unterstützt keine angeschlossene Kamera mehr. Kann das sein?  Nein es werden auch weiterhin Kameras unterstützt, nur auf eine andere Weise, was viele Probleme aufwirft.

Aufgefallen ist mir das ganze als ich am neuen Raspberry PI 2 W eine Kamera angeschlossen habe, die einfach nicht funktionierten wollte.

Als ich dann dasselbe Problem an einem Raspberry Pi 3 hatte, der ebenfalls mit Raspberry OS Bullseye lief, wurde ich nachdenklich und begann eine Recherche. Der Grund ist, dass mit Bullseye andere Kommandos verwendet werden müssen. Aus Raspistill und Raspivid wurde nun libcamera.

Im Vergleich:

Aus dem Kommando raspistill -o pic.jpg wird libcamera-jpg -o pic.jpg

Warum die Raspberry Foundation, die sonst so viel Wert auf Abwärtskompatibilität legt, das in diesem Fall nicht tut, bleibt mir verschlossen. Angeblich will man kompatibler zu Industriestandards werden. Dahinter steht Libcamera

Beschreibung auf der Webseite von Libcamera:

Eine komplexe Kamera-Unterstützungsbibliothek für Linux, Android und ChromeOS

Kameras sind komplexe Geräte, die umfangreiche Hardware-Bildverarbeitungsoperationen benötigen. Die Steuerung der Verarbeitung basiert auf fortschrittlichen Algorithmen, die auf einem programmierbaren Prozessor laufen müssen. Dies wurde traditionell in einer dedizierten MCU in der Kamera implementiert, aber in eingebetteten Geräten wurden die Algorithmen auf die Haupt-CPU verlagert, um Kosten zu sparen. Durch die Verwischung der Grenze zwischen Kamerageräten und Linux blieb dem Benutzer oft keine andere Wahl als eine herstellerspezifische Closed-Source-Lösung.
Um dieses Problem zu lösen, arbeitet die Linux-Medien-Community mit der Industrie zusammen, um einen Kamera-Stack zu entwickeln, der Open-Source-freundlich ist und gleichzeitig die Kern-IP des Anbieters schützt. libcamera wurde aus dieser Zusammenarbeit geboren und bietet moderne Kamera-Unterstützung für Linux-basierte Systeme, einschließlich traditioneller Linux-Distributionen, ChromeOS und Android.

Die offizielle Erklärung und Beschreibung zur Verwendung mit dem Raspberry findet sich auf der Raspberry Pi Homepage  Aus diesem Grund sind Millionen Tutorials, die seit dem Erscheinen des Raspberry Pi im Jahr 2012 erstellt wurden, mit dem neuen OS nicht mehr verwendbar. Ebenso sind Python Programme nicht mehr verwendbar, da die picamera Bibliothek nicht mehr verwendbar ist. Ob und wie die Raspberry Foundation in Zukunft doch noch eine Abwärtskompatibilität herstellen will, bleibt abzuwarten Die zurzeit einzige Lösung, ist das vorige Raspberry OS Buster weiterzuverwenden.

Quelle: https://libcamera.org/

Quelle: https://www.raspberrypi.com/

22. November 2021

Da ich mit dem ThinkPad auch gern mal in dunklen arbeite kam der Wunsch auf die Tastaturbeleuchtung zu nutzen. Ich habe mal schnell die Einstellungen überflogen und leider nichts passendes gefunden. Nachdem ich die Frage kurz in die Suchmaschine meines vertrauens geworfen habe, kam der (für mich so erwartete) Tipp den wert direkt das Verzeichnis /sys/class zu schreiben.

Mit folgenden Befehl als root ausgeführt kann ich die Tastaturbeleuchtung direkt einschalten:
echo 2 > /sys/class/leds/tpacpi\:\:kbd_backlight/brightness

Man kann die “2” auch gegen eine “1” tauschen und damit die Helligkeit reduzieren und bei einer “0” ist die Beleuchtung ausgeschaltet.

Mozilla hat mit Firefox 94.0.2 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht.

Download Mozilla Firefox 94.0.2

Mit dem Update auf Firefox 94.0.2 behebt Mozilla eine mögliche Absturzursache, welche einen größeren Teil der Linux-Nutzer potentiell betreffen konnte, sowie eine weitere mögliche Absturzursache. Außerdem wurden Performance-Probleme behoben, die für Nutzer assistiver Technologien wie einem Screenreader auftreten konnten, wenn Firefox über den Microsoft Store installiert worden ist. Dazu kommen noch diverse Anpassungen in Zusammenhang mit Firefox Suggest, einem Feature, welches nur für Nutzer in den USA aktiviert ist.

Der Beitrag Mozilla veröffentlicht Firefox 94.0.2 erschien zuerst auf soeren-hentzschel.at.

Mo, 22. November 2021, Ralf Hersel

Es ist viereinhalb Jahre her, seit Canonical bekannt gab, den Unity-Desktop anstelle von GNOME aufzugeben, und den Fokus auf die Cloud und IoT-Geräte zu verlagern. Die Reaktionen der Community waren damals gemischt. Einige Leute mochten GNOME, andere nicht. Diejenigen, die es nicht mochten, wechselten zu anderen Desktops wie Cinnamon, MATE, KDE und Xfce. Ubuntu-Nutzer nach 2017 wissen vielleicht nicht einmal, dass es den Unity-Desktop gibt. Aber eine Gruppe von Menschen weigerte sich, Unity loszulassen. Diese Leute gründeten ihr eigenes Ubuntu-Derivat mit dem Namen "Ubuntu Unity Remix", das später einfach als Ubuntu Unity bekannt wurde.


Die Version 21.10 von Ubuntu Unity wurde letzten Monat veröffentlicht, zusammen mit den anderen Ubuntu 21.10-Derivaten.

Die Gemeinschaft, die hinter der Distribution steht, ist allerdings sehr klein. Die offizielle Website und die Bug-Tracker sind halbtot, und es gibt kaum Updates über den Fortschritt der geleisteten Arbeit. Es ist in der Tat eine gewaltige Arbeit diesen Desktop weiterzuentwickeln. Vielleicht wäre es die bessere Strategie, Unity 7 so zu belassen, wie es ist, und nur Fehler zu beheben und kleine neue Funktionen einzuführen.

Schliesslich konnte selbst Canonical mit seinen Ressourcen die Entwicklung von Unity 8.x (das mit dem Qt-Toolkit entwickelt werden sollte) nicht abschliessen, sodass es unwahrscheinlich ist, dass ein oder zwei einzelne Entwickler in absehbarer Zeit eine ähnliche Leistung alleine erbringen können. Insgesamt ist es also eine schwierige Situation für den Unity Desktop. Und ob er in den kommenden Ubuntu-Releases installierbar bleiben wird, hängt ganz von den wenigen Freiwilligen ab, die daran arbeiten.

Quelle: https://ubuntuunity.org/post/ubuntu-unity-21.10/

Mo, 22. November 2021, Lioh Möller

In einem Changelog-Eintrag vom 17.11.2021 hat der Slackware Gründer Patrick Volkerding einen Hard-Freeze für den Entwicklerzweig der Distribution namens -current angekündigt.

Clearly we're going to have to tread more carefully for things to settle down,
so consider this RC2 and a much harder freeze. A test mass rebuild was done
here and there are no more "fails to build from source" remaining (thanks to
nobodino for some amazing and relentless testing).

Mit dem als RC2 deklarierten Stand nähert sich die Distribution der kommenden stabilen Version 15.0, welche möglicherweise noch in diesem Jahr veröffentlicht werden wird. Alle ausstehenden Fehler, bei dem Übersetzen von Paketen aus dem Quellcode konnten bereits ausgeräumt werden.

Interessierte Anwender sind eingeladen, den aktuellen Stand des Entwicklerzweiges zu testen und etwaige Schwierigkeiten bei der Installation und Nutzung zu melden.

Auch der auf Slackware aufbauende Linux-Kurs wurde bereits angepasst. Test und Feedback sind hier ebenfalls ausdrücklich erwünscht, wobei die Installation aktuell mit einem inoffiziellen -current Installationsmedium durchgeführt werden sollte.

Download: https://slackware.nl/slackware/slackware64-current-iso/slackware64-current-install-dvd.iso
Linux-Kurs Git: https://notabug.org/LiohMoeller/LinuxKurs

Ein Web Key Directory (WKD) stellt einen einfachen Weg bereit, um öffentliche GnuPG-Schlüssel für E-Mail-Adressen über eine HTTPS-Verbindung abzurufen. Es ist dazu gedacht, die Benutzererfahrung zur Nutzung verschlüsselter E-Mail-Kommunikation zu vereinfachen.

Ich bin dem ausführlichen Artikel „GnuPG: Web Key Directory (WKD) einrichten“ von Mike Kuketz gefolgt und habe ein WKD für E-Mail-Adressen unter meiner Domain „my-it-brain.de“ konfiguriert. Denn ich teile seine Auffassung:

WKD ist nach meiner Auffassung eine benutzerfreundliche Alternative für den Austausch von Schlüsseln, da Clients wie Thunderbird/Enigmail diesen Standard bereits verwenden, um beim Verfassen einer E-Mail automatisch den öffentlichen Schlüssel eines Benutzers abzurufen. Insgesamt wird der Schlüsseltausch mit WKD stark vereinfacht – das steigert insgesamt die Nutzerfreundlichkeit der E-Mail-Verschlüsselung.

https://www.kuketz-blog.de/gnupg-web-key-directory-wkd-einrichten

Probiert es doch selbst einmal aus. Verschlüsselte E-Mail-Kommunikation wird dadurch deutlich vereinfacht.

Quellen und weiterführende Links

21. November 2021

Erstmal ein paar Sätze zu meinem beruflichen Hintergrund:

Seit Ende meines Studiums arbeite ich bei einem kleinen Unternehmen, welches IT-Forensik bzw. e-Discovery betreibt. Dort entwickle ich, zusammen mit meinen Kollegen, eine Pipeline zur Analyse von Kommunikationsdaten (Vorrangig in Python und Java). Ein wichtiges Merkmal unserer IT-Infrastruktur ist, dass unsere Server und Entwickler-PCs keinen Internetzugang besitzen. Zum Surfen und E-Mails schreiben haben alle Mitarbeiter einen zusätzlichen Laptop oder PC zur Verfügung. Jedes Programm muss also ohne Internetzugang funktionieren und darf auch keine externen Daten nachladen.

Was nach einer trivialen Anforderungen klingt, stellte sich z.B. beim Finden einer Alternative zu Jira als ein sehr großes Problem heraus. Wenn man rein auf OSS-Programme setzen will, kommt man irgendwann an einen Punkt an dem das Programm einen normalen Internetzugang verlangt (Weil z.B. Javascript-Bibliotheken von externen Servern nachgeladen werden). In der Welt von nahezu allen OSS-Entwicklern gibt es anscheinend die Einstellung, dass jeder Server einen Zugang zum Internet haben muss, egal wie sensibel die darauf abgelegten Daten auch sein mögen. Das ist aber ein anderes Thema.

Das Problem

Ich suchte eine einfache und unkomplizierte Möglichkeit die diversen Statusnachrichten unserer Server bzw. NAS an einer zentralen Stelle zu sammeln.

Einfach und unkompliziert heißt folgendes:

  1. Kein SNMP, da dessen Einsatz den Kosten/Nutzenfaktor in unserem kleinen Netzwerk übersteigt. Unsere Infrastruktur ist aktuell noch recht überschaubar (Ca. ein Dutzend Server und NAS).
  2. Kein interner Mail-Server, da er auch zu pflegen und er nur für den Versand und Empfang von Statusmeldungen vorhanden wäre. Dazu käme dann noch ein E-Mail-Client auf meinem Rechner, der nur für diese Meldungen da wäre und sonst nichts weiteres.
  3. Die einzelnen Programme sollten einfach so ihre Statusmeldungen versenden können, ohne dass man den Quellcode verändern muss.

Die Lösung

Da wir zur internen Kommunikation RocketChat einsetzen, lag es nahe die Statusmeldungen direkt an diesen Server zu senden. Leider konnte ich keine Software finden, welches es ermöglicht auf einfache Weise eine E-Mail an einen RocketChat-Server zu senden. Es gibt zwar Tools, welche z.B. nach Nachrichten auf normalen E-Servern lauschen und diese dann an RocketChat weiterleiten. Aber das führt dann wieder zu Ausschlusskriterium #2 (Kein zusätzlicher E-Mail-Server).

Am Ende blieb mir nichts anderes übrig als das Gateway selbst zu programmieren. Ich wollte dies zuerst in Python erledigen, da es eine brauchbare API für RocketChat gibt. Leider hat Python immer noch Riesenprobleme, wenn es um die Handhabung von EML-Dateien (Sprich E-Mails) und UTF-8 geht (Die Kodierung eines HTML-formatierten E-Mail-Body löste reproduzierbar eine Exception aus, welche ich nicht ohne Weiteres beseitigen konnte).

Der einzig sinnvolle Weg war die Teile der RocketChat-API in Java zu implementieren, welche ich zwingend benötigte (Senden von Nachrichten und Anhängen an einzelne Benutzer oder Gruppen). Unter Java hatte ich nämlich noch nie Probleme beim Verarbeiten von E-Mails (Die Zahl der verarbeiteten E-Mails in unserer Pipeline dürfte sich langsam auf eine Milliarde zubewegen).

Zusätzlich gibt es in Java eine sehr gute Bibliothek namens SubEthaSMTP bzw. deren Fork zum Implementieren eines SMTP-Servers:

https://github.com/davidmoten/subethasmtp

Der Riesenvorteil an dieser Bibliothek ist, dass sie sehr einfach einzusetzen ist und sie auch die Möglichkeit anbietet eine Authentifizierung zu aktivieren (z.B. Benutzername und Passwort). Denn einige Programme oder Serverdienste (z.B. TrueNAS) verlangen einen Benutzernamen und ein Passwort beim Einrichten der SMTP-Verbindung. Auch SSL bzw. TLS stellen in Verbindung mit einer Zusatzbibliothek kein großes Problem dar.

Das Gateway macht am Ende nichts anderes als einen SMTP-Server bereitzustellen und die ankommenden E-Mails je nach Empfänger an den passenden RocketChat-Benutzer oder die passende Gruppe weiterzuleiten. Dabei werden HTML-Nachrichten in Textnachrichten konvertiert und die originale HTML-Nachricht als Datei versendet. Das wurde deshalb so implementiert, da RocketChat aus Sicherheitsgründen keine HTML-Nachrichten darstellen kann und der Markdownparser nicht alle benötigten Tags (z.B. Tabellen) unterstützt. Normale Dateianhänge werden ebenfalls als Datei versendet.

Zwei Voraussetzungen hat das Gateway:

  1. Man muss einen Bot-Nutzer auf dem RocketChat-Server anlegen.
  2. Dieser muss das Recht haben die E-Mail-Addressen aller Benutzer auszulesen. Am besten legt man dafür eine zusätzliche Bot-Gruppe an, welche nur vom Gateway-Bot benutzt wird.

Optional kann eine „spam“-Gruppe angelegt werden. Dort landen dann, wenn man möchte, alle E-Mails deren Empfänger nicht bekannt ist. So sieht man sehr schnell, bei welchen Diensten man noch nachbessern muss.

Jetzt reicht es in den jeweiligen Programmen bzw. Webdiensten den SMTP-Server des Gateways und eine passende Empfängeraddresse anzugeben um E-Mails als RocketChat-Nachrichten zu empfangen.

Download des Programms

Ich habe das Gateway auf meinem Github-Account gehostet:

https://github.com/glasen/rocketgateway

„Digitale Souveränität“ und solche Abkömmlinge wie „souveräner Arbeitsplatz“ gehören seit einiger Zeit zum politischen Wortschatz. Dieser Artikel thematisiert, warum die aktuell anvisierten Maßnahmen dieses Ziel nicht erreichen können und allen ein verbales Abrüsten im Sinne eines allgemeinen Realismus guttäte.

Digitale Souveränität gehört zu jenen Grundbegriffen, die gerne in einem Atemzug mit Datenschutz oder Datensicherheit genannt werden, aber im Grunde genommen nur wenige Schnittmengen haben.

Wikipedia enthält folgendes zur Bedeutung des Begriffes:

Abgeleitet von dem Begriff der Souveränität versteht man unter digitaler Souveränität selbstbestimmtes Handeln unter vollständiger, eigener Kontrolle im Hinblick auf die Nutzung digitaler Medien. Der Begriff beschreibt zum einen die Notwendigkeit des souveränen Handelns in direktem Umgang mit digitalen Medien (z. B. Smartphones, Tablets, Internet etc.). Zum anderen erwarten Experten, dass die Entwicklung von digitaler Souveränität auch in verschiedenen anderen Bereichen (z. B. Kultur, Bildung, Politik und Forschung) indirekt „zukünftig stark über Nutzung und Erfolg“ entscheiden wird.

Wikipedia Artikel „Digitale Souveränität“, abgerufen am 21.11.2021

Das ist ein eher unscharfer Zugriff, deshalb lohnt sich noch ein Blick in den Artikel zur Souveränität. Dort steht:

Unter dem Begriff Souveränität (französisch souveraineté, aus mittellateinisch superanus ‚darüber befindlich‘, ‚überlegen‘) versteht man in der Rechtswissenschaft die Fähigkeit einer natürlichen oder juristischen Person zu ausschließlicher rechtlicher Selbstbestimmung. Diese Selbstbestimmungsfähigkeit wird durch Eigenständigkeit und Unabhängigkeit des Rechtssubjektes gekennzeichnet und grenzt sich so vom Zustand der Fremdbestimmung ab. In der Politikwissenschaft versteht man darunter die Eigenschaft einer Institution, innerhalb eines politischen Ordnungsrahmens einziger Ausgangspunkt der gesamten Staatsgewalt zu sein.

Wikipedia Artikel „Souveränität“, abgerufen am 21.11.2021

Das Vorhaben wird aus mindestens fünf Gründen nicht gelingen und bestenfalls in Teilen umgesetzt werden können:

  1. Markenrechte
  2. (Unfreie) Treiber
  3. (Unfreie) Firmware
  4. Souveräne Infrastruktur
  5. Dienstleister

1. Rechte und ihre Folgen

Open Source klingt immer so ganz wunderbar frei. Code von einer weltweiten Community gemeinsam geschrieben unter einer freien Lizenz usw. usf. Leider ist dem nicht so, weil sich Open Source in ein festgefügtes (juristisches) System einfügen musste. Das Problem hatte ich in einem anderen Kontext schon am Beispiel von Fedora deutlich gemacht. Auf der Webseite von Fedora steht im Abschnitt Download:

Durch das Herunterladen von Fedora, erklären Sie sich mit den folgenden Nutzungsbedingungen einverstanden.

Indem Sie Fedora Software herunterladen, bestätigen Sie, dass Sie das Folgende verstehen: Fedora Software und technische Informationen kann Exportkontrollvorschriften der USA (U.S. Export Administration Regulations, “EAR”) und weiteren Gesetzen der USA und anderer Länder unterliegen und darf nicht ausgeführt, wieder ausgeführt oder weitergeleitet werden (a) in irgendein Land, das in Ländergruppe E:1 des Supplement No. 1 zu EAR Part 740 aufgeführt ist (momentan Kuba, Iran, Nordkorea, Sudan und Syrien); (b) an irgendein Ziel oder irgendeinen Endbenutzer, dem die Teilnahme an US Exporttransaktionen durch irgendeine Bundesbehörde der US Regierung untersagt ist; oder (c) zum Gebrauch in Verbindung mit der Konstruktion, der Entwicklung oder Herstellung von nuklearen, chemischen oder biologischen Waffen oder Raketensystemen, Trägerraketensystemen oder Höhenforschungsraketen oder unbemannten Luftfahrzeugsystemen. Sie dürfen Fedora Software oder technische Informationen nicht herunterladen, wenn Sie sich in einem der genannten Länder befinden oder auf eine andere Weise diesen Einschränkungen unterliegen. Sie dürfen Fedora Software oder technische Informationen weder Personen noch Einrichtungen zur Verfügung stellen, die sich in einem dieser Länder befinden oder auf eine andere Weise diesen Einschränkungen unterliegen. Weiterhin sind Sie für die Einhaltung rechtlicher Anforderungen anderer Länder bezüglich Einfuhr, Ausfuhr und Benutzung von Fedora Software und technischer Informationen verantwortlich.

Fedora Workstation herunterladen, abgerufen am 21.11.2021

Von der Nutzung sind also alle jene Staaten ausgeschlossen, die sich gerade in einem tiefer gehenden Konflikt mit den USA befinden und die Verwendung wird auch stark beschränkt. Souveränität wäre das nicht. Das betrifft jedwede Software bzw. Marken, deren Rechteinhaber in den USA sitzen. Die meisten davon sind halt nur nicht so transparent und schreiben das auf der Webseite.

Für einen „souveränen Arbeitsplatz“ bräuchte man also mindestens eine Distribution, die nur Software enthält, deren (Marken-)rechteinhaber auch in Deutschland sitzen. Alle anderen Projekte müssten geforkt und von problematischen Bestandteilen bereinigt werden. So wie Debian das lange bei Firefox und Thunderbird getan hat. Faktisch läuft das auf eine eigene Distribution hinaus.

2. (Unfreie) Treiber

Diese Distribution müsste man auf Hardware installieren. Leider ist es mit der freien Treiberversorgung nicht so weit her, wie wir alle gerne glauben. Das liegt daran, dass die allermeisten Distributionen standardmäßig unfreie Treiber bzw. sogenannte Firmware-Blobs mitliefern. Jeder, der mal seine Hardware nur mit Debian main oder Trisquel zum Laufen bringen wollte, weiß worum es geht.

Ein „souveräner Arbeitsplatz“ mit unfreien Treibern schließt sich aus, weil die Hardware- bzw. Treiberhersteller im Fall der Fälle die Zusammenarbeit einstellen würden und man vor dem gleichen Problem stünde wie nun mit Microsoft. Ausgenommen Hardwarehersteller mit Sitz in Deutschland – ein sehr vielfältiges Angebot also.

3. (Unfreie) Firmware

Ein Betriebssystem ist nett, aber längst nicht mehr alles, was heute so auf einem normalen Gerät läuft. Unter dem saloppen Begriff „Firmware“ verbirgt sich bei den meisten Herstellern quasi ein Betriebssystem unter dem Betriebssystem. UEFI, Intel Active Management Technology (früher „Intel Management Engine“). usw. usf. Ich erzähle hier wahrlich nichts Neues.

Ein kleines Beispiel: Mein HP EliteBook kann im UEFI selbstständig über eine Internetverbindung Updates für die Firmware beziehen, ohne dass mein Betriebssystem gestartet ist.

Ein „souveräner Arbeitsplatz“ dürfte nur Hardware beinhalten, über die man auch wirklich die Kontrolle hätte. Also dürfte man eigentlich nur aus dem reichhaltigen Pool an deutschen Hardwareproduzenten schöpfen.

4. Souveräne Infrastruktur

Ein „souveräner Arbeitsplatz“ existiert nicht ohne souveräne Infrastruktur. Inklusive einer vollständigen Hoheit über die Rechenzentren und Datenübertragung. Das führt auch in Bereiche, wie die Auseinandersetzung, um den Einsatz von Huawei-Hardware im Mobilfunknetz. Es gibt hier somit Schnittstellen zu anderen strittigen Themen.

In den vollständig „souveränen Rechenzentren“ dürfte natürlich keine Hardware mit unfreien Treibern und unfreier Firmware (siehe oben) stehen, um auch wirklich die Kontrolle über Hard- und Software zu haben.

Diese umfassende Infrastruktur müsste entweder direkt von staatlichen Stellen oder von vertrauenswürdigen Dienstleistern betrieben werden, womit wir beim nächsten Problem wären.

5. Dienstleister

Es dürfte unstrittig sein, dass es der öffentlichen Hand unmöglich ist, das komplette Portfolio eines „souveränen Arbeitsplatzes“ selbst anzubieten. Spätestens durch die Einbeziehung der Hardware wäre hier eine Grenze erreicht.

Deshalb benötigt man Dienstleister und hier beginnt das Problem. Wenn der „souveräne Arbeitsplatz“ dann wie die Corona Warn App von SAP oder T-Systems programmiert wird, mag das noch klappen, aber hinter der jüngst spektakulär gescheiterten ID wallet stand letztlich IBM. Wie souverän ist ein Arbeitsplatz, der letztlich doch wieder von amerikanischen IT-Konzernen programmiert wird?

Natürlich, es soll alles freie und offene Software sein, aber jedem dürfte klar sein, dass man hier im Fall der Fälle nicht einfach den Git-Zugang einem anderen Dienstleister geben und sagen kann „mach da weiter“.

Es bedürfte also umfassender Kriterien und Sicherheitsüberprüfungen, um herauszufinden, wer als Dienstleister für den „souveränen Arbeitsplatz“ infrage käme. Insbesondere kleinere Dienstleister mit unzureichenden Sicherheitsstandards könnten sonst ein Einfallstor für Spionage usw. usf werden.

Zusammengefasst

Es wird keinen „souveränen Arbeitsplatz“ geben. Dabei handelt es sich nur um einen politischen Modebegriff, auf den zu viele gerade anspringen. Letztlich gibt es bestenfalls einen in Teilen quelloffenen Arbeitsplatz. Also wenn man so will einen „Open Source Arbeitsplatz“, von dem man auch noch abwarten muss wie „Open“ der sein wird und ob nicht letztlich doch wieder die großen IT-Konzerne mitarbeiten. Hört sich gleich viel weniger sexy an.

Der Artikel Warum ein „souveräner Arbeitsplatz“ Utopie bleibt erschien zuerst auf [Mer]Curius

20. November 2021

Irgendwie hat das Thema nun zu Jahresende Konjunktur. Vermutlich weil man sich langsam über die guten Neujahrsvorsätze Gedanken machen kann. Der Staat will mal wieder auf Open Source umsteigen. Anstelle digitaler Zukunftsthemen reden wir aber über LibreOffice.

Ich möchte das gleich vorweg schreiben, weil das in den bisherigen Blogbeiträgen zu dem Thema vielleicht nicht so deutlich wurde:

Natürlich bin ich für den Einsatz von Open Source im Staatseinsatz. Mir fällt auch gar kein Grund ein, warum man dagegen sein sollte. Ich finde es auch gut, wenn der Staat hier die Initiative ergreift, langfristige Konzepte entwirft, daraus Strategie entwickelt und dem auch Taten folgen lässt. Der Trend zu Open Source-Lösungen ist ungebrochen und ich kann keine Organisation verstehen, die sich im Jahr 2021 sehenden Auges bei gleichwertigen Open Source-Alternativen auf proprietäre Software einlässt. Allerdings sehe ich auch nicht, dass dies blindlings irgendwo passieren würde.

Das ist auch für das Kernthema dieses Blogs – Datenschutz und digitale Privatsphäre – ein sehr relevantes Thema, weil jedwede Absicherung im privaten Umfeld wenig Sinn macht, wenn die staatlicherseits erhobenen Daten völlig unzureichend gesichert z. B. in die AWS-Cloud übertragen werden.

Was ich nicht leiden kann – und deshalb schreibe ich diese Blogartikel – sind weltfremde Debatten von IT-Redakteuren, die keine Ahnung vom Staatsbetrieb haben, auf jede PR-Meldung unhinterfragt aufspringen und keine Mühe auf Recherche verwenden. Flankiert von Kommentatoren, bei denen man sich bei der einen Hälfte wirklich fragen muss, ob sie überhaupt schon mal in einem ernst zu nehmenden Großunternehmen (denn nichts anderes ist der Staat) tätig waren und bei der anderen ob ihr Renteneintritt schon vor dem Jahr 2000 war. Das ganze Thema dann noch befeuert, von einer Open Source-Community, die in substanziellen Teilen im Gestern lebt und die Zukunft geflissentlich ignoriert.

Denn genau das konnte man diese Woche wieder mal beobachten. Schleswig-Holstein hat als einziges Bundesland eine ernst zu nehmende Open Source-Strategie. Die Absichtserklärung kann man hier nachlesen. Diese Erklärung ist durchaus interessant zu lesen, es werden Verweise auf die Bedeutung von Daten im 21. Jahrhundert und eine zunehmende Digitalisierung der öffentlichen Verwaltung geschrieben. Es geht um Webauftritte, Intranet-Services, Kollaborationsplattformen usw. usf.

Dabei ist es nicht so, dass sich die Projekte Schleswig-Holsteins in dieser Absichtserklärung erschöpfen würde – so wie das bei vielen anderen Ländern und dem Bund gegenwärtig der Fall ist. Einen ausführlicheren neueren Bericht mit verlinkten Videos kann man hier lesen. Da geht es dann um Projekte wie die dPhoenixSuite oder Nextcloud in der Verwaltung. Das sind meiner Meinung nach die wirklich interessanten Open Source-Projekte für den öffentlichen Dienst. Denn hier geht es auch um die Frage, welche Dienstleister man betraut und was man durch Firmen der öffentlichen Hand abdecken möchte. Das sind keineswegs triviale Fragen, weil ein Dienstleister nicht automatisch vertrauenswürdig wird, nur weil er aus Deutschland kommt. Der Bund muss das gerade schmerzlich erfahren, denn der Chef des Dienstleisters für die Absicherung der Kommunikation steht im Verdacht Verbindung zum flüchtigen Jan Marsalek gehabt zu haben (s. schriftliche Anfrage der Linkspartei und Bericht des SPIEGEL).

Und worüber berichtet die „Presse“: Die geplante Migration auf LibreOffice und die lose anvisierte Umstellung auf Linux in ferner Zukunft. Echt jetzt? Zumal bei LibreOffice bzw. The Document Foundation nicht mal klar ist, ob es ein offizielles Supportvertragsverhältnis gibt.

Ich bin mir nicht sicher, ob diese Berichte mehr über die Community oder das Staatsbild der Berichterstatter aussagt. Hängt die Open Source-Community wirklich noch so am Desktop und irgendwelchen an Anciennität kaum zu überbietenden Softwarelösungen wie LibreOffice, dass man unfähig ist, die Gegenwart, geschweige denn die Zukunft zu sehen? Oder glaubt man wirklich, der Staat wäre so wenig digitalisiert, dass es ein bisschen Desktop und eine Office-Suite schon tut? Oder schreibt man einfach nur Pressemitteilungen der TDF ab, weil die auch dringend mal wieder positive Neuigkeiten brauchen? Immerhin taumelt das LibreOffice-Projekt in der jüngeren Vergangenheit eher als eine zielgerichtete Projektentwicklung zu kommunizieren.

Ganz nebenbei kann man das Projekte auch mal einordnen. Das ist bisher auch vollständig ausgeblieben. Schleswig-Holstein ist ein Bundesland, das hört sich natürlich erst mal groß an. Deshalb ist eine Zahl sehr interessant, die nur in einem einzigen Artikel – nämlich bei Golem – erwähnt wurde: 25.000. Das sind alle Arbeitsplätze, um die es geht. Das beinhaltet alle Landesbeamten und -angestellten inklusive der Lehrkräfte. Jeder kann diese Zahl wohl einordnen. Das Projekt ist nicht klein, klein wären die Vorhaben von z. B. Dortmund, aber groß ist auch was anderes. Nur mal so zum Vergleich, die Stadt München – um mal an ein früheres Projekt zu erinnern – hat ausweislich offizieller Informationen fast 40.000 Mitarbeiter. Viele Firmen oder auch nur Universitäten mit angeschlossenen Unikliniken kommen auf Mitarbeiter- bzw. Arbeitsplatzzahlen, die von den Zahlen in Schleswig-Holstein nicht so weit entfernt sind. Es ist eben auch „nur“ Schleswig-Holstein – nicht gerade das flächen- oder bevölkerungsmäßig größte deutsche Bundesland. Die Reichweite solcher Maßnahmen ist deshalb auch begrenzt. Ein umtriebiger, öffentlichkeitswirksamer und in der Community gut gelittener Digitalminister kann das auch nur begrenzt ausgleichen.

Das führt zu einem weiteren Punkt. Es gibt zig interessante Projekte im Staatsumfeld, wo Open Source evaluiert oder die Migration bereits angestoßen ist. Das sind teilweise riesige Unterfangen mit großen Budgets, vielen betroffenen Mitarbeitern und noch mehr betroffenen Bürgern. Ich hatte da mal für einen Spezialfall berichtet. Diese Projekte werden selten thematisiert, weil sie ganz offenkundig den Horizont der Journalisten der großen IT-Medien und der Community übersteigen. Die kennen nur „Linux“ und „LibreOffice“. Und damit will man die Zukunft repräsentieren?

Trotzdem wäre es natürlich schön, wenn Schleswig-Holstein Erfolg haben sollte und 2026 wirklich Microsoft Office ablöst und anschließend die Linux-Migration auf dem Desktop startet. Mal sehen, ob es 2030-2035 noch Desktopsysteme nach heutigem Vorbild gibt. Denn das sind die Zeiträume, von denen wir hier reden.

Der Artikel Staat und Open Source – Diese Woche Schleswig-Holstein erschien zuerst auf [Mer]Curius

19. November 2021

Die MZLA Technologies Corporation hat mit Thunderbird 91.3.2 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.3.2

Mit dem Update auf Thunderbird 91.3.2 hat die MZLA Technologies Corporation ein Update außer der Reihe für seinen Open Source E-Mail-Client veröffentlicht und behebt damit mehrere Fehler der Vorgängerversion. Diese lassen sich in den Release Notes (engl.) nachlesen.

Der Beitrag Thunderbird 91.3.2 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

17. November 2021

Mo, 15. November 2021, @65536@troet.cafe

Die Installation von NixOS stelle eine gewisse Hürde dar. NixOS verfügt nicht über einen komfortablen GUI-Installer wie Calamares oder Anaconda. Es stehen ISO-Images für Livesysteme zur Verfügung, welche eine ausführliche Anleitung und die Kommandozeilenwerkzeuge zur Installation beinhalten. Allerdings ist auch nicht allzu viel Vorwissen zur Installation nötig. Neben Englischkenntnissen zum Lesen der Anleitung ist lediglich das händische Partitionieren und Mounten wichtig, falls man von dem vorgegebenen Beispiel abweichen möchte.

Wichtig: diese Artikelserie soll weniger eine Anleitung darstellen, als eine grobe Vorstellung davon zu vermitteln, was den Interessierten bei NixOS erwartet.

Dokumentation finden

Es sind einige Dokumentationen verfügbar, um mit den zahlreichen Optionen der Konfigurationsdatei und den Nix-Befehlen etwas anfangen zu können. NixOS bringt die besagte Anleitung mit, die wahlweise mit nixos-help, als Eintrag im Anwendungsmenü oder unter https://nixos.org/manual/nixos/stable zu finden ist. Darüber hinaus gibt es https://search.nixos.org zum Finden von Paketen und Konfigurationsoptionen sowie das inoffizielle Nixos-Wiki, welches zwar bei einigen Dingen weiterhilft, an manchen Stellen aber etwas knapp oder veraltet ist. Das liegt an der vergleichsweise kleinen NixOS-Community.

Festplatte partitionieren

Die Partitionierung erfolgt manuell im Terminal, beispielsweise mit parted. Im Live-System ist dazu sudo su ohne Passwort möglich, da hier ein Passwort sinnlos wäre. Sofern man mit der Beispielpartitionierung der Anleitung zufrieden ist (boot, Swap und eine grosse unverschlüsselte ext4-Partition), kann man der Anleitung folgen, andernfalls sollte man die nötigen Befehle kennen oder nachschlagen. Die Partitionen müssen dann passend formatiert und so eingehängt werden, dass /mnt/ die Wurzel der neuen NixOS-Instanz darstellt.

Konfiguration generieren

Mit nixos-generate-config --root /mnt werden automatisch zwei Dateien in /mnt/etc/nixos/ angelegt. configuration.nix ist diejenige der beiden, die bearbeitet werden sollte. Es ist empfehlenswert, dazu insbesondere die Anleitungsabschnitte '13. Networking' sowie wahlweise '9. X Window System', '10. Wayland', oder einen gesonderten Abschnitt zu Gnome, Pantheon oder XFCE anzusehen. Definitiv sollte die Konfigurationsdatei auch einmal samt Kommentaren sorgfältig durchgelesen werden, um Dinge wie Zeitzone, Tastaturschema, Sound und zusätzliche Software korrekt zu deklarieren. Selbstverständlich sollte die Konfiguration anschliessend gespeichert und geschlossen werden.

NixOS installieren

nixos-install ist nun alles, was zur Installation nötig ist. Das System wird so aufgesetzt, wie es die Konfiguration vorschreibt, und keinerlei manuelles Kopieren oder weiteres Installieren und Konfigurieren ist nötig. All das wurde ja schon im vorherigen Schritt getan. Zum Abschluss des Installationsbefehls fragt dieser nach dem gewünschten Rootpasswort, und ein zweites Mal zur Bestätigung. Dann kann neu gestartet werden, anstatt ins Livemedium in die frische Installation. Sofern nicht bereits deklarativ geschehen, sollte man nun im Textmodus den Alltagsbenutzer erstellen und ein Passwort vergeben, um nicht den Rootaccount nutzen zu müssen. Das ist auch imperativ mit den klassischen Befehlen useradd und passwd möglich.

Konfiguration ändern

Die Datei /etc/nixos/configuration.nix kann jederzeit angepasst werden, um die verfügbare Software, aktivierten Dienste und vieles mehr zu ändern. sudo nixos-rebuild boot wendet die Datei neu auf das System an, so, dass beim nächsten Systemstart die neue Konfiguration gilt. Ungeduldige können sie stattdessen mit sudo nixos-rebuild switch sofort anwenden. Manche Desktopumgebungen benötigen dann jedoch wenigstens ein Ab- und Anmelden, um neue Software wahrzunehmen.

Sehr hilfreich ist hierbei die Suchseite von NixOS nicht nur zum Finden der richtigen Pakete, sondern auch um die benötigten Einstellungsoptionen zu ermitteln.

Booteinträge verstehen

Jeder nixos-rebuild legt einen neuen Eintrag im Bootmenü an. Geht etwas schief, kann man somit einfach einen älteren, funktionierenden Systemzustand auswählen. Diese Systemstände sind alle im Nix-Store abgelegt. Wie man ältere Stände loswird, um Speicherplatz freizugeben, wird im nächsten, dritten Teil dieser Artikelserie behandelt werden.

Links

https://nixos.org/
https://nixos.org/manual/nixos/stable/
https://nixos.wiki/
https://search.nixos.org/options

16. November 2021

Firefox Relay ist ein kostenloser Dienst von Mozilla, der die persönliche E-Mail-Adresse vor Spam und unerwünschter Offenlegung schützt. Nun hat Mozilla mit Firefox Relay Premium ein kostenpflichtiges Zusatz-Angebot gestartet.

Was ist Firefox Relay?

E-Mail-Adressen sind gleichzusetzen mit einer persönlichen Adresse. Sie sind einmalig und viele Nutzer besitzen nur eine einzige E-Mail-Adresse, die sie teilweise auf dutzenden, wenn nicht gar auf hunderten Websites verwenden. Findet auf einer Website, auf der man mit seiner E-Mail-Adresse registriert ist, ein Datendiebstahl statt, wird damit in vielen Fällen auch die persönliche E-Mail-Adresse offengelegt. Und haben Spammer erstmal eine E-Mail-Adresse in ihrem System, darf man sich auf viele unerwünschte E-Mails ohne realistische Hoffnung einstellen, dass der Spam abnehmen wird.

Mit Firefox Relay können Alias-Adressen angelegt werden, die der Nutzer für Newsletter-Anmeldungen und Website-Registrierungen angeben kann. Firefox Relay leitet diese E-Mails dann an die persönliche E-Mail-Adresse weiter.

Die Nutzung von Firefox Relay ist kostenlos. Stand der Dienst bisher nur in englischer Sprache verfügbar, gibt es Firefox Relay jetzt auch in deutscher Sprache.

Firefox Relay Premium

Außerdem bietet bietet Mozilla ab sofort in diversen Ländern, darunter auch Deutschland, Österreich und die Schweiz, Firefox Relay Premium an. Der zeitlich begrenzte Einführungspreis beträgt 0,99 EUR respektive 1,00 CHF pro Monat.

Mit Firefox Relay Premium können unendlich viele statt wie bisher maximal fünf Alias-Adressen angelegt werden. Weiter ist es mit Firefox Relay Premium möglich, seine eigene E-Mail-Domain zu erhalten. Statt <id>@relay.firefox.com werden die Adressen dann <id>@<eigene_domain>.mozmail.com heißen. Außerdem ermöglicht es Firefox Relay Premium im Gegensatz zur kostenfreien Basis-Version, auf weitergeleitete E-Mails zu antworten.

Firefox Relay Premium

Firefox Relay Premium

Firefox Relay Premium

Firefox Relay Premium

Der Beitrag Mozilla startet Firefox Relay Premium erschien zuerst auf soeren-hentzschel.at.

Die MZLA Technologies Corporation hat mit Thunderbird 91.3.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.3.1

Mit dem Update auf Thunderbird 91.3.1 hat die MZLA Technologies Corporation ein Update außer der Reihe für seinen Open Source E-Mail-Client veröffentlicht und behebt damit mehrere Fehler der Vorgängerversion. Diese lassen sich in den Release Notes (engl.) nachlesen.

Der Beitrag Thunderbird 91.3.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Di, 16. November 2021, Lioh Möller

Kurz nach der Veröffentlichung von AlmaLinux 8.5 (wir berichteten) zieht das Rocky Linux Projekt mit einer neuen Minor-Version nach.

Diese beinhaltet erstmals Secure Boot Unterstützung und die bereits im Upstream Red Hat Enterprise Linux enthaltenen Neuerungen:

  • Ruby 3.0
  • nginx 1.20
  • Node.js 16
  • PHP Version 7.4.19
  • Squid Version 4.15
  • Mutt Version 2.0.7
  • GCC 11
  • LLVM 12.0.1
  • Rust 1.54.0
  • Go 1.16.7
  • OpenJDK 17 und aktualisierte Versionen von OpenJDK 11 sowie OpenJDK 8

Darüber hinaus wird nun bei einer Netzwerkinstallation automatisch mithilfe des FastestMirror DNF Plugins der schnellste Spiegelserver gewählt.

Das sogenannte plus Repository, welches Zusatzsoftware enthält, beinhaltet neu Thunderbird mit PGP Unterstützung und OpenLDAP Serverpakete.

Das rockypi Repository wurde um einen rasperrypi2-Kernel für Raspberry Pi spezifische AArch64 Unterstützung erweitert.

Mithilfe von pkgcompare lassen sich Abweichungen im Projekt im Vergleich zum Upstream auf einfache Weise ermitteln.

Release Notes: https://docs.rockylinux.org/release_notes/8.5/
Download: https://rockylinux.org/download/

15. November 2021

In vielen Blogbeiträgen schreibe ich wie selbstverständlich von der „verschränkten Datenschutz- und Open Source-Community“. Doch was meine ich damit eigentlich?

Das war eine berechtigte Frage, die mich erreichte und ich habe das tatsächlich noch nie erklärt. Wohl, weil es mir (nichts für ungut) trivial erschien. Mit dieser Bezeichnung möchte ich niemanden herabwürdigen oder irgendetwas konstruieren.

Es gibt rund um die Themen „Datenschutz“ und „Open Source“ Gemeinschaften, die sich mit den Themen befassen und sie voranbringen wollen. Das kann man z. B. sehr schön bei den vielen gegenseitigen Referenzierungen bei Twitter beobachten. Teilweise sind das professionelle Akteure (im Sinne, dass diese damit ihren Lebensunterhalt bestreiten), teilweise ehrenamtliche Aktivsten.

Meiner Meinung nach handelt es sich dabei zwar um zwei Communitys, aber die Überlappungszonen sind sehr ausgeprägt. Auf Akteursebene heruntergebrochen heißt das, viele Personen sind in unterschiedlicher Intensität in beiden Themenfeldern aktiv. Vermutlich könnte man das mit einer Netzwerkstudie sogar belegen, aber der Aufwand wäre natürlich enorm.

Also stark vereinfacht: Viele Open Source Enthusiasten finden, dass Datenschutz ein wichtiges Thema ist und viele Datenschutz-Aktivisten glauben, dass Open Source ein wichtiger bzw. der wichtigste Baustein bei der digitalen Selbstverteidigung ist.

Diese Verschränkung kann man beispielsweise bei den Themenfeldern sehen, mit denen sich die Electronic Frontier Foundation befasst.

Das bedeutet natürlich nicht, dass dies bei allen Akteuren so ist. Manche Open Source-Aktivisten scheren sich nicht um Überwachung (und arbeiten dann für Google…), andere Datenschutz-Aktivisten halten Open Source für ein nachrangiges Thema.

Auf diesem Grund schreibe ich häufiger mal von der „verschränkten Datenschutz- und Open Source-Community“ wenn mal wieder beide Phänomene zusammen treffen.

Der Artikel Verschränkte Datenschutz- und Open Source-Community? erschien zuerst auf [Mer]Curius

Mo, 15. November 2021, Lioh Möller

Der Manjaro Community Member Frede (auch bekannt als linux-aarhus) hat sich die Mühe gemacht einen Spin mit der aktuellen LXQt Version zu erstellen.

Dabei hat er die Installationsmedien so angepasst, dass nur Freie Treiber zum Einsatz kommen. Darüber hinaus wurden nur essenzielle Programme integriert, wodurch sich die Distribution sehr gut eignet, um ein angepasstes und leichtgewichtiges Desktopsystem zu erstellen.

Wie von Manjaro gewohnt, kommt auch beim LXQt-Spin ein ansprechendes dunkles Erscheinungsbild zum Einsatz. Das aktuell vorliegende Live-ISO eignet sich für die Nutzung auf einem Computer der x86_64 Architektur. Es bleibt zu hoffen, dass in naher Zukunft auch eine Variante für AArch64 bereitgestellt wird, da insbesondere auf Einplatinenrechnern eine leichtgewichtige Desktopumgebung sinnvoll sein kann.

Quelle: https://forum.manjaro.org/t/lxqt-unofficial-minimal-norse-root/90306
Download: http://iso.uex.dk/lxqt/

GNU/Linux.ch 15. November 2021 10:00

SteamOS 3.0

Mo, 15. November 2021, Ralf Hersel

Bekannterweise entwickelt Valve seinen ersten Spiele-Handheld namens Steam Deck, auf dem SteamOS läuft, Valves hauseigene GNU/Linux-Distribution, die jetzt von Arch Linux abgeleitet ist und nicht mehr von Debian GNU/Linux, wie die vorherigen Versionen.


SteamOS konnte wie viele andere GNU/Linux-Distributionen kostenlos heruntergeladen und auf jedem beliebigen Rechner installiert werden, wenn man ihn in einen vollwertigen Spielecomputer verwandeln wollte. Valve hat seine SteamOS-Distribution auf Arch Linux umgestellt, eine leistungsstarke und flexible Rolling-Release-Distribution, wahrscheinlich um den Benutzern die neuesten Sicherheits- und Software-Updates zur Verfügung zu stellen, sobald sie im Vorfeld verfügbar sind. Ausserdem kommt der KDE Plasma Desktop auf Wayland zum Einsatz.

Aktuell ist SteamOS 3.0 noch nicht final, wird aber nach dem (verschobenen) Erscheinen des Steam Desks ab Februar 2022 als Download und für die Installation auf eigenen PCs zur Verfügung stehen. Die Distribution wird ein unveränderliches Root-Dateisystem haben, um unbefugten Zugriff zu verhindern und System-Aktualisierungen zu erleichtern. Darüber hinaus wird in Zukunft PipeWire für Audio zum Einsatz kommen.

Quelle: https://9to5linux.com/valve-says-steamos-3-0-will-be-available-for-everyone-to-download-and-install