Springe zum Hauptinhalt

Kontrollverlust

Ich schätze, Kontrolle kann man nur verlieren, wenn man vorher glaubte, sie besessen zu haben.

Ein einfaches Resümee, das Michael Seemann hier zieht. Ich sehe in diesem kurzen und knappen Befund aber ein Phänomen, das auch andere Bereiche umfasst, als mspr0 hier umreißt.

Ich frage mich bei solchen Aussagen ja immer: Habe ich Kontrolle über mein Leben? Über mein Umfeld? Habe ich die Kontrolle verloren? Ich finde die Fragen spannend, weil die aktuellen politischen Entwicklungen in Deutschland oft mit Aussagen einhergehen, dass Menschen empfänden, die Kontrolle über ihr Leben verloren zu haben. Gehe ich in mich, muss ich die Fragen mit "nein", "nein" und "hatte ich nie" beantworten.

Das ist natürlich sehr verallgemeinert. Es gibt Bereiche in meinem Leben, über die ich die Kontrolle habe, über andere habe ich sie nicht. In wiederum anderen Bereichen habe ich gute Chancen, Kontrolle zu erlangen, wenn ich mich engagiere.

Politisch und wirtschaftlich sah ich mich jedoch nie in der Position, Kontrolle zu haben. Ich empfand das auch nie als schlimm, denn Menschen sind soziale Tiere: Wir können uns in Gemeinschaften einbringen, aber keine Kontrolle über sie ausüben. In der Wirtschaft gibt es das Phänomen, dass einzelne Individuen ein Maß an Kontrolle erlangen können, das sicher den Eindruck erwecken kann, tatsächlich Kontrolle zu haben. Und es gibt den Mythos, dass, wer sich nur genug anstrenge, seines eigenen Lebens Herr werden können.

Als Mann mag ich mich da weit aus dem Fenster lehnen, ich wag es aber trotzdem. Ich denke, gerade beim letzten Punkt gibt es eine stark gegenderte Schieflage, denn Kontrolle zu haben gehört zur männlichen Rollenvorstellung, oder scheint es zumindest. Frauen lernen sehr früh, sich in Gewässern zu bewegen und bewegen zu müssen, wo sie keine Kontrolle ausüben können. Vielleicht hat das auch Auswirkungen auf die Berufswahl; ich will den Gedanken später nochmal aufgreifen.

Männer ziehen einen großen Teil ihres Selbstverständnisses daraus, von sich behaupten zu können, sie hätten die Kontrolle – über sich, über ihr Leben, über ihr Umfeld. Zu akzeptieren, dass andere über das eigene Leben entscheiden könnten, wird als unmännlich und sogar emaskulierend empfunden. In vielerlei Hinsicht bedeutet "Kontrolle zu haben", bekannte Umstände navigieren zu können. Unter verändernden Umständen jedoch taugen die eingeübten Navigationsfähigkeiten nicht mehr, es folgt das Gefühl des Kontrollverlusts und im Falle von konventionell männlich denkenden und fühlenden Männern wohl auch das Gefühl eines Angriffs auf die eigene Männlichkeit.

Frauen haben sich, wie ich oben erwähnt habe, früh damit arrangiert, weniger Kontrolle über ihr Umfeld zu haben, und orientieren sich eher im Rahmen des Möglichen der jeweiligen Situation. Frauen definieren ihre Geschlechtsperformance nicht in dem Umfang wie Männer darüber, Kontrolle über ihr Leben zu haben.

Jetzt gibt es eine Partei des Kampfes gegen den empfundenen Kontrollverlust: Es ist die Alternative für Deutschland, die AfD. Die AfD ist das Sammelbecken all derer, die das Gefühl des Kontrollverlustes haben. Die Welt verändert sich, und die AfD macht das Versprechen, die Welt wieder auf den gewohnten Pfad zurückführen, eine gefühlte alte Ordnung wiederherstellen zu können.

Ich bin kein Politwissenschaftler, meine Aussage ist kein Absolutum, sondern nur meine Sichtweise, der Versuch, Sinn zu erzeugen aus dem, was ich sehe.

Die AfD ist natürlich mehr als nur das. Sie ist, was sie vorgibt zu sein, sie ist eine Projektionsfläche für Mitglieder und für Wähler*innen, für Gegner*innen und Beobachter*innen, und somit ist sie auch das, was auf sie projiziert wird.

Aber "Kontrollverlust" ist auch ein Schlagwort, das aus den Reihen von AfD und ihren Sympathisant*innen zu hören ist. Die Flüchtlinge ab 2015, die Alternativlosigkeit in den Merkeljahren, die Klimakrise, die Pandemie – es gibt vieles, was instrumentalisiert werden kann, um einen Kontrollverlust herbeizureden.

Es gibt einen Gendergap bei den Unterstützer*innen der AfD. Es gibt sie auch bei den Wähler*innen der Republikaner. Es gibt ihn in der Parteipräferenz bei den Erstwähler*innen. Jungen und Männer neigen viel stärker dazu, Parteien zu wählen, die die Geschichte von der Kontrolle über das eigene Leben propagieren oder auch den Kontrollverlust beklagen. Die Republikaner fordern die Mauer an der Grenze nach Mexiko, und sie werfen ihren politischen Gegnern immer wieder vor, das Land nicht im Griff zu haben. Law & Order als Form von Kontrolle spricht generell eher Männer an als Frauen.

Kontrolle ist ein Weg, Sicherheit zu erlangen. Die beiden Begriffe sind nicht synonym, das eine folgt nicht aus dem anderen, sie bedingen sich vielleicht nicht einmal gegenseitig, aber sie sind assoziativ dicht beisammen.

Veränderungen verunsichern. Unsicherheit deutet an, keine Kontrolle zu haben.

Wer auch Kontrollverlust verspürt, wer auch die wählt, die Gewohntes zu konservieren versprechen, sind ältere Menschen. Es heißt, man werde konservativer, je älter man wird. Alter bedingt, im Laufe des Lebens mehr Veränderungen in der eigenen Lebenszeit angehäuft zu haben. Der Schock der Veränderungen ist natürlich umso größer, je länger man sein Leben leben konnte, ohne bewusst die Veränderungen um einen herum wahrnehmen zu müssen. Wer ein Leben von 60 Jahren führen konnte, in dem Homosexualität nicht vorzukommen schien, kriegt dann die Veränderungen von 40 bis 50 Jahren mit einem Schlag serviert.

Ich kann mir vorstellen, dass das ein sehr privilegiertes Leben war.

Wer 40 Jahre im Kohleberg- oder -tagebau geschuftet hat, um dann erst lernen zu müssen, dass die eigene Arbeit Anteil am Klimawandel trägt, kann davon auch komplett überfordert sein.

Wenn die Opfer unseres Wohlstandes vor der Tür stehen, und wir uns der Wahrheit stellen müssen, dass wir nicht nur geschaffen, sondern auch ausgebeutet haben, dann sind auch das Erkenntnisse von Jahrzehnten auf wenige Augenblicke komprimiert.

Die Augen vor Veränderungen verschließen zu können, ist ein Privileg.

Es ist wohl nur zu verständlich, wenn sich Menschen um Sicherheit in ihrem Leben bemühen. Und Kontrolle über das Umfeld auszuüben, ist eine Art, diese Sicherheit erlangen zu wollen. Für Frauen sind Männer ein Quell der Unsicherheit, männlich dominierte Arbeitsumfelder ein beständiger Kontrollverlust, der sich leichter in weiblich dominierten Arbeitsumfeldern bewältigen lässt. Safe spaces, von rechter, konservativer und männlicher Seite gerne verspottete Bereiche von lesbischen, schwulen, bisexuellen, trans, queeren und anderen Menschen, um Sicherheit durch Kontrolle des Umfeldes zu erzeugen. Auch People of Color haben sich ihre safe spaces errichtet, um nicht der Unsicherheit durch Weiße Menschen ausgesetzt zu werden.

Für viele Menschen ist Unsicherheit durch Unkontrolle Alltag. Und diejenigen, die den Kontrollverlust am lautesten beklagen, sind für diese Menschen nur allzuoft in der Vergangenheit der Grund für die Unsicherheit.

Ich stimme mspr0 zu. Kontrolle kann man nur verlieren, wenn man vorher glaubte, sie besessen zu haben. Ich möchte Kontrolle aber auch als Selbstlüge, als Illusion betrachten, zumindest für das Gros der Menschen. Unter großem Einsatz von Ressourcen lässt sich vielleicht individuelle Kontrolle erzeugen, aber ich wage zu behaupten, dass das für die meisten Menschen keine realistische Perspektive ist.

Ich persönlich neige dazu, die Zustände der Vergangenheit nicht zu idealisieren, und flexibel und spontan auf veränderte Umstände zu reagieren. Für Segelmetaphern bin ich im Thema nicht tief genug drin, aber Stürmen trotzt man wohl nicht, indem man sich ihnen entgegenstemmt.

Steam Deck, SSD-Upgrade

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.

Mein Steam Deck von vorne mit der Galaxy-Skin

Steam Deck Front

Mein Steam Deck von hinten mit der Galaxy-Skin

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

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?

Strange Behaviour in Container Namespace

Anmerkung: Dieser Beitrag ist zusammengestellt aus mehreren Posts im Fediverse, wo ich gerade bei technischen Beiträgen zu englisch neige in der Hoffnung, dass jemand drauf reagiert. 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.


I am, by no means, a good C programmer or a good programmer at all. But looking at the #dnsmasq source code causes some severe headaches. Indentation is wildly mixed between tabstops, 8 spaces and 2 spaces. Functions have no meaningful documentation … has anybody some resources to make sense of this code? I'm especially interested in iface_check (network.c:112) as dnsmasq complains about my interface not having an address (dhcp.c:295).

For the moment, I'm tempted to just switch over to Kea + Bind. Or try to get systemd-networkd + systemd-resolved to do what I want.

Background: I'm migrating my NAS to a new NAS (NAS1 → NAS2). On my NAS1 I have a systemd-nspawn lan-basics which provides some LAN basics like DNS and DHCP. My NAS1 only has 1 physical interface so I created a bridge and added it to the nspawn. That worked reasonably well. My NAS2 has 4 physical ports and I wanted to dedicate 1 port for the nspawn. I did not try yet to replicate the complete NAS1 interface config on NAS2 to rule out some other sources for my problems.

On NAS1 I added all nspawns to the bridge interface. On NAS2 my plan was to only expose the nspawns that are required to be exposed. Everything else should be reverse proxied using nginx on the lan-basics nspawn. So, lan-basics requires at least two interfaces: the physical interface and a veth connected to the veth zone on NAS2. The other nspawns only get veth interfaces bound to that zone.

The NAS2 does DHCP using systemd-networkd on the zone interface, vz-zone. lan-basics should provide DNS and DHCP on the physical interface but itself use LLMNR on the veth interface to find the neighbouring nspawns.

At the moment, I think I'll just drop this requirement and use a dedicated nspawn for nginx. But then along came the message "DHCP packet received on enp6s0 which has no address" which is caused by dnsmasq and I can't find out what's wrong.

I could imagine it has something to do with the interface being moved into a different namespace, though. Maybe there's a difference in a veth bound to bridge and a physical interface in a different namespace, even if veth and physical interface both were in the same namespace.


Okay, I did replicate the config but it's still "DHCP packet received on host0 which has no address".

The last difference is the version of dnsmasq: 2.85 vs 2.89. I'll move the nspawn to NAS1 and try it there.

I must emphasize that I really appreciate the networkctl command. Prior to that I always issued systemctl restart systemd-networkd.service and still wasn't sure if it really applies my changes. networkctl reload OTOH seems to always does.

And then there's netplan. The people from Openmediavault, as much as I appreciate their work, decided to use netplan for network management. I just managed to terminate my ssh connections by netplan apply.

Of course, that's just a coincidence as my DHCP server wasn't running and the interfaces were set to DHCP. 😄

Well, I cannot tell for sure why, but the lan-basics nspawn from NAS2 doesn't work on NAS1, too. Because I already wasted^Wlearned so much I'll just copy the old lan-basics to NAS2 and see if it works there as I intended. Actually, I feel bad not using btrfs send|receive for that but it's just too big a hassle to ro-snapshot the subvolumes, send/receive them and the set them rw again. I should suggest automating these steps.

Result 1: The lan-basics1 nspawn bound to a bridge interface works.

Result 2: When providing exclusive access to enp6s0 the nspawn's dnsmasq starts showing "DHCP packet received on enp6s0 which has no address".

I don't know what's happening here but I'd say it's a bug somewhere, either in systemd-nspawn or in dnsmasq.

After a long chat with the nice people of #systemd IRC channel (nice to have it hashtagged if I mention the channel) I conclude that the bug is with dnsmasq. There's no reason it shouldn't work.


I then went on to file a bug report:

I finally found some time for further investigations. Here are my observations.

NAS1

old NAS with systemd-nspawn lan-basics

NAS2

new NAS with systemd-nspawn lan-basics

lan-basics1

NAS1's lan-basics on NAS2

lan-basics2

NAS2's lan-basics on NAS1

OS NAS1

Debian 11

OS NAS2

Debian 12

OS lan-basics at NAS1

Debian 11

OS lan-basics at NAS2

Debian 12

lan-basics at NAS1 is configured to use bridge br0 which enslaved the physical interface enp1s0.

lan-basics at NAS2 started with 1 of 4 interfaces moved into the systemd-nspawn, enp6s0. I removed any additional interfaces of my prior setup as I wanted to reduce the moving parts.

Leaving aside dnsmasq's configuration that worked on lan-basics at NAS1, I made the following attempts:

  1. I copied lan-basics at NAS2 to lan-basics2 at NAS1. As NAS1 only has one interface I added lan-basics2 to the same br0 as lan-basics at NAS1. The result was the same as on NAS2: "DHCP packet received on host0 which has no address" (the veth interface in this configuration is named host0 in the container).

  2. I replicated the network configuration from NAS1: I created a bridge interface br0, enslaved enp6s0 and configured lan-basics at NAS2 to use this bridge interface. Still the same symptoms.

  3. I copied lan-basics at NAS1 to lan-basics1 at NAS2. There I first tried using the same initial config as lan-basics at NAS2 with enp6s0, but lan-basics1 now oddly showed the same symptoms.

  4. I reconfigured the network to enslave enp6s0 under br0 and lan-basics1 to use this bridge interface. It works.

For the moment I stick to setup 4 but there's apparently something wrong with how dnsmasq treats namespaced interfaces. I can switch around setups 3 and 4, always with the same result of dnsmasq complaining about receiving DHCP packets on the interface where it doesn't know its address. Yes, I made sure that dnsmasq is started after the interface got its configuration (stopping dnsmasq, checking the address of the interface, starting dnsmasq).

I haven't tried yet the other network options of systemd-nspawn, e.g. IPVLAN, MACVLAN, VETH with port forwarding etc. Giving a systemd-nspawn container a network interface with exclusive access should be the gold standard of all possible network configurations.

FWIW, the versions of the involved dnsmasq binaries are 2.85 for Debian 11 and 2.89 for Debian 12.

I believe this to be a bug in dnsmasq. I'd gladly help to debug it but I can't do it myself. AFAICT the problem seems to be in iface_check in network.c but I don't know where it goes wrong.

Erste Erfahrungen mit dem E-Rezept

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.

Ü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

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:

  1. Ich schreibe einen Blog-Eintrag.

  2. Ich verlinke in einem Mastodon-Beitrag auf meinen Blog-Eintrag.

  3. Ich notiere die ID meines Mastodon-Beitrags.

  4. 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

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

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.

Erste Schritte mit Flatpak

Flatpak logo

Ich habe die letzten Tage Spaß mit Flatpak-Paketierung gehabt. Meine Mädels wollten Dungeondraft haben, was für Linux wahlweise als .deb oder als .tar.gz angeboten wird. Aber ich habe ihre Rechner ja mit Silverblue aufgesetzt, und dort sind Flatpaks First-Class-Citizens. Klar, die tar-Balls hätten auch irgendwie funktioniert, aber warum nicht das Nützliche mit dem Lehrreichen verbinden? 😀

Das Paketieren hat super funktioniert. Ich hatte vor einiger Zeit mal mit Vicuna begonnen und den Flow jetzt ausgenutzt, Vicuna, Pattypan, Commonist, OpenRefine und Freemind flatpaketieren zu wollen, die bei WMDE Teil der Installation sind. Meine Recherche zu Freemind zeigte, dass die Software seit einigen Jahren schon nicht mehr weiterentwickelt wird. Ich fand dann Freeplane als Ergebnis meiner Recherche zu Mindmapping-Werkzeugen unter Linux, die noch weiterentwickelt werden. Und das gibt es auch schon als Flatpak, also musste ich da nichts mehr machen. OpenRefine ist ein Sonderfall, weil es lokal einen Server startet und die Bedienung dann im Browser stattfindet. Da weiß ich noch nicht, wie ich damit umgehen will. Vergleichbares kenne ich nur von Syncthing, aber das gibt es auch nicht "pur" als Flatpak, sondern nur mit dem einen oder andern Tray-Indicator. Aber Vicuna, Pattypan und Commonist habe ich erfolgreich paketiert gekriegt, im Falle von Vicuna sogar besser als lokal installiert, weil ich dem Flatpak ohne Probleme die passende JVM konfigurieren kann (alles über OpenJDK8 macht irgendwie Probleme mit der Konfigurationsdatei).

Der nächste Schritt wird sein, ein Repository aufzusetzen. Momentan habe ich ein lokales Repository.

Auflistung der Flatpaks im lokalen Repository

Das ist nur begrenzt nützlich. Die Flatpaks für meine Kinder will ich lokal bei mir verteilen, die Flatpaks für WMDE sollten für die damit bespielten Rechner erreichbar sein. Ich muss mir da noch was mit GPG-Signaturen und so anlesen und wie ich das dann tatsächlich verteilen soll. Ein pacman-Repository war ja recht simpel, aber ich habe noch keine Ahnung, wie das mit Flatpaks läuft.

Natürlich könnte ich die WMDE-Flatpaks auch bei Flathub einreichen, aber einer der Vorteile von Flatpaks gegenüber Snap ist ja eben, dass man das dezentral aufsetzen kann und keine zentrale Autorität braucht.

Und Dungeondraft und Wonderdraft sind kommerzielle Software, die ich nicht einfach irgendwo herunterladen lassen kann. Für die Verwendung in der Familie finde ich das noch fair, was ich mache, auch wenn ich mich rechtlich sicher in einer Grauzone bewegen sollte. Wenn Megasploot drauf bestehen sollten, kaufe ich eben zwei weitere Lizenzen dafür. Für eine Verwendung in der Familie sehe ich da aber nicht akut Handlungsbedarf.

Spotifys Familientarif

Es kam jetzt schon mehrmals vor, dass ich auf dem Heimweg Musik über Spotify hörte und plötzlich die Musik ausging. Ich konnte sie zwar wieder starten, aber kurz danach war sie wieder weg.

Zuhause hat $Familie nämlich Spotify über Google Home gestartet.

Jetzt dachte ich mir, so viel mehr kostet Spotify Premium Family auch nicht, da gönn ich mir das mal, und jede*r kriegt eigene Playlists und Verläufe …

Aber, ich habe die Rechnung ohne Spotify gemacht. Spotify bietet eine App an, Spotify Kids. Die Rezensionen ließen nichts Gutes ahnen, also dachte ich mir, ich erstelle einen normalen Account für $Kind1. Tja, Spotify verlangt ein Geburtsdatum. Gebe ich das korrekte Datum an, verweigert Spotify den Account mit Verweis darauf, dass man zu jung sei für Spotify.

Okay, also probiere ich doch erstmal die Kids-App. Melde mich dort mit meinem Konto an und erstelle ein Kids-Konto. Dann die Ernüchterung: Ich kann der App nur sagen, sie soll sich per Bluetooth mit irgendwas verbinden. Keine Auswahl der Abspielgeräte. Aber es soll ja eben die Musik über Google Home abgespielt werden!

Najut, denke ich mir, Spotify bietet Kids-Konten für 0-6 Jahre und für 5-12 Jahre an. Dann mache ich sie eben 3 Jahre älter und erstelle ein normales Konto … aber Pustekuchen! Auch dann gilt sie noch als zu jung.

Also suche ich nach dem Mindestalter für Spotify und finde: »Um die Spotify-Dienste nach diesen Allgemeinen Nutzungsbedingungen nutzen und auf Inhalte zugreifen zu können, (1) müssen Sie 18 Jahre alt oder älter sein, oder 16 Jahre alt oder älter sein und das Einverständnis Ihrer Eltern oder Ihres Vormunds zu der Vereinbarung besitzen,[…]«

Es gibt also für Kinder von 13 bis 16 Jahren keine Möglichkeit, Spotify zu nutzen, da sie zu jung für ein Konto und zu alt für ein Kids-Konto sind. Das sie selbstverständlich nutzen könnten, aber erklärt mal einem Teenager, dass sie ein Kinderkonto nutzen sollen. Zumal es gegenüber dem regulären Spotify kuratiert, limitiert und technisch beschnitten ist. Jedenfalls motivieren mich diese Einschränkungen nicht, mehr Geld für den Familientarif zu zahlen.

Grundsätzlich frage ich mich, welchen Sinn der Familientarif überhaupt hat, wenn die Hauptnutzerïnnen im Alter von 12 bis 16 Jahren den Dienst nicht nutzen können, wie sie wollen. Und Familienmitglieder über 18 Jahre am selben Wohnort sind eine verschwindend kleine Gruppe. Viele Kinder können es gar nicht erwarten auszuziehen, selbst wenn ich meinen Kindern anbiete, dass sie bis zum Ende ihres Studiums bei uns wohnen können, was wohl so mit 24 Jahren sein dürfte.