Zum Inhalt

Autor: Dennis Wilmsmann

Plesk und Let’s Encrypt: http-01 oder dns-01

Aufgrund von DNS Problemen beim Hoster dieser Domain konnte ich keine Let’s Encrypt Zerfifikate via Plesk ausstellen und verwenden. Übergangsweise habe ich dann ZeroSSL benutzt und mir manuell ein valides Zertifikat besorgt.

Da ich bisher bei der Domain in Plesk immer ein Wildcard Zertifikat genutzt hatte, war mir nicht bewusst, das auch in Plesk via http-01 Domains verifiziert werden können. Dafür sind dann keine DNS TXT Records (_acme-challenge.domain.tld) notwendig, sondern es muss ein zufälliges Token unter /.well-known/acme-challenge/ abgelegt werden. Macht Plesk auch alles automatisch.

Daher: Wenn ein Wildcard Zertifikat ausgestellt werden soll, geht das in Plesk nur via dns-01, d.h. es müssen DNS TXT Records erstellt werden. Wenn ein Zertifikat ohne Wildcard ausgestellt werden soll, läuft das über http-01.

Nachlassende Akkuleistung beim Gardena SILENO+

Seit einigen Wochen konnte ich bei meinem ca. 4,5 Jahren alten Gardena SILENO+ (R130Li) beobachten, dass dieser nur noch ca. 30 Minuten mäht, dann wieder 30 Minuten lädt, usw. Das ist nur noch die Hälfte der ursprünglichen Dauer (zu Beginn jeweils ca. 60 Minuten). Das hat mich erst mal weniger gestört, leider hat es der Mower auch regelmäßig nicht mehr bis zur Ladestation zurück geschafft und ist auf dem Heimweg stehengeblieben.

Die Infos, die der Mower zur Batterie anzeigte, waren allerdings unauffällig und normal, wie mir der Gardena Support bestätigt hat. Im Hauptmenü lange 0 drücken, dann Infos und Batterie.

Letztendlich hat nur der Austausch des Akkus (584 85 28-01) geholfen. Den gibts es für ca. 100€ direkt bei Gardena, oder auch günstiger bei Amazon oder eBay.

Einen größeren Akku zu kaufen, bringt aber wohl nichts. Damit wird nicht die Mähdauer erhöht. Der Mower geht wohl immer davon aus, 1600 mAh Kapazität zur Verfügung zu haben. Daher scheint es egal zu sein, ob der neue Akku 2,1 Ah Kapazität hat, oder 2,5 Ah oder noch mehr.

Automatische Docker Image Updates

Auf meinem kleinen Ubuntu Server zu Hause tummeln sich ca. 30 Docker Container. Bisher habe ich mich via Docker-Update-Image-Notififier (DIUN) über Updates benachrichtigen lassen, wenn es neue Version der genutzten Images gab. Das Update hab ich dann aber trotzdem noch selbst gemacht bzw. machen müssen. Die Benachrichtung via eMail ist ganz ansprechend und die ganze Geschichte lässt sich sich schön individuell konfigurieren, ja nachdem, wie man es braucht.

Hier mal das dazugehörige docker-compose.yml:

version: "3.5"
services:
  diun:
    container_name: diun
    image: crazymax/diun:latest
    volumes:
      - "./data:/data"
      - "./diun.yml:/diun.yml:ro"
      - "/var/run/docker.sock:/var/run/docker.sock"
    environment:
      - "TZ=Europe/Berlin"
      - "LOG_LEVEL=info"
      - "LOG_JSON=false"
    restart: unless-stopped

Und noch die diun.yml dazu:

watch:
  workers: 20
  schedule: "30 2 * * *"
  firstCheckNotif: true

providers:
  docker:
    watchByDefault: true
    
notif:
  mail:
    host: smtp.my-email-provider.de
    port: 465
    ssl: true
    insecureSkipVerify: true
    from: [email protected]
    to: [email protected]
    username: blablabla
    password: blablubb123

Die Benachrichtigung sieht dann in etwa so aus:

Soweit, so gut. Heute habe ich dann zufällig Watchtower entdeckt. Da sehen die Benachrichtigungen zwar nicht so schön aus, aber dafür können automatische Updates gemacht werden, wenn neue Versionen der Images vorliegen.

Auch hier wieder eine komplette docker-compose.yml, inkl. eMail Relay via Postfix:

version: "3.5"

services:
  watchtower:
    image: containrrr/watchtower:latest
    container_name: watchtower
    restart: unless-stopped
    depends_on: 
      - postfix
    environment:
      TZ: 'Europe/Berlin'
      WATCHTOWER_MONITOR_ONLY: 'false'
      WATCHTOWER_CLEANUP: 'true'
      WATCHTOWER_SCHEDULE: '0 15 5 * * *'
      WATCHTOWER_HTTP_API_METRICS: 'true'
      WATCHTOWER_HTTP_API_TOKEN: no5theit0dooqueih2ohjoo7ya6Tai7a
      WATCHTOWER_NOTIFICATIONS: email
      WATCHTOWER_NOTIFICATION_EMAIL_FROM: [email protected]
      WATCHTOWER_NOTIFICATION_EMAIL_TO: [email protected]
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER: postfix
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT: 25
      WATCHTOWER_NOTIFICATION_EMAIL_DELAY: 5
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 9180:8080
  postfix:
    image: juanluisbaptiste/postfix:latest
    container_name: postfix
    restart: unless-stopped
    environment:
      TZ: 'Europe/Berlin'
      SMTP_SERVER: smtp.my-email-provider.de
      SMTP_PORT: 25
      SMTP_USERNAME: blablabla
      SMTP_PASSWORD: blablubb123
      SERVER_HOSTNAME: my-dockerhost

Die bereitgestellten Metriken greift mein Prometheus ab:

  - job_name: 'watchtower'
    scrape_interval: 5s
    metrics_path: /v1/metrics
    bearer_token: no5theit0dooqueih2ohjoo7ya6Tai7a
    static_configs:
      - targets: ['192.168.1.130:9180']

Wenn bestimmt Images nicht aktualisiert werden sollen, was z.B. bei auf dem System selbst gebauten Images der Fall ist, kann das mit diesem Label verhindert werden:

version: '3.3'
services:
  my-app:
    ports:
      - '8080:8080'
    container_name: my-app
    image: 'my-app:latest'
    restart: unless-stopped
    volumes:
      - './log:/app/log'
    labels:
      - com.centurylinklabs.watchtower.enable=false

Pi-hole und DNS over HTTPS (DoH)

Out of the box kann Pi-hole bisher kein DoH, aber ein Docker Container eilt zur Hilfe: crazymax/cloudflared

Diesen kann man zusammen mit Pi-Hole starten und via TUNNEL_DNS_UPSTREAM einen oder mehrere DoH Server mitgeben. Pi-Hole bekommt dann den Container als DNS Server und nutzt dann (in-) direkt DoH.

version: "2.1"

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8000:80/tcp"
      - "8443:443/tcp"
    environment:
      TZ: Europe/Berlin
      WEBPASSWORD: zaewooQu0kaequaZ
      DNS1: 192.168.1.130#5053
      DNS2: 192.168.1.105#5053
      ServerIP: 192.168.1.105
      VIRTUAL_HOST: pihole.fritz.box
    volumes:
       - './etc-pihole/:/etc/pihole/'
       - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
    dns:
      - 127.0.0.1
      - 46.182.19.48
    restart: unless-stopped
    networks:
        - pihole_net
    depends_on:
        - cloudflared

  cloudflared:
    image: crazymax/cloudflared:latest
    container_name: cloudflared
    ports:
      - "5053:5053/udp"
      - "49312:49312/tcp"
    environment:
      TZ: "Europe/Berlin"
      TUNNEL_DNS_UPSTREAM: "https://anycast.uncensoreddns.org/dns-query,https://unicast.uncensoreddns.org/dns-query,https://dns.digitale-gesellschaft.ch/dns-query,https://dot.ffmuc.net/dns-query"
      TUNNEL_DNS_PORT: 5053
    restart: unless-stopped
    networks:
        - pihole_net

networks:
  pihole_net:
    enable_ipv6: true
    driver: bridge
    driver_opts:
      com.docker.network.enable_ipv6: "true"
    ipam:
      driver: default
      config:
      - subnet: fc00::/64

Bei mir sind das dann 192.168.1.130#5053 und 192.168.1.105#5053. Redundanz muss sein. ? Und via Port 49312 gibt es noch ein paar Metriken im Prometheus Format.

DoT (DNS over TLS) wäre auch eine Alternative, habe ich bisher aber nicht ausprobiert. Vielleicht bekommt Pi-hole ja auch irgendwann einmal native DoH oder DoT Unterstützung, dann sind Bastellösungen wie diese überflüssig.

Abschließend: Braucht man das wirklich? Nein, kann man aber.

Kleines Update vom 04.02.2021: IPv6 Konfiguration hinzugefügt, damit Pi-Hole als auch Cloudflared via IPv6 erreichbar sind im LAN.

Lüftereinstellungen für ZOTAC RTX 3060 TI TWIN EDGE OC

Ich hatte zum Release der GeForce RTX 3060 leider kein Glück, eine FE zu bekommen, aber immerhin konnte ich ein Custom Modell von ZOTAC zur UVP ergattern. Die Karte ist an sich nicht schlecht und liefert auch wie erwartet deutlich mehr Leistung als meine alte GTX 1060, macht aber auch leider deutlich mehr Krach. Ich habe zwar keinen eigenen Vergleich, aber die relativ kompakten ZOTAC Grafikkarten mit nur 2 Lüftern sind in vielen Tests als die lautesten der RTX 3060 aufgefallen. Die OC Variante stoppt die Lüfter zwar im Idle Betrieb, dreht aber relativ schnell hoch, sobald Last erzeugt wird. Aber das lässt dich mit MSI Afterburner ganz gut in den Griff bekommen.

Hier die Anpassungen in der Übersicht:
Memory Clock + 1000 MHz
Power Limit 110%
Temp Limit 90°C

Die Kurve fürs Undervolting:
Die obere Kurve um 160 MHz reduziert und bei 875 mV auf + 160 Mhz erhöht, danach Apply in der Hauptansicht.

Und so sieht meine angepasste Lüftereinstellung aus, die die Temperatur unter Last dann relativ gut zwischen 75°C und 80°C hält, die Lüfter aber merklich langsamer drehen lässt, als die automatische Einstellung:

Eigentlich sollte das auch mit dem Tool Firestorm von Zotac selbst auch funktionieren, hat es bei mir aber nicht. Zum Rumspielen mit den Lüftereinstellungen hab ich FurMark benutzt, um Last zu erzeugen.

Raspberry Pi Distro Update

Mein etwas in Jahre gekommener Raspberry Pi hat seit einiger Zeit keine Updates mehr bekommen. Auch wenn auf dem System nur noch FHEM und ein Pi-hole (in Docker) laufen, sind (Sicherheits-) Updates nicht unwichtig. Ein Blick auf die Infoseite zu Debian LTS bestätigte dann, mein raspbian auf Basis von Jessie (8) bekommt keinen Support mehr. Leider ist ein direktes Update von Jessie (8) auf Buster (10) nicht möglich bzw. nicht sinnvoll. Daher ist ein Zwischenschritt auf Stretch (9) notwendig. Im Endeffekt dauert es nur alles etwas länger, die Schritte für die Updates sind identisch. Vorab hab ich ein Backup der SD Karte mit Win32DiskImager gemacht; für alle Fälle.

Update Jessie auf Stretch:

sudo sed -i /deb/s/jessie/stretch/g /etc/apt/sources.list
sudo sed -i /deb/s/jessie/stretch/g /etc/apt/sources.list.d/*.list
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo apt-get autoremove
sudo apt-get autoclean
sudo reboot

Das hat sogar komplett problemlos geklappt. Bei Update von Stretch auf Buster kam dann aber ein kleines Problem dazwischen:

sudo sed -i /deb/s/stretch/buster/g /etc/apt/sources.list
sudo sed -i /deb/s/stretch/buster/g /etc/apt/sources.list.d/*.list
sudo apt-get update

sudo apt-get upgrade
# Hier funktionierte nun apt-listchanges nicht mehr, wegen einem fehlenden Python Paket: debconf
sudo apt-get remove apt-listchanges
sudo apt-get upgrade # neuer Versuch
sudo apt-get dist-upgrade

# debconf wieder manuell installieren
wget http://ftp.de.debian.org/debian/pool/main/d/debconf/debconf_1.5.61_all.deb
sudo dpkg -i debconf_1.5.61_all.deb

sudo apt-get autoremove
sudo apt-get autoclean
sudo reboot

Das zweite Update hat deutlich länger gedauert, aber letztendlich auch funktioniert. Hier das Ergebnis:

pi@raspberrypi:~ » cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Pi-hole mit docker-compose

Auf einem Raspberry Pi oder einem anderen System mit einem Docker Daemon lässt sich Pi-hole sehr leicht betreiben. Hier das dazugehörige docker-compose.yml:

version: "2.1"

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8000:80/tcp"
    environment:
      TZ: Europe/Berlin
      WEBPASSWORD: peeGhoh7voh9thim
      PIHOLE_DNS_: 5.1.66.255#53;80.241.218.68#53
      ServerIP: 192.168.1.105
      ServerIPv6: fd00::935d:666d:f026:8b11
      PROXY_LOCATION: pihole.fritz.box
      VIRTUAL_HOST: pihole.fritz.box
    volumes:
       - './etc-pihole/:/etc/pihole/'
       - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
    dns:
      - 127.0.0.1
      - 5.1.66.255
    restart: unless-stopped
    networks:
        - pihole_net

networks:
  pihole_net:
    enable_ipv6: true
    driver: bridge
    driver_opts:
      com.docker.network.enable_ipv6: "true"
    ipam:
      driver: default
      config:
      - subnet: fc00::/64

Angepasst werden müssen die IP Adresse (hier 192.168.1.105), VIRTUAL_HOST und am besten auch WEBPASSWORD. Die beiden hinterlegten DNS Server gehören zu Freifunk München bzw. UncensoredDNS. Über Port 8000 ist dann die Weboberfläche erreichbar. Die IP Adresse des Docker Hosts stellt dann via Port 53 Pi-hole für DNS Anfragen bereit.

Update: IPv6 funktioniert nur bis zur docker-compose Version 2.1 und mit der zusätzlichen Network Konfiguration unten.

Amazfit Bip verliert Bluetooth Verbindung

Vor einiger Zeit hat mein Huawei P30 Pro das Update auf EMUI 10 bzw. Android 10 bekommen. Seitdem hat meine Amazfit Bip noch häufiger als noch unter EMUI 9 das Problem, keine Verbindung per Bluetooth herstellen zu können. Ein System dahinter habe ich bisher nicht entdeckt: Es funktioniert mehrere Tage problemlos, dann wieder nicht. Neustart der App bzw. des Handys helfen manchmal, aber nicht immer.

Aber scheinbar klappt es hiermit: Die Bluetooth App (ein Systemprozess) muss gestoppt und der Cache dieser App gelöscht werden. Dann klappt es.

  1. Apps
  2. Systemprozesse anzeigen (Menü rechts oben)
  3. nach Bluetooth suchen
  4. App stoppen
  5. Cache löschen (unter Speicher zu finden)

Via Telegram über SSH Logins informieren

Über die Telegram API kann man sich bequem benachrichtigen lassen, wenn sich ein Benutzer per SSH auf einem System eingeloggt hat. Dazu folgende Zeilen in die Datei /etc/ssh/sshrc einfügen.

IP=`echo $SSH_CONNECTION | cut -d " " -f 1`
HOSTNAME=`hostname`
MESSAGE="SSH Login on $HOSTNAME as $USER from $IP"
curl --output /dev/null -s -X POST -H 'Content-Type: application/json' -d "{\"chat_id\": \"-123456789\", \"text\": \"$MESSAGE\", \"disable_notification\": true}" https://api.telegram.org/bot123456789:hgDW0mvUcio_AF4Za1nh-aY7PX/sendMessage

Wie an die Chat ID und das Token für den Bot zu kommen ist, ist z.B. hier beschrieben.