ubuntuusers.de

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

Neuerungen von Thunderbird 91.3.1

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

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

Di, 16. November 2021, Lioh Möller

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mo, 15. November 2021, Lioh Möller

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

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

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

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

Mo, 15. November 2021, Ralf Hersel

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

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

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

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

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. Nur wenn man explizit einen Tag angibt, kann man sicher sein, welche Version man bekommt (Vielen Dank an Dirk für diesen Hinweis).

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.

Bitte beachtet, dass für die Nutzung folgender Registries eine Authentifizierung notwendig ist, für die ein Account bei der jeweiligen Registry erforderlich ist:

• registry.suse.com
• registry.access.redhat.com
• quay.io

Wie man sich an einer Registry authentisiert, wird im Abschnitt Anmeldung an einer Container-Registry erläutert.

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.

Kein Datenschutz ohne freie Software?

Der Ruf nach freier Software bzw. die Gleichsetzung von Open Source und Privacy hat sich inzwischen in vielen Köpfen verankert. Ohne Linux kann es bei vielen Kommentatoren keinen Datenschutz geben. Dadurch schirt sich eine exklusive Gruppe nach außen ab und alle anderen können sowieso keinen Datenschutz erreichen.

Das sehe ich nicht so. Erstens hängt das von der Art ab, wie man Linux nutzt und zweitens halte ich reale Fortschritte für wichtiger als für viele unerreichbare ideale Fernziele. 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 und das wäre bei richtiger Konfiguration für den Datenschutz nicht so viel schlechter als ein Linux-System

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ähige 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 dann trotzem 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 Kommentar: Datenschutz im Alltag – Auch kleine Schritte lohnen erschien zuerst auf [Mer]Curius

elementaryOS verfügt über eine Status- und Menüleiste, ähnlich macOS. In dieser Leiste, welche sich am oberen Bildschirmrand befindet, befinden sich Indikatoren für das Netzwerk, den Sound und einige andere Dinge. Auch Applikationen, wie z. B. der Nextcloud-Client legen dort ihr Status-Icon ab. Wenn der Nextcloud-Client unter elementaryOS in der Version 6 (Odin) installiert wird, taucht allerdings kein Icon in der oberen Leiste auf. Grund hierfür ist das diese nicht Out-of-the-box unterstützt wird.

Allerdings kann hier Abhilfe geschaffen werden mit dem Wingpanel Ayatana-Compatibility Indicator. Um diesen in elementaryOS zu installieren, sollte im ersten Schritt das Terminal geöffnet und einige Abhängigkeiten installiert werden:

install libglib2.0-dev libgranite-dev libindicator3-dev libwingpanel-dev indicator-application

Anschließend kann der Download der entsprechenden DEB-Datei angestoßen werden:

wget -c "https://github.com/Lafydev/wingpanel-indicator-ayatana/blob/master/com.github.lafydev.wingpanel-indicator-ayatana_2.0.7_amd64.deb?raw=true" -O wingpanel-indicator.deb

Danach wird das heruntergeladene Paket installiert:

dpkg -i wingpanel-indicator.deb

Nun muss dafür gesorgt werden, dass der Wingpanel Ayatana-Compatibility Indicator beim Systemstart geladen wird. Dies kann unter elementaryOS über die Systemeinstellungen und dort den Punkt Anwendungen bewerkstelligt werden. Dort findet sich der Punkt Beim Anmelden automatisch gestartete Anwendungen. Unter diesem Punkt wird nun unten links eine neue Anwendung hinzugefügt und dort ein benutzerdefinierter Befehl eingegeben:

/usr/lib/x86_64-linux-gnu/indicator-application/indicator-application-service

Im Terminal muss nun noch eine Änderung an der Datei indicator-application.desktop vorgenommen werden:

nano /etc/xdg/autostart/indicator-application.desktop

Dort muss nun der Parameter Pantheon; hinzugefügt werden, sodass die Datei am Ende wie folgt aussieht:

[Desktop Entry]
Type=Application
Name=Indicator Application
Exec=/usr/lib/x86_64-linux-gnu/indicator-application/indicator-application-service
StartupNotify=false
Terminal=false
OnlyShowIn=Unity;GNOME;Pantheon;
NotShowIn=ubuntu;
NoDisplay=true
AutostartCondition=GNOME3 unless-session gnome

Nach einem Neustart des Systems funktioniert der neue Indikator, sodass z. B. das Status-Icon des Nextcloud-Clients ebenfalls auftauchen sollte.

Was Linux-Distributionen angeht, bin ich ein Freund von elementaryOS. Vor einiger Zeit hatte ich diese Distributionen auf einem älteren Laptop installiert. Die Festplattenverschlüsselung wurde bei der Installation aktiviert. Beim Hochfahren erschien nun allerdings keine Aufforderung zur Eingabe des Passwortes. Stattdessen blieb der Bildschirm dunkel.

Nach einem erzwungenen Neustart, erscheint dann das GRUB-Bootmenü und nach dem Start der elemantaryOS-Installation erscheint die Passworteingabe im Textmodus. Behoben werden kann diese Verhalten durch eine Änderung der GRUB-Konfiguration:

nano /etc/default/grub

Der Datei sollte nun folgende Zeile hinzugefügt werden:

GRUB_GFXPAYLOAD_LINUX=text

Nach dem Speichern der Datei muss die Konfiguration und mit ihr der Bootloader noch aktualisiert werden:

update-grub

Damit wird beim Start des Linux-Kernels der Textmodus erzwungen und somit sollte die Passworteingabe immer zu sehen sein.

Google hat mit dem Pixel 6 und dem Bose-Deal ein gutes Angebot vorlegt. Zumal dafür mittelfristig GrapheneOS lauffähig sein wird und so manche Querelen mit normalem LineageOS damit der Vergangenheit angehören werden. Bis dahin liegt das Gerät in der Schublade.

Allerdings wollte ich noch kurz die Funktionsfähigkeit testen und habe das Gerät eingeschaltet, die Einrichtungsroutine durchlaufen, kein Google-Konto hinterlegt und lediglich mit dem Gast-WLAN verbunden. Dann habe ich interessehalber Blokada installiert und das Gerät ein paar Stunden liegen gelassen.

Das Ergebnis sieht so aus:

Viele, viele Verbindungen zu allen möglichen Google-Diensten. Viele davon werden mindestens stündlich aktiviert, manche nur beim Aufwecken des Gerätes (die 14-15 Sekunden vorher erfolgte Verbindung). Wie gesagt: Ohne weitergehende Interaktion mit dem Gerät, ohne irgendwelche der Apps zu öffnen.

Das gesamte Portfolio von Play-Store über AdService und die wichtige Werbeplattfom Doubleclick. Eine tiefer gehende Analyse des Datensendeverhaltens ist das jetzt nicht, deshalb sind die Ursache der Abfrage und die mit ihnen übertragenen Metadaten nicht klar, aber vermutlich wird das Übliche an Informationen bei den Verbindungen mit übertragen, um einen digitalen Fingerabdruck zu erzeugen.

Kaum eine dieser Abfragen ist wirklich notwendig. Mein LineageOS-System benötigt keine davon und der Updatecheck und die Push Notifications über die Play Services reichen als Erklärung/Rechtfertigung garantiert nicht aus.

Man muss es so deutlich sagen: Bei diesem Datensendeverhalten kann sich Google noch so sehr um Privacywashing bemühen – der Datenschutz ist eine Katastrophe. Nur schade, dass die Berichterstattung immer darauf anspringt. Gerne natürlich von Bloggern und Newsseiten mit vielen Anzeigen und Analysewerkzeugen von Google. Eigentlich müsste da unter jeden Artikel ein Transparenzvermerk über mögliche Interessenkonflikte stehen.

Dabei ist ein Google Pixel im Android-Ökosystem sogar noch die bessere Alternative, weil wenigstens nur Daten an Google fließen und nicht noch an ein weiteres Unternehmen wie Samsung oder mittelbar an einen totalitären Überwachungsstaat (Xiaomi, Huawei etc.)

Datenschutz und Googles Android sind zwei unvereinbare Begriffe. Android ist nur dann eine Option, wenn man das Knowhow und die Zeit hat, sich mit alternativen ROMs zu beschäftigen, sowie eher unterdurchschnittliche Erwartungen an Apps hat und diese dann über F-Droid bezieht. Alle anderen weichen besser auf einen Hersteller aus, der seinen Umsatz nicht mit Werbung und damit faktisch auch User-Tracking generiert. Leider ist das momentan einzig und allein Apple.

Der Artikel Google Pixel 6 – Keine Aktivität, viele Anfragen erschien zuerst auf [Mer]Curius

Fr, 12. November 2021, Lioh Möller

Unmittelbar nach der Veröffentlichung der neuen Red Hat Enterprise Linux Version 8.5 steht eine aktualisierte Version von AlmaLinux zur Verfügung. Die Geschwindigkeit, mit der diese bereitgestellt wurde, stellt eine herausragende Leistung des Projektes dar.

Neben neuen Versionen für die x86_64 und ARM Architekturen werden Images für den Raspberry Pi angeboten.

Die Live ISOs sowie die Abbilder für die Cloud und Containernutzung werden in Kürze nachgeliefert. Das AlmaLinux bedankt sich in der Ankündigung ausdrücklich beim CentOS Projekt und läutet eine neue Ära der RHEL-Clones ein.

AlmaLinux möchte auch in Zukunft mit CentOS Stream zusammenarbeiten, um so einen bestmöglichen Nutzen für die Anwender beider Distributionen zu bieten.

In der aktuellen Version wurden unter anderem die Container Tools verbessert und OpenJDK 17 integriert. Darüber hinaus wurde Network Time Security (NTS) zur Erhöhung der Sicherheit von NTP implementiert. Eine ausführliche Liste aller Änderungen finden sich in den Release Notes.

Quelle: https://almalinux.org/blog/almalinux-os-85-stable-now-available/

Download: https://mirrors.almalinux.org/isos

Fr, 12. November 2021, @65536@troet.cafe

NixOS ist eine Linuxdistribution, die viele Dinge bei der Systemverwaltung anders handhabt als die meisten anderen Distributionen. Wie es funktioniert und weshalb es anders gemacht wird, darum soll es in dieser Artikelserie gehen.
Im ersten Teil wird es einen Überblick über die Ideen, die hinter NixOS stehen, geben. Im zweiten werden die Installation und grundlegende Konfiguration behandelt, und der dritte Teil befasst sich mit Details der Softwareverwaltung. Im vierten Teil folgen ein paar Empfehlungen und sonstige Details.

Imperativ

Klassischerweise wird Linux zu grossen Teilen imperativ verwaltet. Das bedeutet, einzelne Befehle werden nacheinander angewandt, um das System Schritt für Schritt in den gewünschten Zustand zu bringen. NixOS erlaubt zwar diesen imperativen Ansatz, versucht jedoch, soweit irgend möglich, stattdessen deklaratives Verwalten anzubieten.

Der Grund dafür ist die mangelnde Reproduzierbarkeit beim imperativen Ansatz. Zwei Instanzen eines Betriebssystems unterscheiden sich in der Regel, weil sie unterschiedliche Vergangenheiten haben. Vielleicht wurde auf einem System eine Software getestet, auf dem anderen jedoch nicht. Auch nach Deinstallation hinterliess es Spuren auf dem ersten. Vielleicht wurde Software in unterschiedlichen Abständen aktualisiert, oder in unterschiedlichen Versionen erstmals installiert, weshalb kleine Unterschiede auftreten.

Selbst wenn man sich bemüht, mehrere Betriebssysteminstanzen immer gleich zu verwalten, werden sich durch kleine Zufälle und Versehen die Unterschiede anhäufen, bis auf einem System ein Befehl gelingt und auf dem anderen scheitert, und man sich fragt, warum.

Deklarativ

NixOS wurde konzipiert in der Bemühung, möglichst viele Dinge deklarativ konfigurieren zu können, sodass lange Zeit zurückliegende imperative Befehle keinen Einfluss darauf haben, was man jetzt erreichen will. Hierzu wird eine in /etc/nixos/ abgelegte Datei configuration.nix bearbeitet. In der nix-eigenen Syntax lassen sich die gewünschten Pakete angeben, zahlreiche Optionen von der Zeitzone über automatische Updates bis hin zu Benutzereinstellungen deklarieren und bei Bedarf weitere Konfigurationsdateien mit mehr Details einbinden.

Mit einem einzigen Befehl kann dann - nach jeder Änderung der Konfigurationsdatei - diese auf das komplette System angewandt werden, wahlweise bei Neustart oder - soweit ohne diesen möglich - sofort. Jede solche Neukonfiguration sowie jedes Systemupdate erzeugt einen neuen Booteintrag, was bei Problemen und Fehlkonfigurationen Rollbacks sehr leicht macht.

Anstatt sein System mit Einzelbefehlen kontinuierlich umzuformen, hat man nun eine Datei als Bauanleitung, die knapp und deutlich definiert, wie das System auszusehen hat.

Reproduzierbar

Ein resultierender grosser Vorteil ist die Reproduzierbarkeit. Stattet man mehrere Rechner mit derselben Konfiguration aus, so gilt diese für alle. Andernfalls müssten eine ganze Reihe an Befehlen zum Einrichten eines Programms oder zum Setzen bestimmter Einstellungen auf sämtlichen Rechnern jeweils identisch durchgeführt werden, was wesentlich fehleranfälliger ist.

Auch für einzeln zu verwaltende Rechner ist die Reproduzierbarkeit nützlich. Um sein System wiederherzustellen oder um einen neuen Rechner einzurichten, braucht es weder ein vollständiges Backup der Festplatte noch eine Liste aller bislang vorgenommenen Installationen von Software. Das Sichern und Einfügen der Konfigurationsdatei reicht, was Speicherplatz im Backup und Zeit bei der Einrichtung spart.

Lediglich die hardwarespezifischen Konfigurationsteile könnten eine Änderung benötigen.

Funktional

Damit die Konfiguration wirklich reproduzierbar angewandt werden kann, muss ein funktionaler Paketmanager eingesetzt werden. Dieser wird Nix genannt. Um zu garantieren, dass das Installieren eines Paketes überall dasselbe Resultat bewirkt, werden alle Abhängigkeiten unabhängig von bereits installierter Software berechnet und alles unter /nix/store/ installiert, in einem Ordner mit einem Hashwert als Präfix. Der Hashwert ändert sich, wenn das Paket in irgendeiner Weise anders erstellt und installiert wird, im einfachsten Fall bei einer Versionsänderung. Nix ist rein funktional: die Installation desselben Paketes in derselben Version resultiert immer in einem identischen Eintrag im Nix-Store, unabhängig von jeder Eigenschaft der NixOS-Instanz.

Unkonventionell

All diese Eigenschaften zu haben, bedeutet für NixOS, in einigen Dingen ungewöhnliche Wege gehen zu müssen. Insbesondere sind zahlreiche Ordner und Dateien nicht dort, wo sie üblicherweise zu erwarten sind, sondern sind Verknüpfungen auf den Nix-Store. Die Tatsache, dass zum Systemstart lediglich /nix/ und /boot/ zwingend nötig sind, erlaubt auch interessante Ansätze, um Systemzustand noch weiter zu verringern.

Wie oben erwähnt soll im weiteren Verlauf der Artikelserie konkreter auf die Handhabung von NixOS eingegangen werden. Von all den Möglichkeiten und Werkzeugen wird allerdings nur an der Oberfläche gekratzt werden, um Interessierten den Einstieg in NixOS zu erleichtern.

Links

https://nixos.org/
https://nixos.wiki/

Do, 11. November 2021, Ralf Hersel

In der Vergangenheit finden sich einige Beispiele dafür, wie sich 'übermotivierte' Projekte vom Community-Geist verabschiedet haben. Da wäre zum Beispiel die Firma Canonical, die sich mit vielen Ideen (TV, Smartphone, MIR, Unity, Snap-Paketen) vom Rest der freien Gesellschaft abheben wollte, letztendlich aber damit gescheitert ist. Oder Tuxedo-Computers, die mit TUXEDO-OS (einem Ubuntu-Derivat) einen eigenen Weg beschritten sind.

Eine ähnliche Richtung schlägt nun auch der Geräte- und Distro-Hersteller System76 ein. Wir berichteten darüber, dass die Firma demnächst GNOME links liegen lässt, um einen eigenen Desktop (COSMIC) zu entwickeln. In den letzten Tagen hat sich das Verhältnis zwischen System76 und dem GNOME-Team weiter abgekühlt, was sich in einem Blog-Post des GNOME-Designers Chris Davis manifestiert.

Als Einleitung schreibt er:

In letzter Zeit gab es einige hitzige Diskussionen über die Zukunft von GNOME. Dies hat dazu geführt, dass eine Menge Angst, Unsicherheit und Zweifel über GNOME verbreitet wurden, sowie Angriffe und Feindseligkeit gegenüber GNOME als Ganzes und gegenüber einzelnen Mitwirkenden. Dies begann grösstenteils aufgrund der Äusserungen von Mitarbeitern der Firma System76.

Einer der Streitpunkte ist der Linux Vendor Firmware Service (LVFS). In den Jahren 2017 und 2018 kommunizierte Richard Hughes, dass man für Firmware Updates LVFS einsetzen wolle. Dann kündigte System76 plötzlich seine eigene Infrastruktur und Software für Firmware-Updates an.

Weiter ging es mit der Behandlung von Patches. Im Jahr 2019 teilte Sebastien Bacher von Canonical einen Beitrag über den Umgang mit Fehlerbehebungen gegenüber Upstream durch System76. Dieses Verhalten betraf sowohl Ubuntu als auch GNOME. System76 hat Fehler, die für Pop!_OS relevant waren, behoben, jedoch nicht an Upstream geliefert:

"Später fingen sie an, die Upstream (Ubuntu, GNOME, ...) Bug Tracker zu kommentieren und weisen die Benutzer darauf hin, dass das Problem in Pop!_OS behoben wurde, und werben damit, dass sie sich um die Benutzer kümmern und das Problem bei sich behoben haben. Sie sollten zwar stolz auf die Arbeit sein, die sie für Ihre Benutzer leisten, aber ich denke, sie gehen hier den falschen Weg. An Korrekturen zu arbeiten und sie früh in das Produkt einzubauen ist eine Sache, diese Korrekturen nicht in an Upstream zu geben, um sich besser vermarkten zu können, ist ein riskantes Spiel", so Sebastien Bacher.

Dann kam System76 mit dem GNOME-Shell Tiling. Ende 2019 begann System76 mit der Arbeit an einer Erweiterung, die ein i3-ähnliches Tiling in GNOME ermöglichte. Als ein Upstream-Designer die Zusammenarbeit beim Tiling anbot, weigerte sich Jeremy Soller, leitender Ingenieur bei System76, mit ihm zu arbeiten. Der wirklich problematische Teil ist, dass System76 in den letzten Jahren immer wieder behauptet hat, dass Upstream nicht an Tiling interessiert sei, was laut Michael Murphy (GNOME) eine Falschaussage ist.

Kurz nachdem GNOME 40 bekannt gegeben hatten, überraschte Jeremy Soller mit der Aussage, dass System76 dem neuen Design der GNOME-Shell nicht zugestimmt habe. Er behauptete auch, dass das Feedback der Designerin nicht berücksichtigt wurde. Laut dem GNOME-Team ist das nicht der Fall. Tatsache sei, dass System76 für etwa ein Jahr des dreijährigen Entwurfsprozesses eine Designerin hinzugezogen hat. Die Designerin nahm an Design-Calls und Diskussionen mit dem Design-Team teil, und ihre Rolle konzentrierte sich auf die UX-Forschung selbst. Während des Designprozesses gab es nie Mockups oder konkrete Vorschläge von System76. Das einzige Mal, dass System76 einen Vorschlag gemacht habe, war ganz am Ende des Entwurfsprozesses bei einem Treffen des Entwurfsteams mit Interessengruppen. Dort stellten sie COSMIC vor und bekamen nicht das gewünschte Feedback.

Das Verhalten des Unternehmens wiederholte das ursprüngliche Muster. Als sich System76 mit seinem Entwurf nicht durchsetzen konnte, begann es, Fehlinformationen zu verbreiten. Dieser spezielle Fall von Fehlinformation war sehr schädlich für den Ruf von GNOME.

Die neueste Eskalation zwischen GNOME und System76 betrifft das Thema 'Gtk Themes und libadwaita'. Als Hintergrund-Information empfehle ich dieses Video von 'The Linux Experiment'. Die umfangreichen Details dazu erfahrt ihr im letzten Kapitel der Quelle.

Fazit

System76 gesellt sich zu den Projekten (Firmen), die Mühe mit der Balance zwischen eigenem Erfolgsbegehren und der Community-Zusammenarbeit haben. Exklusion und eigene Suppen kochen, haben in der Geschichte freier Software noch nie zum Erfolg geführt. Zusammenarbeit unter den Projekten und Upstream-Delivery sind bessere Rezepte um am gemeinsamen Ziel zu arbeiten. Die Firma System76 muss sich fragen lassen, ob ihr Verhalten nicht nur ein Lippenbekenntnis zu freier Software und der Community ist.

Quelle: https://blogs.gnome.org/christopherdavis/2021/11/10/system76-how-not-to-collaborate/

Do, 11. November 2021, Lioh Möller

Zwischen dem 7. und 29. Oktober hat das openSUSE Projekt Paketbetreuer befragt. Nun wurden die Ergebnisse veröffentlicht, welche einerseits erwartbar waren, aber dennoch ein Bild aufweisen, welches in den meisten Free Software Communitys vorzufinden ist.

So gaben 95% der Befragten an männlichen Geschlechts zu sein. Ein Grossteil der Paketbetreuer stammt aus Westeuropa. Nur 6% gaben an aus Amerika zu stammen. Weitere 6% finden sich im asiatischen Raum.

Fast 75% haben einen Universitätsabschluss oder studieren und 68.75% sind oder waren zuvor beruflich im IT-Umfeld tätig.

Als Kommunikationsmittel der Wahl wird weitestgehend auf Mailinglisten und IRC gesetzt. Matrix hingegen spielt bisher eine eher untergeordnete Rolle.

Es sind nahezu alle Altersgruppen vertreten, was aufzeigt, dass ein Projekt wie openSUSE durchaus auch für jüngere Beitragende interessant ist.

Die gesamten Ergebnisse der Umfrage, sowie einige persönliche Stellungnahmen der Befragten finden sich im Wiki

Mi, 10. Oktober 2021, Niklas

Es ist wieder so weit, das Haiku Projekt, ein freier Nachbau des alten BeOS Betriebssystems, berichtet über die Fortschritte in der Entwicklung. Beta 3 ist inzwischen erschienen und ein voller Erfolg. Trotzdem gibt es noch viel zu tun und das Projekt hat wieder beeindruckende Fortschritte gemacht.

Der Kernel wird jetzt immer mit GCC 8 kompiliert, auch auf 32 Bit Systemen. Bisher wurde GCC 2 benutzt, um die Kompatibilität zu BeOS Treibern zu erhalten, aber aufgrund von anderen Neuerungen wie SMAP, wodurch sich das ABI leicht änderte, haben diese ohnehin schon einige Zeit nicht mehr funktioniert. Da sich niemand beschwert hat, sieht das Projekt keinen Grund, die Treiberkompatibilität weiterhin zu behalten. Die Umstellung sorgt für Performanceverbesserungen auf 32 Bit Systemen, da GCC 8 den Code besser optimiert. Ausserdem können Kernelentwickler jetzt modernere C++ Funktionen verwenden.

Des Weiteren wurden Optimierungen am Syscall Entry und Exit vorgenommen. Hier enthielt der Assembler Code einige nutzlose Synchronisierungsinstruktionen, die nur für Hardware Interrupts und nicht für Syscalls gebraucht werden. Diese wurden entfernt.

Es wurden auch einige Anstrengungen unternommen, um das Haiku Hauptpaket zu verkleinern. Aus diesem Grund wurden Translators, Media Add-ons und WLAN Firmwares in eigene Pakete ausgelagert. Sie sind trotzdem noch vorinstalliert. Der Grund für die Änderung ist, dass das Hauptpaket deutlich öfter aktualisiert wird als diese Bestandteile und es ergibt wenig Sinn, die gleichbleibenden Teile jedes Mal neu herunterzuladen.

Das Flat Theme für Haiku, das bereits seit Juni 2020 in Arbeit ist, wurde jetzt zum haiku_extras Paket hinzugefügt. Es kann einfach über Haiku Depot installiert und dann in den Einstellungen aktiviert werden. Damit sieht Haiku deutlich moderner aus. Achtung: Nur für Nightly Nutzer! Beta 3 Nutzer erhalten das haiku_extras Update nicht bzw. erst mit der nächsten grossen Beta.

Im Repository mit den Haiku Build Paketen wurden libavif und ZSTD aktiviert. libavif wird fuer den AVIF Translator gebraucht, ZSTD soll in Zukunft für die HPKG Pakete zum Einsatz kommen und zlib ablösen. Es wird die Pakete kleiner und schneller machen. Ausserdem wurden die Paketinformationen vereinfacht, um zu vermeiden, dass manche Angaben für jede Architektur einzeln gemacht werden müssen.

Der Quellcode der Tools Container und ShelfInspector wurden in Haiku eingefügt. Diese ermöglichen das Testen von Replikanten, ohne sie auf dem Desktop einfügen zu müssen. Sie erscheinen dann in einem eigenen Fenster, was hilfreich beim Debugging ist. Es gab davon zu BeOS Zeiten schon einige Implementierungen, aber bisher war keine im Haiku Quellcode enthalten.

Die os-prober Scripts zum automatischen Erkennen und Hinzufügen von Haiku zu GRUB wurden ebenfalls mit aufgenommen. Vorher waren diese nur im Bug Tracker von Debian zu finden und wurden nicht gemerged. Man hofft, dass sie in die offiziellen os-prober Releases aufgenommen werden, wenn sie jetzt besser zu finden sind.

Auch an den Programmen wurde gearbeitet. In HaikuDepot wurde der Sprachfilter repariert, mit dem nur Review in Sprachen angezeigt werden, die der Nutzer versteht. Ausserdem wurde eine Spalte hinzugefügt, die anzeigt, wann ein Paket zuletzt aktualisiert wurde.

Im MediaPlayer wurde das Caching von Längen in der Playliste verbessert, wenn Dateisysteme verwendet werden, die diese Information nicht in den Dateiattributen speichern können. So kann man zum Beispiel auch auf read-only Dateisystemen ohne Verzögerung durch die Liste scrollen.

Die Hexadezimal-Ansicht in DiskProbe wurde optisch aufgewertet und stellt die Reihen jetzt unterschiedlich dar und hat vertikale Linien, damit man nicht so leicht durcheinander kommt. Das thttpd Server, der vom Poorman Webserver verwendet wird, wurde auf die neueste Version aktualisiert. HaikuWebKit wurde auch aktualisiert, was die Performance verbessert und einige Abstürze behebt.

Die Server und Bibliotheken wurden ebenfalls verbessert. app_server hat Unterstützung für die neu eingeführten RGB48 und RGBA64 Colorspaces bekommen. Ausserdem wurde die Verarbeitung von Clipping und Reverse Clipping verbessert.

Es wurden einige Funktionsanmerkungen hinzugefügt, um GCC mitzuteilen, dass manche Funktionen immer Pointer mit Vielfachen von 2 Bytes zurückgeben. GCC kann dadurch schnelleren Code generieren, zum Beispiel durch Verwendung von SSE2 Instruktionen, die diese Ausrichtung erfordern.

Einige fehlende POSIX Errors wurden zu Errors.h hinzugefügt. Der B_FILE_NOT_FOUND Error wurde aus dem Storage Kit entfernt. Er war schon in BeOS R5 als veraltet markiert und wurde durch den allgemeineren B_ENTRY_NOT_FOUND Errorcode ersetzt.

BMenu hat jetzt Methoden, um Einträge zu sortieren und tauschen, ohne sie zu löschen und neu zu erstellen. Das wird in der Liste der WLAN-Netzwerke genutzt. Vorher konnten Einträge gelöscht werden, als das Menü gerade offen war, was einen Absturz auslöste.

Ein paar spezielle Memory Copy Funktionen wurden aus dem app_server entfernt. Sie wurden als Workaround für Einschränkungen des AGP Bus eingeführt und werden nicht mehr gebraucht, weil die Implementierung von memcpy jetzt genauso gut funktioniert.

Folgende Verbesserungen wurden an den Treibern vorgenommen:

• Intel Grafiktreiber
  • Fehler bei Bildschirmschonern auf älterer Hardware behoben.
  • Bugfixes, wenn Programme ihr Bild am app_server vorbei direkt an den Treiber senden, zum Beispiel durch BWindowScreen.
  • Benutzerdefinierte Bildwiederholungsraten sind jetzt möglich.
  • Erlaubte Frequenzen wurden repariert (die Intel Dokumentation ist teilweise nicht korrekt, also werden jetzt die Informationen aus dem Linux Treiber benutzt).
  • Fortschritt bei der Unterstützung moderner Skylake und Haswell Chipsets.
• Fehler bei fragmentierten USB Transfers und Locking Probleme im XHCI Treiber behoben.
• NVMe Treiber verbessert, mit überarbeitetem Interrupt Handling, Optimierung der Transfers in bestimmten Situationen und besserer Verwendung mehrerer Threads. Das macht den Treiber schneller und mit mehr Hardware kompatibel.
• SMAP Fehler im USB Massenspeicher und Matrox Grafiktreiber behoben.
• Kleine Verbesserungen am Intel HD Audio Treiber.
• Der Code für TTY Handling wurde überprüft, dabei wurden Locking Issues gefunden, die bei Nutzung der seriellen Schnittstelle zu einem Kernel Panic führen können.
• Es wurde begonnen, den TTY Treiber für pseudo-TTY und Terminal und das TTY Modul für serielle Schnittstellen zusammenzuführen.
• TCP Optionen sind jetzt in der gleichen Reihenfolge wie bei anderen Betriebssystemen, was theoretisch egal sein sollte, aber einige TCP Implementationen erwarten keine andere Reihenfolge.
• Unterstützung für MSI-X Interrupts mit 64 Bit PCI BAR Adressen hinzugefügt.
• VESA und Framebuffer Grafik wurden in zwei verschiedene Treiber aufgeteilt, da sie nicht viel Code teilen und der VESA Treiber mehr Funktionen bekommt.
• Es wurde begonnen, die Netzwerktreiber mit FreeBSD 13 zu synchronisieren.
• Der Radeon HD Grafiktreiber wurde verbessert, um einige neuere Grafikkarten zu unterstützen.

Neben den allgemeinen Veränderungen und Verbesserungen findet auch immer mehr Arbeit an der Unterstützung für andere CPU Architekturen statt. Von dem RISC-V Port, über den wir bereits berichteten, wurden weitere Teile übernommen. Das beinhaltet Fehlerkorrekturen bei einigen Linker Scripts und einen Absturz, wenn Threads beendet werden.

Es wird ausserdem daran gearbeitet, den Kernel auf ARM64 zum Laufen zu bringen. Gleichzeitig wird sehr aktiv am ARM (32 Bit) Port gearbeitet. Hier startet der Kernel bereits, des Weiteren wurden folgende Verbesserungen erarbeitet: Der frühe Startprozess wurde aufgeräumt, Unterstützung für das ARM MMU und die Übergabe vom EFI Bootloader zum Kernel wurde hinzugefügt, Fehlerkorrekturen bei Linker Scripts, vollständigere Verarbeitung von ARM-spezifischen ELF Sektionen und einige weitere Dinge.

In einigen Fällen, zum Beispiel auf manchen ARM Geräten, gibt es keinen nativen Textmodus, weshalb der Bootloader jetzt so angepasst wird, dass er eine Text-Konsole (Textmodus auf einem VGA Bildschirm oder serielle Schnittstelle) oder einen Framebuffer mit direkter Pixelzeichnung unterstützt. Je nachdem, was von der Hardware unterstützt wird, wird der Bootloader zwischen Textmodus und Framebuffer entscheiden. Das kann auch bei Systemen mit sehr eingeschränktem Textmodus wie SPARC nützlich sein.

Auch am SPARC Port wurde gearbeitet. Hier gibt es erste Schritte bei der MMU Unterstützung. Bei SPARC wurde das MMU mehrmals bei verschiedenen CPU Generationen verändert und ist ein sehr simples Design, das viel Softwareunterstützung braucht. Als ersten Schritt muss der Kernel die Traps (Exceptions) vom MMU verarbeiten und ihm die korrekten Daten geben. Aber weil der Kernel im virtuellen Speicher arbeitet, muss das MMU funktionieren. Das ist alles möglich und im SPARC Architekturdesign geplant, aber braucht viel spezifischen Code für das erste Setup. Ein Teil dieses Codes muss direkt in Assembler geschrieben werden, was diesen Schritt nicht so einfach macht.

Zu guter Letzt möchte ich auch noch auf die allgemeinen Optimierungen am Code eingehen:

• Warnungen in video_producer_demo wurden behoben.
• Die Keymap Einstellungen und die Bildschirmtastatur teilen ihren Code für die Anzeige einer Tastatur auf dem Bildschirm wieder. Ursprünglich war der Code in der Bildschirmtastatur eine Kopie der Keymap Einstellungen, aber sie wurden unterschiedlich weiterentwickelt.
• Syslog, Power Daemon und mount_server nutzen die BServer Klasse, um sich mit dem app_server zu verbinden. Dadurch wird der Boot Prozess zuverlässiger und unnötige Abhängigkeiten zwischen den Services werden entfernt.
• Der Launch Daemon wurde überarbeitet, um ein Problem zu beheben, durch das der Desktop manchmal nicht startete.
• Es wird weiter am Beheben von Compiler Warnungen in allen Teilen des Codes gearbeitet, diesen Monat im Netzwerkstack, EFI Bootloader, netfs, Media Plugins, Translators, dem Kernel, Treibern und einigen anderen Stellen.
• Der Weg um schwache Symbole, Alias und versteckte Funktionen zu definieren, wurde an einem Platz zusammengefasst. Vorher wurden sehr ähnliche Makros an verschiedenen Stellen definiert und genutzt.
• Die Fehlermeldung von runtime_loader, wenn eine Bibliothek nicht gefunden wird, wurde verbessert. Sie zeigt jetzt an, welche andere Bibliothek versucht hat, sie zu laden. Das hilft beim Debuggen von ungewollten Abhängigkeiten.

Leider habe ich es aus privaten zeitlichen Gründen nicht geschafft, die letzten Activity Reports seit Mai zu übersetzen. Sie enthalten sehr interessante Informationen rund um die Weiterentwicklung des Projekts. Ich kann deshalb empfehlen, diese im englischen Original nachzulesen.

Quelle: https://www.haiku-os.org/blog/pulkomandy/2021-11-01-haiku_activity_report_october_2021/

Verwendet man WebDAV-Freigaben mit einer sicheren Verbindung unter Linux (gvfs) wird immer ein Zertifikatsfehler angezeigt, wenn man Let’s Encrypt als Zertifizierungsstelle verwendet. Durch manuellen Import der Zertifikate lässt sich das beheben.

Let’s Encrypt ist eine der größten Erfolge für die Sicherheit des Internets in den vergangenen Jahren. Im Gegensatz zu vielen anderen Vorhaben geschah diese auch endlich mal wieder durch die Gemeinschaft und nicht unter der Ägide eines der großen IT-Giganten. Mittels Let’s Encrypt sind verschlüsselte Verbindungen Standard geworden und die kommerziellen Zertifizerungsstellen wurden massiv zurückgedrängt.

WebDAV ist wiederum der Standard für Dateifreigaben im Internet, analog zu CalDAV für Kalendereinträge und CardDAV für Adressbücher. Viele proprietäre Dienste, aber auch solche wie das Open Source Flaggschiff Nextcloud setzen auf WebDAV.

Ausgerechnet diese beiden Dienste vertragen sich unter Linux nicht besonders gut. Versucht man bei einem Desktop, der auf GVFS basiert (GNOME Virtual File System) eine WebDAV-Freigabe mit HTTPS-Verbindung einzurichten, scheitert man mit einer kryptischen Fehlermeldung. Erschreckend vor allem, weil das Problem schon seit 2015 besteht, wie es Chris bei LinuxuUndIch damals beschrieb. Ich möchte das hier aufgreifen, weil einige Lösungsschritte von damals nicht mehr aktuell sind.

Das Problem ist relativ leicht erklärt. Zwar „vertrauen“ alle großen Browser den Let’s Encrypt-Stammzertifikaten, aber die Distributionen haben diese in ihre Systemzertifikate aus irgendwelchen Gründen immer noch nicht aufgenommen. Ob man davon betroffen ist, kann man auf der Konsole überprüfen, indem man dort die WebDAV-Freigabe einbindet. Wie immer sind die konkreten Angaben natürlich anzupassen.

$ gio mount davs://domain.de:0000/cloud

Erhält man dort eine Fehlermeldung mit einem ungültigen Zertifikat, ist man davon betroffen.

Die Lösung besteht darin, die Stammzertifikate manuell zu installieren. Diese kann man auf der Seite von Let’s Encrypt beziehen. Hier muss man verschiedene Zertifikate einspielen. Man benötigt die Root-Zertifikate und die Intermediate-Zertifikate, da bei mir z. B. alle Zertifikate mittelbar durch Let’s Encrypt R3 ausgestellt wurden.

$ wget https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem
$ wget https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem
$ wget https://letsencrypt.org/certs/lets-encrypt-r3.pem

Diese Zertifikate muss man anschließend mit Root-Rechten einspielen.

# trust anchor lets-encrypt-x1-cross-signed.pem
# trust anchor lets-encrypt-x2-cross-signed.pem
# trust anchor lets-encrypt-r3.pem

Abschließend kann man prüfen, ob alles ordnungsgemäß eingespielt wurden. Bei den Root Zertifikaten:

$ trust list | grep -C 2 "Let's Encrypt"
pkcs11:id=%A8%4A%6A%63%04%7D%DD%BA%E6%D1%39%B7%A6%45%65%EF%F3%A8%EC%A1;type=cert
    type: certificate
    label: Let's Encrypt Authority X1
    trust: anchor
    category: authority
--
pkcs11:id=%C5%B1%AB%4E%4C%B1%CD%64%30%93%7E%C1%84%99%05%AB%E6%03%E2%25;type=cert
    type: certificate
    label: Let's Encrypt Authority X2
    trust: anchor
    category: authority

Und beim Intermediate-Zertifikat:

$ trust list | grep -C 2 "R3"
pkcs11:id=%14%2E%B3%17%B7%58%56%CB%AE%50%09%40%E6%1F%AF%9D%8B%14%C2%C6;type=cert
    type: certificate
    label: R3
    trust: anchor
    category: authority

Bei Letzterem werden ggf. noch weitere Zertifikate gefunden. Hier muss man dann genau hinschauen.

Die abschließende Prüfung ist natürlich die WebDAV-Freigabe. Gibt es keine Fehlermeldung bei der Einbindung, ist alles glattgegangen.

Der Artikel Let’s Encrypt Zertifikatsfehler bei WebDAV beheben erschien zuerst auf [Mer]Curius

Die Raspberry Pi Foundation hat eine neue Raspberry-Pi-OS-Version auf der Basis von Debian Bullseye freigegeben. Damit ändert sich Einiges: Zum einen natürlich eine Menge Versionsnummern dank des modernisierten Debian-Unterbaus, zum anderen aber auch durchaus wichtige technische Details. Z.B. verwendet Rasbperry Pi OS nun standardmäßig GTK3 und den Displaymanager Mutter — zumindest auf Rechnern mit 2 GByte. Aber der Reihe nach …

Update 7.12.2021: Die alte Raspberry-Pi-OS-Version (Buster) wird bis auf Weiteres mit Updates versorgt und erhält die Bezeichnung Legacy. Damit wird niemand zum Update auf die neue Version (Bullseye) gezwungen. Mehr Details können Sie im Blog von raspberrypi.com nachlesen.

Desktop

Auf dem Desktop gibt es nur wenige optische Änderungen:

• Hinweise (Notifications) werden jetzt am rechten Bildschirmrand angezeigt. Diese Funktion kann bei Bedarf deaktiviert werden. Dazu öffnen Sie im Panel das Kontextmenü und führen Leisten-Einstellungen / Erscheinungsbild aus.

• Zu den neuen Notifications zählt auch der Hinweis auf anstehende Updates. Ein Klick auf den Hinweis öffnet einen neuen, grafischen Update-Manager.

• Im Dateimanager gibt es nur mehr zwei Darstellungsmodis: die Icon- und die Listenansicht.

Grafiksystem und Gtk

Der erste Eindruck täuscht aber. Hinter den Kulissen hat sich wesentlich mehr verändert als an der Oberfläche:

• Für die Aktivierung des richtigen Grafikmodus ist jetzt der Kernel zuständig (Kernel Mode Setting, KMS). Dabei kommen offizielle Funktionen des Kernels zum Einsatz, nicht mehr wie bisher Raspberry-Pi-spezifische Funktionen, deren Code nicht öffentlich war (Quelle raspberrypi.com).

• Raspberry Pi OS verwendet nun standardmäßig GTK3-Bibliotheken (bisher GTK2). Das vereinfacht die Realisierung optischer Effekte (z.B. abgerundeter Fensterecken). Viel wichtiger ist aber: GTK2 ist eine veraltete, nicht mehr aktiv gewartete Bibliothek. Immer mehr moderne Programme setzen GTK3 voraus. Insofern war der Umstieg auf GTK3 überfällig.

• Auf Raspberry Pis mit zumindest 2 GByte RAM kommt der Fenstermanager Mutter zum Einsatz (bisher openbox). Auch hier gilt: Mutter ist moderner, zukunftssicherer. Bie Raspberry Pi Organisation bezeichnet den Umstieg auf Mutter als den ersten Schritt hin zur Ablöse von X durch Wayland. Einen konkreten Zeitplan für den Wechsel zu Wayland gibt es allerdings noch nicht, und es ist unklar, ob dieser überhaupt möglich ist. Selbst Mutter braucht so viel RAM, dass es nur auf großzügig mit RAM ausgestatteten Geräten zum Einsatz kommt.

• RDP zickt: In der Vergangenheit reichte es aus, xrdp zu installieren, damit man sich mit Remotedesktopverbindung oder einem anderen RDP-Client am Raspberry Pi anzumelden. Gleich aus mehreren Gründen funktioniert das mittlerweile nicht mehr. Abhilfe: Richten Sie einen weiteren Benutzer ein und melden Sie sich damit an (statt mit pi). Mehr Details: https://pi-buch.info/aerger-mit-rdp

Kamera-Software

In bisherigen Raspberry-Pi-OS-Versionen waren proprietäre Software-Treiber und die Programme raspistill und raspivid zuständig, um Fotos bzw. Videos von der Kamera aufzunehmen. Mit dem neuen Raspberry Pi OS wird die Kamera dagegen über die libcamera-Treiber des Kernels angesprochen. Dass im Zuge dieser Umstellung raspistill und raspivid einfach eliminiert wurden, wird viele Scripts vor Kompatibilitätsprobleme stellen. Ja, es gibt mit libcamera-still und libcamera-vid neue Kommandos, diese haben aber komplett andere Optionen. Dokumentation dazu finden Sie hier:

https://www.raspberrypi.com/documentation/accessories/camera.html#libcamera-and-libcamera-apps

Aus dem Konfigurationsprogramm ist die Option zur Kamerakonfiguration verschwunden. Dafür enthält /boot/config.txt jetzt den Parameter camera_auto_detect=1, der sich um die automatische Treiberkonfiguration kümmern soll. Tests zur Nutzung der Kamerafunktionen reiche ich später in einem eigenen Artikel nach, sobald ein neues Kameramodul bei mir eintrifft. Das alte hat überraschend seinen Geist aufgegeben.

Update 11.11.2021: Mittlerweile habe ich auch die neuen libcamera-Tools kurz dokumentiert:

https://pi-buch.info/fotos-und-videos-mit-den-libcamera-tools-aufnehmen

Versionsnummern

Viel getan hat sich bei den Versionsnummern des Software-Stacks. Die wichtigste Änderung für viele Raspberry-Pi-Anwender betrifft Python: Erstmals steht die veraltete Version 2 nicht mehr zur Verfügung. Das Kommando python startet nun Python 3.9 statt Python 2.7. Es ist zu befürchten, dass das bei vielen alten Programmen/Bibliotheken zu Problemen führt. Wirklich überrascht sollte aber keiner sein — vor dem Ende von Python 2 wurde ein Jahrzehnt lange gewarnt.

Basis             Desktop              Programmierung   Server
---------------   ------------------   --------------   --------------
Kernel     5.10   Chromium        92   bash       5.1   Apache     2.4
glibc      2.31   Gimp          2.10   gcc       10.2   CUPS       2.3
X-Server   1.20   LibreOffice    7.0   Java        11   MariaDB   10.5
Mesa       20.3   LXDE            11   PHP        7.4   OpenSSH    8.4
Systemd     247   VLC            3.0   Python     3.9   Samba     4.13

Die »Black-Screen-Edition«?

Ich hatte bei meinen Tests massive Probleme mit meinen Monitoren. Immer wieder passierte es, dass meine Monitore nach einer kurzen Darstellung des Raspberry-Pi-Logos einfach schwarz blieben. In allen Fällen lief der Raspberry Pi, d.h. eine SSH-Verbindung war möglich. Die Monitore erhielten offenbar auch ein Signal, d.h. sie wechselten nicht wie sonst automatisch in den Stand-by-Modus oder schalteten sich aus.

Für meine Tests habe ich einen Pi 4B der ersten Generation (1 GB RAM) sowie ein Modell 400 verwendet. Als Monitore kamen ein moderner LG-4k-Monitor (Modell 27UL850-W) sowie ein uralter Benq-Monitor (G2400-WT) zum Einsatz.

Dass während des Bootprozesses keine Meldungen des Kernels bzw. von systemd angezeigt werden, ist beabsichtigt, auch wenn ich mir nicht sicher bin, dass das eine gute Idee ist. Abhilfe: Entfernen Sie quiet splash aus der Datei /boot/cmdline.txt. Eine echte Lösung des Problems ist dies aber nicht: Während der ersten Sekunden sind nun diverse Meldungen sichtbar. Danach wird der Monitor schwarz. Eine Weile später (nach ca. 10 bis 15 Sekunden) erscheint der Desktop — oder auch nicht.

Manchmal half es, den Monitor einfach kurz aus und wieder ein zu schalten.

Sicher ist, dass die Probleme mit dem neuen Raspberry Pi OS zu tun haben; ich habe die gleiche Hardware auch schon mit der vorigen Version des Betriebssystems verwendet und hatte nie derartige Probleme. Trotzdem bleibt unklar, ob die Fehler nur spezifisch bei meiner Hardware auftreten oder ob auch andere Raspberry-Pi-Anwender betroffen sind. Ein diesbezüglicher Twitter-Post erhielt kaum Resonanz.

Problematisch ist in diesem Zusammenhang auch die Veränderung der Bildschirmauflösung: Bei Systemen mit 2 GB RAM oder mehr (also Gtk3) wird die Änderung erst nach einem Reboot wirksam. Das ist nicht nur unpraktisch, sondern auch äußerst problematisch, wenn die gewählte Auflösung am Bildschirm nicht angezeigt werden kann. Mit Pech bleibt der Bildschirm dann ganz einfach schwarz — ohne eine einfache Möglichkeit, die Änderung der Auflösung rückgängig zu machen. Definitiv nicht benutzerfreundlich!

Abhilfe schafft dann nur die Veränderung der Datei /home/pi/.config/monitors.xml via SSH oder auf einem zweiten Linux-Rechner. (Unter macOS oder Windows können Sie auf direkt auf der SD-Karte auf die Partition mit dem Linux-Dateisystem ja gar nicht zugreifen.)

Ich kann mich nicht erinnern, wann ich zuletzt so viel Zeit damit vergeudet habe, um einfach nur ein Bild am Monitor zu sehen. Meine Vermutung ist, dass der ganze Ärger mit dem neuen Kernel Mode Switching (KMS) zu tun hat, das in Raspberry Pi OS Bullseye erstmals aktiv ist und möglicherweise noch nicht in allen Fällen perfekt funktioniert. (Grundsätzlich ist KMS natürlich eine gute Sache: Es ermöglicht einen flicker-freien Bootprozess und erleichtert die Nutzung der Grafikfunktionen ohne Closed-Source-Treiber.)

Sonstiges

• Bei RP-Modellen ab 2 GByte RAM ist eine Drehung der Bildschirmdarstellung nicht mehr möglich (z.B. für einen Monitor in Portrait-Modus). Laut der Diskussion auf raspberrypi.com liegt das Problem beim Window Manager Mutter.

• Auch die neue Raspberry-Pi-OS-Version verbleibt in der 32-Bit-Welt. Eine 64-Bit-Version wäre möglich, aber die Entwickler sehen keine großen Performance-Vorteile. Außerdem würde eine 64-Bit-Version zwei unterschiedliche Betriebssystemversionen je nach CPU erfordern. (Nur die aktuellen Raspberry-Pi-Modelle haben eine 64-Bit-CPU.) Wer also Docker oder ähnliche Funktionen am Raspberry Pi mit einem 64-Bit-Stack ausführen muss, ist mit alternativen Betriebssystemen wie Ubuntu besser bedient.

• Die CPUs auf aktuelle Raspberry-Pi-Modelle mit 2, 4 oder 8 GByte erreichen nun automatisch eine Taktfrequenz von 1,8 GHz. Voraussetzung dafür ist die auf den neuen Platinen integrierte Switch-mode Power Supply (Quelle: raspberrypi.com).

• Die Raspberry Pi Foundation rät dringend davon ab, ein Update von Raspberry Pi OS Buster auf die neue Bullseye-Edition zu versuchen — und ich schließe mich diesem Ratschlag an. Grundsätzlich ist so ein Update relativ einfach möglich, in dem Sie in /etc/atp/sources.list jeweils buster durch bullseye ersetzen und dann ein Update aller Pakete durchführen. (So ein Update ist zeitaufwändig — rechnen Sie zumindest mit 30 Minuten, während der Sie immer wieder Rückfragen beantworten müssen.) Aufgrund der vielen grundlegenden Änderungen zwischen den beiden Versionen sind Kompatibilitätsprobleme zu erwarten. Deswegen ist es sicherlich vernünftig, ein Backup aller relevanten Dateien durchzuführen und dann (idealerweise auf eine zweite SD-Karte) die neue Version von Raspberry Pi OS zu installieren.

Fazit

Viele technische Änderungen, die zusammen mit dem Umstieg auf die neue Basis Debian Bullseye durchgeführt wurden, sind aus Open-Source-Sicht erfreulich: Es kommen mehr Open-Source-Treiber als bisher zum Einsatz, Raspberry Pi OS ist näher an Linux-Standards und es gibt sogar einen (vager) Ausblick Richtung Wayland.

Zumindest bei meinen Tests sind allerdings auch erhebliche Probleme aufgetreten. (Ich habe natürlich auch andere Tests gelesen. Deren Autoren hatten offenbar weniger Probleme. Vielleicht liegt es an mir oder an meiner Hardware?)

Wie auch immer: Sie machen vermutlich nichts verkehrt, wenn Sie noch ein, zwei Monate abwarten, bevor Sie auf das neue Raspberry Pi OS Bullseye umsteigen.

Quellen, Links

• https://www.raspberrypi.com/news/raspberry-pi-os-debian-bullseye
• https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/
• https://www.raspberrypi.com/news/new-old-functionality-with-raspberry-pi-os-legacy
• https://www.heise.de/news/Raspberry-Pi-OS-auf-Debian-Bullseye-Basis-aktualisiert-6260224.html
• https://www.raspberrypi.com/documentation/accessories/camera.html#libcamera-and-libcamera-apps

Download der aktuellen Version (Bullseye) und der alten Legacy-Version (Buster):

• https://www.raspberrypi.com/software/

Beschreibung von libcamera-Kommandos:

• https://pi-buch.info/fotos-und-videos-mit-den-libcamera-tools-aufnehmen

Di, 9. November 2021, Norbert Rüthers

Nach 2 Jahren ist nun wieder eine neue Hauptversion von Raspberry Pi OS herausgekommen.

Nachdem im August Debian Bullseye erschien, ist jetzt auch Raspberry Pi OS mit Raspberry Pi OS 2021-10-30 auf den neuesten Stand gebracht worden. Als Unterbau dient jetzt das neueste Debian.

Im Gegensatz zu Debian fielen die Änderungen bei Raspberry Pi OS aber eher moderat und im verborgenen aus. Am offensichtlichsten ist, das die Update-Funktion inzwischen nicht mehr rein über die Kommandozeile zu erreichen ist (apt update), sondern ein grafisches Plugin in der Taskleiste bekam.  Nun wird nach jedem booten bzw. alle 24 Stunden auf updates geprüft und diese ggf. angezeigt.

Ferner wurde GTK+ auf Version 3 gebracht. Eine der Änderungen, die mit disem Wechsel einherging, ist die Verwendung eines neuen Fenstermanagers namens mutter anstelle des in früheren Versionen verwendeten Openbox-Fenstermanagers. Ein Nachteil von mutter ist, dass es aufgrund der Notwendigkeit, den gesamten Bildschirm in den Speicher zu zeichnen, bevor es ihn anzeigen kann, ziemlich anspruchsvoll in Bezug auf den Arbeitsspeicher ist und nur auf einem Raspberry Pi mit 2 GB oder mehr richtig laufen kann. Daher wird auf Raspberry Pis mit weniger als 2 GB weiterhin der ältere Openbox-Fenstermanager verwendet

Die kompletten Release notes findet ihr hier

Di, 9. November 2021, Lioh Möller

Die vom Unternehmen CloudLinux ins Leben gerufene RHEL-kompatible Enterprise Distribution wird zusätzlich zu den klassischen Installationsmedien auch als Live-Variante zur Verfügung gestellt. Initiiert wurde dies von der Community im Rahmen einer SiG (Special Intrest Group).

Neben einer abgespeckten GNOME Version, werden ISOs mit Xfce, KDE Plasma sowie GNOME mit Zusatzsoftware wie LibreOffice und Thunderbird angeboten.

Die Live-Medien eignen sich gut, um einen Blick auf die Distribution zu werfen oder eine mögliche Hardwarekompatibilität zu testen.

Aktuell werden diese noch als Beta deklariert, was sich in naher Zukunft ändern soll. Mithilfe des integrierten Anaconda Installationsprogramms lässt sich die Distribution dauerhaft auf ein Speichermedium übertragen.

Download AlmaLinux 8 Live: https://repo.almalinux.org/almalinux/8/live/x86_64/

Mo, 8. November 2021, Ralf Hersel

Wie oft wird eine neue Kernelversion pro Jahr veröffentlicht? Wie lange wird ein Kernel unterstützt? Es gibt LTS-Kernel (Long Term Support). Wie lange werden die LTS-Linux-Kernel unterstützt? Die kurze Antwort ist, dass alle zwei bis drei Monate eine neue Kernelversion veröffentlicht wird. Die lange Antwort ist, dass es sich dabei nicht um eine feste Regel handelt.

Longterm release kernels

Das bedeutet, dass oft alle zwei bis drei Monate eine neue Kernelversion veröffentlicht wird. Das ist das Ziel des Kernel-Maintainer-Teams, aber es gibt keinen festen Termin, an dem die neue Version genau 8 Wochen nach der vorherigen Version veröffentlicht werden muss. Eine neue Kernel-Version wird (oft) von Linus Torvalds veröffentlicht, wenn sie fertig ist. Dies geschieht normalerweise alle 2 bis 3 Monate. Die Veröffentlichung wird als "stabil" deklariert und normalerweise im Format X.Y nummeriert.

Dies ist jedoch nicht das Ende der X.Y-Entwicklung. Die stabile Version erhält weitere kleinere Versionen, um Fehlerkorrekturen vorzunehmen. Diese kleinen Versionen fügen dem stabilen Kernel einen weiteren Punkt hinzu, um ihn wie X.Y.Z zu machen. Während X.Y (oft) vom Torvalds veröffentlicht wird, liegt die Verantwortung für die Pflege des stabilen X.Y-Kernels, die Einarbeitung von Fehlerkorrekturen und die Veröffentlichung von X.Y.Z-Versionen bei einem Kernel-Entwickler.

Wie bei der Veröffentlichung gibt es keine festen Termine und keinen Zeitplan dafür, wie lange eine Kernelversion unterstützt wird. Ein reguläres stabiles Kernel-Release wird in der Regel zweieinhalb bis drei Monate lang unterstützt, abhängig von der Veröffentlichung des nächsten stabilen Kernel-Release. Zum Beispiel würde der stabile Kernel 5.14 einige Wochen nach der Veröffentlichung des stabilen Kernels 5.15 das Ende seiner Lebensdauer erreichen. Das Ende der Unterstützung wird vom Betreuer der jeweiligen stabilen Kernelversion in der Linux-Kernel-Mailingliste bekannt gegeben. Benutzer und Mitwirkende werden gebeten, auf die neu veröffentlichte stabile Version umzusteigen.

Dies gilt nur für die normalen stabilen Kernel-Versionen. Es gibt auch LTS-Kernelversionen (Long Term Support), die für einen viel längeren Zeitraum als nur 3 Monate unterstützt werden. Auch für LTS-Kernel gibt es keinen festen Veröffentlichungszeitplan. Normalerweise gibt es jedes Jahr eine LTS-Kernel-Veröffentlichung, meist die letzte des Jahres, und sie wird mindestens zwei Jahre lang unterstützt. Aber auch hier gibt es keine festen Regeln.

Der Betreuer eines LTS-Kernels kann zustimmen, einen bestimmten LTS-Kernel länger, als die üblichen zwei Jahre zu betreuen. Die Vereinbarung wird auf der Grundlage der Notwendigkeit und der beteiligten Akteure getroffen. Dies geschieht häufig bei Android-Projekten. Da zwei Jahre für die Hersteller nicht ausreichen, um ihre Hardware- und Softwarefunktionen zu unterstützen, werden einige LTS-Kernel oft sechs Jahre lang unterstützt.

Wenn man die Version des eigenen Linux-Kernels überprüft, stellt man möglicherweise fest, dass die Distribution einen alten Kernel verwendet. Es könnte auch sein, dass der von der Distribution angebotene Kernel laut Kernel-Website das Ende seiner Lebensdauer erreicht hat. Kein Grund zur Panik. Die Distribution kümmert sich darum, den Kernel mit Patches für Fehlerbehebungen und Sicherheitslücken zu versorgen. Wer nicht gerade eine obskure Linux-Distribution verwendet, kann sich darauf verlassen, dass die Distribution den Kern sicher und stabil hält.

Selbstverständlich ist es möglich den neuesten Linux-Kernel in Ubuntu oder einer anderen Distribution zu installieren, wenn man gute Gründe dafür hat, wie z. B. die Unterstützung für neuere Hardware.

Quelle: https://www.kernel.org/category/releases.html

In diesem Artikel gebe ich euch einen Überblick, was Network Bound Disk Encryption (NBDE) ist und beschreibe einen konkreten Anwendungsfall. Am Ende des Artikels führe ich einige Verweise auf, mit deren Hilfe ihr NBDE bei Interesse selbst implementieren könnt.

Linux Unified Key Setup (LUKS)

Bevor ich auf NBDE eingehe, möchte ich kurz ein paar Worte zu LUKS verlieren.

Bei LUKS handelt es sich um das Standardverfahren zur Festplattenverschlüsselung unter Linux (siehe 1). Dieses erweitert dm-crypt um einen Header, welcher Slots zum Speichern von bis zu acht Schlüsseln bietet (siehe 2).

Ich benutze dieses Verfahren auf nahezu all meinen Rechnern. Ich möchte damit erreichen, dass meine Daten bei Diebstahl des Rechners bzw. der Festplatte möglichst lange vor unberechtigtem Zugriff geschützt sind.

Typischerweise wird zur Entschlüsselung einer Festplatte bzw. Partition während des Boot-Vorgangs die Eingabe eines Kennworts benötigt. Die Sicherheit des Verfahrens hängt dabei direkt von der Stärke des verwendeten Passworts ab (siehe 1).

Steht der Rechner im Büro und man ist täglich vor Ort, ist es kein Problem, bei Neustart des Rechners das LUKS-Kennwort einzugeben. Wenn man allerdings im Homeoffice arbeitet und Zugriff auf seinen Büro-Rechner braucht, sieht die Sache anders aus.

Möchte man den entfernten Rechner neustarten, z.B. nach der Installation von Updates, muss man dafür extra ins Büro fahren. Alternativ kann man ein zweites Kennwort einrichten, dieses einem Kollegen mitteilen und diesen bitten, es vor Ort einzugeben. Beides ist nicht komfortabel. Und hier kommt NBDE ins Spiel.

LUKS an Netzwerkressource binden

Network Bound Disk Encryption heißt auf Deutsch in etwa netzwerkgebundene Festplattenverschlüsselung und bedeutet, dass die Verschlüsselung an eine oder mehrere Ressourcen im Netzwerk gebunden ist.

Das Prinzip ist ganz einfach. Wenn ein Rechner mit einer verschlüsselten Festplatte oder Partition startet, sucht er nach einer bestimmten Ressource im Netzwerk. Kann der Rechner diese Netzwerkressource erreichen, wird die Festplatte bzw. Partition entschlüsselt und der Startvorgang fortgesetzt. Folgende Abbildung soll dies veranschaulichen.

Im eigenen LAN werden zwei sogenannte Tang-Server positioniert (siehe 4 und 6). Diese stellen die Netzwerk-Ressource dar, welche erreichbar sein muss, damit ein an Tang gebundenes Gerät entschlüsselt werden kann. In diesem Beispiel werden zwei Tang-Server betrieben, um die Verfügbarkeit des Dienstes zu gewährleisten, wenn ein Server gewartet wird.

Auf dem Client kommt die Anwendung Clevis zum Einsatz (siehe 5, 6 und 7), bei welcher es sich um die Client-Komponente zum Tang-Server handelt. Diese empfängt einen Schlüssel vom Tang-Server und verwendet diesen, um einen Token in einem LUKS-Slot zu speichern (Details siehe 3, 6 und 7). Beim Start eines Rechners wird nun versucht, einen der Tang-Server zu erreichen, an die man sich gebunden hat.

Wird der Rechner bzw. seine Festplatte gestohlen, sind die Tang-Server nicht erreichbar und die Daten werden nicht automatisch entschlüsselt. Der Dieb muss nun die Verschlüsselung bzw. das verwendete Kennwort brechen.

Steht der Rechner jedoch an seinem Platz, kann er aus der Ferne neugestartet werden und den Startvorgang beenden, ohne dass jemand vor Ort ein LUKS-Kennwort eingeben muss.

Damit diese Konfiguration Sinn macht, dürfen die Tang-Server nicht weltweit erreichbar sein. Ihr Standort und die Netze, aus denen sie erreichbar sind, sind daher sorgfältig zu planen.

Zusammenfassung

Ohne NBDE muss an einem Rechner mit LUKS-Verschlüsselung bei jedem Startvorgang das LUKS-Kennwort eingegeben werden, was einen Neustart aus der Ferne enorm erschwert.

NBDE ist leicht zu implementieren und löst dieses Problem. Gleichzeitig bleiben die Daten im gleichen Maße bei einem Diebstahl des Rechners geschützt.

Quellen und weiterführende Links

1. LUKS im Wiki von Ubuntuusers.de. URL: https://wiki.ubuntuusers.de/LUKS/
2. https://de.wikipedia.org/wiki/Dm-crypt#LUKS
3. Automatic data encryption and decryption with Clevis and Tang. ADMIN 43/2018. URL: https://www.admin-magazine.com/Archive/2018/43/Automatic-data-encryption-and-decryption-with-Clevis-and-Tang
4. https://github.com/latchset/tang
5. https://github.com/latchset/clevis
6. RHEL 8 Security Hardening Chapter 12. Configuring automated unlocking of encrypted volumes using policy-based decryption. URL: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening
7. RHEL 7 Security Guide 4.10.1. Network-Bound Disk Encryption. URL: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-policy-based_decryption#sec-Using_Network-Bound_Disk_Encryption
8. How to set up Network-Bound Disk Encryption with multiple LUKS devices (Clevis+Tang unlocking). URL: https://access.redhat.com/articles/4500491. (Login erforderlich)

Diese Woche haben Bund und Länder mal wieder den Lieblingsfetisch der Open Source Community bedient. Open Source im Staatseinsatz – von vielen gleich auf „Linux löst Windows ab“ und den Vergleich mit LiMux heruntergebrochen. Werfen wir doch mal einen Blick auf die Fakten anstelle immer die gleichen Phrasen zu bedienen.

Das Thema schwappte einer Welle gleich durch die nennenswerten IT-Medien. Golem und Heise waren ebenso dabei wie die reichweitenstarke Community-Plattformen linuxnews und GNULinux.ch. Dazu kommen noch ein paar Blogposts, bei denen ich vor allem den Beitrag auf kaffeeringe hervorheben möchte, weil er eine etwas andere inhaltliche Stoßrichtung hat.

Die Fokussierung der Open Source Community auf den Staatseinsatz von Open Source ist wirklich putzig. Man befasst sich doch auch nicht mit den Softwarelösungen von Volkswagen, der Lufthansa oder ThyssenKrupp. Glaubt man hier mehr mitreden zu dürfen, weil es letztlich Steuergeld ist? Wie dem auch sei, werfen wir zur Abwechslung doch mal einen Blick auf die Fakten.

Einordnung

Erst mal kann man getrost annehmen, dass kaum jemand das Papier wirklich gelesen hat. Ansonsten wäre ihnen der Titel „Gemeinsame Absichtserklärung“ aufgefallen. Das ist in etwa so verbindlich, wie das 1,5 Grad-Ziel der letzten Bundesregierung für die Klimapolitik verbindlich war. Absichten kann man viele haben. Zudem ist das Papier gespickt mit Buzzwords, enthält erstaunlich wenig Fakten und noch weniger Festlegungen. Nach der Lektüre bin ich mir nicht mal sicher, ob dieser souveräne Arbeitsplatz wirklich ausschließlich Open Source sein soll.

Stand jetzt bleibt es dabei, dass nur Schleswig-Holstein eine wirkliche Open Source-Strategie verfolgt und hier auch klare Meilensteine gesetzt hat. Nehmen wir also der Einfachheit mal an, dass diese Strategie indirekt das Vorbild ist und die Absichtserklärung in eine ähnliche Richtung deutet (Anmerkung: Muss man aber nicht so lesen! Werden andere nicht so lesen! Kann eine andere Regierung anders lesen!)

Schauen wir uns mal ein paar Fakten zu den Vorhaben an.

Digitale Souveränität – Nationalismus des 21. Jahrhunderts

Digitale Souveränität ist eines dieser schrecklichen Buzzwords. Es hört sich modern an, ist aber nichts anderes als dumpfer Nationalismus. In der ersten Hälfte des 20. Jahrhunderts hätte man wohl äquivalent von Autarkie bei der Rohstoff- und Lebensmittelversorgung gesprochen. Gemeint es ist das Gleiche: Unabhängigkeit von ausländischen Mächten. Anmerkung vorweg: Hat früher nicht geklappt, wird heute nicht klappen.

Dahinter stecken letztlich eine gehörige Portion dumpfe Verschwörungserzählung. In einem Großkonflikt mit den USA, klemmt Microsoft unser Windows ab, Google und Amazon drehen die Cloud zu und Deutschland wird in die Steinzeit zurück katapultiert. Das glaubt kein Politiker oder leitender Ministerialbeamter wirklich, aber irgendwie hat es die Open Source Community geschafft, mit Lobbyismus die Idee salonfähig zu machen und Politiker sagen und schreiben halt, was auf Zustimmung stößt. Microsoft wählt schließlich in Deutschland nicht und außerhalb von München profitiert auch kaum jemand von dem Konzern.

Dabei verkennt das Vorhaben komplett die Realität und wie Sanktionen der USA funktionieren. Es gibt keine geheime Backdoor mit der man Windows lahmlegt. Stattdessen verbieten die USA den Export und Geschäft mit Staaten und Firmen. Das konnte man gut am Beispiel Iran, China/Huawei oder auch Nord Stream 2 in den letzten Jahren beobachten. Weil die Sanktionen oft schwammig formuliert sind und viele Firmen Angst vor einer Strafe haben, kooperieren sie im vorauseilenden Gehorsam nicht mehr mit den sanktionierten Staaten oder Firmen.

Die Open Source Community glaubt ja gerne, ihre Software wäre irgendwie gut, international und unabhängig, aber das ist Quark. Alle Entwickler sitzen in irgendwelchen Staaten, alle Firmen haben ihren Firmensitz in irgendwelchen Staaten und alle Marken sind irgendwo gemeldet. Ich hatte das im Kontext von Fedora schon mal thematisiert. Bei einem Großkonflikt schützt einen auch der Gebrauch von Linux nicht. Und da haben wir noch gar nicht über die proprietären Treiber bzw. Firmware-Blobs gesprochen, die man faktisch für viele Funktionen benötigt. Der deutsche souveräne Linux-Desktop wäre ebenso funktionsunfähig bzw. von der Weiterentwicklung abgehängt wie jedes proprietäre Äquivalent.

Digitale Souveränität ist eine Fata Morgana und wenn man sie als das bezeichnen würde, was sie wirklich ist – nämlich purer Nationalismus – wäre sie auch deutlich weniger populär.

Fortschritt in der Digitalisierung

Deutschland hat ein Problem mit der Digitalisierung seiner Strukturen. Das wissen wir nun spätestens seit der Pandemie. Kann eine Open Source-Strategie hier helfen? Nein!

Zuerst muss man hier natürlich differenzieren. Bei neu ausgeschriebenen Projekten oder neuen Software-Lösungen kann man eine Open Source-Strategie fahren. Wie das gut klappen kann, sieht man bei der Corona Warn App und wie es scheitert bei Luca. Das gilt auch für neue Sachen wie die Bundescloud. Es spricht nichts dagegen neue Lösungen gleich als Open Source umzusetzen und wird ja auch bereits vielfach praktiziert.

Anders sieht das bei der Umstellung von Bestandslösungen aus. Hier ist man beim Lieblingsfetisch der Open Source Community: Linux für die Verwaltung. Hier gibt es bestehende Lösungen, die migriert werden sollen. Denn angeblich ist der Linux-Desktop ja besser als ein Microsoft-Arbeitsplatz, bietet gleichwertige Funktionen und alle sollen von den Segnungen freier Software profitieren.

Der Vorteil für die Digitalisierung des Staates, also letztlich den Bürger, ist nicht vorhanden. Es gibt keine Verbesserung, sondern bestenfalls merkt er nichts von der Migration. Faktisch wird es vermutlich sogar Probleme geben, weil Linux, LibreOffice & Co eben nicht überall einfach Funktionsparität bieten. Migrationen ohne Probleme existieren nur in der Fantasie ahnungsloser Amateure.

Die Projektgruppen, IT-Mitarbeiter und Verwaltungsmitarbeiter, die mit dem Vorhaben beschäftigt sind, benötigen aber Arbeitszeit. Denn eine Migration passiert nicht so eben nebenbei. Diese Arbeitszeit können sie nicht in andere Vorhaben stecken, z. B. in das wirkliche Voranbringen der Digitalisierung.

Eine Umstellung auf Open Source ist also nicht geeignet, um die Digitalisierung voranzubringen. Kurz- bis mittelfristig ist sie vermutlich sogar kontraproduktiv.

Kosten – Ein Dauerbrenner

Irgendjemand kommt bei dem Thema immer mit den Kosten. Schließlich geht es um Steuergeld. Microsoft und Anbieter proprietärer Softwarelösungen allgemein sind hier im Nachteil, weil Lizenzen einen klar bezifferbaren Betrag kosten und diese Summen meistens in irgendwelchen Aufstellungen auftauchen.

Open Source ist aber nicht umsonst. Zu dem Thema hatte ich mich hier bereits geäußert. Entweder baut die öffentliche Hand massiv ihre IT-Abteilungen aus, was Geld kostet, oder beauftragt sehr viele Dienstleister, was ebenfalls Geld kostet.

Aber mit Open Source fließt das Ergebnis wenigstens an die Gemeinschaft zurück, so oder so ähnlich klingt es bei Kampagnen wie Public Money Public Code. Dahinter steht diese irrsinnige Geringschätzung gegenüber der öffentlichen Verwaltung, die in Deutschland und vielen anderen Ländern so verbreitet ist. Frei nach dem Motto: Was verwenden die schon – ein bisschen Desktop, ein bisschen Office – die Verbesserungen können doch alle brauchen. Die meisten Anwendungen sind aber Fachanwendungen, die der großen Mehrheit gar nichts bringen und vermutlich noch nicht mal anderen Verwaltungen. Der Mehrwert wäre also überschaubar.

Kurzum: Mir ist keine seriöse Studie bekannt, die belegt, dass ein Umstieg auf Open Source effektiv Geld spart. Bestenfalls ist man kostenneutral unterwegs, schlimmstenfalls muss man sogar mehr Mittel investieren.

Datenschutz

Microsoft bzw. Windows haben in den letzten Jahren nicht gerade einen Preis für Datenschutzes verdient – das ist unbestritten. Ob man Windows überhaupt Datenschutz-konform einsetzen kann, ist ist nicht so ganz klar und hängt massiv von der Konfiguration und verwendeten Version ab.

Unstrittig dürfte sein, dass ein „souveräner Arbeitsplatz“, also ein Linux-System mit viel freier Software, hier besser aufgestellt sein dürfte.

Der Arbeitsplatz alleine ist es nur eben nicht. Ein souveräner Arbeitsplatz bei der deutschen Polizei, die dann Daten in die Amazon-Cloud speichert, bringt für den Datenschutz gar nichts.

Datenschutz ist also eine ganzheitliche Angelegenheit und hängt mitnichten nur vom Desktop-Betriebssystem ab, wie manche gerne glauben machen wollen. Das Desktop-Betriebssystem ist hier nur ein Baustein und vermutlich nicht mal der wichtigste.

Zusammengefasst

Der Staat wechselt auf Open Source? Kann er gerne tun. Ich bin gar nicht dagegen, denn es gibt sinnlosere Projekte. Aber wird dadurch irgendetwas besser oder irgendwelche Probleme beseitigt. Macht Deutschland dann einen Quantensprung in der Digitalisierung, halbiert seine Kosten und der Staat funktioniert endlich perfekt? Nein, eigentlich nicht. Und hier sollte man keine falschen Erwartungen wider besseren Wissens wecken.

Im Grunde genommen wird damit nur eine Forderung der verschränkten Open Source und Datenschutz-Community bedient, die nachhaltig dafür wirbt. Ihre Ziele sind bei Licht betrachtet vielleicht gar nicht so schön wie die modernen Buzzwords suggeriern und viele Ziel lassen sich mit der Migration auch gar nicht erreichen.

Letztlich ist das ganze Thema deshalb so ein Fetisch der FOSS-Community, weil sie hofft, damit mittelfristig ihr Freibier-Problem lösen zu können. Freie Software ist eben für die meisten Anwender doch nur so frei wie Freibier. Alles was nicht Relevant für die Wirtschaft ist – und das ist alles außer der Server-Part – siecht deshalb unterfinanziert vor sich hin. Hier hofft man nun mittelbar auf die helfende Hand des Staates, indem er groß in die Entwicklung einsteigt oder diese über Dienstleister voranbringt.

Nur ist dieser dafür nicht da.

Der Artikel Bund und Länder schwenken auf Open Source? – Ein Blick auf die Fakten erschien zuerst auf [Mer]Curius

In einem Hauptverzeichnis sind diverse Dateien in Unterverzeichnissen vorhanden. In jeder dieser Dateien soll die gleiche Zeichenkette in die gleiche Zeile eintragen werden ohne das eine bereits vorhandene Zeile überschrieben wird. Nehmen wir als Beispiel einmal einen Front-Matter-Bereich eines der hier veröffentlichten Artikel.

---
title: WLAN-USB-Stick Cudy WU1300S unter Linux
date: 2021-05-02T16:49:00+0200
categories:
- OSBN
- Linux
tags:
- WLAN
- USB
slug: wlan-usb-stick-cudy-wu1300S-unter-linux
---

Was tun, wenn man nun beispielsweise zwischen der Zeile mit dem Datum und der Kategorie eine Zeile mit include_toc: true eintragen will? Am einfachst und aufwändigsten wäre es jede Datei händisch anzupassen. Da es sich aber um Dateien im drei- oder vierstelligen handelt, ist das keine gute Idee.

Um Dateien zu ändern, kann man das Tool sed nutzen, was eines der “Urgesteine” unter Linux ist.

sed -i'4 i include_toc: true' Dateiname 

Die 4 gibt hierbei die gewünschte Zeile an. Das i dahinter steht für insert. Also einfügen.

Wer das ganze erst einmal testen will, ohne dass die Datei geändert wird, kann einfach -i bei dem Befehl entfernen. Dann wird der Inhalt der Datei inklusive der Änderung ausgegeben, ohne die Änderung zu speichern.

Bleibt nur noch wie man den Befehl auf alle betreffenden Dateien automatisch anwendet. Hier reicht, wie so oft, eine einfache Schleife.

#/bin/bash
for i in $(find posts -name '*.md');
do
    sed -i '4 i include_toc: true' $i
done;

Hiermit wird im aktuellen Verzeichnis sowie in den darin vorhandenen Unterverzeichnissen nach Dateien mit der Endung .md (Markdown-Dateien) gesucht. Diese werden dann mit dem sed Befehl entsprechend geändert.