Manchmal möchte man ein Lied oder eine Playlist abspielen, die man nicht lokal in der mpd-Datenbank hat. Häufig findet man diese Lieder dann bei youtube. Da ich über meinen mpd mittels snapcast Musik gleichzeitig in mehreren Räumen abspielen kann möchte ich natürlich mpd auch für youtube nutzen.

Dazu habe ich mir ein kleines script geschrieben, welches das Lied oder die Playliste mit mpd abspielt.

Vorraussetzungen um das script nutzen zu können sind mpc und yt-dlp oder youtube-dl.

#! /bin/bash

# MPDPIPE
# Copyright (C) 2021 Martin Dosch 
# 
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

YTDL=$(command -v yt-dlp)
if [[ -z "$YTDL" ]]
then
	YTDL=$(command -v youtube-dl)
	if [[ -z "$YTDL" ]]
	then
		echo "No youtube-dl found."
		exit
	fi
fi

MPC=$(command -v mpc)
if [[ -z "$MPC" ]]
then
	echo "No mpc found."
	exit
fi

get_song_url () {
	URL=$("$YTDL" -qgf bestaudio "$1")
}

check_url () {
	REGEX='(https?|ftp|file)://[-A-Za-z0-9\+&@#/%?=~_|!:,.;]*[-A-Za-z0-9\+&@#/%=~_|]'
	if [[ ! $1 =~ $REGEX ]]
	then
		echo "$1 is not a valid URL."
		exit
	fi
}

show_help () {
	BASENAME=$(command -v basename)
	if [[ -z "$BASENAME" ]]
	then
		PROGRAM="$0"
	else
		PROGRAM=$($BASENAME "$0")
	fi
	echo "USAGE:"
	echo "$PROGRAM URL"
	echo "$PROGRAM MPD_HOST URL" 
	exit
}


case $# in
	1)
		if [ "$1" = "help" ] || [ "$1" = "--help" ]
		then
			show_help
		fi
		MPC_COMMAND="$MPC"
		INPUT="$1"
		;;
	2)
		MPC_COMMAND="$MPC -h $1"
		INPUT="$2"
		;;
	*)
		echo "Invalid input."
		show_help
		;;
esac

check_url "$INPUT"

$MPC_COMMAND clear
FIRSTRUN=1

for LINK in $("$YTDL" --flat-playlist --no-warnings -qg "$INPUT")
do
	get_song_url "$LINK"
	if [ -n "$URL" ]
	then
		$MPC_COMMAND add "$URL"
		if [ $FIRSTRUN -eq 1 ]
		then
			$MPC_COMMAND play
			FIRSTRUN=0
		fi
	fi
done

Ich werde das script hier aktuell halten, aber für den Fall, dass ich es doch mal vergesse: Ich habe es auch auf salsa.debian.org veröffentlicht.

GrapheneOS ist ein Custom ROM, aber nicht irgendeines. Die Entwickler behaupten ein besonders sicheres Custom ROM auszuliefern und bieten dieses auch nur für Hardware an, die besondere Sicherheitsstandards erfüllt. Doch könnte man nicht was anderes verwenden?

Vor Kurzem berichtete ich bereits von meinem Plan, GrapheneOS einzusetzen. Nachdem nun die ersten experimentellen Builds für das Google Pixel 6 zur Verfügung stehen, möchte ich die Serie zu GrapheneOS beginnen. Zuerst ist daher die Frage zu klären, warum man kein anderes ROM oder Betriebssystem nehmen kann. Es gibt schließlich zahlreiche proprietäre und quelloffene Systeme.

Wenn Herstellersoftware, dann Apple

Man sollte sich nichts vormachen, jede Modifikation am Betriebssystem, selbst wenn es so professionell dokumentiert ist wie GrapheneOS, bedeutet für die meisten Menschen einen zu großen Aufwand. Hier fehlt die Zeit, das Interesse, die Kenntnisse oder eine Kombination aus allem.

Wenn man keine Modifikation am System vornehmen möchte, jenseits der Veränderung irgendwelcher Einstellungen oder Installation von Apps, dann empfehle ich nach wie vor iPhones. Diese sind nicht perfekt, es fließen immer noch Daten an Apple ab und man ist von den Entscheidungen in Cupertino abhängig, aber man bekommt ein ganz passables Datenschutzniveau und die Geräte sind sehr sicher. Die extrem geschlossene Plattform hat eben auch Vorteile und nicht nur Nachteile.

Der Vorteil von Apples iOS ist somit lediglich relativ und liegt vor allem daran, wie schlecht Android in der Variante ist, wie wir es bei auslieferten Geräten vorfinden (genannt Stock Android). Stock Android bedeutet in der Regel nicht nur massiven Datenabfluss an Google, sondern auch an mindestens einen weiteren Hersteller. Angesichts der gegenwärtigen Marktanteile sogar oft ein chinesischer Anbieter und damit an ein Unternehmen, das zwangsläufiger Teil des größten, restriktivsten und immer übergriffigeren Überwachungsstaates der Welt ist. Hinzu kommen ungelöste Probleme bei der Updateversorgung, strukturelle Probleme im System etc. pp. Stock Android ist der Traum für jeden Produzenten von bösartiger Software – vom gewöhnlichen Kriminellen bis hin zu staatlichen Akteuren.

Warum nicht LineageOS, Murena (/e/) oder eine andere ROM?

Der Datenschutz macht es somit unumgänglich sich von Stock Android und den proprietären Google-Bestandteilen von Android zu lösen. Das ist nur leider gar nicht so einfach. Ist man bereit, ein alternatives System (eine sogenannte Custom ROM) zu installieren, gibt es zahlreiche Alternativen. Es waren früher mal mehr, aber noch immer gibt es – abhängig vom jeweiligen Gerät – ein paar verschiedene Systeme zur Auswahl. Leider sind diese allesamt nicht nur positiv, vor allem wenn man den Sicherheitsaspekt in den Vordergrund stellt.

Alle diese Custom ROMs basieren auf dem Android Open Source Project (AOSP) und passen dieses an. Eine Zusammenstellung der wichtigsten Begriffe habe ich hier mal erstellt. Die bekannteste Variante ist immer noch LineageOS und dieses bildet auch die Basis für viele andere ROMs. Nur sehr wenige ROMs basieren direkt auf AOSP. Hier ist wichtig sich zu vergegenwärtigen, dass die Modder-Szene nicht automatisch an Datenschutz und Sicherheit interessiert ist. Die Verbindung beider Interessengruppen ist eher ein Zweckbündnis. Vieles von dem, was auf XDA Developers so passiert (fehlende Offenlegung des Codes, Rooten, Bootloader öffnen, Software aus zweifelhaften Quellen via Downloadlink zu einem Filehoster beziehen) widerspricht Datenschutz und Sicherheit.

Das hat verschiedene Probleme zur Folge. Solche, die LineageOS-spezifisch sind und die sich durch die meisten ROMs ziehen und negative Auswirkungen auf die Sicherheit durch die Nutzung eines Custom ROM allgemein.

Die LineageOS-spezifischen Probleme sind mannigfaltig und sowohl technischer als auch organisatorischer Natur. Das Projekt hat – zählt man CyanongenMod dazu – eine lange Entwicklungsgeschichte hinter sich und passt AOSP seit vielen Jahren mit vielfältigen Erweiterungen an. Dabei hat man einige hartnäckige Probleme und Bugs ins System getragen, die man nicht beheben kann oder möchte. XDA Developers ist voll von entsprechenden Berichten über hartnäckige Neustart-Probleme und vieles andere. Hier kann man betroffen sein, muss aber nicht. Das ist auch abhängig vom Gerät. Hinzu kommt eine dünne Entwicklerdecke, die das Mehraugenprinzip als zentrales Sicherheitsprinzip von Open Source unterminiert. Schaut man sich die Änderungen im Code an, stößt man oft auf Commits, bei denen ein und derselbe Entwickler die Änderung vorgenommen, den Review durchgeführt und die Verifizierung abgenommen hat. Vor allem im Bereich der Geräteunterstützung ist das keine Seltenheit. Je kleiner das ROM, desto größer das Problem.

Hinzu kommen Probleme, die jenseits der Möglichkeiten von LineageOS & Co sind. Updates beziehen sich immer nur auf AOSP. Firmware und Kernel müssen vom Hersteller aktualisiert werden. Stellt der Hersteller den Support ein, ist es mit Kernel-Updates nicht mehr weit. Firmware-Updates müssen zudem am System vorbei vorgenommen werden. Das ist keineswegs trivial und passiert deshalb oft nicht. Angesichts der zentralen Bedeutung von Firmware, können dadurch Geräte scheunentorgroße Sicherheitslücken aufweisen. Naturgemäß muss man zudem seinen Bootloader öffnen und ein Custom Recovery installieren. Das System wird dadurch für einen Angreifer unsicherer als ein Stock Android (zur Erinnerung: Datenschutz ungleich Sicherheit).

Das gilt auch für das aktuell sehr populäre Murena (zuvor /e/) und andere LineageOS-Abkömmlinge und sorgt letztlich für den Ausschluss nahezu aller Custom ROMs.

Eine Alternative wäre lediglich CalyxOS, das eine ähnliche Zielsetzung wie GrapheneOS verfolgt, es dem Anwender aber etwas leichter machen soll. CalyxOS ist vor allem für jene Anwender von Interesse, die auf microG wert legen, was mir aber nicht auf das Gerät kommt.

Und Linux? Wann steht das endlich zur Verfügung?

Seitdem ich mich mit Smartphones befasse warte ich auf ein „richtiges“ Linux für Smartphones. Es ist so traurig, aber die Zustandsbeschreibung, die ich 2018 schrieb, gilt eigentlich immer noch.

Linux scheitert mobil daran, dass dort alle negativen Eigenschaften der Community zum tragen kommen und keine der positiven. Zersplitterte Projekte ohne wirtschaftliche Perspektive basteln nebeneinander her und anstelle die neue Geräteklasse zu nutzen, um überholte Strukturen abzulösen, übertragt man die alten Pfadabhängigkeiten des Desktop-Ökosystems auf die mobilen Geräte. Zahlungskräftige Sponsoren fehlen zudem fast vollständig und somit ist Linux im Mobilbereich ein interessantes Beispiel dafür, was passiert, wenn die so oft schutzartig vorgebrachte Ehrenamtlichkeit der Entwicklung tatsächlich mal eintritt: Nicht viel!

Anstelle hier wenigstens aufzuholen, verliert man ganz im Gegenteil immer stärker den Anschluss. Möglicherweise ist man hier bereits endgültig abgehängt, da wird sich substanziell aller Voraussicht nach nichts mehr ändern. Und selbst wenn da noch was kommt, erfüllt es zwar das Kriterium Open Source, aber hinsichtlich elementarer Sicherheitsfunktionen, die sich in den letzten Jahren auf diversen Plattformen eingebürgert haben, hinkt man technisch weit hinterher. Wie eben der Desktop auch.

Diese Problembeschreibung gilt auch für Systeme wie Sailfish OS, das im Gegensatz zu AOSP nicht mal komplett quelloffen ist und bei dem sich die Entwicklerfirma Jolla zudem inzwischen in fragwürdiger finanzieller Abhängigkeit von Russland befindet. Damit ist das absolut keine Option.

Zusammenfassung und Ausblick

Diese Zustandsbeschreibung ist für langjährige Leser dieses Blogs sicher nicht neu, sondern zieht sich durch meine Artikel zu dem Thema. Dazu erhalte ich Widerspruch und interessante Kommentare. In einem jener Kommentare legte man mir GrapheneOS nahe, das viele der Schwächen von Custom ROMs umgeht und ein besonders sicheres System liefert. Ein Überblick über GrapheneOS folgt im nächsten Teil der Serie.

Der Artikel GrapheneOS – Warum kein anderes System? erschien zuerst auf [Mer]Curius

Viele Datenschützer nutzen Android Custom ROMs, um der Überwachung durch Hersteller zu entgehen. Leider fehlen diese einige heute übliche Funktionen wie Push Dienste. Deshalb empfehlen viele gerne microG. Ein Fehler?

Ich persönlich benötige diese Dienste nicht und nutze deshalb kein microG. Die Frage, welchen Mehrwert für Privatsphäre und Datenschutz microG bietet, hatte ich hier aber auch schon gestellt.

microG bewirbt das eigene Produkt wie folgt auf der Webseite:

Although most microG components are far from complete, users are amazed by the results. Free software users got extended application support, privacy-caring users can reduce or monitor data that is sent to Google and especially older phones can expect some battery life improvements. microG is not only used on real devices, but also replaces Google tools in test emulators and is even used in virtual mobile infrastructure.

microG, abgerufen am 04.12.2021 (Hervorhebung durch den Autor)

Die Gleichsetzung von Open Source mit positiven Effekten für Privatsphäre und Datenschutz als Werbestrategie ist hier mal wieder ein beliebtes, aber gefährliches Mittel.

Denn der Mehrwert für Privatsphäre und Datenschutz ist nicht besonders positiv. Das ist jedenfalls die Meinung der GrapheneOS-Entwickler, wie man im September in einem Thread auf Twitter darlegte:

Da viele Leser hier Twitter nicht nutzen möchte, fasse ich die Kernaussagen knapp zusammen:

• microG ist keine Open Source Implementierung, der App Dienste, da die darauf zugreifenden Apps weiterhin proprietäre Google-Bibliotheken nutzen.
• microG ist somit nur ein Open Source Zwischenhändler zwischen proprietären Bibliotheken und proprietären Diensten. Das bietet keinen Mehrwert für Privatsphäre und Sicherheit.
• Sie sind faktisch sogar unsicherer als die proprietäre Play Service-Implementierung, weil das API Sicherheitsmodell nicht richtig umgesetzt ist und Techniken wie Pinning nicht implementiert sind.
• Die Nutzung von microG erfordert die Umgehung von Sicherheitsprüfungen und Play Services Signaturen.
• Die Verwendung von microG kann nur durch eine invasiven Eingriff in das Betriebssystem erfolgen und setzt umfassenden Zugriff auf privilegierte APIs und spezielle SELinux-Richtlinien vorraus.

Meiner Meinung nach trifft damit auf microG die Bezeichnung „Snake oil/Schlangenöl“ zu. Die meisten kennen das bestimmt aus dem Kontext von Antiviren-Programmen. Es handelt sich per Definition um ein völlig wirkungsloses „Wundermittel“, das anstelle zu helfen sogar unerwünschte Nebenwirkungen haben kann. Genau das scheint nach Aussage der GrapheneOS-Entwickler, deren Expertise klar sein dürfte, auf microG zutreffen.

Bei GrapheneOS arbeitet man stattdessen an sogenannten „Sandboxed Play Services„. Letztlich scheint das eine sinnvollere Variante zu sein. Entweder man kann auf Google-Technologien verzichten oder nicht. Wenn man sie benötigt, hilft auch keine vorgeblich freie Reimplementierung in Open Source, da man Bibliotheken in den Apps und die proprietäre Serversoftware bei Google trotzdem nicht kontrolliert. Man verschafft sich damit bestenfalls die Illusion von Datenschutz und vielleicht ist das sogar kontraproduktiv für die Sicherheit des Geräts.

Der Artikel Ist microG nichts anderes als Schlangenöl? erschien zuerst auf [Mer]Curius

Im Blog schreibe ich regelmäßig über unterschiedliche Betriebssysteme und versuche gerne den normalen Nutzer im Blick zu behalten. In der Community kursieren dazu manchmal komische Vorstellungen. Deshalb man ein Blick auf die Fakten.

Nicht nur beim Thema Betriebssysteme gibt es bei vielen „gefühlte Wahrheiten“, die sich aus dem persönlichen Nutzungsverhalten und dem, was man so in seinem Umfeld sieht, ergibt. In der Linux-Community kursieren da manchmal lustige Annahmen, wenn einige behaupten, Linux müsste doch bestimmt 10 % Marktanteil haben oder mobil wären Custom ROMs eine relevante Größe. Solche verzerrten Wahrnehmungen gibt es aber natürlich auch in anderen Communitys.

Eine Möglichkeit an Zahlen zu kommen, bietet Statista. Dabei handelt es sich um ein deutsches Unternehmen, das Daten zu vielen verschiedenen Themen zusammen trägt und aufbereitet. Einige Informationen sind kostenlos, für andere benötigt man eine kostenpflichtige Lizenz. Wer hier als Mitarbeiter oder Student Angehöriger einer Universität ist, kann mal schauen, ob es dafür eine Campuslizenz gibt.

Die Zahlen sind nicht perfekt, sondern werden unter anderem über Millionen Page Views erhoben und aus Lizenzgründen kann ich die genauen Zahlen und Grafiken hier im Blog nicht übernehmen, aber möchte mal eine Trends verdeutlichen und mit Zahlen aus anderen Quellen anreichern, um mal eine gemeinsame Diskussionsgrundlage herzustellen.

Desktopsysteme

Alle Hersteller arbeiten an konvergenten Systemen und Desktop und Smartphone / Tablet nähern sich sukzessiv an, aber noch macht es Sinn, in Desktop- und Mobilbetriebssystem zu trennen.

Am Desktop hält Microsoft mit Windows knapp 75 % des weltweiten Marktanteils, gefolgt von macOS mit ca. 15 % und dann erst Linux mit knapp über 2 % (Statista). Deutschland ist da erstaunlich nahe an den weltweiten Werten (Statista), anders als beispielsweise die USA. Dort hält Windows nur noch knapp 60 %, dafür kommt macOS auf fast 25-30% und Googles ChromeOS kommt hier auf ca. 8 %. Linux hat weniger als 2 % und ist sogar leicht rückläufig (Statista), wobei man das bei so kleinen Marktanteilen sicher schwer zu erheben ist.

Alles Humbug? Mit Steam erhebt eine weitere Stelle umfassend Daten und da sieht das sogar noch besser für Windows aus. Zuletzt kam Microsofts Betriebssystem auf knapp 96 % und macOS kommt auf lediglich 2,70 % und Linux nur auf 1,16 %.

Bei Statista kann man die Erhebung kritisieren, bei Steam den Fokus auf Gamer mit ihrer Präferenz für Windows. Man kann aber auch einfach konstatieren, dass Linux in keiner mir bekannten Erhebung auf mehr als 2-4 % kommt und dieser Marktanteil konstant bis rückläufig ist.

Mobile Geräte

Der Markt an mobilen Betriebssystemen war mal sehr vielfältig. 2010 tummelten sich dort zwar schon iOS und Android, aber daneben gab es noch BlackBerry, Windows Phone, Nokia Symbian und andere Nischensysteme. Das war eigentlich ein idealer Zustand. Heute gibt es hingegen nur noch Apples iOS und Googles Android.

Die Verteilung ist je nach Land aber sehr unterschiedlich. Da spielt vermutlich die unterschiedliche Kaufkraft und unterschiedliche Traditionen eine Rolle. In den USA ist der Markt z. B. fast 50/50 zwischen iOS und Android geteilt, während in Spanien Android komplett dominant ist (Statista). Deutschland nimmt da eine Zwischenposition ein, verzeichnet aber tendenziell einen steigenden Marktanteil für iOS (Statista).

Innerhalb von Android hat Google nach wie vor Probleme mit der Updateverteilung. Ein substanzieller Teil der Nutzer hängt auf älteren Android-Versionen, selbst das jetzt schon wieder veraltete Android 11 kommt erst auf knapp 1/3 Marktanteil (Statista). Custom ROMs spielen dabei überhaupt keine Rolle. Die bekannteste und größte Custom ROM LineageOS hat laut eigenen Angaben 1.865.014 aktive Gerät (Stand 04.12.2021). Zum Vergleich: Pro Quartal werden weltweit knapp 300 Mio. Smartphones verkauft (Statista).

Andere Systeme wie SailfishOS oder die Linux-Systeme (wenn man Android nicht dazu zählt) spielen keine messbare Rolle.

Schlussfolgerungen

Warum diese Zahlenorgie? Manchmal gibt es in Communitys eine verzerrte Binnenwahrnehmung und je kleiner die Community, desto eher entsteht eine geschlossene Blase. Daraus folgen dann bei manchen „gefühlte Wahrheiten“.

Die Marktanteile zeigen, dass Linux nicht sonderlich erfolgreich (Desktop) oder gar nicht existent (Mobil) ist. Viele Linux-Anwender werden das nicht mal als Manko wahrnehmen. Apple geling es hingegen seinen Marktanteil langsam aber stetig zu steigern, das Beispiel ChromeOS in den USA zeigt übrigens, dass die Marktanteile nicht so fest gefügt sind, wie manche es als Grund für den ausblenden Erfolg von Linux anführen. Das sagt übrigens nichts über den Erfolg von Open Source, denn freie Software kommt auch bei Windows oder macOS eine herausragende Bedeutung zu. Nicht umsonst widmen Projekte wie KDE der Windows Plattform mehr Aufmerksamkeit.

Diese Zahlen sollte man aber im Hinterkopf haben, wenn man sich über den Erfahrungsraum und Erwartungshorizont normaler Nutzer Gedanken macht und sich überlegt, wo man diese beispielsweise bei den Themen Datenschutz oder Privatsphäre abholen muss.

Der Artikel Betriebssysteme – Verbreitung und Marktanteile erschien zuerst auf [Mer]Curius

Im Februar 2020 wurde schon angekündigt, dass OpenSSH die Unterstützung von ssh-rsa auslaufen lässt. Umgesetzt wurde dies in Version 8.8, die vor gut einem Monat veröffentlicht wurde.

Leider unterstützt nicht jedes System moderne HostKeyAlgorithms. Ein solches Beispiel konnte ich die Tage z. B. bei einem Switch beobachten konnte. Hier erscheint folgender Fehler:

Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

In so einem Fall kann man ausnahmsweise doch noch ssh-rsa erlauben und das geht entweder per Option im ssh-Aufruf:

ssh -o HostKeyAlgorithms=+ssh-rsa 192.168.1.1

oder man trägt es in die ~/.ssh/config dauerhaft ein:

Host XYZ
    HostName 192.168.1.1
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Im Blogpost „Homeserver in 2020…“ beschrieb ich im Juni 2020, wie mein Homeserver-Setup damals aussah. In diesem Blogpost gebe ich ein kleines Update, wie es heute, im Jahr 2021, aussieht. Extremst viel hat sich nicht verändert, doch sind ein paar Funktionen dazu gekommen, die die Wartung des Servers vereinfacht.

Damals wie heute gilt: Ich will möglichst viel lernen und dabei Dienste einsetzen und betreiben, die für mich einen gewissen Mehrwert haben. Das ist sowohl der Funktionalität des Dienstes selbst, als auch die Installationsweise, die mich in welcher Weise auch immer weiter bringt.

k3s

In der November-Ausgabe TIL013 des Podcasts TILpod, den ich mit Dirk Deimeke veröffentliche, erzählte ich bereits in Tonform warum, wieso und weshalb ich auf k3s als Kubernetes-Distribution für meinen Homeserver betreibe. Wer die Podcast-Folge gehört hat, wird hier eher wenig Neues lesen.

Grundsätzlich betreibe ich, wie zuvor geschrieben, meinen Homeserver mit k3s. Die Kubernetes-Distribution ist relativ „langweilig“: Es handelt sich um eine leichtgewichtige Kubernetes-Distribution, die in einer einzelnen Binärdatei ausgeliefert und installiert werden kann. Das macht die ganze Wartung auf Dauer simpel. So kann ich ein Upgrade und Downgrade sehr simpel ausführen, in dem ich die Binärdatei auf meinem Homeserver austausche. Das klappte grundsätzlich auch immer. Upgrade-Probleme gibt es hingegen trotzdem, was allerdings mehr mit Kubernetes als mit k3s selbst zu tun hatte.

So gab es mal Probleme mit der Unterstützung von btrfs als Dateisystem in Kubernetes generell, weshalb ein Upgrade fehlschlug. Zudem ändern sich häufiger mal apiVersion von Manifests, sodass man da auch mal nach einem Update nacharbeiten muss. Aus diesem Grund schaue ich, dass ich möglichst häufig und regelmäßig ein Upgrade von k3s ausführe, um mögliche Probleme frühzeitig zu entdecken. Ansonsten ist man mit zu vielen Problemen gleichzeitig beschäftigt.

Das klingt zwar jetzt grundsätzlich abschreckend, kam in den letzten ~2 Jahren allerdings auch nur zwei Mal vor, dass mal größere Dinge nicht funktioniert haben, ansonsten gab es da weitaus weniger Probleme.

Flux und Helm

Um meine Deployments auf den Cluster zu automatisieren, nutze ich FluxCD. Bis September 2021 setzte ich noch auf das „alte“ Flux v1. Danach führte ich ein Upgrade auf Flux v2 durch, was durchaus eine nennenswerte Weiterentwicklung ist, die nicht abwärtskompatibel zu v1 ist.

Aber was tut es genau? Grundsätzlich bildet Flux den deklarativen Stand des Repositories im Kubernetes-Cluster ab, neuerdings GitOps genannt. Das heißt im konkreten, ich definiere im Repository – in einer gewissen Struktur – meine Dienste. Ich verwende größtenteils wo es geht Helm Charts, da ich fast nur Dienste hoste, die ich nicht selbst geschrieben habe.

Als „Suchmaschine“ für Helm Charts verwende ich ArtifactHUB. Viele Helm-Charts sind allerdings ordentlich veraltet oder nicht gepflegt, von daher prüfe ich immer, wie aktuell die Helm-Charts sind und von wem sie angeboten wird. Es gibt zum Beispiel die Community k8s-at-home welche diverse Helm Charts zur Verfügung stellt, die ich nutze. Ansonsten sind es häufig auch die Projekte selbst, die eigene Helm Charts anbieten, die ich bevorzugt nutze. Dazu gehören zum Beispiel die Helm Charts von Grafana und Prometheus.

Mein Lieblingsfeature von Flux 2 ist einfache und komfortable Möglichkeit, um automatische Updates auszuführen. Früher hatte ich die Updates händisch vorgenommen. Das heißt, ich habe die YAML-Dateien aufgemacht und händisch jeweils geprüft, ob es eine neuere Version des Helm-Charts gibt. Bei so zehn Anwendungen, die ich so betrieben hatte, war das etwas nervig, weil das viel unnötige Arbeit war.

Mit Flux 2 gebe ich nur noch an, in welcher Versionen ich die Helm-Charts installieren möchte. Für Grafana sieht meine Zeile aktuell etwa so aus:

version: ">=6.16.6 <7.0.0"

Es wird also mindestens die Helm Chart Version von Grafana 6.16.6 installiert und wird kein Upgrade auf die nächste Major Version 7.0.0 durchgeführt. Dieses Vorgehen mache ich für alle meine Helm-Charts, sodass ich keinen Aufwand für Upgrades habe. Ausgenommen sind Major-Releases, weil sich da häufiger mal das Format der values.yaml ändert. Manchmal wird es allerdings auch schon vorher geändert, was zwar auch ein wenig umständlich ist, aber das passiert zum Glück eher nicht so häufig.

Das automatische Upgrade von Versionen hab ich nun seit drei Monaten im Einsatz. Um Upgrades zusätzlich mitzubekommen, habe ich die genutzten Helm-Charts über ArtifactHUB abonniert. Wenn also neue Updates veröffentlicht werden, erhalte ich eine E-Mail. So behalte ich Überblick über neue Major-Releases von mir genutzten Helm-Charts, um manuell das Upgrade durchzuführen.

Anwendungen

Bei den Anwendungen hat sich in den letzten 1,5 Jahren nicht so viel geändert:

• Nextcloud für Kalender, Kontakte und Dateisynchronisation
• Vaultwarden als Passwortmanager (Reimplementation von Bitwarden)
• Prometheus für das Monitoring
• Grafana für die Visualisierung der Daten aus Prometheus, Influx und PostgreSQL
• GitLab für Git-Repositorys
• Unifi Controller für meine Unifi APs
• Syncthing für das Synchronisieren von Backups zu einer Offsite-Stelle
• rclone als Cronjob für das Hochladen von Backups „in die Cloud“
• Dataexporter der Photovoltaik-Anlage, der die Daten in eine Influx und PostgreSQL Datenbank schreibt
• Influxdb für die Daten der PV-Anlage, sowie Stromverbrauch und Temperatur-Sensoren
• PostgreSQL für Nextcloud, Kostal Datenhaltung und GitLab
• Jellyfin für Multimedia-Daten, ersetzte Plex
• minio als S3-kompatibles Object-Storage-Backend für GitLab
• traefik als Reverse Proxy
• Home-Assistant für Smart-Home
• mosquitto als MQTT broker
• paperless-ng für Dokumenten-Management
• fritz_exporter um Fritz!Box Daten für Prometheus zu exportieren
• starboard um die Container-Images im Cluster zu scannen

Außerhalb von Kubernetes läuft sonst weiterhin borgbackup und sonst eigentlich nichts mehr.

In Zukunft werd ich noch einiges mehr ausprobieren müssen. Zum Beispiel ArgoCD statt Flux. Ansonsten sind noch etliche Projekte in der CNCF Landscape Trail Map die man sich anschauen kann.

Open Source Lösungen sind per se gut für den Datenschutz. Irgendwie hat sich diese Gleichsetzung bei vielen festgesetzt. Doch so einfach ist das nicht und vor allem kommt es auf die Umsetzung an.

Die Gleichsetzung alles, was Open Source ist, ist gleichzeitig gut für den Datenschutz, hat sich in den letzten Jahren in der Öffentlichkeit festgesetzt. Dabei ist das gleich auf mehreren Ebenen falsch und entsprechende Behauptungen sollten bei jedem die Alarmglocken läuten lassen.

Open Source bedeutet erst mal nur, dass der Quellcode frei einsehbar ist. Das ist natürlich gut für eine Überprüfung des Datenschutzes, aber jedem sollte einleuchten, dass man die grauenvollste Software grundsätzlich auch Open Source stellen könnte (ich hatte das am Beispiel Linux auch mal durch dekliniert) Zweitens kommt es beim Datenschutz fast immer auf die konkrete Implementierung an und hier sind nicht umsonst aufwendige Prüfverfahren vorgesehen. Wenn irgendjemand in einer Diskussion pauschal behauptet, Lösung XYZ wäre gut für den Datenschutz, ohne auf die konkreten Details einzugehen, sollte bei jedem die Warnglocken läuten, denn entweder verkürzt derjenige stark oder er hat schlicht keine Ahnung.

Warum das so ist, möchte ich an einem kleinen Beispiel ausführen: Big Blue Button (im folgenden BBB) vs. Zoom.

Big Blue Button ist der Darling der Open Source Szene in Pandemie-Zeiten. Eine leistungsstarke Videokonferenzlösung, die quelloffen ist und transparent auf GitHub entwickelt wird. Zoom hingegen war schon vor der Corona-Pandemie suspekt und spätestens seit dem Frühjahr 2020 Gegenstand heißer Auseinandersetzungen. Also eigentlich klar, was hier hinsichtlich Datenschutz die Nase vorn hat, oder?

Das folgende Gedankenexperiment soll zeigen, dass so etwas eben nicht so klar und eindeutig ist, wie das gerne dargestellt wird.

Beide Videokonferenzsysteme arbeiten nicht per P2P-Prinzip, sondern benötigen eine zentrale Infrastruktur. Bei BBB wird meist davon ausgegangen, dass diese durch die nutzende Einrichtung betrieben wird, man kann dafür aber natürlich auch auf Dienstleister zurückgreifen. Zoom wird hingegen in der Regel durch die Zoom Inc. gehostet, es gibt aber auch die Möglichkeit, für große Einrichtungen die Zoom-Server selbst in ihren Rechenzentren zu betreiben.

Beide Systemen haben zudem positive wie negative Funktionen. Nur ein paar Beispiele zum Verständnis: Zoom bietet neben vielen kritisieren Funktionen auch eine Inhalteverschlüsselung für Videokonferenzen und hat dieses Thema erst richtig auf die Agenda gesetzt. BBB wird zwar transparent entwickelt, hat aber in der Vergangenheit Probleme mit der Sicherheit gehabt und die Umsetzung der für den Anwender nicht ersichtlichen Aufzeichnung aller Sessions ist höchst problematisch und muss durch den Administrator ggf. komplett deaktiviert werden.

Spannend wir nun also mal ein denkbar ungünstiges Szenario für BBB auf:

Die Einrichtung hat nicht die notwendigen Kapazitäten oder Expertise BBB selbst zu betreiben. Eine große Instanz für bis zu 300 gleichzeitige Teilnehmer ist schließlich nicht ganz trivial zu betreiben. Stattdessen nimmt man einen Dienstleister. Wenn man jetzt ein richtig negatives Szenario haben möchte, dann sitzt dieser Dienstleister noch nicht mal in der Europäischen Union, aber es funktioniert auch mit einem Sitz in der EU. Weil es schnell gehen musste, ist die vertragliche Basis lückenhaft und der Auftragsdatenverarbeitungsvertrag existiert nicht. Welche BBB-Version genau beim Dienstleister läuft ist unklar, theoretisch könnte es sich sogar um eine von der frei verfügbaren Open Source-Lösung abgewandelte Variante handeln. Ob der Dienstleister die problematischen Funktionen bei BBB deaktiviert hat, kann nicht kontrolliert werden. Ein besonderer Fokus auf Datensparsamkeit bei der BBB-Instanz existiert nicht. Weil BBB nur eine Transport- und keine Inhalteverschlüsselung bietet, sind für den Dienstleister potenziell alle Inhalte und Metadaten frei verfügbar.

Nehmen wir nun das denkbar günstigste Szenario für Zoom zum Vergleich. Die Einrichtung hat nicht nur eine teure Lizenz, sondern betreibt die Zoom-Server sogar in den eigenen Rechenzentren (Zoom on-premise). Die Metadaten, d. h. vor allem welche Benutzer eingeladen sind und wann das Meeting stattfindet, landet zwar weiterhin bei Zoom, der gesamte Meeting-Verkehr wird aber über die eigene Infrastruktur abgewickelt. Durch die Inhalteverschlüsselung ist das zudem deutlich sicherer als bei nahezu allen konkurrierenden Lösungen. Versteckte Aufzeichnungen etc. pp. gibt es bei Zoom nicht, hier hat man in den vergangenen Jahren durch den ständigen Fokus der Öffentlichkeit viel nachgearbeitet.

Welche Lösung ist nun hinsichtlich des Datenschutzes die bessere?

Natürlich hat dieses Szenario in sofern Schlagseite, als dass ich das denkbar ungünstigste BBB-Szenario dem denkbar günstigsten Zoom-Szenario gegenüber gestellt habe und das somit eine eher theoretische Fingerübung ist.

In der Realität würde man als lokaler Datenschutzbeauftragter darauf drängen, eine saubere BBB-Infrastruktur zu betreiben und Verbesserungen in dem Bereich vornehmen, weil das Entwicklungspotenzial hier besser ist als bei Zoom, wo man letztlich um den problematischen Metadatenabfluss an Zoom nicht umhin kommt.

Daraus lernen kann man aber, dass die Aussage, ob etwas gut oder schlecht für den Datenschutz ist, bei nahezu allen komplexeren Fällen wie z. B. einer Videokonferenzinfrastruktur niemals pauschal gesagt werden kann, sondern immer das Ergebnis einer intensiven Prüfung unter Einbeziehung aller Faktoren ist. Hinzu kommt oft eine gewisse Freiheit bei der Risikoabwägung, weshalb ähnlich wie bei Juristen gilt: 3 Datenschützer, 5 Meinungen. Jeder, der mal beruflich im Datenschutz gearbeitet hat, weiß das.

Wenn ihr also Pauschalurteile zum Datenschutz lest, dann wisst ihr entweder, dass derjenige stark verkürzt, seine Meinung schon vorher feststand oder der Autor schlicht keine Ahnung von Datenschutz im wirklichen Arbeitsalltag hat – denn da gibt es selten eindeutige oder perfekte Lösungen.

Der Artikel Open Source = Datenschutz? So einfach ist das nicht! erschien zuerst auf [Mer]Curius

Wie Benjamin Brunner, Entwickler bei SUSE, vor einigen Tagen über die Mailingliste kommunizierte, arbeitet man momentan an der Implementierung der neuen systemd-Funktionen, um LUKS2-Volumes mittels TPM oder FIDO2 zu entsperren.

Dabei handelt es sich um eine Funktion, die Lennart Poettering Anfang diesen Jahres ankündigte und über die ich hier bereits berichtete hatte. Mittels systemd-cryptenroll lassen sich unter anderem TPM oder FIDO2 als Entsperrmechanismen für LUKS2 hinterlegen. Diese neuen Verfahren stehen in einem direkten Kontext zu weiteren Bestrebungen, um den Sicherheitslevel der verbreiteten Linux-Verschlüsselung auf ein zeitgemäßes Niveau zu bringen.

Die Zielrichtung der Bestrebungen bei SUSE/openSUSE ist noch nicht klar. Also ob und inwieweit das in die Installationsroutine oder YaST implementiert wird. Zudem sind noch einige Vorarbeiten notwendig. Genaueres können interessierte Anwender im Wiki nachlesen.

Die Funktion systemd-cryptentroll benötigt LUKS2-Volumes. Das ist für SUSE/openSUSE ein Problem, weil die Installationsroutine bis zuletzt LUKS1-Volumes angelegt hat. Daran hat man allerdings anderweitig bereits gearbeitet und ich denke, hier dürfte sich zukünftig was ändern. Bestehende Installationen lassen sich zudem relativ leicht mittels eines Live-Mediums von LUKS1 auf LUKS2 migrieren. Allerdings benötigt systemd-cryptenroll auch eine unverschlüsselte Boot-Partition und das ist standardmäßig bei SUSE/openSUSE schon länger nicht mehr der Fall.

Hinzu kommen noch ein paar Probleme, weil z. B. die FIDO2-Abfrage upstream noch nicht in Plymouth integriert ist und somit nicht optisch schön beim Startvorgang erscheint, sondern „blind“ durch den Anwender erfolgen muss.

Die beiden neuen Authentifizierungsmethoden sind wichtige Ergänzungen für die Legacy-Verfahren mittels Passwort. Teilweise lösen sie auch zusammen gestückelte Skripte bei z. B. Debian und Arch Linux ab, die bereits Sicherheitssticks wie den YubiKey unterstützten. FIDO2 adressiert das Problem der unsicheren Passwörter und TPM2 bietet unter anderem Schutz gegen Angriffe mittels Brute Force und vor allem das beliebte Kopieren der Daten, um sie danach in aller Ruhe zu untersuchen.

Es ist also noch ein wenig Wegstrecke zu meisten, bis diese Funktionen standardmäßig umgesetzt werden können. Wer aber schon ein System mit LUKS2 und unverschlüsselter Boot-Partition hat oder eine Testinstallation betreibt, kann sich die neuen Funktionen mal ansehen. Meiner Meinung nach geht das absolut in die richtige Richtung.

Der Artikel openSUSE arbeitet an LUKS mit TPM und FIDO2 erschien zuerst auf [Mer]Curius

Traditionell gebe ich gegen Ende des Jahres einen kleinen Einblick in mein Nutzungsverhalten und das, was sich im vergangenen Jahr geändert hat. Viele Verfechter von Datenschutz und Privatsphäre schreiben gerne über das richtige Nutzungsverhalten, aber jeder muss Kompromisse machen.

Der Blog auf [Mer]Curius spiegelt meine gegenwärtigen Interessen im Bereich Datenschutz/-sicherheit meist ziemlich gut wider. Für viele Leser dürften sich daher einiges Bekanntes wieder finden.

Hardware & Betriebssysteme

Meine Rückkehr zu Linux hat sich im letzten Jahresrückblick bereits abgezeichnet. Es hat dann doch stärker geruckelt, als ich das anfänglich vermutet hatte. Einfach, weil ich mir in den Apple-Jahren einen gewissen Komfort angewöhnt habe, den ich nicht mehr missen möchte. Ein weiterer für mich wichtiger Aspekt ist Datenschutz und Sicherheit. Linux ist hier nicht so optimal aufgestellt, wie es gerne dargestellt wird. Hier tut sich zum Glück einiges und mittelfristig dürfte Linux hier deutlich besser dastehen. Leider sehen das nicht alle so und so treibt mich die selbstzufriedene Bräsigkeit großer Teile der Community regelmäßig auf die Palme. Zum Leidwesen mancher Leser.

Meine anfängliche Unzufriedenheit konnte ich zumindest teilweise lösen, indem ich von KDE Plasma zur Pantheon Shell migriert bin. Bei der Rückkehr zu Linux hatte ich die Wahl von Plasma als Desktop kaum hinterfragt, schließlich steigt man meist wieder da ein, wo man vorher aufgehört hat, aber nach langen Jahren mit macOS habe ich das amateuerhafte Stümperdesign der VDG einfach nicht mehr ertragen.

Grundsätzlich habe ich die partielle Abkehr von macOS aber nicht bereut. Auch ein Jahr nach der Veröffentlichung der ersten Geräte mit M1 Prozessor kann man kein anderes Betriebssystem auf den Geräten nutzen und Virtualisierung funktioniert nur sehr eingeschränkt mit ARM-VMs. Zudem experimentiert Apple mit zweifelhaften Funktionen wie Client Side Scanning und sollten die zur Marktreife kommen, steht der Kunde mangels alternativer lauffähiger Betriebssysteme mit einem Haufen Elektroschrott da. Jedenfalls sofern das Themen sind, die den Nutzer umtreiben – so wie mich eben. Linux bietet hier mehr Freiheit, wenn sich ein Projekt in die falsche Richtung entwickelt. Man ist nicht derart auf Gedeih und Verderb einem einzigen Hersteller oder Entwicklerteam ausgeliefert.

Wobei das nicht bedeutet, dass ich niemandem zu Apples Hardware raten würde. Vergangene Woche haben wir hier im Haushalt ein MacBook Air 2020 angeschafft. Schönes und extrem flottes Gerät und wunderbar geeignet, wenn der Anwender damit einfach in Ruhe seine Sachen erledigen möchte. Nur für mich eben als Hauptgerät nicht mehr geeignet.

Mobil habe ich vergangenes Jahr verstärkt mit LineageOS gearbeitet und bereite gerade den Umstieg auf GrapheneOS mit neuer Hardware vor. Alternativ gibt es noch ein iPhone SE 2020, das sicher noch viele Jahre als Alltagsgerät seinen Dienst tun wird.

Kern meiner Datenhaltung und Synchronisation ist immer noch das gleiche Synology NAS wie seit Jahren. Ich bin dabei mit Synology nicht übermäßig glücklich, weil ich die Updatepolitik hinsichtlich Sicherheitsupdates bei einem so exponierten System nicht professionell genug finde, aber so lange die Hardware läuft und unterstützt wird, werde ich hier wohl nicht migrieren.

Homeoffice im zweiten Jahr

Während privat Open Source nun wieder viel stärker zum Einsatz kommt, bin ich beruflich so richtig schön proprietär unterwegs und finde das nicht mal schlecht. Ich könnte wegen der aktuellen Sonderregelungen (Corona, Homeoffice etc. pp.) sogar mit Linux arbeiten, aber möchte es gar nicht. Aufgrund ausgedehnter Homeoffice-Zeiten gehören diese Betriebssysteme und Programme inzwischen auch faktisch in meinen IT-Haushalt und werden daher hier aufgeführt.

Windows, Microsoft Office, Citavi, Zoom, das ein oder andere Microsoft Teams oder WebEx-Meeting. Ja, hartleibigen Datenschützern dreht sich hier der Magen um, aber es funktioniert und leider auch viel besser als Lösungen wie Big Blue Button, das wir auch haben und wo die Ärgernisse von der eher bescheiden Oberfläche, den bescheidenen Funktionen und der noch bescheideneren Performance inzwischen zum üblichen Smalltalk der Videocalls gehören. Endlich eine Alternative zum Wetter und Pandemie-Status.

Kommunikation

Abgesehen von der Arbeitskommunikation hat es in diesem Bereich im letzten Jahr erstaunliche Fortschritte gegeben.

Die E-Mail ist bei mir massiv auf dem Rückzug. Da ich E-Mails nie lösche und lediglich in Jahresarchive absortiere kann ich das auch gut quantifizieren. Dieses Jahr habe ich knapp 50 % weniger Mails bekommen und beantwortet als im Vorjahr, womit sich ein langjähriger Trend noch mal beschleunigt hat.

Stattdessen hat aufgrund der amateurhaften Kommunikationspolitik von Facebook Signal bei mir dieses Jahr einen Quantensprung gemacht. 70 % meiner Kontakte und Gruppen kann ich inzwischen über Signal abwickeln. Die Migrationsbewegung hielt aber nur kurz an und seit dem Sommer hat sich hier nichts mehr getan. Die verbliebenen WhatsApp-Kontakte sind echt renitent, weshalb mir WhatsApp erhalten bleibt. Wirklich verloren hat Threema, das bei mir fast keine Rolle mehr spielt. Wenn die Handvoll Kontakte dort noch auf Signal migriert, brauche ich es eigentlich nicht mehr.

Dienste

Ähnlich wie letztes Jahr ist dieser Bereich bei mir sehr statisch. Gerade noch einen Blick auf Desktop und Smartphone geworfen. Das meiste wie z. B. den PIM-Bereich, „Cloudspeicher“ oder RSS-Synchronisation betreibe ich selbst. Der Eigenbetrieb gewährleistet bei mir die höchstmögliche Sicherheit bei gleichzeitigem maximalen Komfort, weil ich eben doch alle Vorteile nutzen kann, die sich aus „Clouddiensten“ und Synchronisation ergeben.

Bei der Suchmaschine nutze ich immer noch DuckDuckGo. Vermutlich nicht die beste Lösung hinsichtlich des Datenschutzes, aber für mich die beste Kombination aus Ergebnisqualität und Datenschutz. Eine Suchmaschine mit der ich nichts oder nur mangelhafte Ergebnisse erziele, nützt mir schließlich auch nichts. Am Desktop arbeite ich für die Navigation sehr zufrieden mit GNOME Maps, für Android nutze ich OsmAnd, wobei ich damit nicht sonderlich zufrieden bin, weil die Oberfläche überladen und die Suchfunktion unterirdisch ist.

Sünden

Nicht nur die genutzten Dienste ändern sich kaum, sondern auch der Katalog an „problematischen“ Diensten und Lösungen ist ziemlich statisch. Twitter, WhatsApp und als besonderes Ärgernis der DB Navigator bleiben mir als besonders problematische Dienste erhalten. Perspektivisch hoffe ich hier wenigstens auf WhatsApp verzichten zu können. Zudem habe ich immer noch zwei Streaming-Dienste für Serien und die DSGVO-Auskunft bei beiden hat es in sich.

Bei der Hardware meide ich den Smart Home-Trend, habe aber inzwischen einen TV von LG mit webOS Betriebssystem (was so gut wie nichts mehr mit den Palm-Wurzeln zu tun hat), von dem ich lieber nicht so genau wissen möchte, was er so an Daten sendet und Sonos Speaker, bei denen das Gleiche gilt.

Der Artikel Wasser predigen, Wein trinken? – Mein Nutzungsverhalten 2021 erschien zuerst auf [Mer]Curius

Viele Nutzer entdecken für ihre Internetseiten immer öfter statische Website-Generatoren, da bei diesen der Wartungsaufwand im Vergleich zu beispielsweise Wordpress sehr gering ist. Ich selbst nutze deswegen seit 2019 Hugo.

Um einen neuen Artikel anzulegen, starte ich VSCode, lege ein neues Verzeichnis unter content/posts an und kopiere bei Bedarf Bilder in dieses Verzeichnis, die in dem Beitrag angezeigt werden sollen. Danach erstelle ich die Datei index.md und erstelle in dieser mittels eines Snippet den Front Matter Bereich den ich entsprechend anpasse. Unter diesen Bereich erstelle ich dann den eigentlichen Artikel. Abschließend werden diese Änderungen in ein Mercurial-Repository hochgeladen, was mittels eines Hooks den Inhalt von fryboyter.de erzeugt und die Änderungen zusätzlich mittels hg-git bei Github hochlädt.

An sich habe ich damit kein Problem. Es funktioniert. Und die Vorgänge kann ich inzwischen auswendig durchführen. Aber ab und zu wäre für mich etwas mehr Komfort trotzdem schön. Das gilt auch für Nutzer, die bei meinem “Workflow” schreiend wegrennen würden. Also vermutlich die meisten Nutzer.

Vor ein paar Tagen habe ich Front Matter entdeckt. Hierbei handelt es sich um eine Erweiterung für VSCode die ein CMS für diverse statische Website-Generatoren direkt in VSCode anbietet. Neben Hugo werden auch noch andere Generatoren wie beispielsweise Jekyll, Gatsby, 11ty, Hexo oder Next.js unterstützt.

Aus zeitlichen Gründen habe ich bisher die Erweiterung nur installiert und die Grundkonfiguration erstellt. Ausgehend davon muss ich aber sagen, dass Front Matter einige Dinge sehr vereinfacht bzw. bequemer macht. Wenn man sich die Dokumentation durchliest, sollten aber durchaus komplexere Dinge möglich sein. Ich würde daher jedem, der einen statischen Website-Generator und Vscode nutzt, raten sich Front Matter zumindest einmal anzusehen. Über den eigenen Tellerrand zu schauen ist ja oft nicht verkehrt.

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 = .*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.

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.

Aus reiner Neugierde wollte ich mir das Packprogramm PeaZip ansehen. Direkt nach dem Starten ist das Programm mit folgender Fehlermeldung abgestürzt.

[FORMS.PP] ExceptionOccurred 
  Sender=EAccessViolation
  Exception=Access violation
  Stack trace:
  $00000000007438D3
  $0000000000723049
  $00000000008ADC66
  $00000000008AD5FC
  $00000000008A9415
  $00000000007B3EFB
  $00000000007B3E02
  $0000000000448D9D
  $0000000000447B43
[FORMS.PP] ExceptionOccurred 

Die Ursache ist Wayland. PeaZip ist damit wohl noch nicht wirklich kompatibel. Daher muss man PeaZip mit dem x11 backend starten. Führt man also QT_QPA_PLATFORM=xcb peazip aus, startet PeaZip ohne Probleme.

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

• https://wiki.gnupg.org/WKD

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

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

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.

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.

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.

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

Unter elementaryOS nutze ich neben der integrierten Paketverwaltung unter anderem auch Snappy und Flatpak. Es ist zwar unschön das sich die zentrale Paketverwaltung dadurch etwas zersplittert, aber leider existieren nicht alle benötigen Pakete in der Paketverwaltung. Bedingt dadurch fand ich den Update-Prozess allerdings etwas umständlich, sodass ich das Ganze in ein kleines Skript gegossen habe:

#!/bin/bash
apt autoremove -y && apt autoclean -y && apt update -y && apt dist-upgrade -y && apt autoremove -y && apt autoclean -y
flatpak update -y
snap refresh 
checkrestart

Mit dem Skript wird die zentrale Paketverwaltung aktualisiert, anschließend Snappy und dann Flatpak. Für die Nutzung des Kommandos checkrestart muss das Paket debian-goodies installiert werden.

Dieses Tutorial führt ein in:

• Die Einrichtung von rootless-Podman unter Debian Bullseye
• Die Konfiguration von Container-Registries
• Die Suche nach Container-Repos mit Podman
• Die Inspektion von Remote-Repos mit Skopeo
• Anmeldung an einer Container-Registry
• Den Download (Pull) von Container-Images mit Podman
• Container Starten, Stoppen und Entfernen mit Podman
• Die Verwaltung von Container-Prozessen und -Images
• Die persistente Speicherung von Daten in Podman-Volumes

Viel Spaß beim Lesen und Freude beim Nachmachen. Falls euch das Tutorial gefällt, freue ich mich über einen Kommentar. Falls ich etwas ausgelassen oder falsch dargestellt habe, freue ich mich ebenfalls über einen Hinweis in den Kommentaren oder per E-Mail.

Vorwort

Um sich im Container-Dschungel zurechtzufinden, ist eine fundierte Kenntnis der Terminologie unerlässlich. Die Einführung in die Terminologie ist jedoch nicht Bestandteil dieses Tutorials, da es den Umfang sprengen würde.

Unter folgenden Links kann man sich mit der Terminologie vertraut machen:

• Linux-Container-Terminologie (PDF); Jörg Kastning; 2021-06-16
• A Practical Introduction to Container Terminology; Scott McCarty (fatherlinux); February 22, 2018

Leider wird die Terminologie selbst von jenen nicht stringent verwendet, die sie eigentlich kennen müssten. Dies sorgt gerade beim Einstieg in dieses komplexe Thema häufig für Verwirrung. Ich versuche in diesem Artikel so stringent wie möglich zu sein.

Umgebung

Für dieses Tutorial habe ich eine Installation mit Debian 11.1 (Bullseye) verwendet. Auf dem Host existieren die beiden User Alice und Bob, welche für die Nutzung von rootless-Podman vorbereitet werden.

Die Einrichtung von rootless-Podman unter Debian Bullseye

Rootless-Container haben die Eigenschaft, dass sie in User Namespaces (siehe user_namespaces(7) und namespaces(7)) ausgeführt werden. UIDs und GIDs, welche innerhalb des Containers existieren, werden dabei auf UIDs/GIDs des Hosts abgebildet. So besitzt ein Prozess, welcher innerhalb eines Containers mit der UID 0 (root) läuft, außerhalb des Containers bspw. die UID 165537 und damit die Rechte eines normalen Benutzers.

Damit dies funktioniert, wird jedem Benutzer, welcher in der Lage sein soll rootless-Podman-Container auszuführen, ein disjunktes Intervall sogenannter SUBUIDs und SUBGIDs zugewiesen. Dazu werden zuerst das Paket uidmap installiert und anschließend die Dateien /etc/subuid und /etc/subgid erzeugt, wie in folgendem Codeblock dargestellt.

sudo apt install uidmap
[...]
$ cat /etc/subuid
alice:100000:65536
bob:165536:65536

$ cat /etc/subgid
alice:100000:65536
bob:165536:65536

Ich habe mich hier an der RHEL 8 Dokumentation orientiert, welche am Ende des Artikels verlinkt ist. Darüber hinaus ist das Vorgehen in der Manpage podman(1) im Abschnitt „Rootless mode“ dokumentiert.

Nun werden podman und skopeo installiert, welche im weiteren Verlauf dieses Tutorials zum Einsatz kommen werden.

sudo apt install podman skopeo

Die Konfiguration von Container-Registries

In der Datei /etc/containers/registries.conf befindet sich die systemweite Konfiguration für Container-Registries. Jeder Benutzer kann abweichend von dieser eine eigene Konfiguration unter $HOME/.config/containers/registries.conf pflegen.

Bevor nun die ersten Container-Registries konfiguriert werden, möchte ich kurz auf voll-qualifizierte Image-Namen und Präfixe eingehen.

Im Internet findet man häufig Beispiele für Befehle wie podman pull ubuntu. Dabei ist podman das Kommando, pull ein Subkommando und ubuntu der Kurzname des herunterzuladenden Images.

Obige Kurznamen haben das Problem, dass durch ihre Verwendung nicht spezifiziert wird, aus welcher Container-Registry das Image heruntergeladen werden soll. Existiert ein Image mit gleichem Namen in diversen Container-Registries, wird es aus der ersten heruntergeladen, in der es gefunden wurde. Dies stellt ein potenzielles Sicherheitsrisiko dar!

Nehmen wir an, auf einem System sind die Container-Registries registry-1.de und registry-2.de konfiguriert. Das ubuntu-Image befindet sich unter registry-2.de/canonical/ubuntu. Stellt nun jemand ein Image gleichen Namens unter registry-1.de/boeserbube/ubuntu ein, wird bei Ausführung des oben genannten Kommandos mit Image-Kurznamen das falsche Container-Image heruntergeladen. Dies birgt die Gefahr, dass auf diesem Wege mit Schadcode angereicherte Container-Images ihren Weg ins System finden.

Es wird daher dringend empfohlen, stets den voll-qualifizierten Image-Namen zu verwenden, um vorstehend beschriebenes Sicherheitsrisiko auszuschließen. Der voll-qualifizierte Name hat dabei folgende Form:

host[:port]/namespace[_namespace_...]/repo(:_tag|@digest)

• host spezifiziert den FQDN unter dem eine Container-Registry erreichbar ist, z. B. registry.fedoraproject.org.
• port ist optional und wird verwendet, wenn die Registry nicht den Port 443/tcp nutzt.
• namespace spezifiziert den Namensraum, in dem Container-Repos bereitgestellt werden.
• repo bezeichnet ein Repository, aus dem konkrete Container-Images heruntergeladen werden können.
• _tag|@digest optional können spezifische Tags oder Digests mit angegeben werden, um eine spezifische Version eines Container-Images herunterzuladen. Standardmäßig wird immer die letzte Version (mit dem Tag latest) heruntergeladen.

Statt einem podman pull ubuntu wird also ein podman pull registry-2.de/canonical/ubuntu empfohlen. Dabei stellt registry-2.de den Host, canonical den Namespace und ubuntu das Repository dar. Bei Verwendung der Docker-Registry führt man so nicht podman pull ubuntu aus, sondern stattdessen podman pull docker.io/library/ubuntu.

Für dieses Tutorial werden mehrere Registries durch folgenden Eintrag in der Datei /etc/containers/registries.conf konfiguriert:

unqualified-search-registries = ['registry.fedoraproject.org', 'registry.access.redhat.com', 'registry.centos.org', 'quay.io', 'registry.opensuse.org', 'registry.suse.com, 'docker.io']

Diese habe ich dem englischsprachigen Artikel unter 2 entnommen und um die Registries aus /etc/containers/registries.conf.d/shortnames.conf ergänzt. Letztere Datei stammt aus dem Paket golang-github-containers-common und stellt Aliase/Shortnames bereit, mit denen man sich einige Tipparbeit ersparen kann, da sie die Shortnames mit den entsprechenden Registries verknüpft. So sorgt z. B. der folgende Eintrag dafür, dass der Befehl podman pull rhel7 das Image ausschließlich aus der Registry „registry.access.redhat.com/rhel7“ herunterlädt und aus keiner anderen.

[aliases]
 "rhel7" = "registry.access.redhat.com/rhel7"

Auf diese Weise können Shortnames gefahrlos verwendet werden.

Jetzt, da einige Registries konfiguriert sind, können wir zum nächsten Abschnitt übergehen und mit Podman nach Images suchen.

Die Suche von Container-Images mit Podman

Mit folgendem Kommando durchsucht man die konfigurierten Registries nach einem Image für ‚debian‘:

$ podman search debian
INDEX      NAME                                                        DESCRIPTI
ON                                      STARS   OFFICIAL  AUTOMATED
docker.io  docker.io/library/debian                                    Debian is
 a Linux distribution that's compos...  4036    [OK]      
docker.io  docker.io/smartentry/debian                                 debian wi
th smartentry                           6                 [OK]
docker.io  docker.io/library/ubuntu                                    Ubuntu is
 a Debian-based Linux operating sys...  12971   [OK]
[Ausgabe gekürzt]

Auf meinem System lieferte die Suche nach ‚debian‘ 271 Treffer zurück. Die Ausgabe wurde zur besseren Übersicht gekürzt. In der Spalte ‚INDEX‘ findet sich der Name der Registry, aus der ein Suchergebnis stammt, gefolgt von der Spalte ‚NAME‘, welche den Namen des gefundenen Repositorys enthält. Nutzer können für einzelne Repos Sterne vergeben, wenn sie diese besonders toll finden. Dies wird in der Spalte ‚STARS‘ ausgedrückt.

Laut Manpage podman-search(1) drückt ein „[OK]“ in Spalte ‚OFFICIAL‘ aus, dass es sich hierbei um ein offizielles Image handelt. Mir ist Stand heute noch unklar, wer diesen Status in den einzelnen Registries vergibt. Er ist in meinen Augen mit etwas Vorsicht zu genießen.

Die Spalte ‚AUTOMATED‘ gibt an, ob das Image automatisiert erstellt wurde und ‚DESCRIPTION‘ sollte selbsterklärend sein.

Die Suche bietet einige Filtermöglichkeiten. So kann man mit folgender Suche nach offiziellen Images filtern:

$ podman search --filter is-official debian
INDEX      NAME                      DESCRIPTION                                      STARS   OFFICIAL  AUTOMATED
docker.io  docker.io/library/debian  Debian is a Linux distribution that's compos...  4036    [OK]      
docker.io  docker.io/library/ubuntu  Ubuntu is a Debian-based Linux operating sys...  12971   [OK]

Damit ist die Ausgabe schon übersichtlicher, viele Informationen bietet sie allerdings nicht. Der folgende Abschnitt zeigt eine Möglichkeit auf, sich etwas mehr Informationen zu verschaffen.

Die Inspektion von Remote-Repos mit Skopeo

Mit skopeo können aus dem Terminal heraus weitere Informationen über ein Remote-Repo abgerufen werden, z.B. für den ersten Suchtreffer von oben:

skopeo inspect docker://docker.io/library/debian

Die Ausgabe obigen Kommandos wird hier stark gekürzt dargestellt. Neben dem Namen befinden sich darin u.a. Informationen zu vorhandenen Tags, das Erstellungsdatum, Layer und Angaben zum Environment:

{
    "Name": "docker.io/library/debian",
    "Digest": "sha256:4d6ab716de467aad58e91b1b720f0badd7478847ec7a18f66027d0f8a3
29a43c",
    "RepoTags": [
        "10.11",
[...]
       "bookworm-20211011",
        "bookworm-20211011-slim",
        "bookworm-backports",
        "bookworm-slim",
        "bullseye",
        "bullseye-20190708",
        "bullseye-20190708-slim",
        "bullseye-20190812",
        "bullseye-20190812-slim",
        "bullseye-20190910",
[...]
        "bullseye-20211011",
        "bullseye-20211011-slim",
        "bullseye-backports",
        "bullseye-slim",
        "buster",
[...]        
    ],
    "Created": "2021-10-12T01:20:30.89167925Z",
    "DockerVersion": "20.10.7",
    "Labels": null,
    "Architecture": "amd64",
    "Os": "linux",
    "Layers": [
        "sha256:bb7d5a84853b217ac05783963f12b034243070c1c9c8d2e60ada47444f3cce04
"
    ],
    "Env": [
        "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    ]
}

Probiert dieses Kommando ruhig einmal selbst aus und blättert durch die sehr umfangreiche Tag-Liste. Hier wird deutlich, dass es sich um ein Repository und nicht um ein einzelnes Image handelt. Neben Bullseye lassen sich hier noch Images für Buster, Stretch, Jessie und weitere herunterladen.

Ich selbst verwende skopeo primär, um mir einen Überblick über die verfügbaren Tags zu verschaffen, um darüber das für mich am besten geeignete Image auswählen zu können.

An dieser Stelle sei darauf hingewiesen, dass zu den meisten Repos eine Webseite existiert, auf der sich weitere Informationen zu einem Repo bzw. Image finden lassen. Hier finden sich oft auch Hinweise, wie ein Image bei der Instanziierung zu parametrisieren ist.

Es braucht dann leider doch mehr als ein Werkzeug, um einen guten Überblick zu bekommen.

Anmeldung an einer Container-Registry

Bisher wurde in diesem Tutorial nur die frei zugängliche Registry „docker.io“ verwendet. Neben dieser existieren noch viele weitere Registries. Auf einige davon darf man erst nach erfolgreicher Authentifizierung zugreifen bzw. sind einige Inhalte erst nach erfolgreicher Authentifizierung zugänglich.

Meist muss man sich zuerst über die Webseite einer Registry registrieren, um Zugangsdaten zu erhalten, welche man dann im Terminal verwenden kann.

$ podman login quay.io
Username: alice
Password:
Login Succeeded!

Vorstehender Code-Block zeigt ein einfaches Beispiel für einen Login-Vorgang. Die Manpage podman-login(1) verrät, dass Benutzername und Passwort base64-codiert in der Datei ${XDG_RUNTIME_DIR}/containers/auth.json gespeichert werden. Dabei löst ${XDG_RUNTIME_DIR} zu /run/user/ auf, welches von der entsprechenden UID und Prozessen mit root-Rechten zugreifbar ist.

Hinweis: Bei Base64-Codierung handelt es sich um keine Sicherheitsfunktion, zum Schutz der Zugangsdaten. Diese werden quasi als Klartext gespeichert.

Die Zugangsdaten werden in der Datei auth.json gespeichert, bis man sich wieder abmeldet (z.B. mit podman logout) oder der Host neu gestartet wird. Weitere Informationen dazu bieten die Manpages podman-login(1) und containers-auth.json(5).

Den Download (Pull) von Container-Images mit Podman

Der folgende Befehl zeigt, wie das Container-Image für Debian Bullseye aus dem Repo ‚debian‘ der Registry ‚docker.io‘ heruntergeladen wird:

$ podman pull docker.io/library/debian:bullseye
Trying to pull docker.io/library/debian:bullseye...
Getting image source signatures
Copying blob bb7d5a84853b done  
Copying config f776cfb21b done  
Writing manifest to image destination
Storing signatures
f776cfb21b5e06bb5b4883eb15c09ab928a411476b8275293c7f96d09b90f7f9

Das Image wird im lokalen Image-Speicher abgelegt. Dieser befindet sich bei Rootless-Podman unterhalb von .local/share/containers/storage/overlay-images/. Die lokal gespeicherten Images kann man sich mit dem folgenden Kommando auflisten lassen:

$ podman images
REPOSITORY                TAG       IMAGE ID      CREATED      SIZE
registry.access.redhat.com/ubi8  latest    b1e63aaae5cf  7 days ago   233 MB
docker.io/library/debian         bullseye  f776cfb21b5e  3 weeks ago  129 MB

Auf meinem Beispielsystem existiert aktuell nur das soeben heruntergeladene Debian-Image sowie ein UBI8-Image.

Container starten, stoppen und entfernen mit Podman

An dieser Stelle möchte ich in Erinnerung bringen, dass es sich bei Linux-Containern um zustandslose Prozesse handelt, welche in Kernel-Namespaces ausgeführt werden. Für wen dies eine völlig neue Erkenntnis ist, der sei auf die Artikel unter 3, 4 und 5 verwiesen.

In den folgenden Unterpunkten führe ich noch einige wenige Beispiele exemplarisch auf. Für weitere Optionen sie auf die Manpage podman(1) verwiesen, welche einen Überblick über allgemeine Optionen und Verweise zu verfügbaren Podman-Kommandos bietet.

Befehl in einem Container ausführen

Dieses Beispiel zeigt, wie ein Container von einem lokal gespeicherten Image instanziiert wird, einen einzigen Befehl ausführt, dessen Ausgabe nach STDOUT schreibt und danach beendet und entfernt wird:

$ podman run --rm ubi8 cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="8.4 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.4"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.4 (Ootpa)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:8.4:GA"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/red_hat_enterprise_linux/8/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_BUGZILLA_PRODUCT_VERSION=8.4
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.4"

Der Container existierte nur für die Zeit, die zur Ausführung des Befehls cat /etc/os-release erforderlich war. Die Ausgabe lässt erkennen, dass das Image ubi8 ein Userland aus RHEL 8.4 bereitstellt.

Einen Dienst in einem Container starten

Möchte man einen Dienst in einem Container laufen lassen, so gibt es dafür die Option ‚-d‘, mit welcher man den Container im Hintergrund startet. Ich demonstriere dies an einem kleinen Webserver:

$ podman run -d -p 8080:80 httpd
✔ docker.io/library/httpd:latest
Trying to pull docker.io/library/httpd:latest...
Getting image source signatures
Copying blob 462e88bc3074 done  
Copying blob 21d69ac90caf done  
Copying blob ca52f3eeea66 done  
Copying blob 7d63c13d9b9b done  
Copying blob 448256567156 done  
Copying config 1132a4fc88 done  
Writing manifest to image destination
Storing signatures
3893630d276a7bfb4a3d8c74c5be8ad353b82c1f45081dec0d31b599a5856944

Da noch kein Image für ‚httpd‘ im lokalen Image-Speicher existiert, wird dieses automatisch heruntergeladen. Mit der Option -p 8080:80 wird der TCP-Port 8080 des Host-Betriebssystems mit dem Port 80 des Containers verknüpft.

Folgender Code-Block zeigt, dass nun ein einfacher Webserver läuft, welcher die Standard-HTML-Seite „It works!“ ausliefert:

$ curl http://localhost:8080
<html><body><h1>It works!</h1></body></html>

Der Container läuft, bis er durch einen Neustart des Betriebssystems oder manuell durch den Benutzer beendet wird.

Container stoppen

Um einen im Hintergrund laufenden Container zu stoppen, wird zunächst dessen ID benötigt. Diese ist in der ersten Spalte der Ausgabe des Kommandos podman ps enthalten:

$ podman ps
CONTAINER ID  IMAGE                           COMMAND           CREATED         STATUS            PORTS                 NAMES
3893630d276a  docker.io/library/httpd:latest  httpd-foreground  16 minutes ago  Up 2 minutes ago  0.0.0.0:8080->80/tcp  optimistic_visvesvaraya

Gestoppt wird der Container mit folgendem Befehl:

$ podman container stop 3893630d276a
3893630d276a7bfb4a3d8c74c5be8ad353b82c1f45081dec0d31b599a5856944

Es wird die vollständige ID des Containers ausgegeben. Diese kann genutzt werden, um den Container zu entfernen (podman rm ID) oder um ihn wieder zu starten (podman start ID).

Wird ein Container nur gestoppt, bleibt seine Konfiguration erhalten, sodass er mit den gleichen Optionen wieder gestartet werden kann. Eine Übersicht über gestoppte oder anderweitig beendete Container bietet das folgende Kommando:

$ podman ps --all
CONTAINER ID  IMAGE                           COMMAND           CREATED         STATUS                     PORTS                 NAMES
3893630d276a  docker.io/library/httpd:latest  httpd-foreground  13 minutes ago  Exited (0) 16 seconds ago  0.0.0.0:8080->80/tcp  optimistic_visvesvaraya

Die Verwaltung von Container-Prozessen und -Images

Eine Übersicht über laufende Container bietet das folgende Kommando:

$ podman ps
CONTAINER ID  IMAGE                           COMMAND           CREATED         STATUS            PORTS                 NAMES
3893630d276a  docker.io/library/httpd:latest  httpd-foreground  16 minutes ago  Up 2 minutes ago  0.0.0.0:8080->80/tcp  optimistic_visvesvaraya

Möchte man einen Container entfernen, so geschieht dies mit dem Kommando podman rm ID. Dabei wird nur die Konfiguration des Containers entfernt, nicht das lokal gespeicherte Image. Folgender Code-Block verdeutlicht dies:

$ podman rm 4476cb9d7eec939281abfe0b12bdb8f2083154dbfbc138492b811e0389ad5bfa
4476cb9d7eec939281abfe0b12bdb8f2083154dbfbc138492b811e0389ad5bfa

$ podman ps --all
CONTAINER ID  IMAGE   COMMAND  CREATED  STATUS  PORTS   NAMES

$ podman images
REPOSITORY                       TAG       IMAGE ID      CREATED      SIZE
registry.access.redhat.com/ubi8  latest    b1e63aaae5cf  7 days ago   233 MB
docker.io/library/httpd          latest    1132a4fc88fa  11 days ago  148 MB
docker.io/library/debian         bullseye  f776cfb21b5e  3 weeks ago  129 MB

Möchte man auch das Image entfernen, so geschieht dies mit folgendem Befehl:

$ podman rmi b1e63aaae5cf
Untagged: registry.access.redhat.com/ubi8:latest
Deleted: b1e63aaae5cffb78e4af9f3a110dbad67e8013ca3de6d09f1ef496d00641e751

Bei ‚b1e63aaae5cf‘ handelt es sich um die Image-ID, welche in der Ausgabe von podman images zu sehen ist.

Die persistente Speicherung von Daten in Podman-Volumes

Container sind, wie bereits erwähnt, zustandslose Objekte. Möchte man Daten persistent speichern, können dafür sogenannte Podman-Volumes verwendet werden.

So ist es bspw. möglich, ein Verzeichnis vom Host in einen Container hinein zu mounten. Schreibt der Container-Prozess nun Daten in diesem Mountpoint, bleiben diese erhalten, nachdem der Container gelöscht wurde. Sie können später in eine neue Container-Instanz hinein gemountet werden.

Beispiel: Verzeichnis vom Host in Container einhängen

Im folgenden Code-Block wird ein Verzeichnis im HOME-Verzeichnis eines normalen Nutzers erstellt und anschließend in einen Container eingehängt. Der Einhängepunkt im Container muss dabei bereits im Container-Image existieren. Der Container erstellt eine Datei namens TEST in diesem Volume. Anschließend wird der Container beendet und entfernt. Die erstellte Datei befindet sich weiterhin in dem Verzeichnis auf dem Host.

$ mkdir testdir
$ podman run --rm -v ~/testdir:/tmp:Z debian touch /tmp/TEST
$ ls -l testdir/
total 0
-rw-r--r--. 1 alice alice 0  7. Nov 14:01 TEST

Die Option ‚Z‘ sorgt dafür, dass der SELinux-Datei-Kontext für das Verzeichnis korrekt gesetzt wird, sodass der Container auf dieses Volumen zugreifen kann. Für weitere Details siehe Option ‚-v‘ in podman-run(1).

Podman-Volume erstellen und einhängen

Mit podman-volume(1) stellt Podman ein einfaches Verwaltungswerkzeug für Podman-Volumes zur Verfügung. Folgendes Code-Beispiel zeigt, wie mit podman-volume-create(1) ein Volume mit einem eindeutigen Beizeichner (testdir2) erstellt wird. Anschließend wird dieses, wie im vorangehenden Beispiel, in einen Container eingehängt und die Datei TESTDATEI hineingeschrieben.

$ podman volume create testdir2
testdir2
$ podman run --rm -v testdir2:/tmp:Z debian touch /tmp/TESTDATEI

Doch wo findet man nun die TESTDATEI außerhalb des Containers wieder? Wo befindet sich der Speicherort des zuvor erstellten Volumes ‚testdir2‘? Auskunft darüber gibt das Kommando podman volume inspect VOLUMENAME:

$ podman volume inspect testdir2
[
    {
        "Name": "testdir2",
        "Driver": "local",
        "Mountpoint": "/home/alice/.local/share/containers/storage/volumes/testdir2/_data",
        "CreatedAt": "2021-11-07T14:39:56.557400855+01:00",
        "Labels": {},
        "Scope": "local",
        "Options": {}
    }
]

Der Schlüssel Mountpoint gibt den Volume-Pfad an. Und tatsächlich findet sich dort die TESTDATEI:

$ ls -l /home/alice/.local/share/containers/storage/volumes/testdir2/_data
total 0
-rw-r--r--. 1 alice alice 0  7. Nov 14:40 TESTDATEI

Die TESTDATEI gehört Alice, welche den Container-Prozess gestartet hat. Möchte man den Inhalt eines Volumes sichern, kann man die enthaltenen Verzeichnisse und Dateien mit bekannten Mitteln kopieren oder mittels podman-volume-export(1) in ein TAR-Archiv verpacken:

$ podman volume export testdir2 -o testdir2.tar

Benötigt man das Volume nicht mehr, kann man es inkl. seines Inhalts mit dem folgenden Befehl löschen:

$ podman volume rm testdir2
testdir2

Möchte man sich die existierenden Volumes anzeigen lassen, gelingt dies mit dem folgenden Befehl:

$ podman volume ls
DRIVER      VOLUME NAME
local       vol1
local       vol2
local       vol3

Der Spalte DRIVER ist zu entnehmen, dass alle diese Volumes im lokalen Dateisystem gespeichert sind. Über weitere Storage-Backends kann ich an dieser Stelle leider noch keine Aussage treffen, da mir hierzu noch das notwendige Wissen fehlt.

Zum Abschluss dieses Abschnitts noch der Befehl, mit dem sich alle ungenutzten Volumes entfernen lassen:

Achtung: Bei folgendem Kommando ist Vorsicht geboten. Ein genauer Blick darauf, welche Volumes entfernt werden sollen, lohnt sich. Andernfalls droht Datenverlust.

$ podman volume prune
WARNING! This will remove all volumes not used by at least one container. The following volumes will be removed:
vol1
vol2
vol3
Are you sure you want to continue? [y/N] y
vol1
vol2
vol3

An dieser Stelle möchte ich den kurzen Überblick über die Podman-Volume-Befehle beenden. Wer sich weitergehend damit auseinandersetzen möchte, findet über die Manpage podman-volume(1) einen guten Einstieg.

Fazit

Am Ende dieses Tutorials sollte man in der Lage sein, Rootless-Podman auf Debian Bullseye einzurichten. Mit ein wenig Abstraktionsvermögen sollte dies auch auf weiteren Distributionen gelingen.

Die grundlegenden Befehle zur Bedienung und Nutzung wurden kurz vorgestellt, sodass man nun über das nötige Wissen verfügt, die ersten eigenen Schritte mit dieser noch recht jungen Technologie zu unternehmen.

Für eure ersten Versuche mit Podman wünsche ich euch viel Spaß und Erfolg.

Quellen und weiterführende Links

1. RHEL 8 Building, running, and managing containers. Chapter 1.5. Upgrading to rootless containers URL: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/building_running_and_managing_containers/assembly_starting-with-containers_building-running-and-managing-containers#proc_upgrading-to-rootless-containers_assembly_starting-with-containers
2. How to manage Linux container registries. Valentin Rothberg (Red Hat). Enable Sysadmin. 2021-02-16.
3. Architecting Containers Part 1: Why Understanding User Space vs. Kernel Space Matters; [Scott McCarty (fatherlinux)}(https://www.redhat.com/en/authors/scott-mccarty-fatherlinux); July 29, 2015
4. Architecting Containers Part 2: Why the User Space Matters; Scott McCarty (fatherlinux); September 17, 2015
5. Architecting Containers Part 3: How the User Space Affects Your Application; Scott McCarty (fatherlinux); November 10, 2015
6. Beginn der Artikelserie „Kanboard im Container…“; My-IT-Brain; Jörg Kastning; 2021-01-04

Seit ein paar Wochen bin ich Besitzer einer mechanischen Keychron K6-Tastatur. Diese habe ich mir primär aus zwei Gründen angeschafft:

1. Es sollte eine 65% Tastatur mit mechanischen Switches sein.
2. Die Tastatur sollte kabellos funktionieren, am besten per Bluetooth. Bluetooth vor allem deshalb, weil meine Logitech-Maus auch per Bluetooth gekoppelt ist.

Beides erfüllt die K6 perfekt. Man gewöhnt sich recht schnell an die kleine Größe und die fehlenden F-Tasten. Ein kleines Problem gibt es aber leider:

Die Tastatur funktioniert erst nach dem Laden des Bluetooth-Stacks, d.h. wenn man z.B. im Bootmenü (Grub2 oder Bootctl) einen anderen Kernel oder ein anderes Betriebssystem auswählen will, muss man ein USB-Kabel an die Tastatur anschließen.

Das war mir auf Dauer zu blöd und zu unelegant. Es gäbe grundsätzlich noch die Möglichkeit einen HID-Proxy-fähigen USB-Bluetooth-Dongle einzusetzen, aber leider will die K6 nicht mit dem angeschafften Dongle koppeln. An Selbstbau-HID-Proxies auf Basis eines Raspberry PI-Zeros habe ich erst mal verzichtet.

Die Idee

Eigentlich bräuchte ich nur ein kleines Keypad, welches die Cursor-Tasten und eine Enter-Taste enthält. Keypads mit einem Ziffernblock gibt es wie Sand am Meer zu kaufen und auch programmierbare Keypads gibt es ein paar auf dem Markt. Ersteres war mir aber zu groß und nicht nerdig genug, letzteres viel zu teuer!

Also musste eine Selbstlösung her:

Diese sollte die genannten fünf Tasten plus noch eine Zusatztaste (Escape) enthalten um ein 3×2 Layout zu erhalten und um das Bootmenü und auch das BIOS mit diesem Keypad vollständig steuern zu können.

Alles was ich dazu benötigte, waren sechs Tasten (Switches), Tastenkappen (Keycaps=, eine passende Platine für die Tasten und einen Mikrocontroller, der als HID-Gerät (Sprich Tastatur) arbeiten kann.

Die Bauteile

Hier mal die Liste der Bauteile in Reihenfolge der Schwierigkeit ihrer Beschaffung:

1. Arduino Pro Micro: Grundsätzlich überall für ~11€ kaufbar. Mein Arbeitskollege Lukas hatte noch einen zu Hause rumliegen und hat ihn mir geschenkt (Danke nochmals dafür 😁). Dieser basiert auf dem ATmega32U4, welcher den HID-Modus bereitstellen kann.
2. Zehn Cherry-MX-kompatible Switches von einem No-Name-Hersteller über Amazon. Kostenpunkt ~1€ pro Switch.
3. Zehn symmetrische schwarze Keycaps ohne Beschriftung. Diese zu finden hat mich einen ganzen Abend gekostet! Wäre ich mehr in der Makerszene drin, hätte ich sie in zwei Minuten gefunden (Siehe 4.)
4. Breakout-Boards für die Switches. Diese gibt es in Deutschland z.B. bei Berrybase zu kaufen (Wie auch die Switches und die Keycaps, was ich aber zu spät gemerkt habe).

Da ich zuerst vorhatte das ganze erst einmal Prototyp-mäßig über ein Breadboard zu stecken, habe ich nicht direkt nach solchen Platinchen gesucht und erst einmal die Switches und die Keycaps bestellt. Da aber die Switches sich nur sehr schlecht auf einem Breadboard befestigen lassen, habe ich schnell nach passenden Platinen für die Switches gesucht.

Mehr Teile sind für den Aufbau eines Keypads nicht notwendig. Auf Pullupwiderstände kann man verzichten. Auf LEDs, für meinen Teil, auch.

Der Aufbau

Im Grunde ist der Aufbau sehr einfach:

Man verbindet die Breakout-Boards miteinander, indem man jeweils die 2er und 1er Lötpunkte verbindet. Um mehr Stabilität zu erhalten habe ich noch zusätzlich die Lötpunkte für die LEDs miteinander verbinden (+ und – auf den Breakoutboards). Um mir das Löten einfacher zu machen, habe ich die Platinen vor dem Löten mit Sekundenkleber zusammengeklebt. Das machte am Ende die Lötarbeiten viel einfacher. Danach habe ich die Kabel eingelötet. Das kann man 100% noch schöner machen, aber da das Keypad am Ende eh in ein kleines Gehäuse kommt, spielt das erst mal keine Rolle.

Am Ende habe ich dann noch die Switches eingelötet (Es kam ebenfalls Sekundenkleber als Löthilfe zum Einsatz). Auf den Arduino wird dann ein kleines installiert Sketch und fertig.

Leider habe ich keine Bilder vom Aufbau des Keypads gemacht, deshalb hier an dieser Stelle nur Bilder des fertigen Aufbaus:

Der Sketch ist dann auch ziemlich minimal:

#include <Keypad.h>
#include <Keyboard.h>

const byte rows = 3;
const byte columns = 2;

byte keys[rows][columns] = {
    {0xb0, 0xd7}, // Enter, Key right
    {0xda, 0xd9}, // Key up, Key down 
    {0xb1, 0xd8}  // Escape, Key left
};

byte rowPins[rows] = {3, 4, 5};
byte columnPins[columns] = {2, 9};
Keypad keypad = Keypad(makeKeymap(keys), rowPins, columnPins, rows, columns);

void setup() {
  pinMode(LED_BUILTIN_TX,INPUT); // Disable TX-LED
  pinMode(LED_BUILTIN_RX,INPUT); // Disable RX-LED
  Keyboard.begin();
}


void loop() {
  char key = keypad.waitForKey();

   if (key != NO_KEY){
    Keyboard.write(key);
  }
}

Man benötigt nur die beiden folgenden Libraries:

• Die Keyboard-Library: https://www.arduino.cc/reference/en/language/functions/usb/keyboard/
• Die Keypad-Library: https://playground.arduino.cc/Code/Keypad/

Danach funktioniert das Selbstbau-Keypad vollkommen fehlerfrei. Die einzige Einschränkung ist, dass es keine Tastenwiederholung gibt (Man muss die Taste loslassen und neu betätigen). Aber das spielt bei der Funktion, für die ich das Pad gebaut habe, keine Rolle.

Hier im Blog spreche ich mich immer wieder für Produkte bzw. Betriebssysteme von Apple aus und bekomme dafür ebenso oft Kritik. Meiner Meinung nach ist jedoch Perfektion der Feind des Guten und auch kleine Fortschritten lohnen sich.

Desktop und Smartphone sind nicht alles

Zuerst einmal lohnt es sich mal einen Schritt zurück zu machen und den ganzen Komplex Betriebssysteme, Smartphone und Desktop von seinem Sockel runter zu nehmen. Datenschützer schreiben gerne über den Komplex, weil man hier was tun kann und kehren alle anderen Bereiche unter den Teppich. Gedanken zu dieser Selbstermächtigung im Angesicht der Ohnmacht hatte ich vor einiger Zeit schon mal was geschrieben.

Auf konkretes Beispiel heruntergebrochen: Du kannst ein super gehärtetes System mit Coreboot und FreeBSD nutzen und vielleicht ein Purism Librem 5 als Smartphone (ich übertreibe jetzt absichtlich). Wenn du dann vor die Tür gehst und in deinen Tesla oder ein anderes modernes Auto steigst, ist dein persönlicher Datenschutzniveau bereits völlig im Eimer – um es mal umgangssprachlich auszudrücken. Und hier haben wir noch nicht mal von Konzepten wie beispielsweise der elektronischen Patientenakte gesprochen, die sich völlig der Kontrolle des Einzelnen entzieht. Ganz zu schweigen davon, dass man natürlich an keinem Bonusprogramm wie payback & Co partizipiert. Mit Kredit/Debitkarte zahlt man natürlich auch nicht. Und man schließt besser auch keine Verträge mit Schufa-Überprüfung. Unter der Brücke, soll es sich ganz gut leben lassen, hab ich gehört. Hauptsache der Datenschutz ist gewahrt! Allerdings natürlich nur wenn man ein blickdichtes Zelt hat.

Das bedeutet jetzt nicht, dass man im Bereich der eigenen Geräte nichts machen sollte, aber vielen Leuten würde es guttun, von ihrem Sockel herunterzusteigen. Die vermeintlichen Lichtgestalten strahlen außerhalb ihrer Selbstdarstellung meist gar nicht so hell. Datenschutz im Alltag ist viel mehr und gemessen am großen Ganzen wiegen die Fortschritte im digitalen Bereich vielleicht gar nicht so schwer.

Ausgangsniveau beachten

Maßnahmen muss man auf Basis des Ausgangsniveaus der meisten Menschen bewerten. Ausgehend von den Marktanteilen nutzt der durchschnittliche Anwender ein Notebook mit Windows 10 und ein Android-Smartphone. Bei den mobilen Begleitern sind das ausweislich der Zahlen meist ein Budget-Modell von Samsung oder ein Gerät von Xiaomi. Huawei hat zuletzt Marktanteile eingebüßt.

Diese Hardware/Betriebssystem-Ausgangsbasis ist dann mit zahllosen wenig Datenschutz-freundlichen Diensten angereichert. E-Mail-Konten aus dem United Internet-Universum, Cloudspeicher bei einem der großen amerikanischen Unternehmen, Stream für Musik und Serien/Filme usw. usf. Vielleicht auch bereits erste Anleihen am Smart Home-Trend, smarte Lautsprecher und smarte Fernseher. Natürlich mit Rundumüberwachung.

Kleine Schritte, große Wirkung

Bei dieser Ausgangslage können bereits kleine Schritte viel Effekt erzeugen. Mal die Einstellungen auf dem Smartphone durchgehen, den ein oder anderen Dienst, den man nicht braucht abbestellen oder durch eine Datenschutz-freundlichere Alternative ersetzen. Gerade am Anfang ist das Optimierungspotenzial noch gewaltig, ohne gleich den Vorschlaghammer zu benötigen, der den kompletten eigenen Hardwarebestand zertrümmert. Die eigene Hardware kommt dann erst in einem weiteren Schritt dran, vielleicht beim nächsten Erneuerungszyklus, wenn auch aus Gründen des Datenschutz ein anders Gerät von einem besseren Hersteller gewählt wird.

Genau an diesem Punkt kommt für mich auch die Empfehlung für ein MacBook, iPhone & Co. Gemessen an der Datenerhebung von Microsoft und den massiven Datenabflüssen zu Google und nach China bei handelsüblichen Android-Smartphones, bietet Apple einen substanziellen Fortschritt. Keine Perfektion, denn auch bei Apple ist beim Datenschutz noch viel Luft nach oben, aber ein Grundverständnis für Privatsphäre und Datenschutz gibt es zumindest in Teilen des Unternehmens und keine enge Verquickung mit der Werbebranche. Ein „dummer“ Fernseher mit einem Apple TV ist im Zweifelsfall eben doch Datenschutz-freundlicher als ein smarter Xiaomi-TV.

Die stetig steigenden Marktanteile des iPhones in Deutschland sind somit eine gute Entwicklung für das allgemeine Datenschutz-Niveau, zumindest bezüglich der Endgeräte und Dienste.

Linux/freie Software – nett, aber verzichtbar

Hallo – und Linux? Das ist doch superduper perfekt und stellt alles in den Schatten. So ungefähr lauten dann ja meist die Kommentare. Erstens hängt das von der Art ab, wie man Linux nutzt und zweitens bewerte ich reale Fortschritte höher als Luftschlösser von Fantasten. Für diese harten Aussagen gibt es mutmaßlich wieder empörte Kommentare, aber so ist das halt. Linux wird auf dem Desktop in der bisherigen Form keine substanzielle Position mehr einnehmen, der Zug ist abgefahren. Das aktuelle Niveau mag man halten, aber mehr auch nicht. Eher glaube ich noch an steigende Marktanteile von macOS im Desktopsegment.

Die Linux-Community hat schon vor längerer Zeit den Versuch aufgegeben, auf dem Desktop eine gleichwertige Alternative zu macOS oder Windows anzubieten. Ungefähr zu jenem Zeitpunkt, als Canonical seine Investition in den Ubuntu-Desktop massiv zurückfuhr. Stattdessen hat man sich in der Nische eingerichtet, bedient die Bedürfnisse einer hochgradig spezialisierten Community, führt lächerliche Grabenkämpfe und feiert das als Stärke von freier Software.

Im mobilen Bereich ist man sogar von diesem erbarmungswürdigen Niveau noch Jahre entfernt und freut sich schon, wenn das Gerät mit freier Software startfähig ist und rudimentäre Funktionen bietet. Andere Bereiche hat die Community noch nicht mal in den Blick genommen, weil die Kriege von gestern zu viel Ressourcen binden, um in die Zukunft zu schauen.

Es ist daher vollkommen fehlgeleitet, Anwender auf den Linux-Pfad zu zwingen, wenn sie „nur“ etwas für den Datenschutz tun wollen. Da gibt es leichtere, sinnvollere und zukunftsfähigere Alternativen. Diese werde ich hier weiter empfehlen, denn diese Seite hat den Anspruch praktische Hilfestellung für digitalen Selbstdatenschutz zu vermitteln und nicht die reine Lehre zu predigen, die niemand umsetzt.

Schlussfolgerung

Wenn man mit Linux arbeiten kann und möchte, ist das natürlich noch besser, als wenn man macOS nutzt, wenn man Lust hat, sich mit Custom ROMs zu befassen, ist Android besser als iOS. Wenn man das aber zum alleinseeligmachenden Anspruch erhebt, dann haben in diesem Land <5% der Nutzer eine Chance auf wirksamen Datenschutz.

Hier sollte man hinterfragen, ob das wirklich faktengestützt ist oder nur der Selbstdarstellung einer kleinen Minderheit dient, die für ihre Leidensfähigkeit belohnt werden möchte.

Dazu möchte ich ein kleines Bild bemühen. Wenn man sich Datenschutz im digitalen (!) Alltag im Bereich der Endgeräte als Skala von 1 bis 100 vorstellt, wobei „1=Windows/Stock-Android+Crap-Dienste“ und „100=gehärtete Linux+GrapheneOS+selbstgehostete Dienste“, dann kommt man mit macOS/iOS und so Diensten wie Posteo vielleicht schon in Richung von 70-80 Punkte. Hier darf durchaus hinterfragt werden, ob die Entbehrungen für die letzten Meter noch einen nennenswerten Ertrag bringen. Das Paretoprinzip lässt hier freundlich grüßen.

Für die große Mehrheit ist ein Wechsel auf macOS/iOS schon ein Fortschritt für den persönlichen Datenschutz und dieser Fortschritt ist realistischer als ein verbreiteter Einsatz von Linux.

Zumal – und das führt an den Anfang des Artikels zurück – Desktopbetriebssysteme und Smartphones nur ein sehr kleiner Baustein sind und nur, weil man hier verhältnismäßig viel Einfluss nehmen kann, sollte man nicht dem Glauben verfallen, hier auch einen großen Effekt zu haben. Ob man hier nun ein zu 80 % oder 100 % perfektes System hat, ist auch schon wieder nicht mehr so wichtig, wenn der Rest nicht auch perfekt ist – und das ist er bei niemandem.

Der Artikel Datenschutz im Alltag – Auch kleine Schritte lohnen erschien zuerst auf [Mer]Curius