Damit Grub den letzten Kernel startet, der im Grub Menü gewählt wurde muss in
/etc/default/grub
folgendes eingetragen, bzw. angepasst werden
GRUB_SAVEDEFAULT=true
GRUB_DEFAULT=saved
Dazu noch ein update-grub2 und reboot. Dann den gewünschten Kernel im Menü wählen. Danach sollte dieser dann default bei reboots genommen werden.
So entfernt man eine „auffällige“ IP bei nextcloud:
sudo -u www-data php /pfadzumdocroot/occ security:bruteforce:reset 123.123.123.123
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.
Bewegt sich der Mauszeiger fröhlich von alleine über den Bildschirm, dann hilft vielleicht ein:
rmmod psmouse
modprobe psmouse
Mir hat es beim X250 unter Ubuntu 22.04 jedenfalls geholfen (manchmal muss man es auch zweimal ausführen).
Beides in einer Zeile mit && als Bedingung, hat komischerweise nicht funktioniert.
Falls die Binlogs zu viel Platz wegnehmen, kann man mit Hilfe des MySQL Befehls
PURGE BINARY LOGS TO ‚mysql-bin.01234‘;
alte Binlogs löschen. Dabei werden alle Binlogs bis zum angegebenen gelöscht (das bleibt also erhalten). Sauberer als die Logs einfach im Logordner zu löschen, da so auch der Dienst vom Löschen erfährt.
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.
Man kann natürlich das Addon Motioneye verwenden und dabei den rtsp Stream via URL (z. B. rtsp://192.168.178.123:8554/Streaming/Channels/101) abgreifen. Man kann aber auch die ONVIF Erweiterung von Home Assistant nutzen. Wichtig dabei ist den ONVIF Port 8000 anzugeben und nicht 8554. Die Cams, die ich nutze sehen in etwa so aus und waren für wenig Geld zu haben:
Unter Debian 11 beim Starten von calibreweb:
Fehler: ImportError: cannot import name ‚escape‘ from ‚jinja2‘
Lösung: pip install Jinja2==3.0.3
Link: https://www.datasciencelearner.com/importerror-cannot-import-name-escape-from-jinja2-solved/
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.
Falls Thunderbird sich weigert via imap mails von google abzurufen, sollte man einfach mal in der Konteneinstellung folgendes tun:
Keine Ahnung was es da noch für sinnvolle Lösungen gibt um auf das „-“ bei su unter Debian zu verzichten und trotzdem alle Pfade zu haben. Ein paar nenne ich mal:
.bashrc von root
export PATH=$PATH:/sbin export PATH=$PATH:/usr/sbin export PATH=$PATH:/usr/local/sbin
/etc/login.defs
ALWAYS_SET_PATH yes
.bashrc vom Benutzer
alias su='su -'
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.
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.
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.
Damit ich bei wekan mails verschicken kann musste ich im admin Panel folgendes eintragen
SMTP Server:meinmailer.xyz:587/?ignoreTLS=false&tls={rejectUnauthorized:true}&secure=true
Einfach nur den Hostname eintragen führte zu einer Fehlermeldung. Die Einträge in der docker-compose.yml Datei zu mail habe ich default belassen.
Darauf gekommen bin ich via https://github.com/wekan/wekan/wiki/Troubleshooting-Mail