XPS 9320 mit Ubuntu 22.04…

Ich schreibe dazu nochmal ein bisschen ausführlicher…irgendwann. Meiner Meinung nach ist das XPS 9320 mit Ubuntu 22.04 einfach nur Mist. Ich kann davon nur abraten. Da läuft einfach nichts vernünftig.

Falls es bei euch auch dauernd abstürzt und es sich verhält als hätte jemand im laufenden Betrieb die Festplatte ausgebaut, hilft vielleicht folgendes:

GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash nvme_core.default_ps_max_latency_us=6000″

in /etc/default/grub eintragen. Eventuell muss man den Wert sogar auf 0 setzen. Bisher kann ich nur sagen, dass es keine weiteren Abstürze gab. Ich nutze das OEM Linux von Dell…sollte man wohl auch da default sonst die Kamera nicht funktioniert (oder hier lesen https://www.dell.com/support/kbdoc/de-de/000203830/webcam-wird-auf-xps-13-plus-9320-laptops-mit-ubuntu-22-04-nicht-erkannt).

So unzufrieden war ich glaube ich noch nie mit einem Notebook. Dagegen ist mein altes Thinkpad x250 ein Traum.

Update von Raspbian von Debian 10 zu 11(bullseye)

Anleitungen gibt es dazu genug. Trotzdem nochmal ein wichtiger Hinweis, den ich leider übersehen habe.

Nach dem Reboot am Ende des Updates war mein Raspberry nicht mehr via ssh erreichbar (daher muss man im Keller nach diesen komischen micro hdmi Kabel suchen, was man natürlich seit dem letzten Umzug nicht gebraucht hat und es daher immer noch in irgendeiner Technik Kiste auf seinen Einsatz wartet).

Geholfen hat eine Anpassung von  /etc/systemd/system/dhcpcd.service.d/wait.conf:
[Service]
ExecStart=
ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w
Zu:
[Service]
ExecStart=
ExecStart=/usr/sbin/dhcpcd -q -w

Steht natürlich auch hier im Kommentar, man muss es halt nur lesen. Ansonsten musste ich noch

x-systemd.device-timeout=15

aus der /etc/fstab entfernen, da ansonsten die USB Devices nicht automatisch gemountet wurden. Der Rest (z. B. pihole) lief ohne Probleme nach dem Update.

 

 

Home Assistant: Fehler beim Mailversand via smtp

Seit einiger Zeit funktionierte bei mir der Mailversand via smtp nicht mehr unter Home Assistant. Der Dienst wurde bei der Automatisierung nicht mehr als Dienst aufgeführt. Infolgedessen kam es bei den Automatisierungen, bei denen der Dienst als Aktion hinterlegt war, zu Fehlermeldungen bzw. wurden diese nicht aufgeführt. Geholfen hat (erstaunlicherweise) ein „verify_ssl: false“ in der configuration.yaml im Block der smtp Konfiguration zu ergänzen. Danach wurde der Dienst wieder in der Liste angezeigt und Mails konnten wieder verschickt werden. Das SSL Zertifikat des genutzten Mailers ist aber valide. Scheint also ein Fehler von hassio zu sein.

Kurztipp: Debian 11 Update – procmail und maildir

Da ich nach langer Zeit auf eine größere VM bei netcup migriert bin, habe ich auch gleich einen Wechsel von Debian 10 zu Debian 11 und von mailbox zu maildir gemacht.

Der Umstieg lief eigentlich bisher ohne große Probleme. Nur bei Procmail zum sortieren der Mails muss man ein bisschen aufpassen.

Lauteten die Regeln für procmail mit mailbox vorher noch

:0      
* ^Subject.*SPAM.*
spam

lauten sie nun mit maildir

:0      
* ^Subject.*SPAM.*
.spam/

Irgendwie auch klar, muss man aber trotzdem auf dem Schirm haben.

Kurztipp: Pacemaker und Ubuntu

Da ich diverse Nodes in letzter Zeit geupdatet habe, teile ich meine Erkenntnis für die eine Person.

14.04 mit 16.04 ist nicht kompatibel. Die Nodes sehen sich nicht.

16.04 mit 18.04 ist kompatibel. Ressourcen können hin und her migriert werden.

Bei 18.04 muss man noch die crm shell „crmsh“ nachinstallieren. Ansonsten ist das Pacemaker Update aber problemlos.

nginx mit TLS 1.3 und der alert number 70

Da habe ich nun ein bisschen für gebraucht, bis TLS 1.3 endlich auf einer bestimmten Maschine lief. Ich nutze nginx als Reverse Proxy und terminiere dabei ssl dort. Es werden die Repositories von nginx genutzt. Aktuell ist dort zur Zeit Version 1.19.10 von nginx. Das System ist ein Ubuntu 18.04. Wollte ich nun für eine bestimmte Seite TLS 1.3 aktivieren, kam beim Test immer nur folgendes:

$ openssl s_client -connect dieseitemittls1_3.de:443 -tls1_3
CONNECTED(00000005)
140426905970496:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1528:SSL alert number 70

OpenSSL 1.1.1 wird genutzt und die Nginx Version kann auch TLS 1.3.

Funktioniert hat es letztendlich nachdem ich für die default site auch TLS 1.3 aktiviert habe. Wobei diese eigentlich nichts mit der anderen Seite zu tun haben sollte. Durch das aktivieren in der default site ist nun TLS 1.3 für alle Seiten aktiviert, auch wenn dort nur TLS 1.2 eingetragen ist.

Ein bisschen würde mich schon interessieren, ob das Verhalten auch auftritt, wenn man die Ubuntu Repositories für nginx nutzt.

Drauf gekommen bin ich via eines Beitrags bei askubuntu.