MueSLi Tech-Blog

Digitale Unabhängigkeit - der Digital Independence Day

2026-02-01T00:00:00Z

Wer schon länger Linux nutzt, hat in der Regel seine Gründe. Nicht selten ist das der Wunsch nach Freiheit; die Freiheit die Apps zu installieren die man nutzen möchte oder braucht, und nicht die vom Hersteller genehmigten. Die Freiheit seine Software zu verändern und anzupassen und vor allem auch die Freiheit die eigene Privatsphäre zu schützen anstatt auf Gedeih und Verderb den Nutzungsbedingungen von Big Tech ausgeliefert zu sein.

Das Thema ist uns nicht neu. Neu ist aber, dass sich seit kurzem auch eine wesentlich breitere Masse dafür interessiert; Nicht nur Hobbyisten und Nerds sondern auch Eltern die sich fragen wie sie ihre Kinder im Netz vor rechter Hetze schützen können, Politiker:innen die Angst haben aus ihren Outlook-Konten und anderen Microsoft Diensten ausgesperrt zu werden, Queere Personen die sich auf Sozialen Plattformen ausgeschlossen oder sogar verfolgt fühlen, Unternehmer:innen die Betriebsspionage fürchten oder einfach anständige Menschen die die Nase voll haben von einer digitalen Abhängigkeit die ihnen KI generierten Slop in jeder möglichen Art aufdrängt.

So hilflos sind wir nicht

Die gute Nachricht ist: So hilflos sind wir nicht. Wir können direkt etwas ändern. Es reicht wenn es kleine Schritte sind; Stück für Stück, aber immer weiter. Das ist die Idee vom Digitalen Unabhängigkeitstag oder auch Digital Independence Day (oder kurz DID). Den Startschuss hatte Marc-Uwe Kling auf dem 39. Chaos Communication Kongress gegeben.

Der DID soll jeden ersten Sonntag im Monat stattfinden, mit der Idee dass man sich für jeden DID eine weitere Kleinigkeit vornimmt mit der man sich digital etwas unabhängiger macht. Das könnten Dinge sein wie die Standard Suchmaschine auf dem Handy zu wechseln, von Google weg zu einer datenschutzfreundlicheren Alternative. Oder den Messenger von WhatsApp zu Signal zu wechseln. Natürlich ist es auch völlig okay erst ein mal die Alternative auszuprobieren und eine Zeit lang Zweigleisig zu fahren.

Auf https://di.day gibt es dazu einige Wechselrezepte die das Wechseln erleichtern und schmackhaft machen sollen.

Zuletzt darf man voller Stolz mit seinem Wechsel angeben; ob in sozialen Netzwerken oder bei Freunden und Verwandten ;-) Unter den Hashtags #diday, #DIDit oder #DUTgemacht findet man schon jetzt etliche Nachrichten von Menschen die die Nase voll hatten und den Digitalen Unabhängigkeitstag mit einem eigenen Schritt in Richtung ihrer eigenen Unabhängigkeit feiern.

Zusammen feiern macht mehr Spaß

Es war schon immer so; zusammen feiern macht mehr Spaß. Deshalb entstehen gerade in vielen Städten überall offene Treffs. Wer Fragen oder Bedenken hat oder sich einfach nur austauschen will; die Menschen kommen zusammen um ihre kleinen und großen Schritte zu machen um langsam aber sicher eine Bewegung weg von Big Tech zu freien und unabhängigen Alternativen zu machen. Auch in Münster wollen wir regelmäßig in präsenz zum ersten Sonntag im Monat ein offenes Treffen anbieten, um dieses Projekt zu unterstützen. Zum ersten mal wird das am 01.02.2026 in der Warpzone stattfinden. Mitglieder der Warpzone e.V. und MüSLi aber auch aus anderen Gruppierungen aus Münster werden auch zur Beratung und Beantwortung von Fragen vor Ort sein oder einfach feiern.

Also kommt vorbei, teilt eure Erfolge und Erfahrungen, macht mit und feiert mit uns!

Workaround für Kernel Panic auf ThinkPad T410 unter Debian Trixie

2025-05-18T00:00:00Z

Im Mail 2025 habe ich Testinstallationen von Debian Trixie (Testing) auf zwei unterschiedlichen ThinkPad T410 vorgenommen.

Rechner: Intel(R) Core(TM) i5 CPU M 580 @ 2.67GHz, BIOS Version: 1.36
Rechner: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz ,BIOS Version: 1.45

Beide Rechner stürtzen unvermittelt ab. In den Logfiles war kein relevanter Eintrag zu finden. Zufälligerweise ist ein Absturz passiert als von der graphischen Oberfläche auf die Console gewechselt wurde. Hier stand dann:

Kernel panic - not syncing: DMAR hardware is malfunctioning

Die Internetrecherche ergab, dass der Boot-Parameter intel_iommu=igfx_off das Problem behebt. Dem ist in der Tat so! Abstürze sind danach nicht mehr aufgetreten.

Der Boot-Parameter kann durch Eintrag in die /etc/default/grub persistiert werden.

root@t410:~# grep igfx_off /etc/default/grub 
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=igfx_off"

In Memory Datenbank mit Umgebungsvariablen

2024-04-26T00:00:00Z

Einleitung

Manchmal benötigt man eine einfache und generische Variante um Daten zwischen Anwendungen auszutauschen welche zu dem nur für eine gewisse Zeit gültig sind. Außerdem sollte der Dienst keine weiteren Abhängigkeiten benötigen um den Betrieb und die leichte Verteilung zu ermöglichen und auf allen Systemen laufen.

Server-Umsetzung

Realisieren kann man dies einfach und sicher z.B. mit der Programmiersprache Nim und einem Web-Framework. Die Datenspeicherung selbst wird in den Umgebungsvariablen der Anwendung realisiert und die Schlüssel entsprechen Pfaden die intern mit base64-Kodierung umgesetzt werden. So lassen sich einfach auch größere Datenmengen schnell teilen. Eine Beispielumsetzung ist im Projekt envmw zu finden.

Client

Als Client kann jede http-fähige Anwendung eingesetzt werden. Hier ein Beispiel auch in Nim:

import os
import std/[times, asyncdispatch, strformat, strutils]
import httpclient, httpcore
import jsony

type
  KV = object
    key: string
    value: string
    expire: float

var
  data: KV
  t1, t2: float
  n = 500
  client: HttpClient

proc twrite(data: KV) {.async.} =
  let client = newAsyncHttpClient()
  #client.headers = newHttpHeaders({"Content-Type": "application/json"})
  discard await client.postContent("http://127.0.0.1:6380/set",
      body = data.toJson())
  client.close()


proc main() {.async.} =
  while true:
    t1 = epochTime()
    for i in 1 .. n:
      data.key = fmt"/app/part1/subpart3/key{i}"
      data.expire = i/10
      data.value = fmt"{epochTime()=}, {i=}"
      await twrite(data)
    t2 = epochTime()

    echo fmt"{(t2-t1)/n.toFloat() * 1000} ms/req"
    client = newHttpClient()
    let key = "/app/part1/subpart3/key10"
    echo client.getContent(fmt"http://127.0.0.1:6380/get{key}").strip()
    sleep(500)
    echo client.getContent(fmt"http://127.0.0.1:6380/get{key}").strip()
    sleep(600)
    assert client.getContent(fmt"http://127.0.0.1:6380/get{key}") == "\n"
    client.close()


when isMainModule:
  waitFor main()

Zusatzfunktionen

In envmw steht noch eine ping-Funktion zur Verfügung und mit /keys können alle verfügbaren Schlüssel erfragt werden.

Datenspeicherung

Es ist natürlich auch möglich die Daten auf dem Server, z.B. durch ein Signal an diesen zu speichern. Hier könne man die Key-Value Paare z.B. als Symlink in base64 Kodierung effizient im Dateisystem abspeichern. Hier ein Beispiel in shell-script

ln -s $(echo $VALUE | base64) $KEY
RVALUE = $(readlink $KEY | base64 -d)

Zentrale Schlüsselverwaltung für ssh

2023-10-30T00:00:00Z

Einleitung

Wenn man mehr als einen Server und mehrere Nutzer hat, die evtl. auch noch nur eingeschränkt auch die verteilten Dienste zugreifen dürfen, ist die manuelle Schlüsselverwaltung aufwendig. Hier bietet sich eich zentraler Server mit allen Schlüsseln incl. deren Konfiguration z.B. command an.

Um diese Schlüssel nutzen zu können bietet der sshd die Möglichkeit den Nutzerschlüssel per Anwendung zu erhalten AuthorizedKeysCommand.

Server-Baum

Am einfachsten ist es wenn man einen Dienst hat auf den alle Server zugreifen können, z.B. die eigene Webseite. Damit die Konfiguration wie auch die Server und die Nutzer nicht enthüllt werden werden wir hier mit den Hashwerten und asynchron verschlüsselten Dateien arbeiten. Der Dateibaum auf dem Server ist im Klartext wie folgt:

keys/
├── user1
│   ├── host1
│   └── host2
├── user2
│   └── host2
└── user3
    ├── host1
    └── host3

nur das statt der Klarnamen die Hash-Werte verwendet werden.

Schlüsseldaten für den Server

Da die Dateien mit den öffentlichen Nutzerschlüsseln evtl. auch die Namen und andre Daten enthalten, die andere nicht angehen, ist es sinnvoll diese zu verschlüsseln. Hier biete sich age an. Zuerst wird ein neues Schlüsselpaar mit age-keygen -o /etc/ssh/key.txt && chown nobody /etc/ssh/key.txt erzeugt.

Mit dem so erzeugten Public-Key kann der Inhalt, z.B. der ursprünglichen Nutzer "authorized_keys"-Datei, mit:

#!/bin/sh

if [ $# -eq 1 ]; then
    grep public /etc/ssh/key.txt | awk -F': ' '{print $2}' > /tmp/pub_key
    UK=$1
    U=$(echo user1 | sha256sum | awk '{print $1}')
    H=$(echo hostname | sha256sum | awk '{print $1}')
    mkdir -p keys/$U
    cat $UK | age -a -R /tmp/pub_key > keys/$U/$H
else
    echo $0 user_keys_file
    exit 1
fi

für den zentral Server erzeugt werden.

Diese müssen dann noch in den passenden Serverordner kopiert oder synchronisiert werden.

Script zum holen der Schlüssel

Die Script wird mit Nutzername des sich anmeldenden von sshd aufgerufen, zusätzlich fragen wir noch den Hostnamen ab. In der sshd_config ist folgendes einzutragen:

AuthorizedKeysCommand /usr/local/bin/get_key %u
AuthorizedKeysCommandUser nobody

und der Dienst ist nach der Änderung neu zu starten.

Das ausführbare Script selbst ist recht einfach:

#!/bin/sh

H=$(hostname | sha256sum | awk '{print $1}')
U=$(echo $1 | sha256sum | awk '{print $1}')
logger "get central key for: $1"
curl -sf https://my_website.host/keys/$U/$H | age -d -i /etc/ssh/key.txt || echo "$U/$H"

So kann man es auch in der Shell aufrufen und testen.

Zusammenfassung

Mit dem hier gezeigten lassen sich die Berechtigungen für verschiedene Nutzer und Server zentral und sicher Verwalten und es werden keine weiteren Informationen preisgegeben, denn nur der Besitzer des privaten Schlüssels ist in der Lage die Schlüsselinformationen der Nutzer zu lesen.

Alle Scripte sind auch in 1 zu finden.

Backup bei Anschluss des USB-Laufwerks

2023-08-23T00:00:00Z

Einleitung

Da moderne Laptops oft keine Netzwerk-Buchse mehr haben und die WLAN Verbindung meist langsamer als einen Kabelverbindung ist, man aber doch ein Backup zügig durch führen möchte, bietet es sich an hierfür eine Wechseldatenträger via USB zu verwenden. Weiterhin wäre es natürlich sehr schön wenn man dies nicht noch explizit anstoßen muss. Mit ein wenig Skripting und der passenden udev-Regel ist das einfach möglich.

Vorbereitung

Um den Vorgang nur bei den richtigen Datenträger auszulösen kann man die idVendor und idProduct Nummern des Backuplaufwerks nutzen. Ein Eintrag in /etc/udev/rules.d/test_backup.rules mit folgendem Inhalt:

ATTRS{idVendor}=="152d", ATTRS{idProduct}=="3234", KERNEL=="sd*", RUN+="/usr/local/bin/bktest.sh"

wobei die Werte z.B. mit lsusb ermittelt werden können, ein dazu passendes Skript aus. Das Skript selbst schreibt das neue Gerät in eine FiFo-Datei, so das andere ohne zu pollen davon erfahren können.

Hier ein Beispiel:

#!/bin/sh

if [ "${ACTION}" = add -a -d "/sys${DEVPATH}" ]; then
    date > /tmp/usbdev.log
    if [ -p "/tmp/usbdev" ]; then
        echo "${DEVPATH}" | awk -F'block' '{print $2}' | awk -F'/' '{print "connected /dev/"$3}' >> /tmp/usbdev
    else
        echo "pipe not found" > /tmp/usbdev.log
    fi
    echo "${DEVPATH}" | awk -F'block' '{print $2}' | awk -F'/' '{print "connected /dev/"$3}' >> /tmp/usbdev.log
fi

Dabei muss die FiFo-Datei dem lesenden Nutzer gehören.

Das Script was dann das eigentliche Backup durchführt erstellt die FiFo-Datei und wartet dort auf Nachrichten.

Hier ein Beispiel mit restic als normaler Nutzer.

#!/bin/bash

backup()
{
    REPO="$1/rbk"
    export RESTIC_REPOSITORY="$REPO"
    if [ ! -d "$REPO" ]; then
        echo "$REPO not found" >&2
        return 1
    else
        echo mkdir -p "$REPO"
        # restic init
    fi
    restic forget --keep-last 365 --prune
    restic -q backup --exclude={$HOME/.cache} --one-file-system $HOME
    restic stats
    echo "done"
    logger "backup for $USER done"
}

trap "rm -f /tmp/usbdev" EXIT


if [ ! -p /tmp/usbdev ]; then
     mkfifo /tmp/usbdev
fi

echo "start waching"
if [ -z "$RESTIC_PASSWORD" ]; then
    RESTIC_PASSWORD=$(pass path/to/your/password)
    export RESTIC_PASSWORD
fi

while true; do
    if read -r line < /tmp/usbdev; then
        if echo "$line" | grep "connected" | grep "sd" > /dev/null; then
            USB="${line//connected /}"
            M="${USB//\/dev/\/media/}"
            if [ -f "$M" ] && echo "$USB" | grep -v "1" > /dev/null; then
                echo "ignore $USB" >&2
            else
                pmount "$USB"
                backup "$M" || echo "please check your setup"
                pumount "$USB"
            fi
        fi
    fi
done

Durch ausführen dies Skripts im Hintergrund, z.B. beim starten der grafischen Oberfläche, wird ein Backup durchgeführt, sobald der passende Datenträger verfügbar ist.

Anmerkung

Die externe Platten muss nicht wie sonst üblich verschlüsselt sein, denn die Daten werden durch restic selbst verschlüsselt.

Anmerkung 2

Bei USB-Adaptern wird nur der Adapter selbst eindeutig erkannt, nicht aber die die daran angeschlossene Platte. Durch einen Test z.B. auf eine bestimmte Datei und/oder deren Inhalt kann die notwendige Aktion darüber gesteuert werden.

Anmerkung 3

Um ein Sytem-Backup als normaler Nutzer durchführen zu können, gibt es unter systembackup eine Anleitung.

Der entscheidende Punkt ist hier die Anwendung vom setcap cap_dac_read_search=+ep, dabei ist aber zu beachten, das die erzeugten Dateien im Backup-Repo dem normalen User gehören.

Erfahrungen mit dem Upgrade auf Debian 12 (Bookworm)

2023-07-27T00:00:00Z

Seit dem 10.06.2023 ist nun Debian 12 die stabile Debian Distribution. Ich möchte in einem lebenden Dokumente beschreiben was funktioniert hat und auch was nicht mehr funktioniert (wenn etwas nicht mehr funktioniert, so muß das nicht unbedingt an Debian, sondern kann auch ein meiner Mißkonfiguration liegen.)

Aktuell habe ich > 20 Rechner auf Debian 12 geupdated

Allgemeines Vorgehen

Die Vorgehensweise ist detailliert in der offiziellen Debian Dokumentation beschrieben.

Ich habe mich zum großen Teil daran gehalten.

Zuerst alle Nicht-Libraries deinstallieren (mit apt purge), die man nicht explizit selbst installiert hat.

apt-forktracer  |sort | grep -v ^lib | egrep -v "net.downloadhelper.coapp|signal-desktop|zoom"

In meinem Falle war das z.B.:

matrix-mirage (0.6.4~dfsg+~hsluv1.0.0-4)
python3-matrix-nio (0.16.0-1)

Wenn einem die Ausgabe gefällt kann man eingeben:

apt purge $(apt-forktracer  |sort | grep -v ^lib | egrep -v "net.downloadhelper.coapp|signal-desktop|zoom" | awk '{print $1 " "}')

Dann Deinstallation der Libraries nach Augenmaß

apt purge $(apt-forktracer  |sort | grep  ^lib  |awk '{print $1 " "}')