Zum Inhalt

Kategorie: Internet

Alexa erkennt smarte TP-Link Steckdosen nicht mehr

Ich habe diverse ältere und neuere Modelle der smarten Steckdosen von TP-Link im Einsatz, hauptsächlich HS100 und KP105. Leider hat die Alexa App die nervige Angewohnheit, die Steckdosen zwischendurch als „offline“ zu erkennen, falls die Stromversorgung oder die Verbindung zum WLAN unterbrochen wurde.

Eine einfache Lösung sieht so aus: Es reicht aus, den Namen der Steckdose in der TP-Link Kasa App zu ändern und die Liste der Steckdosen in der Alexa App zu erneuern. Die unbenannte Steckdose sollte dort dann wieder steuerbar sein. Es ist nun auch möglich, der Steckdose in der TP-Link Kasa App wieder ihren ursprünglichen Namen zu geben.

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.

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.

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.

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.

Datenbanken auf dem Raspberry Pi 3?

Ist es eine gute Idee, Datenbanken auf dem Raspberry Pi 3 zu betreiben? Nach meinen Erfahrungen der letzten Wochen, rate ich davon ab. Jedenfalls von größeren Datenbanken. Auf meinem Raspberry Pi 3 läuft eine PostgreSQL, die für kleine Datenmengen ausreichend ist, z.B. für Gogs (Git Repository). Zusätzlich liefen für ca. 1,5 Jahre Messdaten via FHEM in die Datenbank, was zu ca. 2,5 Millionen Datensätzen geführt hat. Und damit ist der Raspberry Pi 3 definitiv überfordert. Davor lagen diese Messdaten in einer SQLite Datenbank, die eine noch schlechtere Performance bot. Eine Java Applikation, die ebenfalls auf dem Raspberry Pi 3 läuft, hat für das Laden und Aufbereiten der Daten ca. 30 Minuten gebraucht. Die (momentane) Lösung ist, dass ich die Messdaten nun in einer MySQL Datenbank speichere, die auf einem vServer bei Host Europe läuft. Die Tabellen haben eine etwas andere Struktur, da ich direkt nach dem INSERT von neuen FHEM Messdaten diese via Trigger aufbereitet in eine andere Tabelle ablege. Der Start der Java Applikation hat sich auf ca. 30 Sekunden (nicht mehr Minuten!) reduziert. Der Zugriff auf die MySQL Datenbank erfolgt via SSH Tunnel, um die MySQL Datenbank auf dem vServer nicht direkt im Internet verfügbar zu machen.