Noble

Ich sammele hier mal, was mir beim Upgrade auf von Ubuntu 22.04 LTS auf Ubuntu 24.04 LTS so auf die Füße fiel. Die Liste wird ergänzt, bis ich meinen letzten Server auf der aktuellen LTS habe.

Upgrade bleibt stehen

Ursächlich hierfür war needrestart. Ein

ps aux | grep dpkg

zeigte

root       17007  0.0  0.3  12252  7204 pts/2    Ss+  09:37   0:00 /usr/bin/dpkg --force-overwrite --status-fd 107 --configure --pending 
root       17008  0.0  0.0   2800  1056 pts/2    S+   09:37   0:00 sh -c -- (test -x /usr/lib/needrestart/dpkg-status && /usr/lib/needrestart/dpkg-status || cat > /dev/null) 
root       17009  0.0  0.0   2800   104 pts/2    S+   09:37   0:00 sh -c -- (test -x /usr/lib/needrestart/dpkg-status && /usr/lib/needrestart/dpkg-status || cat > /dev/null) 
root       17010  0.0  0.0   2800  1116 pts/2    S+   09:37   0:00 /bin/sh /usr/lib/needrestart/dpkg-status 
root       18937  0.0  0.1   6544  2280 pts/1    S+   09:48   0:00 grep --color=auto dpkg

Vermutlich lauerte needrestart auf eine Eingabe, die aber in der Shell mit do-release-upgrade nie erschien. Weiter ging es erst nach einem

kill 17010 # also den Prozess hier: /bin/sh /usr/lib/needrestart/dpkg-status

Also: Von Anfang an zwei Shells auf einem Server offen haben, der gerade do-relase-upgrade laufen hat.

Wireguard & Namensauflösung

Unser Wireguard Server hat einen lokalen unbound für die Namensauflösung – und der wollte nach dem Upgrade nicht mehr starten. Ursächlich hierfür war, dass systemd-resolved den entsprechenden Port bereits belegt hatte – und das, obwohl der Dienst davor eigentlich disabled war. Vermutlich hatte ich das mask vergessen? Wie auch immer: die Konfiguration von unbound für 24.04 ist hier beschrieben.

Seitenleistengedöhns

Nachdem ich gerade 10 Minuten brauchte, um eine aus Versehen in Libreoffice gelöste rechte Seitenleiste wieder anzudocken:

Wer den Desktop unter KDE über mehrere Monitore hinweg liegen hat, kann wohl so oft Strg Umschalten F10 drücken, wie er will – es passiert schlicht gar nix. Also darauf achten, dass

  1. nur noch ein Libreoffice Fenster offen ist (also alle Dialogfenster geschlossen sind)
  2. für den Andockvorgang das Hauptfenster von Libreoffce auf den Monitor legen, von dem aus es nicht „weiter nach rechts“ geht.

Und schwupp sitzt sie nach Strg Umschalten F10 wieder am rechten Rand, wo sie auch hingehört.

Fettwanne

Nachdem die Fettwanne für unseren Kontaktgrill verschwand … ein schneller Nachdruck derselben. OpenSCAD Datei dazu hat es hier:

https://codeberg.org/dowel/fettwanne

Dreamweaver Gefrickel

Falls das gerade auch jemandem so geht, dass der Dreamweaver unter XFCE, Cinnamon oder Gnome einige Felder bei der Konfiguration nicht vollständig anzeigt: viele Optionen aus den nicht angezeigten Feldern können in die user.reg direkt eingetragen werden.

Ein

sudo updatedb
locate user.reg

sollte den lokalen Pfad aufzeigen. Dann ist ein wenig Rumprobieren und auch Raten angesagt. Im konkreten Fall verschluckte die Dreamweaver-GUI das Feld Passiven FTP verwenden und alle folgenden Felder:

"PASV FTP"=dword:00000001

Die 00000001 setzt den Haken; lauter Nullen zeigen an, dass der Haken nicht gesetzt ist.

Schaut man mit einem KDE drauf, ist zu sehen, dass dieser Umweg wirkte:
Screenshot aus Dreamweaver Site-Definition, Karteikarte Erweitert, Rubrik Remote-Informationen.

Nicht schön so – aber es funktioniert.

Besuch

Endlich ist das Kreuz wieder in einem Zustand, dass ich mir Hoffnungen auf Löcher machen könnte. Gestern also nach „meinem Loch“ gesucht und nach vielen Schrammen auch gefunden. Der Wald sieht verheerend aus: viel Totholz, lauter umgestürzte Bäume.

Vollgummi

Vollgumireifen

Der Velix E-Kick 20 hatte hier Dauerplatten – also musste ein Vollgummireifen her. Unsicherheit bestand, welcher denn passen würde – und das tat der hier [ebay.de]:

Monuary E Scooter Reifen 8 1/2 X2, Vollgummireifen 50/75-6.1, 8,5 Zoll

Die Montage überließen wir unserem Autoschraub, der ganz hübsch fluchte. Gut in der Pfanne warm machen half aber. Das Fahrverhalten hat sich erst mal nicht groß geändert; ein klein wenig härter vielleicht.

LDAPs via HAProxy

Situation: LDAPs Verbindungen sollen via pfSense und dem dortigen HAProxy an den LD-Server ge-proxied werden, um mehr Kontrolle über die zulässigen LDAP-Hosts zu haben als mit plain LD-Server.

Problem: Obwohl die LDAPs Verbindung vom Client via pfSense und HAProxy zum lokalen LDAP-Server klappt, geht keine Antwort vom LDAP-Server nach Außen.

Lösung: TLS1.3 verbieten – mit TLS1.2 funktioniert es. Das Feld im Frontend nennt sich „Advanced ssl options“ und braucht den folgenden Eintrag:

no-tlsv13

Dann ist es im übrigen auch auf der pfSense einstellbar, dass es Wurst sein soll, dass das LDAP-Zertifikat auf dem LD-Server self signed ist. Hauptsache das Zertifikat in Richtung Internet ist sauber (z.B. Let’sEncrypt-Certificate mit ACME Plugin für pfSense), damit sich z.B. ein Moodle verbinden kann.

Tools zum Debuggen: tcpdump, Apache directory Studio

OpenVPN und OpenSSL 3.x

Das Arch-Update von OpenSSL auf Version 3.x brachte mit sich, dass ich nicht mehr via OpenVPN auf meinen Server kam.

Fehlermeldungen waren ungefähr solche hier:

2022-11-09 08:23:40 OpenSSL: error:11800071:PKCS12 routines::mac verify failure
2022-11-09 08:23:40 OpenSSL: error:0308010C:digital envelope routines::unsupported
2022-11-09 08:23:40 Decoding PKCS12 failed. Probably wrong password or unsupported/legacy encryption
2022-11-09 08:23:40 Error: private key password verification failed
2022-11-09 08:23:40 Exiting due to fatal error

Die Lösung ist hier [1, 2] beschrieben. Am schnellsten (wenn auch nicht am saubersten) geht es via Anpassung der /etc/ssl/openssl.cnf

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1