Blog Wiedner (Posts about Technik)

systemd asncounter-service

Masin Wiedner — Sun, 11 Jan 2026 12:21:17 GMT

Nach zwei Tagen habe ich mir mal angeschaut, was mein systemd-service zum Zählen von Zugriffen nach ASN denn so angestellt hat. Dabei fielen mir ein paar kleinere Fehler auf, die ich korrigiert habe.

Außerdem kam bei mir der Wunsch auf, auch auf der Kommandozeile schnell Zugriff auf die Analyse des asncounters zu kriegen und habe mir zwei kleine Skripte geschrieben. Da diese aber auch wissen müssen, wo die cachierten Logs liegen, habe ich die Umgebungsvariablen aus dem systemd-Service in ein EnvironmentFile=/etc/asncounter-service/env ausgelagert. Umbenannt habe ich den Service auch, weil ich nicht mehr als ein Verb im Namen haben wollte: count_asn_get_prefixes klang einfach falsch, asncounter-get-prefixes klingt besser.

Die aktuelle Version befindet sich in meinem Repository.

systemd-service zum Zählen von Zugriffen nach ASN

Masin Wiedner — Fri, 09 Jan 2026 18:00:00 GMT

Ich will es wissen: Woher kommen die Zugriffe auf meinen Rootserver? Und stellt das ein Problem dar?

Die letzte Frage kann ich klar mit "nein" beantworten. Der Server langweilt sich die meiste Zeit. Aber neben meinem Rootserver habe ich noch einen virtuellen Server (VPS, virtual private server), der ein bisschen mehr zu tun hat und bei dem es ein Problem sein könnte, wenn da zu viel Mist aufläuft. Der Rootserver ist aber ein gutes Versuchskaninchen.

Anarcat hat letztes Jahr das Python-Programm asncounter veröffentlicht, das Logs aus verschiedenen Quellen nehmen kann, um sie zu analysieren und eine ASN-Statistik auszugeben. Im (englischsprachigen, aber gut verständlichen) Blogbeitrag befinden sich Erklärungen zu AS, ASN und BGP.

Der Server läuft derzeit noch mit Debian 12. Anarcat stellt in Aussicht, dass asncounter in Debian 14 in den offiziellen Repositorys enthalten seien könnte. Bis dahin ist die beste Installationsmethode wohl mittels pip bzw. pipx. Ich habe mich für letzteres entschieden. Der Einfachheit halber installiere ich gleich die Pakete mit, die bei der Installation von asncounter benötigt werden:

apt install pipx build-essential python3-dev

Ich mag es nicht, wenn pipx die virtuellen Environments und so in /root erstellt. Deswegen setze ich in der /root/.bashrc ein paar Variablen für pipx:

export PIPX_BIN_DIR=/usr/local/bin
export PIPX_HOME=/usr/local/share/pipx
eval "$(register-python-argcomplete pipx)"

Die letzte Zeile dient der Tabvervollständigung von pipx-Befehlen. Einmal kurz ausgeloggt und wieder eingeloggt, geht es weiter:

pipx install --include-deps asncounter

Das installiert den asncounter inklusive seiner Abhängigkeiten. Der Blogbeitrag erwähnt im tl;dr am Anfang eine Befehlszeile folgenden Formats:

tcpdump -q -i enp0s31f6 -n -Q in "tcp and tcp[tcpflags] & tcp-syn != 0 and (port 80 or port 443)" | asncounter --input-format=tcpdump --repl

Ich lese "tcpdump" jetzt nicht so wahnsinnig flüssig, aber ich erkenne eine Filterung nach TCP-Zugriffen auf Ports 80 und 443. Das soll mir für den Anfang reichen. Dummerweise hänge ich dann im REPL fest und muss die dazugehörige man-Page erstmal ein wenig gründlicher lesen, wo ich auf recorder.display_results() stoße:

>>> recorder.display_results()
count       percent ASN     AS
7248        85.27   265269  MEGA TELE INFORMATICA, BR
1132        13.32   270606  R3 TELECOM, BR
25  0.29    54801   ZILLION-NETWORK, US
25  0.29    45102   ALIBABA-CN-NET Alibaba US Technology Co., Ltd., CN
15  0.18    209334  MODAT-01, NL
11  0.13    197540  NETCUP-AS netcup GmbH, DE
6   0.07    16276   OVH, FR
4   0.05    213438  COLOCATEL-INC Colocatel Network - High Bandwidth Dedicated Servers, SC
4   0.05    14061   DIGITALOCEAN-ASN, US
3   0.04    211607  RECORDEDFUTURE, US
unique ASN: 26
count       percent prefix  ASN     AS
1826        21.48   168.90.91.0/24  265269  MEGA TELE INFORMATICA, BR
1823        21.45   168.90.89.0/24  265269  MEGA TELE INFORMATICA, BR
1806        21.25   168.90.88.0/23  265269  MEGA TELE INFORMATICA, BR
1793        21.09   168.90.90.0/24  265269  MEGA TELE INFORMATICA, BR
310 3.65    177.37.19.0/24  270606  R3 TELECOM, BR
282 3.32    177.37.17.0/24  270606  R3 TELECOM, BR
273 3.21    177.37.18.0/24  270606  R3 TELECOM, BR
267 3.14    177.37.16.0/24  270606  R3 TELECOM, BR
25  0.29    148.178.64.0/20 54801   ZILLION-NETWORK, US
25  0.29    47.83.0.0/17    45102   ALIBABA-CN-NET Alibaba US Technology Co., Ltd., CN
unique prefixes: 34
total lookups: 8500
total skipped: 0
total failed: 0

asncounter gibt also im Falle des Durchpipens von tcpdump nur auf explizite Anfrage Werte aus. Damit kann man sicher arbeiten, aber mir wird beim Gedanken, irgendwelche Sockets regelmäßig abzufragen, ein wenig flau im Magen. Langlaufende Prozesse, die ich verbrochen habe? Nein, danke :-).

Aber tcpdump minütlich Dinge erfassen lassen, die ich asncounter dann zum Analysieren vorwerfen kann? Klar, das sicher. Und so lernte ich heute von timeout, das genau das tut, was ich will:

timeout -sHUP 1m tcpdump -q -i enp0s31f6 -n -Q in "tcp and tcp[tcpflags] & tcp-syn != 0 and (port 80 or port 443)" > tcpdump4asncounter.log

Jetzt brauche ich nur ein Bash-Skript, das mir jede Minute eine Datei mit diesen Daten erstellt.

#!/usr/bin/env bash
CACHE_DIR=/var/cache/count_asn
IF="${INTERFACE:-any}"
DIR="${CACHE_DIRECTORY:-${CACHE_DIR}}"
printf "Interface set to %s.\n" "${IF}"
printf "Cache directory set to %s.\n" "${DIR}"

cleanup () {
    #kill -s SIGTERM $!
    exit 0
}

trap cleanup SIGINT SIGTERM

if [ ! -d "${DIR}" ]
then
    install -d "${DIR}"
fi

printf "Starting logging loop …\n"
while true
do
    CURRENT=$(date +%s)
    timeout -sHUP 10s tcpdump -q -i "${IF}" -n -Q in "tcp and tcp[tcpflags] & tcp-syn != 0 and (port 80 or port 443)" > "/tmp/count_asn_${CURRENT}.log" 2> /dev/null
    find "${DIR}" -type f -mtime +1 -delete
    mv "/tmp/count_asn_${CURRENT}.log" "${DIR}/"
    cat "${DIR}/"count_asn_*.log | /usr/local/bin/asncounter --input-format tcpdump --no-prefixes --output /etc/motd.d/01-asncounter.txt 2> /dev/null
done

Am Anfang werden ein paar Variablen initialisiert, die ich entweder per systemd übergebe oder eben auch nicht. Dann braucht es aber sinnvolle Defaults.

Ich habe feststellen dürfen, dass sich so eine while-true-Schleife nicht mit Strg+c abbrechen lässt. Vielleicht liegt es auch an timeout. Deswegen werden die Signale SIGINT und SIGTERM explizit abgefangen und in der cleanup()-Funktion behandelt. Das aktuelle tcpdump läuft aber noch bis zum Ende durch. Damit kann ich leben.

Der Dump wird erstmal nur nach /tmp geschrieben. Dann werden die Dateien entfernt, die älter als 1 Tag sind, bevor die neue Datei in den Cache geschoben wird. Der Cache-Inhalt wird dann asncounter zur Analyse übergeben, das Ergebnis wird nach /etc/motd.d geschrieben (Verzeichnis muss manuell erstellt werden). Und auf diese Weise lernte ich, dass pam_login auch die Dateien dieses Verzeichnisses ausgibt statt nur /etc/motd.

Natürlich muss das Skript ausführbar gemacht werden:

chmod +x /usr/local/bin/count_asn

Jetzt muss das Skript nur noch dauerhaft laufen. Ich benutze dafür gerne systemd. Schnell mal eine Vorlage im Web herausgesucht und an meine Bedürfnisse angepasst. Ich bin leider immer noch nicht so weit, dass ich das aus dem Ärmel schütteln kann:

# /etc/systemd/system/count_asn.service
[Unit]
Description=Count ASNs using asncounter and update motd
After=network.target

[Service]
Type=simple
Environment=INTERFACE=enp0s31f6
ExecStart=/usr/local/bin/count_asn
Restart=always
RestartSec=5
CacheDirectory=count_asn
IgnoreSIGPIPE=no

[Install]
WantedBy=multi-user.target

Der Install-Abschnitt gibt wie immer an, an welcher Stelle beim Booten der Dienst gestartet werden soll, wenn er enabled wird. Im Unit-Abschnitt sagen wir an, dass der Dienst erst nach dem Erreichen des network.target gestartet werden soll. Verfügbarkeit von Netzwerk ist eine Wissenschaft für sich, aber hier sollte das passen.

Der wichtigste Teil ist hier IgnoreSIGPIPE=no, ansonsten klappt das Pipen der Daten an asncounter nicht. Das Skript kriegt mit der Umgebungsvariable INTERFACE noch die richtige Schnittstelle mitgeteilt.

Lohn der Mühe:

$ ssh root@hades
Linux hades.fluchtkapsel.de 6.1.0-41-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.158-1 (2025-11-09) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
count       percent ASN     AS
21811       78.65   265269  MEGA TELE INFORMATICA, BR
5486        19.78   265410  JL INFORMATICA E TELECOM LTDA - ME, BR
108 0.39    14618   AMAZON-AES, US
71  0.26    197540  NETCUP-AS netcup GmbH, DE
43  0.16    8075    MICROSOFT-CORP-MSN-AS-BLOCK, US
40  0.14    202306  HOSTGLOBALPLUS-AS, GB
31  0.11    51852   PLI-AS, PA
17  0.06    206264  AMARUTU-TECHNOLOGY, SC
14  0.05    398705  CENSYS-ARIN-02, US
10  0.04    62068   SPECTRAIP SpectraIP B.V., NL
unique ASN: 40
total lookups: 27730
total skipped: 152
total failed: 0
Last login: Fri Jan  9 18:05:35 2026 from 79.248.89.181

Ich werde beim Login mit der Statistik begrüßt. Das sieht mir jetzt robust genug aus, dass ich das auch auf meinem VPS einrichten kann. Dort läuft Arch Linux. Als erstes installiere ich pipx:

pacman -Sy python-pipx python-pip base-devel

python-pip ist nur dafür dabei, falls ich mal manuell in die venv schauen muss, und base-devel ist das Arch-Äquivalent zu Debians build-essential. Als nächstes kommen die Einträge in die .bashrc von oben gefolgt von einem Logout und erneuten Login.

Ich übertrage das Skript und den Service, passe die Schnittstelle an, erstelle das Verzeichnis /etc/motd.d und starte den Service. Nach ein paar Minuten gibt es dann auch hier Statistiken:

$ ssh root@persephone
count       percent ASN     AS
651 58.97   265269  MEGA TELE INFORMATICA, BR
151 13.68   265410  JL INFORMATICA E TELECOM LTDA - ME, BR
113 10.24   24940   HETZNER-AS, DE
61  5.53    14618   AMAZON-AES, US
22  1.99    16276   OVH, FR
12  1.09    197540  NETCUP-AS netcup GmbH, DE
8   0.72    3320    DTAG Internet service provider operations, DE
8   0.72    63949   AKAMAI-LINODE-AP Akamai Connected Cloud, SG
8   0.72    15169   GOOGLE, US
7   0.63    14061   DIGITALOCEAN-ASN, US
unique ASN: 52
total lookups: 1104
total skipped: 7
total failed: 9462

Deutlich weniger Betrieb. Das überrascht. Im nächsten Schritt muss ich dann mal schauen, ob ich aus diesen Daten sinnvolle Regeln für die Firewall ableiten kann. Auf beiden Systemen läuft nftables – das macht es mir ein wenig einfacher. Aber das ist eine Aufgabe für einen Folge-Eintrag ins Blog.

Dieser Blog-Eintrag wurde ohne Unterstützung generativer KI erstellt.

Fritz!Box WireGuard und systemd-networkd

Masin Wiedner — Tue, 06 Jan 2026 22:03:50 GMT

Vor Jahren schon habe ich einfache WireGuard-Verbindungen zwischen meinem Heimserver und meinem virtuellen Server, damals bei Contabo, eingerichtet. Ich erinnere mich düster, dass ich den WireGuard-Schnittstellen eigene IP-Adressen zuweisen musste, über die dann das Routing eingerichtet wurde.

In diesem Eintrag werde ich Verbindungsschlüssel entfernen und IP-Adressen austauschen bzw. durch Labels ersetzen, die ihre Funktion beschreiben, damit das ggf. auf vergleichbare, aber nicht identische Situationen angewendet werden kann.

Die Situation

Bei mir liegen zwei Spezialfälle vor: Ich habe auf meinem Server ein paar Systemcontainer mit systemd-nspawn am Laufen. Diese hängen dort an einer Network Zone, die von systemd-nspawn gemanagt wird. Für vorhersagbare IP-Adressen läuft auf der Bridge-Schnittstelle der DHCP-Server von systemd-networkd. Der wird einfach mittels einer Drop-in-Datei aktiviert und konfiguriert.

# /etc/systemd/network/80-container-vz.network.d/00-dhcp.conf
[Network]
Address=192.168.1.1/24
Address=fd00:1::1/64
DHCPServer=yes
IPMasquerade=both

[DHCPServer]
ServerAddress=192.168.1.1/24
EmitDNS=yes
DNS=9.9.9.9
EmitRouter=yes
EmitTimezone=yes
Timezone=Europe/Berlin
PoolOffset=99
PoolSize=150

[DHCPServerStaticLease]
# nspawn 1
MACAddress=12:34:56:00:00:01
Address=192.168.1.101

[DHCPServerStaticLease]
# nspawn 2
MACAddress=12:34:56:00:00:02
Address=192.168.1.102

[DHCPServerStaticLease]
# qemu 1
MACAddress=12:34:56:00:01:01
Address=192.168.1.201

Die einzelnen statischen Leases könnten jeweils auch in eigenen Dateien stecken.

Die andere Besonderheit ist, dass die Fritzbox bei mir nicht für das DHCP zuständig ist. Das macht ein dnsmasq auf meinem Heimserver in einem systemd-nspawn-Container.

Wichtig ist, dass am Ende aus dem lokalen Netz hinter der Fritzbox via WireGuard auf die einzelnen Container zugegriffen werden kann.

## Konfiguration auf der Fritzbox Der wichtige Teil findet statt auf der Seite "Internet > Freigaben > VPN (Wireguard)" (Fritz-OS 8.21). Der Assistent wird mit der Schaltfläche "WireGuard®-Verbindung hinzufügen" aufgerufen.

Effektiv musste ich in dem Assistenten immer die rechte Option wählen:

Welche Art Verbindung möchten Sie erstellen? → Netzwerke koppeln.
Ist diese WireGuard®-Verbindung auf der Gegenstelle bereits eingerichtet? → Nein.
Soll die Verbindung gleichzeitig zu einer bestehenden WireGuard®-Verbindung der Gegenstelle genutzt werden? → Nein. Ich habe nicht geschaut, was "ja" an der Stelle bewirkt. Ich nehme an, davon hängt ab, ob ich eine vollständige Konfiguration kriege oder nur einen Schnipsel zur Ergänzung.
Was für ein Gerät befindet sich auf der Gegenstelle? → WireGuard®-fähiger Router. Keine Ahnung, warum das abgefragt wird, wenn ich am Anfang "Netzwerke koppeln" ausgewählt habe. Ja natürlich muss da ein WireGuard®-fähiger Router sein.

Der Assistent warnt mich dann:

Das manuelle Hinzufügen der neuen Verbindungseinstellungen wird nur erfahrenen Benutzern empfohlen.

Naja, wir sind ja erfahren, nicht wahr?

Als nächstes vergeben wir einen Namen, unter dem die Verbindung geführt wird.

Der nächste Schritt ist ein wenig unklar. Der Assistent möchte eine Angabe der "DNS-Domains der WireGuard®-Gegenstelle". Nirgends scheint die Angabe eine Auswirkung zu haben. Ich kann nur mutmaßen, dass dieser Wert via DHCP als search domain verteilt wird. Wie eingangs erwähnt, kümmert sich ein anderes System hier um DHCP.

Im vorletzten Schritt fragt der Assistent nach den "IP-Einstellungen der Verbindung". Hier musste ich ein wenig experimentieren, um herauszufinden, was der Assistent damit meint. Letzten Endes funktionierte es mit der IP-Adresse der systemd-nspawn-Zone, deren Netzmaske (CIDR zu Netzmaske) und der ULA-IPv6-Adresse ebendieser Schnittstelle. Bis zu dieser Konfiguration hatte ich der Zonen-Schnittstelle überhaupt keine IPv6-Adresse vergeben, was zu ein bisschen Recherche-Arbeit geführt hat.

Im letzten Schritt gibt es ein paar Kästchen anzukreuzen oder auch nicht. In diesem Fall wird nichts davon gebraucht.

Wenn man zu lange brauchte seit der letzten Bestätigung, dass man berechtigt sei, Änderungen an der Konfiguration vorzunehmen, muss das jetzt nochmal bestätigt werden. Im Anschluss arbeitet die Fritzbox ein wenig und bietet dann den Download der erstellten Konfiguration an, was wir auch annehmen. Nach dem Download muss noch auf "Ok" geklickt werden. Der Assistent weist ein letztes Mal darauf hin, dass die geheimen Verbindungsdaten aus der Datei nicht wieder eingesehen werden können.

[Interface]
PrivateKey = <privater Schlüssel des Servers>
Address = 192.168.1.1/24,fd12:3456:7891::/64
DNS = <private IPv4 und IPv6 der Fritzbox>
DNS = fritz.box

[Peer]
PublicKey = <öffentlicher Schlüssel der Fritzbox>
PresharedKey = <geteilter Schlüssel der Verbindung>
AllowedIPs = <private IPv4- und IPv6-Netze der Fritzbox>
Endpoint = foobar.myfritz.net:52008
PersistentKeepalive = 25

Eigentlich brauchen wir die Datei gar nicht, aber sie beinhaltet die Werte, die wir für die Konfiguration mit systemd-networkd brauchen.

## Konfiguration von systemd-networkd auf dem Server Die Konfigurationsdateien von systemd-networkd liegen üblicherweise in /etc/systedm/network/.

Die Verbindung wird auf drei Dateien aufgeteilt:

wg0.netdev: Die Datei legt das Netzwerkgerät an. Sie beinhaltet die Verbindung zur Gegenstelle sowie alle für die Verbindung notwendigen Geheimnisse bzw. verweist auf entsprechende Dateien (vgl. man-Page systemd.netdev, Abschnitt Wireguard).
wg0.key: Die Datei beinhaltet den base64-kodierten privaten Schlüssel des Servers für diese Verbindung.
wg0.network: Hier wird ganz normal das Netzwerk auf der Schnittstelle wg0 konfiguriert – IP-Adressen, Routen und was sonst noch so anfällt (vgl. man-Page systemd.network).

Die Namen der Dateien sind beliebig wählbar. Allein bei dem privaten Schlüssel muss drauf geachtet werden, dass die Datei in der .netdev-Datei korrekt referenziert wird.

# wg0.netdev
[NetDev]
Name=wg0
Kind=wireguard
Description=WireGuard tunnel wg0

[WireGuard]
# Vermutlich unnötig, ist einfach auf den gleichen Port gesetzt, den die Fritzbox auch nutzt.
ListenPort=52008
PrivateKeyFile=/etc/systemd/network/wg0.key

[WireGuardPeer]
AllowedIPs=192.168.178.1/24,fd12:3456:7890::/64
PublicKey=<öffentlicher Schlüssel der Fritzbox>
PresharedKey=<geteilter Schlüssel der Verbindung>
Endpoint=foobar.myfritz.net:52008
PersistentKeepalive=25

Die Werte für PublicKey und PresharedKey können einfach aus der heruntergeladenen Konfigurationsdatei kopiert werden. Tatsächlich benutzen WireGuard und systemd-networkd die gleichen Namen für die Werte, so dass sogar die Zeilen komplett kopiert werden können.

systemd-networkd möchte nicht, dass diese Datei weltlesbar ist, weswegen wir die Berechtigungen und Eigentümerschaft anpassen:

chmod 640 /etc/systemd/network/wg0.netdev
chown root:systemd-network /etc/systemd/network/wg0.netdev

Das PrivateKeyFile beinhaltet einfach nur den Wert <privater Schlüssel des Servers> aus der Konfigurationsdatei ohne PrivateKey= oder ähnlichem. Netterweise ist der Wert bereits base64-kodiert, so dass dahingehend nichts weiter getan werden muss. Für die Datei verlangt systemd-networkd aber sogar, dass sie nicht weltlesbar ist:

chmod 640 /etc/systemd/network/wg0.key
chown root:systemd-network /etc/systemd/network/wg0.key

Bei der letzten Datei, der wg0.network, ist systemd-networkd entspannter. Sie kann ruhig von allen gelesen werden.

# wg0.network
[Match]
Name=wg0

[Network]
Address=192.168.1.1/24
Address=fd00:1::1/64
IPMasquerade=both

[Route]
Destination=<IPv4-Netzwerk der Fritzbox>

[Route]
Destination=<IPv6-Netzwerk der Fritzbox>

Aufmerksamen Leser*innen ist es sicher aufgefallen, und mir bereitet es auch Bauchschmerzen, aber es funktioniert tatsächlich: Die Schnittstelle wg0 erhält die gleichen Adressen und Netzmasken wie die Schnittstelle der systemd-nspawn-Zone.

Mit einem finalen networkctl reload wird die Schnittstelle aktiviert und der WireGuard-Tunnel aufgebaut.

Da die systemd-nspawn-Container als Default-Route die Adresse der Zonen-Schnittstelle konfiguriert haben, funktionieren Verbindungen von Seiten der Container sofort. Auch die Geräte hinter der Fritzbox können die Container ohne Probleme erreichen, da die Fritzbox –wie in den meisten Fällen– als Gateway konfiguriert ist.

Dieser Blog-Eintrag wurde ohne Unterstützung generativer KI erstellt.

Umtausch des Führerscheins mit der BundID

Masin Wiedner — Wed, 09 Apr 2025 16:07:50 GMT

Seit Monaten piesackt mich die Ehefrau, dass ich doch endlich mal meinen Führerschein umtauschen soll. Durch meinen Beinbruch Anfang des Jahres hatte sich die Notwendigkeit dazu ein wenig verringert. Aber seit dem 19.1. habe ich effektiv keine gültige Fahrerlaubnis mehr. Aber jetzt, wo der Bruch so langsam verheilt ist, wird es doch dringlicher.

Meine Frau meinte, der Online-Umtausch sei eigentlich ganz einfach. Das stimmte mich zuversichtlich. Also schnell mal die Website des Landkreises aufgerufen und nach irgendwas mit Führerschein oder Fahrerlaubnis gesucht. Bei den häufig gestellten Fragen gab es zwar viele Antworten aber keinen Link zum Umtausch. Den fand ich dann bei den Dienstleistungen unter "F" wie "Führerschein, Umtausch". Alles in allem ging der Teil schneller als befürchtet.

Nirgends ein Link zum Online-Umtausch

Hier ist der gesuchte Link. Man muss nur denken wie ein Bürokrat.

Gleich zu Anfang wird mir angeboten, meinen Ausweis mit Onlinefunktion zum Identitätsnachweis nutzen zu können! Wow! Das zweite Mal nach der Krankenversicherung, dass ich ihn zum Einsatz bringen kann!

Vermutlich wäre es ohne Online-Identitätsnachweis schneller gegangen. Aber es ist ja auch das erste Mal

Frohen Mutes wähle ich im nächsten Schritt meine Nationalität und die einzige angebotene Option (Personalausweis mit Online-Ausweisfunktion), nur um dann gesagt zu bekommen, ich müsse mich mittels BundID authentifizieren.

*seufz*

Also probieren wir es damit. Abgesehen davon, dass die Erstellung einer BundID in dem Popup-Fenster ein wenig beengt ist, geht das eigentlich recht gut. Nur stolpere ich hier und da über den einen oder anderen Fallstrick.

Als erstes wundere ich mich, warum die Registrierung eine Verbindung zu localhost aufbauen will. Dann dämmert es mir, dass auf diese Weise mit der AusweisApp gesprochen werden soll. Also starte ich die AusweisApp, die es dankenswerterweise auch für Linux gibt, sogar als Flatpak. Spannendes Konzept übrigens: Die AusweisApp auf dem Rechner kann auf zweierlei Weise den Ausweis auslesen: Entweder über ein Kartenterminal mit Nummernblock, das ich nicht habe (auf Arbeit hätten wir eines), oder indem sie mit der AusweisApp auf dem Smartphone redet und das liest die Daten aus. Die beiden Geräte wollen einmalig gekoppelt werden, aber dann läuft das nach Eingabe der 6-stelligen PIN überraschend stabil. Auch die Erkennung des Smartphones im WLAN durch die AusweisApp auf dem Rechner läuft geschmeidig.

Leider mag das bereits geöffnete Popup-Fenster jetzt nicht mehr mit der AusweisApp reden. Also zurück, neu probiert, Fehler "eine Registrierung ist bereits im Gange" oder so ähnlich erhalten, alles angezündet und nochmal von vorn in einem eigenen Fenster auf id.bund.de. Das geht dann gut bis zur Eingabe meiner E-Mail-Adresse, die ich mit einem Code bestätigen soll – "Session wurde nicht gefunden" oder so ähnlich.

Also zurück, "registrieren" angeklickt. "Registrierung ist bereits im Gange". Tab schließen, neuen öffnen, nochmal von vorne. Jetzt geht es, und ich komme bis zum Ende durch. Ich habe eine BundID!

Ich bin mir sicher, die Authentifizierung für den Führerschein wäre auch ohne BundID technisch möglich, wurde aber nicht implementiert, um die Nutzung der BundID zu erzwingen. Aber ich will mal nicht so sein, Digitalisierung in Deutschland und so.

Jetzt klappt es auch mit der Anmeldung für den Führerschein. Natürlich merkt sich die BundID nicht, dass ich eine laufende Sitzung habe, und ich muss erneut eine Anmeldung durchführen inkl. AusweisApp auf beiden Geräten und dem Ausweis am Smartphone. Welchen Nutzen Benutzername und Passwort haben sollen, die ich bei der Registrierung bei der BundID vergeben musste, erschließt sich mir noch nicht.

Der Blog-Eintrag ist schon länger, als ich beabsichtigt habe, also versuche ich es kurz zu halten.

Der Ablauf für den FÜhrerschein-Umtausch besteht aus vier bis sieben Seiten, je nach Zählweise. Die ersten vier Seiten sammeln die Daten des bestehenden Führerscheins und, was für den neuen gebraucht wird. Die anderen Seiten sind dann Kontaktdaten und Bestätigung. Für jeden Schritt habe ich 5 Minuten, danach wird alles beendet, und ich muss wieder von vorn beginnen.

Nachdem ich das erste Mal ins Timeout geraten bin, habe ich mir angewöhnt, immer mal wieder vor und zurück zu navigieren über die Buttons in der Website (nicht die Navigation des Browsers!). Dabei gehen zwar die Daten auf der letztbesuchten Seite verloren, aber ich kann vorbereiten, was notwendig ist.

So musste ich beide Seiten meines Führerscheins fotografieren. Damit bin ich dann ins Timeout geraten. Dateien zugeschnitten und ordentlich benannt, vor und zurück navigiert, angemeldet, Fragen beantwortet, Bilder hochgeladen. Sie wollen ein biometrisches Passfoto. Ich habe noch eines von der Krankenversicherung, aber das muss ich erst aus einem PDF befreien (yay, pdfimages). Die Website findet, dass der Hintergrund nicht gleichmäßig genug sei – er ist weiß. Meine Unterschrift nach der Namensnennung befindet sich noch nicht auf dem privaten Laptop, sondern nur auf dem Arbeitslaptop, also vor und zurück, Treppe hoch, Laptop einschalten, Treppe runter, SSH, Ordner kopieren, feststellen, dass sie überall PDF, JPEG, PNG erlauben, nur nicht bei der Unterschrift, die nur JPEG sein darf. Also Unterschrift in JPEG konvertiert. Vorher vor und zurück. Foto und Unterschrift hochgeladen, fertig.

Steam Deck, SSD-Upgrade

Masin Wiedner — Fri, 01 Mar 2024 21:39:00 GMT

Anmerkung: Dieser Beitrag ist zusammengestellt aus mehreren Posts im Fediverse. Für die bessere Auffindbarkeit veröffentliche ich das nachträglich auch hier. Das Datum des Beitrags setze ich auf das vom ersten Beitrag des Threads.

Ich habe mir eine WD Black 2230 mit 2 TB fürs Steam Deck gekauft. Alte SSD ausgebaut, in USB-Adapter eingesetzt, Image gezogen. Dann neue SSD in den Adapter, Image wieder zurückschreiben.

Abbruch des Schreibvorgangs nach 200 GB. Wiederholt, Abbruch nach 170 GB, Abbruch nach 60 GB, Abbruch nach 160 GB. Das Device kriegt immer einen neuen Buchstaben, erst sdb, dann sdc, dann nach einem Neustart wieder sda, sdb, sdc. Fehlermeldung: Kein Speicherplatz auf dem Gerät.

Irgendwann steigt eine Komponente also aus, die SSD wird aber wieder erkannt und als neues Device bereitgestellt. Der Schreibvorgang ist dann natürlich hin. Ich vermute, dass entweder die SSD überhitzt (unwahrscheinlich) oder der USB-Controller-Chip, der NVMe auf USB umsetzt.

Ich pipe also die Ausgabe von gunzip durch pv -L 20M, bevor es weiter nach dd geht. Ja, umständlich, aber ich hatte vorher mit pv und dd probiert, weil ich da die Ursachen gesucht hatte. Der Parameter -L 20M begrenzt die Übertragung auf 20 MB/s. Unbegrenzt werden 150 bis 200 MB/s durch den Controller auf die SSD gejagt.

In meinen letzten Versuch mit dd setze ich also noch pv. Und wo der Schreibvorgang vorher nach 1000 bis 1500 Sekunden abbrach, läuft er jetzt schon mehr als 2,5 Stunden. Leider darf ich noch mit mindestens der gleichen Laufzeit rechnen. Aber ich habe es ja nicht sonderlich eilig, Hauptsache, die Daten werden vollständig geschrieben.

Als Lehre daraus nehme ich jedenfalls mit, dass es bei diesen USB-Adaptern wohl auch Qualitätsunterschiede gibt.

Es hat fast 7 Stunden gedauert, aber der Schreibvorgang wurde ohne Fehlermeldung beendet. Ich fasse das mal als "fehlerfrei" auf.

In parted dann die GPT reparieren lassen, und das Ende der Partition 8 auf 100% gesetzt. Ich dachte, das Dateisystem sei btrfs auf der Partition, aber es ist ext4. Also e2fsck -f /dev/sdc8 und im Anschluss resize2fs /dev/sdc.

Der Zusammenbau erfolgt wie das Auseinandernehmen nach iFixit-Anleitung, aber natürlich in umgekehrter Reihenfolge.

Meine Kinder haben mir zum Geburtstag vor zwei Wochen eine Skin fürs Steam Deck geschenkt. Wenn ich schon am Steam Deck arbeite, klebe ich die Skin dann auch gleich mal auf. Ja, es war nervenaufreibend, mit dem Booten zu warten, bis ich damit fertig wurde.

Steam Deck Front

Steam Deck Rückseite

Aber das Steam Deck bootete ohne zu klagen. MicroSD-Karte vergessen! Da ich eh noch in die Firmware wollte, habe ich das Deck ausgeschaltet und dann erst die Karte eingesetzt.

Jetzt wird deren Inhalt auf den internen Speicher verschoben.

Update fürs Blog: Steam erlaubt aus dem UI heraus, die Spiele zwischen den konfigurierten Bibliotheken hin und her zu schieben. Leider warf das bei mir beim einen oder anderen Spiel Fehlermeldungen, die ich aber nicht weiter recherchiert habe, weil es mir eh zu umständlich war, bei 50 oder 60 Titeln manuell das Verschieben anzustoßen. Ich habe einfach den Ordner steamapps von der MicroSD-Karte mit dem gleichnamigen Ordner /home/deck/.local/Steam/steamapps zusammengeführt. Nach einem kurzen Test, ob das so funktioniert, habe ich die MicroSD-Karte formatiert, um sicherzugehen, dass kein Spiel mehr von dort gestartet wird. Großes Lob an Valve, dass man so unkompliziert auch direkt im Dateisystem arbeiten kann.

Fehlercode 0.60 bei Prime Video auf Google Chromecast mit Android-TV

Masin Wiedner — Thu, 08 Feb 2024 09:08:06 GMT

Seit etwas mehr als einer Woche plagte mich der Fehlercode 0.60 bei der "Prime Video"-App auf dem Google Chromecast mit Android TV – ich finde es ja auch furchtbar, das so auszuschreiben, aber das Gerät heißt nun mal so. Da ich meine Lösung letztendlich über ein Apple-TV-Support-Forum fand, wird das aber vermutlich auf verschiedenen Geräten von Roku, Amazon und Herstellern von Smart-TVs ähnlich sein.

Auf die falsche Fährte führte mich, dass am 2024-01-24 ein Update der App stattgefunden hat, was dann vermutlich in den ein, zwei Tagen danach auch auf meinem Chromecast landete. Während meiner Recherche habe ich mich zu sehr auf diese zeitliche Koinzidenz eingeschossen. Tatsächlich lag die Ursache aber in der Aktivierung unserer Glasfaser am 2024-01-25 und vermutlich am Kurzurlaub meiner Familie am 2024-02-03 für ein paar Tage.

Die Glasfaser-Aktivierung war schuld, weil damit erstmalig IPv6 Einzug hielt bei uns. Vorher befand sich das Heimnetz in einem Zustand von "vielleicht funktioniert das ja so". Ich konnte ja nichts belastbar testen, ich konnte keine Erfahrungen sammeln. Hätte ich nicht zu viele Eigenheiten im Heimnetz, wäre das vielleicht auch nie aufgetreten, wer weiß?

Durch IPv6 über die Glasfaser hat mein Netz jetzt jedenfalls auch endlich ein IPv6-Präfix erhalten. Und ich war super erstaunt, dass das praktisch sofort alle Geräte erreichte, die sich dann auch selbst konfiguriert hatten. Für mich ein Rätsel war aber immer noch, wie die Geräte eigentlich herauskriegen, wo das Gateway liegt und wie sie Namen auflösen sollen. Das sollte mir hierbei noch auf die Füße fallen.

Im Nachhinein kann ich mir nicht erklären, warum das nicht sofort aufgefallen ist. Vielleicht haben wir bei Amazon einfach nichts geschaut für ein paar Tage. Oder ich habe das als Fehler auf Amazons Seite betrachtet, denn alle anderen Streamingdienste liefen ja ohne Probleme. Ja, die App "Prime Video" auf dem Google Chromecast mit Android TV macht irgendwas eigenes, und sie macht das nicht auf anderen Android-Geräten – auf meinem Tablet wie auch auf dem Handy konnte ich sie normal benutzen.

Der Kurzurlaub meiner Familie wiederum war dahingehend daran beteiligt, dass ich währenddessen am NAS gearbeitet hatte, wo ich einen dnsmasq in einem systemd-nspawn-Container betreibe, der für DNS und DHCP im Heimnetz zuständig ist. Nach viel hin und her beschloss ich am Ende, um zumindest einen Teil des Umzugs durchzuführen, den alten Container auf dem neuen NAS in Betrieb zu nehmen. Für niemanden überraschend außer mich, der schlicht nicht dran gedacht hat, hat der Container dort natürlich eine neue IPv6 für sich erzeugt, so dass der DNS-Server-Eintrag in den IPv6-Netzwerkeinstellungen der Fritzbox natürlich falsch war. War er vorher vermutlich auch schon, denn es hatte ja schon vorher nicht funktioniert.

Jetzt habe ich auch ein paar Tage Urlaub und habe mich heute früh mal dran gesetzt. Der Forumsbeitrag erwähnte IPv6, und da ich das noch nicht weiter verfolgt hatte, dachte ich mir, dass ich das ja mal machen könnte. Stück für Stück habe ich dann meine Konfiguration im Heimnetz mal abgeklopft.

Die resolv.conf meines Containers war noch auf die alte IP eingerichtet.

Meine Datei für Namensauflösungs-Overrides warf immer Fehler.

Feb 08 09:34:22 lan-basics1 systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Feb 08 09:34:22 lan-basics1 dnsmasq[4698]: bad option at line 1 of /etc/dnsmasq.d/override.hosts
Feb 08 09:34:22 lan-basics1 dnsmasq[4698]: FAILED to start up
Feb 08 09:34:22 lan-basics1 systemd[1]: dnsmasq.service: Control process exited, code=exited, status=1/FAILURE
Feb 08 09:34:22 lan-basics1 systemd[1]: dnsmasq.service: Failed with result 'exit-code'.
Feb 08 09:34:22 lan-basics1 systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server.

Hintergrund: Auch wenn in der /etc/dnsmasq.conf steht:

conf-dir=/etc/dnsmasq.d,*.conf

so steht in der /etc/default/dnsmasq dummerweise:

CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new

In der /etc/init.d/dnsmasq wird die Default-Datei dann gesourcet und CONFIG_DIR auf der Kommandozeile übergeben, womit es die Option in dnsmasq.conf überschreibt, falls die Datei dann überhaupt noch ausgewertet wird. Das hat jedenfalls dazu geführt, dass alle Dateien in /etc/dnsmasq.d eingebunden wurden, die nicht auf .dpkg-dist, dpkg-old oder dpkg-new endeten. Ich habe den Eintrag in der Default-Datei entsprechend geändert, dass er dem in der Konfigurationsdatei entspricht.

Ich vermute, die Debian-Maintainer hatten das irgendwann in der Vergangenheit aus guten Gründen so gehandhabt, aber dann nicht mitbekommen, dass die Upstream-Konfigurationsdatei das bereits erledigt, was die Maintainer erzielen wollten. Ich werde das auch mal melden müssen. Die Korrektur hat jetzt jedenfalls dazu geführt, dass meine ausgelagerten Einstellungen für DNS-Server –google.dns und quad9.dns– nicht mehr beide gleichzeitig eingebunden werden. War zwar vorher kein bemerkbares Problem, aber ich erinnere mich, dass ich zurück auf Google musste, weil Quad9 irgendeinen Blödsinn gemacht hat (oder auch nix gemacht hat).

Ich finde solche Probleme bei Konfigurationsdateien ja doch sehr ärgerlich. Ich möchte gerne wissen, welche Dateien die Laufzeit-Konfiguration enthalten. Ich möchte Kontrolle darüber haben. Ich will nicht so überrascht werden.

Auf der anderen Seite, beim Chromecast, konnte ich zumindest feststellen, dass die App funktionierte, wenn ich die Netzwerkkonfiguration von "DHCP" auf "statisch" änderte.

Trivia: Ändert man das, werden die einzelnen Optionen nicht mit den letzten DHCP-Werten befüllt, sondern mit generischen Werten aus dem 192.168.1.1/24-Netz. Und die Eingabe über die Fernbedienung ist nicht sonderlich komfortabel.. Immerhin müssen nur Adresse, Subnetzlänge und Gateway eingegeben werden. Bei den DNS-Servern habe ich schlicht die Vorgaben (Google-DNS) verwendet.

Damit ging es also, was mir die Vermutung nahelegte, dass irgendwas bei der DHCP-Konfiguration schief lief. Aber mehr als die IP-Adressen kann ich der Oberfläche des Chromecast nicht entlocken. Und irgendwie funktionierte ja die Konfiguration. Ich habe wieder einmal in die DHCP-Einstellungen von dnsmasq geschaut, und wieder hatte ich vergessen, dass IPv6 anders konfiguriert wird. Mein Router meldet den IPv6-Clients, welchen DNS-Server sie verwenden sollen. Und da fiel mir dann auf, dass da ein falscher Wert steht. Schwupps ausgetauscht gegen die aktuelle IPv6-Adresse des lan-basics-Containers, und schon läuft es.

Hilfreich zum Überprüfen (Quelle: How can I view IPv6 router advertisements that are being received by my computer for diagnostic purposes?) :

tcpdump -n -i wlp2s0 icmp6
tcpdump -n -i wlp2s0 icmp6 and ip6[40] == 134
radvdump

Interessanter Nebeneffekt: Ich hatte seit Monaten das Gefühl, dass mein Tablet beim Aufruf einer noch nicht cachierten Website eine unangenehm lange Denkpause einlegt. Ich hatte DNS im Verdacht, aber ich fand nichts. Ich denke, das geht jetzt auch flotter. Vermutlich hat auch das Tablet erst einmal DNS per IPv6 aufzulösen versucht, und wenn keine Antwort kam, hat es IPv4 probiert. Das scheint die "Prime Video"-App nicht zu machen.

Mir bleibt nur noch die Frage offen, wie stabil die Selbstkonfiguration bei IPv6 ist. Ich habe für den lan-basics-Container folgendes gesetzt:

IPv6LinkLocalAddressGenerationMode=eui64

Nach dem Wälzen der man-Page (ist schon ein paar Monate her) scheint mir das die einzige Einstellung zu sein, die keine Konflikte erzeugen kann und reproduzierbar die gleiche IPv6-Adresse erzeugt. Aber ist das so?

Erste Erfahrungen mit dem E-Rezept

Masin Wiedner — Thu, 01 Feb 2024 08:07:01 GMT

Über das E-Rezept wurde ja schon viel gemeckert, aber ein Aspekt kam mir noch nicht unter.

Ich muss jedes Quartal meine Versichertenkarte in die Praxis bringen. Meine Medikamente reichen knapp weniger als ein Quartal. Meine regulären Kontrolltermine werden aber auch nicht so gelegt, dass sie mit der Reichweite meiner Medikamente übereinstimmen.

Effektiv habe ich nur ca.jedes 4. Rezept etwas vom e-Rezept, wenn mal ausnahmsweise das neue Rezept ans Ende eines Quartals fällt.

Wichtige Zusatzinfo: Eigentlich könnte ich einfach eine Mail schreiben mit meinem Rezeptwunsch und einen halben Tag später zur Apotheke gehen, um mit meiner Versichertenkarte mein E-Rezept einzulösen.

Wie ich heute aber erfuhr, wird kein E-Rezept ausgestellt, wenn ich im aktuellen Quartal noch nicht meine Karte habe einlesen lassen.

Obendrauf kam, dass meine Praxis mir diese Info erst mitteilte, als ich persönlich vor Ort nach dem Verbleib des E-Rezeptes nachfragte. Aber das ist ja kein Fehler des e-Rezeptes, sondern des Prozesses in meiner Praxis. Ich hoffe, sie kriegen das noch besser hin.

Und ja, ich habe mitbekommen, dass gerade im Gespräch sei, diesen Quartalsturnus zu einem Jahresturnus zu verändern. Meine Unterstützung hat das.

Update: Am Samstag danach, also 2024-02-03, war ich gerade auf dem Rückweg nach Hause, als ich überlegte, noch eine Apotheke aufzusuchen, um endlich mein Rezept einzulösen. Aber nach der obigen Erfahrung würde ich ungerne in der Apotheke stehen ohne Rezept im System. Also dachte ich mir, dass es doch eine Möglichkeit geben müsste zu überprüfen, ob ich jetzt ein E-Rezept habe oder nicht.

Gibt es.

Die App erfordert aber eine Anmeldung bei der Krankenversicherung. Gut, dass ich erst vor zwei Monaten die App eingerichtet habe. Schlecht, dass es offensichtlich eine weitere Authentifizierung braucht, weil Rezepte als Daten mit erhöhten Sicherheitsbedarf gelten. Ich kann mich also per Personalausweis plus PIN oder per Gesundheitskarte plus PIN authentifizieren.

Es gehört natürlich nicht viel Fantasie dazu sich vorzustellen, dass ich weder die eine noch die andere PIN auf dem Rückweg nach Hause dabei habe. Bei der Gesundheitskarte ist mir nicht einmal klar, ob ich jemals eine PIN dafür zugesandt bekommen habe. Ich kann mich nur an einen Einmal-Code erinnern, mit dem ich mich initial bei der App anmelden konnte.

War also nix. Hatte eh keine Apotheke gefunden, die nach 14 Uhr noch auf hat und gut gelegen war.

Mir fiel dabei nur auf, dass beide Apps zwingend eine App-PIN festlegen wollten. Mir geht so was ja auf die Nerven, schließlich ist mein Handy bereits gesichert, vermutlich sicherer als die Apps es könnten.

Mastodon als Kommentarsystem für Nikola

Masin Wiedner — Sun, 14 Jan 2024 18:03:43 GMT

Ich bin sicher nicht der erste, der Mastodon als Kommentarsystem einsetzen wollte. Immerhin waren es Blogbeiträge zum Thema, weswegen ich das überhaupt aufgreifen wollte. Aber anscheinend gab es vor mir niemanden, der das für Nikola umgesetzt hat.

Nun hatte ich mir Nikola ja deswegen ausgesucht, weil es in Python geschrieben ist und ich Python als sehr lesbare und einsteigerfreundliche Sprache ansehe. Zu recht, wie ich nach dieser Arbeit erneut feststellen muss.

tl;dr: https://github.com/MasinAD/nikola-mastodoncomments/ ist das Ergebnis.

Für ausgiebige Erklärungen, was da passiert, verweise ich lieber auf meine Inspirationsquellen:

Grob formuliert, funktioniert das so:

Ich schreibe einen Blog-Eintrag.
Ich verlinke in einem Mastodon-Beitrag auf meinen Blog-Eintrag.
Ich notiere die ID meines Mastodon-Beitrags.
Ich füge dem Blog-Beitrag diese ID als zusätzliches Meta-Datum hinzu.

Das Plugin kann dann auf der Basis dieser ID die Antworten auf den Beitrag laden, sofern der Beitrag nicht in der Sichtbarkeit beschränkt ist. Die hohe Kunst ist dann sicher, aus der Antwort der Mastodon-Instanz hübsch aufbereitete Kommentar-Beiträge unterhalb des Blog-Eintrags zu machen. Um den Teil habe ich mich bislang nicht weiter gekümmert, aber nach dem, was ich gesehen habe, werde ich mit der bisherigen Arbeit sicher nicht glücklich sein.

Das Plugin lädt mittels API den Context des Beitrags. Dieser enthält das Attribut descendants mit Referenzen auf alle Antworten auf die ID. Das ist aber erstmal nur flach und erfordert die Auswertung der jeweiligen Attribute id und in_reply_to_id. Derzeit werden nur Antworten auf Kommentare ein Mal eingerückt, aber das geht bestimmt auch noch besser.

Zeitzonen-Spaß mit Nextcloud

Masin Wiedner — Tue, 19 Dec 2023 21:33:01 GMT

Ich habe meine heutige Neuerstellung meines Kontos bei meiner Nextcloud mal genutzt, die Einrichtung der Kalender auf meinen Androiden zu vervollständigen. Mittels "Google Integration" habe ich mein Google Drive sowie Kalender, Kontakte usw. zu Nextcloud synchronisiert.

Android beherrscht von Haus aus kein CalDAV, einen Kalenderstandard, aber es gibt DAVx, was (nicht nur) CalDAV synchronisiert und als Kalender-Anbieter auf dem Androiden auftritt. Zur Anzeige von CalDAV-Kalendern habe ich mir Etar installiert.

Jetzt fiel mir auf, dass zwei morgige Termine kollidierten. Aber auch nur bei Nextcloud. Nach kurzem Grübeln fiel auf, dass ein Termin ein wiederholender Termin ist, der eine Stunde früher als eigentlich eingestellt begann. Das sah schon so aus, als hätte es was mit dem Wechsel von Sommer- zu Winterzeit zu tun. Es stellte sich heraus: Entweder speichert Google generell alle Termine mit UTC als Zeitzone und interpretiert erst bei Anzeige den endgültigen Wert, oder die Google-Integration hat beim Abgleich Mist gebaut und die Zeitzone irgendwie auf UTC gesetzt, den Zeitstempel aber gelassen.

Ich habe zu wenig Ahnung von den beteiligten Komponenten, um tief ins Debugging einzusteigen. Aber ich konnte den Termin immerhin damit "reparieren", dass ich im Nextcloud-Kalender den ersten Termin suchte und dort bei den Uhrzeiten eine Zeitzone (Europe/Berlin) einstellte. Das hat erstmal nur bis Ende Oktober geholfen, bis zum Wechsel von Sommer- auf Winterzeit. Beim ersten, wieder abweichenden Termin habe ich das Prozedere wiederholt. Das hat anscheinend das Problem auch über den nächsten Sommerzeit-Wechsel hinweg gelöst.

Aus irgendeinem Grund waren die Termine auf einem der beiden Androiden dann aber um 7 Stunden verschoben. Ich würde meinen, Nextcloud war dieses Mal unschuldig. Es hat aber ein Weilchen gedauert, bis ich in den allgemeinen Einstellungen von Etar die "Heimatzeitzone" entdeckte, die merkwürdigerweise auf "Chinesische Normalzeit GMT+8" oder so eingestellt war. Nachdem ich das auf "Europäische Normalzeit GMT+1" zurückgestellt hatte, war auch im Kalender wieder alles okay.

Update 2023-12-19 23:58:00

Links gesetzt. Die beteiligten Android-Apps stammen alle aus dem F-Droid-Repository. Der Plan ist es, sukzessive die Abhängigkeit von Google zu reduzieren.

Umzug auf Nikola

Masin Wiedner — Mon, 21 Aug 2023 22:08:52 GMT

Als die Familie im Urlaub war und mich verantwortungsloserweise allein zuhause gelassen hat, habe ich die sturmfreie Bude genutzt und angefangen, den Familienblog, der de facto eher mein Blog ist, von Serendipity auf einen Static-Site-Generator umzustellen. Ich habe mich für Nikola entschieden. Die Geschwindigkeit vorher war auch nicht schlecht, aber schneller als jetzt geht es halt auch nicht.

Der Workflow ist anders, wobei ich sagen muss, dass es sicher daran liegt, dass ich die Einträge bislang nur konvertiert habe:

Ich erstelle eine Textdatei, …
… schreibe in die ersten paar Zeilen ein paar Metadaten …
… und in den Rest dann den Artikelinhalt.

Um einen Eindruck von der Formatierung zu bekommen, verwende ich lokal ReText, was sowohl RestructuredText wie auch Markdown versteht. Bin ich am Ende zufrieden, wird die Datei gespeichert und mittels nikola build die Änderungen seit dem letzten Build neu erzeugt. Die erstellten statischen Seiten muss ich dann auf den Webserver schieben. Perspektivisch überlege ich, ob nicht einfach ein Git-Repository nutze und da dann eine CI/CD-Pipeline ranbastele. Weiß aber gerade nicht, ob das aufwändiger wird.