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
In der Regel ist es nicht gewollt auf Docker Containern manuell Veränderung vorzunehmen. Will/muss man das doch und hat das Debian 10 Image von dockerhub laufen, fehlt eventuell die bash-completion. Will man nun auch noch die „packet completion“ bei apt install tm[tab][tab] haben, muss man noch in der Datei
/etc/apt/apt.conf.d/docker-clean
Dir::Cache::pkgcache "";
Dir::Cache::srcpkgcache "";
auskommentenieren. Danach geht auch das…jedenfalls bei mir.
Will man bei der Nextcloud App ocDownloader (1.7.8) youtube-dl nutzen und bekommt ständig ein
„Die echte YouTube-Video-URL konnte nicht empfangen werden„
obwohl /usr/local/bin/youtube-dl vorhanden ist, hilft ein einfacher symlink:
ln -s /usr/local/bin/youtube-dl /usr/bin/
Erstaunlich, dass bestimmte Features wie „download from url“, nicht bei nextcloud integriert sind.
Ging erst nicht, dann habe ich in die /etc/sane.d/xerox_mfp.conf die IP eingetragen.
Samsung M267x 287x Series
usb 0x04e8 0x3461
tcp 192.168.178.123
Dann ging es.
Das ist eigentlich nicht besonders kompliziert, ich notier das trotzdem nochmal kurz.
https://forum.xda-developers.com/moto-x-play/development/rom-lineageos-17-1-t4080411
Dort findet man Lineage 17.1 unofficial. Als Google Apps hab ich die micro genommen. Das lief alles recht problemlos beim Update von Android 7 (Lineage 14.1) auf die Version lineage-17.1-20200527-UNOFFICIAL-lux.
Leider musste man zwangsweise beim Einrichten google voice match einrichten, da man sonst nicht weiterkam. Kann man aber natürlich später einfach wieder deaktivieren bzw. neu einrichten.
Bisher läuft anscheinend alles gut, meine Tochter hat sich jedenfalls noch nicht beschwert. Ach ja, es gibt kein root mehr via su addon.
Trotzdem immer vorher ein TWRP Backup machen und das am besten vor dem Update auf den Rechner kopieren.
Update: Man darf sich freuen: https://www.lineageoslog.com/17.1/lux. Damit gibt es hoffentlich bald das erste offizielle 17.1 lineageos build für das Moto X Play. Es wird empfohlen ein clean install zu machen.
Nach 6 Jahren mit OMV auf meinem kleinen NAS, trenne ich mich nun von OMV. Gründe gibt es eigentlich nicht sehr viele, aber mir reichen sie um auf ein Debian 10 zu wechseln.
Da gibt es sicherlich noch einige Kleinigkeiten, aber im wesentlichen sind die oben genannten Gründe ausschlaggebend. OMV ist gut, aber ich habe nur einen Bruchteil der Funktionen benötigt, zudem bietet mir ein 0815 Debian mehr Flexibilität und fühlt sich einfach besser an. Der Umstieg ging sehr schnell und lief problemlos, aber ich habe auch kein Raid, lvm oder sonstiges im Einsatz.
Beschränkt man den Zugriff auf eine Webressource auf bestimmte IPs und will einfach nur eine individuelle Fehlerseite anzeigen lassen, kann man eine einfache Rewrite Regel dafür nutzen:
RewriteCond %{REMOTE_ADDR} 1.2.3.4
RewriteRule .* CustomError.html
bzw. !1.2.3.4 falls man negieren will.