Wie bei jedem anderen kritischen Teil deiner IT-Infrastruktur ist die einfachste Lösung, dein Tasmota-Gerät zu sichern und es bei Bedarf wiederherzustellen.

Tasmota-Backup erstellen

Tasmota stellt eine API bereit, über die sich die Einstellungen des Geräts auslesen lassen. Das Tasmota-Team stellt dafür das Tool decode-config[arch] zur Verfügung, mit dem sich ein einzelnes Gerät sichern lässt.

Tasmota-Backups automatisieren

Meine Anforderungen an automatisierte Tasmota-Backups waren:

• Vollautomatisch
• Unabhängig von meinem Arbeitsplatzrechner (Backup als Service)
• Versioniert (mehrere zeitgestempelte Backups pro Gerät)

Also habe ich tasmockup[arch] geschrieben (Tasmota + Backup). Tasmockup[arch] ist ein Wrapper für decode-config, der alle konfigurierten Tasmota-Geräte nach einem festen Zeitplan sichert. Es steht als Docker-Container zur Verfügung, der sich problemlos in jeder Umgebung deployen lässt.

Ich nutze tasmockup, um automatisierte Backups für alle meine Geräte zu erstellen. Der tasmockup-Container läuft auf meinem Server, auf dem ohnehin schon Home Assistant und weitere Smart-Home-Dienste laufen. Tasmockup sichert täglich alle Tasmota-Geräte in meinem Netzwerk und versioniert die Backups mit einem Unix-Zeitstempel.

Hier geht’s zu Tasmockup auf GitHub[arch]

Konfiguration

Die Konfiguration ist denkbar einfach. Zum Zeitpunkt dieses Artikels gibst du an, welche Geräte gesichert werden sollen, und mountest ein Docker-Volume, in dem die Backups abgelegt werden:

1docker run -t -i -e DEVICES="192.168.0.2;superSecret 192.168.0.3;AnotherSecret" -v tasmota-backups:/data gorootde/tasmockup

Eine ausführliche Beschreibung zur Konfiguration von tasmockup findest du in der README.md[arch] auf GitHub.

Wiederherstellung

Backups lassen sich einfach über die Tasmota-WebUI wiederherstellen. Navigiere einfach zu Backup Configuration / Restore Configuration und lade dein Backup hoch.

Ich brauchte also ein Setup, mit dem ich zumindest dringende Dinge reparieren kann, ohne gleichzeitig in Versuchung zu geraten, mehr als das zu tun.

Warum iOS VSCode nicht nativ unterstützt

Apples iOS ist ein stark reglementiertes Betriebssystem. Das bringt viele Vorteile mit sich, hat aber auch Nachteile. Einer davon ist, dass man keine Apps installieren kann, die auf ein zugrunde liegendes Betriebssystem angewiesen sind. VSCode nutzt intensiv die vom Betriebssystem bereitgestellte Shell. Da iOS keine Shell bereitstellt, ist es schwierig, diese Apps zu portieren. Die App müsste eine komplette Linux-Distribution enthalten, um denselben Funktionsumfang bieten zu können.

Diese Einschränkung führt dazu, dass VSCode auf einem vollwertigen Betriebssystem laufen muss statt direkt auf dem iPad. Aber keine Sorge, es wird sich trotzdem so anfühlen, als würde es direkt auf deinem iPad laufen.

Hardware-Setup

Da wir ein portables und leichtes Setup aufbauen wollen, verwenden wir Komponenten, die auch abseits des Stromnetzes laufen können und eine kleine Bauform haben.

Stückliste

1. Raspberry Pi 4 (8GB)[arch]: du kannst auch die 4GB-Variante wählen, aber man kann nie genug Speicher haben!
2. USB-C-zu-USB-C-Kabel: Achte darauf, dass es Power Delivery und Datenübertragung unterstützt.
3. Micro-SD-Karte mit 128GB oder mehr. Ich selbst nutze eine SanDisk Ultra 400GB Class 10 Karte.
4. Gehäuse für den Raspberry Pi
5. iPad Pro mit USB-C-Anschluss
6. (Bluetooth-)Tastatur & Maus für das iPad

RPis USB-C-Port als Netzwerkschnittstelle einrichten

Wir konfigurieren den USB-C-Port des Raspberry so, dass er als Netzwerkkarte für dein iPad fungiert. Dadurch kann das iPad mit deinem Raspberry kommunizieren, während es gleichzeitig in seinem WLAN-Netzwerk bleibt, um internetbasierte Dienste nutzen zu können.

Verbinde dich per SSH mit deinem Pi und führe die folgenden Schritte aus. Alternativ kannst du deine SD-Karte an einem Computer einbinden und die Schritte 1-3 durch Bearbeiten der Dateien dort durchführen.

1. Bearbeite /boot/config.txt und füge dtoverlay=dwc2 hinzu. Dadurch wird der USB-OTG-Modus auf deinem Raspberry aktiviert.

2. Füge modules-load=dwc2 an das Ende von /boot/cmdline.txt an. Dadurch erhält der Kernel den Befehl, dieses Modul als Parameter zu laden

3. Falls SSH noch nicht aktiviert ist, aktiviere es, indem du eine leere Datei namens ssh in /boot/ anlegst. Das Anlegen aktiviert den SSH-Server beim nächsten Boot

4. Bearbeite /etc/modules und füge libcomposite in einer neuen Zeile am Ende der Datei hinzu. Dadurch wird sichergestellt, dass die USB-Gadget-Treiber geladen werden

5. Bearbeite /etc/dhcpd.conf und füge denyinterfaces usb0 hinzu. Da wir nicht wollen, dass unsere USB-Netzwerkschnittstelle von DHCP konfiguriert wird, schließen wir das hier explizit aus

6. Installiere dnsmasq mit sudo apt-get install dnsmasq. dnsmasq fungiert als DHCP-Server für die USB-basierte Netzwerkschnittstelle. Es stellt sicher, dass die Ethernet-Schnittstelle deines iPads eine IP-Adresse erhält.

7. Erstelle eine neue Datei /etc/dnsmasq.d/usbnetwork mit folgendem Inhalt:

   /etc/dnsmasq.d/usbnetwork #L1-L4 Kopieren

   1interface=usb0
   2dhcp-range=10.55.0.2,10.55.0.6,255.255.255.248,1h
   3dhcp-option=3
   4leasefile-ro

8. Erstelle /etc/network/interfaces.d/usb0 mit folgendem Inhalt:

   /etc/network/interfaces.d/usb0 #L1-L5 Kopieren

   1auto usb0
   2allow-hotplug usb0
   3iface usb0 inet static
   4  address 10.55.0.1
   5  netmask 255.255.255.248

9. Erstelle /root/usb.sh und füge Ben Hardills großartigen Code[arch] zur Konfiguration der Hardware-Eigenschaften ein:

   /root/usb.sh #L1-L31 Kopieren

    1#!/bin/bash
    2cd /sys/kernel/config/usb_gadget/
    3mkdir -p pi4
    4cd pi4
    5echo 0x1d6b > idVendor # Linux Foundation
    6echo 0x0104 > idProduct # Multifunction Composite Gadget
    7echo 0x0100 > bcdDevice # v1.0.0
    8echo 0x0200 > bcdUSB # USB2
    9echo 0xEF > bDeviceClass
   10echo 0x02 > bDeviceSubClass
   11echo 0x01 > bDeviceProtocol
   12mkdir -p strings/0x409
   13echo "fedcba9876543211" > strings/0x409/serialnumber
   14echo "Ben Hardill" > strings/0x409/manufacturer
   15echo "PI4 USB Device" > strings/0x409/product
   16mkdir -p configs/c.1/strings/0x409
   17echo "Config 1: ECM network" > configs/c.1/strings/0x409/configuration
   18echo 250 > configs/c.1/MaxPower
   19# Add functions here
   20# see gadget configurations below
   21# End functions
   22mkdir -p functions/ecm.usb0
   23HOST="00:dc:c8:f7:75:14" # "HostPC"
   24SELF="00:dd:dc:eb:6d:a1" # "BadUSB"
   25echo $HOST > functions/ecm.usb0/host_addr
   26echo $SELF > functions/ecm.usb0/dev_addr
   27ln -s functions/ecm.usb0 configs/c.1/
   28udevadm settle -t 5 || :
   29ls /sys/class/udc > UDC
   30ifup usb0
   31service dnsmasq restart

10. Mache die Datei mit chmod +x /root/usb.sh ausführbar

11. Füge /root/usb.sh in /etc/rc.local vor der Zeile exit 0 hinzu, damit es bei jedem Systemstart automatisch ausgeführt wird.

Nachdem du deinen Pi (neu) gestartet hast, solltest du auf deinem iPad eine neue Netzwerkschnittstelle sehen:

VSCode einrichten

Ich gehe davon aus, dass du raspbian[arch] auf deinem Pi installiert hast. Falls nicht, folge den Anweisungen hier[arch], um dahin zu gelangen.

Um VSCode auf dem Pi auszuführen und vom iPad aus zugänglich zu machen, verwenden wir code-server[arch]. Code-server verpackt VSCode und seine Abhängigkeiten in einen Dienst, auf den du über deinen Browser zugreifen kannst.

Code-server auf deinem Raspberry Pi installieren

1. Installiere yarn mit sudo apt-get install yarn

2. Installiere code-server global mit yarn global add code-server

3. Du solltest code-server jetzt mit yarn run code-server starten können

4. Passe die Code-Server-Konfiguration an deine Netzwerkkonfiguration an. Bearbeite ~/.config/code-server/config.yaml und füge folgende Konfiguration ein:

   ~/.config/code-server/config.yaml #L1-L5 Kopieren

   1bind-addr: 10.55.0.1:8080
   2auth: password
   3password: changeme
   4cert: true
   5cert-host: raspberrypi.local

5. Deine code-server-Instanz sollte jetzt von deinem iPad aus über Safari oder einen anderen Browser unter https://raspberrypi.local:8080 erreichbar sein. Falls das nicht funktioniert, versuche, das WLAN auf deinem iPad vorübergehend zu deaktivieren. Du kannst es wieder aktivieren, nachdem VSCode in Safari geladen wurde.

An diesem Punkt solltest du die VSCode-Anmeldeaufforderung sehen, die nach dem Passwort (changeme) fragt, das wir in der YAML-Datei konfiguriert haben. Um VSCode korrekt nutzen zu können, müssen wir auf dem iPad noch weitere Konfigurationen vornehmen. Lies weiter!

Detailliertere Anweisungen zur Installation von code-server findest du hier[arch].

Code-server beim Systemstart automatisch starten

Damit code-server bei jedem Systemstart automatisch startet, müssen wir es bei systemd registrieren. Erstelle eine neue Datei /lib/systemd/system/code-server.service mit folgendem Inhalt:

 1[Unit]
 2Description=code-server
 3After=network.target
 4
 5[Service]
 6Type=simple
 7ExecStart=yarn exec code-server
 8Restart=always
 9User=pi
10Group=pi
11
12[Install]
13WantedBy=multi-user.target

Führe dann systemctl daemon-reload aus, um den neuen Dienst zu aktivieren.

Du kannst den Status von code-server nun mit systemctl status code-server prüfen. Er sollte dir mitteilen, dass er active (running) ist. Falls nicht, kannst du versuchen, ihn mit systemctl restart code-server neu zu starten.

VSCode zum Homescreen deines iPads hinzufügen

Der Zugriff auf VSCode über den Safari-Browser des iPads ist nicht ganz einfach, da VSCode Web-Sockets verwendet, um mit dem Backend zu kommunizieren, das auf deinem Raspberry Pi läuft. Damit diese Kommunikation funktioniert, muss die Verbindung verschlüsselt sein (HTTPS oder TLS). Glücklicherweise stellt code-server ein Zertifikat für dich bereit. Diesem Zertifikat muss auf dem iPad vertraut werden.

Zertifikat auf dem iPad importieren

1. Suche auf dem Raspberry nach der Datei ~/.local/share/code-server/raspberrypi_local.crt und kopiere sie auf dein iPad.
2. Öffne raspberrypi_local.crt in der Dateien-App und folge den Dialogen, um dem importierten Zertifikat zu vertrauen.
3. Öffne die Einstellungen-App und navigiere zu Allgemein -> Info -> Zertifikatsvertrauenseinstellungen (unten in der Liste) und aktiviere den Schalter Vollständiges Vertrauen für Root-Zertifikate aktivieren für das Zertifikat namens raspberrypi.local.

   

VSCode als Progressive Web App zum Homescreen hinzufügen

1. Öffne https://raspberrypi.local:8080 in Safari
2. Klicke auf das Teilen-Symbol
3. Wähle Zum Home-Bildschirm und vergib einen Namen

   

   Du solltest jetzt VSCode öffnen können, indem du auf das gerade erstellte Symbol tippst.

Herzlichen Glückwunsch!

Du hast gerade ein vollständig portables Software-Entwicklungs-Setup erstellt, das sogar ohne Internetverbindung genutzt werden kann. Lass mich in den Kommentaren wissen, was du davon hältst!

Der ‘Biene in der Kiste’-Algorithmus: Die Theorie

Stell dir vor, jemand reicht dir eine kleine Kiste aus Pappe. Auf der Oberseite der Kiste ist ein gelbes Warnsymbol: “Achtung: Möglicherweise befindet sich eine Biene darin.”

Du kannst nicht hineinschauen. Und öffnen willst du sie auch nicht, da das einen schmerzhaften Stich zur Folge haben könnte. Wie könntest du also herausfinden, ob sich in deiner speziellen Kiste wirklich eine Biene befindet?

Die Antwort ist ziemlich simpel: Du lauschst dem Summen der Biene!

Falls du das Summen gehört hast und die Kiste seitdem nicht geöffnet wurde, kannst du davon ausgehen, dass sich die Biene immer noch darin befindet. Dieses einfache Prinzip lässt sich auch auf dein Smart Home übertragen!

Biene in der Kiste Person im Raum: Wie man den Algorithmus für Präsenzerkennung nutzt

Die Übertragung des ‘Biene in der Kiste’-Algorithmus auf ein Smart-Home-Umfeld ist ziemlich einfach:

• Die Biene entspricht einer beliebigen Person
• Die Pappkiste mit der Biene entspricht einem beliebigen Bereich deines Smart Homes. Das kann ein einzelner Raum, deine Wohnung oder sogar das ganze Haus sein
• Das Summen entspricht in Wirklichkeit jeder Interaktion mit einem ausgelösten Sensor oder Aktor

Nehmen wir ein sehr einfaches Smart-Home-Setup an: Du hast eine Wohnung mit einer einzigen smarten Lampe, die an dein Home Assistant[arch] (oder ein anderes) Smart-Home-System angebunden ist. Wenn irgendjemand das Licht ein- oder ausschaltet, weiß dein Smart-Home-Server, dass sich jemand in der Wohnung befindet. Fügt man noch einen Türsensor an der Haupttür hinzu, weiß das System auch, dass jemand die Wohnung möglicherweise verlassen hat.

Mehr braucht es nicht: Präsenzerkennung mit nur einem Türsensor und einem Lichtschalter!

Präsenzerkennung mit dem ‘Biene in der Kiste’-Algorithmus zusammengefasst

1. Nimm an, dass niemand anwesend ist
2. Sobald ein beliebiger Sensor im Raum ausgelöst wurde, nimm an, dass jemand anwesend ist
3. Falls die Zimmertür geöffnet wurde, gehe zurück zu Zustand 1.)

Die oben genannten Zustände lassen sich problemlos als Automatisierungsregeln in deinem Smart-Home-Server umsetzen. Für Home Assistant kann ein solches Setup die input_boolean-Integration[arch] nutzen, um den Zustand zu speichern, ob in einem Raum Präsenz erkannt wurde oder nicht.

Erweiterte Präsenzerkennung

Der hier beschriebene Algorithmus erlaubt dir zwar zu erkennen, ob irgendjemand in einem bestimmten Raum anwesend ist, kann aber nicht bestimmen, welche Person anwesend ist. Dafür gibt es andere Ansätze, die Thema eines zukünftigen Blogposts sein könnten.

Bis dahin kannst du ‘Biene in der Kiste’ zumindest für einfache Szenarien nutzen, wie zum Beispiel ‘Licht ausschalten, wenn niemand im Raum ist’.

Zu viele ungenutzte BLE-Sensoren, zu viel Zeit während des COVID-19-Lockdowns — lass uns noch mehr Sensoren hinzufügen! Nur weil wir es können…

Nein, im Ernst. Ich hatte in mehreren Bereichen meines Hauses stark mit zu hoher Luftfeuchtigkeit zu kämpfen. Nach dem heißen Duschen im Bad kondensierte die Feuchtigkeit am Fenster, was das Risiko von Schimmelbildung erhöhte. Im Keller, wo unsere Lebensmittelvorräte lagern, hatten wir Probleme mit feucht werdendem Salz. Und da ich außerdem ein Riffbecken besitze, das an mein Smart-Home-System angebunden ist und das Wasser über Verdunstung kühlt, ist die Luftfeuchtigkeit im Wohnzimmer ebenfalls eine sehr interessante Messgröße. Also wa

BLE-Sensoren mit Home Assistant verbinden

Home Assistant bietet bereits eine eigene Integration für Xiaomi-Mijia-Sensoren[arch], daher läge es nahe, einfach einen BLE-Stick anzuschließen und loszulegen. Aus zwei Gründen habe ich mich gegen diese Option entschieden:

1. BLE ist dafür gemacht, Geräte in direkter Sichtverbindung zum steuernden Gerät (oder zumindest in dessen unmittelbarer Nähe) zu steuern. Da meine Sensoren im ganzen Haus verteilt sein werden, könnte ein einzelner BLE-Stick in meinem Serverschrank möglicherweise nicht mit allen Sensoren kommunizieren.
2. Ich versuche konsequent, die Verarbeitung / Darstellung meiner Smart-Home-Daten von der Datenerfassung / Hardware-Anbindung zu trennen. Vor ein paar Jahren habe ich mit OpenHAB[arch] auf einem Raspberry Pi angefangen, der direkt mit jeder einzelnen Hardware verbunden war. Das endete darin, dass Dutzende Kabel durch meine Wohnung liefen, nur um einen DS18S20 auf dem Balkon anzuschließen. Dahin will ich nicht zurück!

Ein ESP32-Board in ein BLE-Gateway verwandeln

Auch hier habe ich mich auf meine bevorzugte ESP-Firmware Tasmota[arch] verlassen. Zum Glück hat Tasmota vor einigen Versionen ESP32-Unterstützung[arch] eingeführt. Auch wenn sie offiziell noch im Beta-Stadium ist, funktioniert zumindest die BLE-Kommunikation absolut zuverlässig.

1. Folge den Anweisungen hier[arch], um deinen ESP mit der erforderlichen Firmware zu flashen. Achte darauf, die ESP32-Binary mit dem Suffix bluetooth zu verwenden, damit alle benötigten Treiber enthalten sind.
2. Logge dich in die Tasmota-Web-UI ein und navigiere zu Configuration -> Configure BLE und aktiviere Enable Bluetooth.
3. Sobald du die Einstellungen speicherst, sollten in der darunterliegenden Liste Devices Seen alle Arten von BLE-Geräten aufgeführt werden.

   

Jetzt ist alles bereit, um deinen ESP32 als BLE-Gateway zu nutzen. Konfiguriere ihn einfach so, dass er mit deinem MQTT-Server spricht, genau wie du es bei jedem anderen Tasmota-Gerät auch tun würdest.

Individuelle Firmware für BLE-Sensoren

Die LYWSD03MMC-Sensoren von Xiaomi kommen bereits mit einer Werksfirmware, die sich sofort verwenden lässt, um sich mit deinem Gateway zu verbinden. Es gibt jedoch einige Nachteile:

1. Der Batteriestatus wird nicht korrekt gemeldet
2. Eine aktive Verbindung ist nötig, um Daten abzufragen — das entlädt die Batterie sehr schnell
3. Vertraue niemals einer Nicht-Open-Source-Firmware ;-)

Eine individuelle Firmware auf das Gerät zu bringen ist ziemlich einfach. Folge einfach den großartigen Anleitungen im Repository von atc1441[arch], um sie zu flashen. Für den Flash-Vorgang selbst benötigst du keine zusätzlichen Tools. Es gibt ein browserbasiertes Tool, das in allen modernen Browsern funktioniert.

Fazit

Ich habe jetzt drei dieser Sensoren mit meinem Home Assistant verbunden. Weitere sind bereits bestellt. Die Verbindung ist absolut zuverlässig, und dank der individuellen Firmware werde ich auch benachrichtigt, falls einem der Geräte bald der Akku ausgeht. Vorgefertigte Geräte zu verwenden, statt meine eigene Schaltung zu bauen, hat mir eine Menge Zeit gespart. Definitiv empfehlenswert!

Tasmota-kompatible Hardware

Es gibt nicht viele Optionen, um den pH-Wert in einem DIY-Setup zu messen. Genau genommen gibt es nur zwei generelle Optionen: Entweder du entscheidest dich für Atlas Scientifics EZO-pH-Schaltkreis[arch], oder für eine günstige analoge pH-Sonde. Die erste Option (inklusive pH-Sonde, Schaltkreis, zusätzlichem Trägerboard) hätte etwa 100 US-Dollar plus Versand gekostet. Die analoge Sonden-Option kostet nur etwa 20 US-Dollar. Diese Sonden kannst du praktisch überall kaufen.

Diese analogen Sonden-Kits kommen bereits mit einer Sonde und dem Schaltkreis. Sie haben meist eine 3-polige Stiftleiste angelötet: VCC, GND und Analog Out. Sie an einen Wemos D1 Mini[arch] anzuschließen ist eine Sache von Sekunden. Achte nur darauf, die 3.3V-Schiene als VCC zu verwenden, damit der Analogausgang das erlaubte Maximum von 3.3V nicht überschreiten kann.

Tasmota um Unterstützung für analoge pH-Sonden erweitern

Da Tasmota keine analogen pH-Schaltkreise unterstützte, habe ich die nötigen Änderungen einfach selbst zum Tasmota-Projekt beigetragen[arch]. Ab Version 9.3.0[arch] unterstützt Tasmota jetzt eine pH-Sonde an Analogeingängen.

Wie du sehen kannst, lässt sich “ADC pH” für deinen Analogeingang konfigurieren:

Tasmota-pH-Messwerte kalibrieren

Da es sich um eine analoge Sonde handelt, müssen wir sie kalibrieren. Dafür werden mindestens zwei Kalibrierlösungen mit unterschiedlichem pH-Wert benötigt. Du kannst sie entweder als Pulver im Internet bestellen, oder bereits fertig gemischt bei deinem lokalen Aquarienhändler bekommen.

Kalibrierprozess:

1. Sonde in die Lösung mit dem niedrigeren pH-Wert legen. Der pH-Wert der Lösung ist ANALOG_PH_CALSOLUTION_LOW_PH.
2. Warten, bis sich der Analogwert / RAW-Wert stabilisiert (~3 Minuten)
3. Der Analogmesswert ist ANALOG_PH_CALSOLUTION_LOW_ANALOG_VALUE
4. Sonde reinigen und in die Lösung mit dem höheren pH-Wert legen. Der pH-Wert der Lösung ist ANALOG_PH_CALSOLUTION_HIGH_PH.
5. Warten, bis sich der Analogwert / RAW-Wert stabilisiert (~3 Minuten)
6. Der Analogmesswert ist ANALOG_PH_CALSOLUTION_HIGH_ANALOG_VALUE

Analogmesswerte lassen sich entweder auslesen, indem du die Konfiguration des Analog-Ports während der Kalibrierung auf “Analog Input” umstellst, oder indem du Debug-Logs in der Konsole aktivierst und stattdessen den RAW-Wert betrachtest.

Nachdem du die Werte notiert hast, führst du folgenden Befehl in der Tasmota-Konsole aus: AdcParam 9 <ANALOG_PH_CALSOLUTION_LOW_PH>, <ANALOG_PH_CALSOLUTION_LOW_ANALOG_VALUE>, <ANALOG_PH_CALSOLUTION_HIGH_PH>, <ANALOG_PH_CALSOLUTION_HIGH_ANALOG_VALUE>

Deine Sonde ist jetzt kalibriert und sollte dir den korrekten pH-Messwert liefern. Ich habe diese Dokumentation auch zur offiziellen Tasmota-Dokumentation[arch] beigetragen.

Tasmota-pH-Sensor mit Home Assistant verbinden

Dieser Schritt ist ziemlich unkompliziert: Tasmota kommuniziert mit Home Assistant über MQTT. Du kannst einfach der Standard-Tasmota-Dokumentation[arch] folgen und schon bist du fertig.

Nachdem dein Sensor ein paar Stunden gelaufen ist, solltest du deinen pH-Wert sehen können:

Funktioniert wie ein Uhrwerk!

Was ist das Problem mit meinem IoT-Gerät?

Die kurze Antwort lautet: Du besitzt es, aber du kontrollierst es nicht. Aber…

Nehmen wir als Beispiel ein IoT-Gerät mit Sprachassistent. Die kleinen Boxen, die in jedem Zimmer stehen, reagieren auf deine Spracheingaben. Die aktuelle Wettervorhersage ist nur einen Sprachbefehl entfernt. Aber was passiert eigentlich im Hintergrund? Der smarte Lautsprecher zeichnet deine Stimme auf, sendet die Aufnahme an einen öffentlichen Cloud-Anbieter, der analysiert, was du gesagt hast, und führt einfach aus, was ihm von der Cloud befohlen wird. In unserem Beispiel: die aktuelle Wettervorhersage vorlesen.

Ein weiteres, eher physisches Beispiel wäre ein Bewegungsmelder, der an einen Internetdienst meldet, ob jemand erkannt wurde. In deinem lokalen Netzwerk werden keine Befehle ausgeführt, aber wer sich Zugang zu den Daten im Cloud-Dienst verschafft, könnte leicht herausfinden, ob du zu Hause bist. Wäre ich der Bösewicht, würde ich warten, bis die Cloud mir ’niemand zu Hause’ meldet, bevor ich in dein Haus einbreche.

Was ist hier also eigentlich passiert? Dein IoT-Gerät führt Befehle aus oder gibt Informationen preis, die nicht unter deiner Kontrolle stehen. Wie stellst du sicher, dass ein solcher Befehl nicht darin besteht, deine Bankdaten von deinem PC in die Cloud hochzuladen? Würdest du ein großes Schild an deine Haustür hängen, auf dem steht “Haus ist leer, niemand zu Hause”?

IoT- und NoT-Geräte in einem segmentierten Netzwerk platzieren

IoT — das Internet of Things — ist ein bekannter Begriff. Er beschreibt Geräte, die mit dem Internet verbunden sein müssen, um richtig zu funktionieren. NoT — Network of Things — beschreibt Geräte, die mit deinem Netzwerk verbunden sind, aber kein Internet benötigen, um richtig zu funktionieren. Beide Geräteklassen sollten von deinem lokalen Netzwerk isoliert werden. Falls dein Router jedoch keine 3 separaten Netzwerke unterstützt, gibt es auch Alternativen, um das mit weniger als 3 umzusetzen.

Falls dein Router ein Gastnetzwerk unterstützt, aber keine weiteren zusätzlichen Netzwerke, kannst du das Gastnetzwerk als kombinierten Ersatz für die hier beschriebenen IoT- und NoT-Netzwerke nutzen.

Geräte für das IoT-Netzwerk sind Geräte, die ohne Internetverbindung nicht funktionieren. Beispiele dafür sind smarte Lautsprecher, Internetradios oder webbasierte Wetterstationen.

Geräte für das NoT-Netzwerk sind Geräte, die mit deinem Heimnetzwerk kommunizieren müssen, aber nicht mit dem Internet. Zum Beispiel smarte Glühbirnen oder WLAN-Überwachungskameras.

Wie man IoT- und NoT-Geräte in einem von Unifi verwalteten Netzwerk segmentiert

Ubiquiti-Netzwerkkomponenten[arch] sind erschwingliche Geräte, die viele professionelle Funktionen mitbringen. Eine dieser Funktionen ist die Aufteilung deines Netzwerks in mehrere VLANs. Genau das nutzen wir in unserem Setup.

Gehe in deinem UniFi-Controller zu Settings -> Network. Erstelle ein neues IoT-Netzwerk mit den hier gezeigten Einstellungen:

Mach jetzt einfach dasselbe mit dem NoT-Netzwerk:

Da wir jetzt zwei Netzwerke haben, kannst du auch zwei WLANs konfigurieren, damit auch kabellose Clients mit deinem Netzwerk verbunden werden können. Ich zeige hier nur das IoT-WLAN, da die Einstellungen für das NoT-WLAN weitgehend identisch sind:

Jetzt ist alles eingerichtet: 2 zusätzliche VLANs / Netzwerke stehen zur Verfügung, du musst nur noch deine Geräte damit verbinden.

Firewall-Konfiguration

Die Netzwerke können momentan noch mit deinem Hauptnetzwerk und auch untereinander kommunizieren. Um das zu verhindern, müssen wir die Firewall entsprechend konfigurieren.

Gehen wir die Regeln durch:

Dieses Setup führt zu folgendem Ergebnis:

• Das IoT-Netzwerk kann nur Verbindungen zum Internet aufbauen
• Das NoT-Netzwerk kann überhaupt keine Verbindungen aufbauen
• Das LAN kann Verbindungen zum IoT- und NoT-Netzwerk aufbauen

Da keines deiner IoT- oder NoT-Geräte mehr mit deinem Hauptnetzwerk (LAN) kommunizieren kann, sind die vertrauenswürdigen Geräte in diesem Netzwerk jetzt sicher.

mDNS-Erkennung aktivieren

Mit dem obigen Setup könntest du Probleme bekommen, deine NoT- und IoT-Geräte z. B. von deinem Smartphone im LAN-Netzwerk aus zu finden. Das liegt daran, dass diese Geräte oft mDNS[arch] verwenden, um die Anwesenheit eines Geräts zu erkennen. Da mDNS keine VLAN-Grenzen überschreiten kann (auch nicht mit einer dedizierten Firewall-Regel!), müssen wir sicherstellen, dass die Geräte ihre Ankündigungen über alle Netzwerke hinweg senden können.

Glücklicherweise erlaubt uns UniFi genau das zu konfigurieren, indem wir den Schalter “Enable Multicast DNS” aktivieren. Du findest diesen Schalter unter Settings -> Services -> MDNS.

Dadurch können nur die Ankündigungen über VLAN-Grenzen hinweg fließen, aber nicht die eigentlichen Verbindungen. Daher werden dadurch keine der zuvor eingerichteten Sicherheitsmaßnahmen ausgehebelt.

1. Das Betriebssystem des Hosts aktuell halten
2. Den Inhalt deiner Container aktuell halten

Das Betriebssystem aktualisieren

Dein Betriebssystem zu aktualisieren ist ziemlich unkompliziert. Nutze einfach die bekannten Paketmanager, die das für dich erledigen. Für Debian wäre das zum Beispiel so einfach wie regelmäßig apt-get update && apt-get upgrade auszuführen.

Um die Ausführung dieser beiden Befehle zu automatisieren, gibt es mehrere Ansätze. Entweder du konfigurierst einen Cronjob, der diese Befehle regelmäßig ausführt, oder du entscheidest dich für eine ausgefeiltere Lösung.

Für apt gibt es ein Paket namens unattended-upgrades. Das Paket kümmert sich darum, täglich alle Sicherheitsupdates zu installieren. Es lässt sich vollständig über /etc/apt/apt.conf.d/50-unattended-Upgrades konfigurieren.

Container aktualisieren

Um Docker-Container automatisch zu aktualisieren, musst du nicht nur den Upgrade-Prozess selbst berücksichtigen.

Das Risiko der Inkompatibilität

Es gibt viele Container, die nicht automatisch sicherstellen, dass auch die Daten (z. B. Datenbanken oder Konfigurationen) aktualisiert werden. Es könnte sogar eine neuere Version deines Dienstes geben, die mit der Datenbank in deinem Sidecar-Container nicht kompatibel ist. Wenn du nur einen von beiden aktualisierst, könntest du am Ende mit völlig unbrauchbaren Diensten dastehen.

Um dieses Risiko zu mindern, kannst du mehrere Dinge tun:

• Nutze feste Container-Versionen in deiner docker-compose.yaml. Wenn du keinen Image-Tag angibst, verwendet Docker implizit latest als Image-Tag. Das bedeutet, dass du bei einem unbeaufsichtigten Upgrade immer die neueste Version bekommst — selbst wenn diese Version Änderungen mit sich bringt, die die API zu einem deiner anderen Dienste brechen. Wirf einfach einen Blick auf die verfügbaren Tags für dein Image. Oft gibt es einen Tag, mit dem du dich nur auf die Hauptversion des Images beschränken kannst. Zum Beispiel würde nginx:2 nur Upgrades auf andere Versionen erlauben, die mit 2 beginnen, was hoffentlich keine brechenden API-Änderungen enthält.
• Stelle sicher, dass du automatisierte Daten-Backups eingerichtet hast. Zum Beispiel, indem du die Cloud als deinen Panic Room nutzt. Wenn du eine neue Version eines Images ziehst, besteht immer das Risiko, dass deine Daten beschädigt werden. Das gilt sogar für Images, die deine Daten migrieren. Migrationsprozesse können scheitern!
• Richte Monitoring mit Alarmierung ein. Für den seltenen Fall, dass ein Upgrade fehlschlägt, musst du das sofort erfahren. Monitoring-Systeme wie Prometheus[arch] bieten eine einfache Möglichkeit zu erkennen, wenn ein Container ausgefallen oder ein Webdienst nicht mehr erreichbar ist.

Unbeaufsichtigte Container-Updates via Cron

Um unbeaufsichtigte Container-Upgrades umzusetzen, kannst du die Standard-Docker-Befehle nutzen, die du bereits kennst. Lege einfach das folgende Skript in /etc/cron.daily/ ab, und du bist startklar:

1#!/bin/bash
2
3cd /my-docker-compose-project
4docker-compose pull
5docker-compose up -d --remove-orphans

Dadurch werden täglich die neuesten, in deinem docker-compose-Projekt referenzierten Image-Versionen heruntergeladen, die Container mit den aktualisierten Images neu gestartet und alte, nicht mehr im Projekt enthaltene Container entfernt.

Unbeaufsichtigte Container-Updates via Watchtower

Es gibt ein hervorragendes Open-Source-Projekt namens Watchtower, das im Grunde selbst ein Docker-Container ist. Es überwacht die Registries aller Images, die auf deinem Docker-Daemon laufen. Wird ein Image in der Registry aktualisiert, lädt es das Image herunter und startet deinen Dienst einfach mit der alten Konfiguration neu. Genial, oder?

Watchtower in ein docker-compose-Projekt einbinden

Füge deiner Docker-Compose-Datei eine weitere Dienstkonfiguration für Watchtower hinzu.

1services:
2    watchtower:
3        restart: always
4        image: containrrr/watchtower
5        container_name: watchtower
6        volumes:
7            - /var/run/docker.sock:/var/run/docker.sock

Dadurch läuft Watchtower in seiner Standardkonfiguration, die alle Container im System überwacht. Es gibt viele Konfigurationsmöglichkeiten. Schau einfach in die Dokumentation[arch].

Anwendungsfall

Jason Wilder selbst erklärt den Anwendungsfall von jwilder/nginx-proxy sehr ausführlich in seinem Blog[arch]. Die Nutzung dieses Images beschränkt sich (Stand der Artikelerstellung) auf statische Setups, wie z. B. docker-compose-Dateien. Wenn du dynamischere Setups betreibst — etwa solche, bei denen Container spontan erstellt werden — sind Lösungen wie Traefik besser geeignet. Zum Zeitpunkt der Erstellung dieses Artikels kann das Image Backend-Dienste ohne spezielle jwilder/nginx-proxy-Konfiguration nicht automatisch erkennen.

Konfiguration

Die Hauptanwendungsfälle lassen sich vollständig über Umgebungsvariablen konfigurieren, die auf den zu proxenden Diensten definiert werden. Leider hat das auch den Nebeneffekt, dass die nginx-proxy-Konfiguration in deinem Backend-Dienst sichtbar wird. Würde man stattdessen Labels zur Konfiguration verwenden, würde das die Umgebung nicht verunreinigen.

Aktivität

Die Community rund um jwilder/nginx-proxy ist sehr aktiv. Das GitHub-Repository[arch] hat über 60 Contributor. Updates des Images erfolgen sehr häufig, was für einen Dienst, der die erste Verteidigungslinie in deinem Setup darstellt, sehr wichtig ist. Besonders wenn man bedenkt, dass die Nutzung von Docker-Images zusätzliche potenziell unsichere Schichten hinzufügt zwischen dir und dem Software-Hersteller.

Skalierung

Der Dienst selbst lässt sich nicht so einfach skalieren wie andere Ingress-Router-Lösungen. Um die Instanzen dynamisch zu skalieren, musst du einen dedizierten Load-Balancer betreiben, der die Aufrufe auf deine jwilder/nginx-proxy-Instanzen verteilt.

Fazit

Jasons nginx-basiertes Reverse-Proxy-Image ist einer der besten verfügbaren Ingress-Router für statische Setups. Es ist besonders nützlich in statischen Umgebungen, z. B. klassischen Servern, auf denen die Dienste in Containern laufen. Die Fähigkeit, die gesamte notwendige Konfiguration aus wenigen Einstellungen zu generieren, ist hervorragend. Es ist eines der wenigen verfügbaren Images, die überhaupt keine Konfigurationsdateien benötigen. Selbst für Einsteiger ohne jegliches nginx-Wissen senkt das die Hürde, einen Ingress-Router zu konfigurieren, wirklich erheblich.

Was ist ein sicheres System?

Die Definition eines sicheren Systems mag je nach Person unterschiedlich ausfallen. Ein System sicher zu halten ist natürlich viel mehr als nur die neuesten Patches und Updates einzuspielen, aber dennoch: Für ein durchschnittliches System ist das Installieren von Updates und Sicherheitspatches der wichtigste Punkt, wenn Systeme dem Internet ausgesetzt sind. Aus Update-Perspektive muss es eine Art “Vertrauenskette” geben, um sein System sicher aktualisieren zu können. Bricht ein einzelnes Kettenglied, können deine Systeme kompromittiert werden, ohne dass du es überhaupt bemerkst:

Lass uns diese Vertrauenskette definieren:

• Zeitnah aktualisieren — Updates so bald wie möglich einspielen
• Sichere Quellen — Alle Updates müssen aus vertrauenswürdigen Quellen bezogen werden. Die Voraussetzungen für eine vertrauenswürdige Quelle sind:
• Vertrauenswürdige Repositories — Die Quellen / Server / Update-Seiten, von denen du deine Updates beziehst, müssen vertrauenswürdig sein
• Vertrauenswürdige Beiträge — Gleiches gilt für die Inhalte dieser Repositories (bzw. den Quellcode, der die Grundlage für die Pakete bildet)
• Integrität sicherstellen — Der Nachweis der Integrität eines Pakets (z. B. durch Signaturen) stellt sicher, dass sich der Paketinhalt auf dem Weg vom Autor zu deinem System nicht verändert hat

Prüfen wir also, ob all diese Anforderungen beim Betrieb von Docker-Containern erfüllt sind.

Der klassische Server

Du betreibst Linux auf einer Bare-Metal-Box (oder einer virtuellen Maschine). Um sie aktuell zu halten, führst du von Zeit zu Zeit ein paar Befehle wie

1apt-get update
2apt-get upgrade

aus. Der Paketmanager deiner Distribution kümmert sich dann um den Update-Prozess. Er greift auf die Paket-Repositories zu, lädt die neuesten Sicherheitsupdates herunter und installiert sie schließlich auf deinem System.

Aber warum müssen wir diese Updates eigentlich manuell durchführen? Können wir das nicht einfach automatisch erledigen lassen? Nun, zumindest bei klassischen Serversystemen kann ein automatisches Update dein System jederzeit lahmlegen. Datenbank-Upgrades, überschriebene individuelle Konfigurationen oder einfach unbeaufsichtigte Upgrades, die zu einem ungünstigen Zeitpunkt laufen, bereiten dir Kopfschmerzen.

Ping mich an!

Fortgeschrittenere Setups überwachen irgendwie den aktuellen Zustand des Systems und benachrichtigen den Administrator, dass ausstehende Updates vorliegen. Das kann entweder mit Tools wie apticron[arch] geschehen, das dich per Mail benachrichtigt, sobald neue Updates verfügbar sind. Noch professionellere Setups nutzen ein dediziertes Monitoring-System wie icinga2[arch], um Alarme auszulösen.

Ist unsere Kette gebrochen?

Nein, eigentlich nicht. Wenn du deine Updates regelmäßig ausführst, kümmert sich dein Paketmanager um all die Anforderungen, die wir definiert haben:

• Zeitnah aktualisieren — Erledigt! Wir werden benachrichtigt, sobald etwas zu installieren ist, und führen das Update sofort aus
• Sichere Quellen — Erledigt! Alle unten definierten Anforderungen sind erfüllt
• Vertrauenswürdige Repositories — Erledigt! Die Standard-Repositories deiner Distribution werden von denselben Leuten gepflegt, die auch deine Distribution gebaut haben. Wenn du denen nicht vertraust, hättest du die Distribution gar nicht erst genutzt.
• Vertrauenswürdige Beiträge — Erledigt! Code-Änderungen werden von der Open-Source-Community überprüft, das Paketieren der finalen Artefakte übernimmt ein Paketmanager, der für den Paketinhalt verantwortlich ist. Zumindest bei Debian gibt es zusätzlich eine sehr lange Testphase, bevor Dinge in Produktion gehen.
• Integrität sicherstellen — Erledigt! Dein Paketmanager prüft Signaturen und Prüfsummen der zu installierenden Pakete und warnt dich, falls etwas nicht stimmt

Ab damit in einen Container

Da wir also gehört haben, dass ein containerisierter Dienst sicherer ist, werfen wir alle unsere Dienste in ihre eigenen Container. Wir haben immer noch unsere Bare-Metal-Box mit Linux und einem Docker-Daemon, aber alles andere versteckt sich in mehreren Containern. Um unser Host-System aktuell zu halten, nutzen wir genau dieselbe Strategie, die wir im letzten Kapitel besprochen haben. Da unser Host-System aber aus nicht viel mehr als einem auf einem Kernel laufenden dockerd besteht, gibt es dort auch gar nicht so viele Updates.

Frischer Anstrich für deine Container

Wie aktualisiert man einen Container? Man aktualisiert das Docker-Image und startet die Maschine mit der neuen Image-Version neu. Ist das also nur ein weiterer Zweizeiler?

1docker pull imagename
2docker restart myContainer

Auf den ersten Blick: ja. Aber konzentrieren wir uns zunächst darauf, wie man alle seine Container aktuell hält. Vielleicht hast du eine ganze Menge davon laufen — willst du die wirklich alle einzeln von Hand aktualisieren?

Es gibt mehrere Lösungen, um alle Container auf einmal zu aktualisieren. Eine davon ist Watchtower[arch]. Es betreibt einen zusätzlichen Container, der alle anderen Container inspiziert und deine aktuellen Image-Versionen mit den neuesten Versionen in der Registry vergleicht. Wird ein neueres Image erkannt, lädt es dieses herunter, reißt deinen Container ab und startet ihn mit der neuesten Image-Version neu. Das alles geschieht ganz ohne manuelles Eingreifen.

Dem Wal vertrauen?

Prüfen wir noch einmal unsere Anforderungen für das Container-Szenario. Unsere Vertrauenskette ist nicht gebrochen, aber angerostet:

Die Quellen unserer Images sind nicht so sicher wie die Paket-Repositories deiner Distribution. Die Bauanleitungen für die Images (auch bekannt als Dockerfiles) sind oft auf GitHub oder anderswo öffentlich verfügbar, aber es gibt auch viele Images, die nicht einmal ihre Dockerfiles veröffentlichen. Zusammengefasst:

• Wenn das Dockerfile nicht verfügbar ist, nutzt du eine Blackbox ohne einfache Möglichkeit zur Einsicht, was eigentlich vor sich geht. Du kannst dir zwar immer die Historie deines Docker-Images ansehen, um eine Vorstellung davon zu bekommen. Aber ist das wirklich der richtige Weg für jedes einzelne Image-Update?
• Wenn das Dockerfile verfügbar ist, hängt es davon ab, ob du überprüfen kannst, dass das veröffentlichte Dockerfile wirklich die Bauanleitung für das von dir verwendete Image ist. Bei Docker Hub wird das implizit durch deren Build-Prozess sichergestellt. Andernfalls gibt es keinen kryptographisch sicheren Weg (wie Signaturen), das wirklich zu belegen.

Noch problematischer aus Sicherheitssicht ist der Inhalt des Images. Mit Docker ist der Prozess der Container-Aktualisierung noch stärker automatisiert (was auch ein Vorteil ist). Das bedeutet aber auch, dass in bestimmten Szenarien der Autor des Dockerfiles ganz allein entscheidet, welche Änderungen in Produktion gehen. Besonders bei kleineren Projekten gibt es überhaupt keine Code-Reviews.

Fazit

Die Frage, ob man einem Open-Source-Projekt vertrauen soll oder nicht, ist so alt wie Open Source selbst. Das Containerisieren deiner Dienste fügt lediglich eine weitere (potenziell) unsichere Schicht zu denen hinzu, die du in einem klassischen Szenario mit Daemons bereits hast. Immerhin gewinnst du definitiv an Sicherheit, da im Fehlerfall alles auf den bösartigen Container isoliert bleibt. Andererseits erhöht sich auch die Wahrscheinlichkeit, sich etwas Bösartiges einzufangen — besonders bei kleineren Projekten, die vielleicht nicht einmal Open Source sind. Welcher Weg der richtige ist, hängt immer von deinem Wissen über die verwendete Technologie und deiner Bereitschaft ab, Zeit in Sicherheit zu investieren. Sei dir einfach bewusst, dass du mehr Dinge berücksichtigen musst, als wenn du die Repositories deiner Distribution nutzt.

Docker-Container sind also unsicher — aber nicht mehr als deine klassischen Systeme, wenn du es richtig machst ;-)

Der Blog startete ursprünglich 2014 und war bis Ende 2016 online. Damals lag mein Fokus vor allem auf Amateurfunk- und IoT-Inhalten. Diese Themen wurden von vielen Lesern geschätzt. Trotzdem musste der alte Blog irgendwann enden, da sich auch meine Interessen mit der Zeit verändert haben. Ich war schlicht nicht mehr in der Lage (oder willens :-)), die nötige Zeit zu investieren, um hochwertige Artikel zu Themen zu schreiben, die nicht mehr mein Hauptfokus sind.

Was ist in Zukunft zu erwarten?

Wie der Titel schon sagt: Cloud. Architektur. IoT. Und jede Menge dazwischen!

Ich habe den zukünftigen Fokus dieses Blogs stärker in Richtung IT verschoben, als es in der Vergangenheit der Fall war. Es wird Geschichten aus dem Alltag eines Entwicklers geben, Beiträge, die aktuelle Technologien kontrovers diskutieren, und noch viele andere Dinge, auf die man sich freuen kann.

Bleib also dran und folge mir auf Twitter[arch], um keinen der kommenden Beiträge zu verpassen!