Was das Badge zeigt

Jeder Beitrag, in dem ein Modell an der Formulierung mitgeschrieben hat, trägt jetzt ein kleines Badge neben Datum und Tags: „IDEA". Ausgeschrieben: I Direct, Engine Assembles – Idee, Konzept und fachliche Einordnung stammen von mir, das Modell hat nur den Text zusammengesetzt. Ein Tooltip erklärt das beim Hovern oder Fokussieren:

I Direct, Engine Assembles — the idea, concept and thinking are mine; the prose was drafted with AI assistance.

Technisch ist es ein einzelnes Flag, das meine Blog-engine auswertet – pro Sprachversion, nicht pro Beitrag. Ein Post kann im Original handformuliert sein und nur in der Übersetzung das Badge tragen, oder umgekehrt.

Was der AI Act von mir verlangt – nämlich nichts

Der Teil, der mich amüsiert hat, als ich es nachgelesen habe: Artikel 50 Abs. 4 AI Act verpflichtet zur Kennzeichnung von KI-generiertem Text zu Angelegenheiten von öffentlichem Interesse – aber nur, wenn der Inhalt kein menschliches Review durchlaufen hat und keine natürliche oder juristische Person die redaktionelle Verantwortung trägt. Ich lese jeden Satz vor Veröffentlichung, korrigiere, kürze, widerspreche mir selbst und stehe für jede Behauptung im Text mit meinem Namen ein. Damit falle ich aus dem Anwendungsbereich raus, bevor er überhaupt anfängt.

Ich mache das Badge trotzdem. Nicht weil ein Gesetz es verlangt, sondern weil Leser hier ein Recht darauf haben zu wissen, wessen Handschrift sie gerade lesen – auch wenn es rechtlich niemanden interessiert außer mir.

Was sich dadurch nicht ändert

Jeder Post fängt mit einer Gliederung an, die ich selbst schreibe: Stichpunkte, Kernthesen, Code-Beispiele, die tatsächlich von mir stammen und nicht erfunden sind. Was eine KI übernimmt, ist ausschließlich die letzte Meile – Sätze glattziehen, Wiederholungen raus, bei Übersetzungen den Zieltext produzieren. Vor Veröffentlichung lese ich jeden Beitrag komplett durch, ändere, was falsch klingt oder nicht meine Stimme trifft, und stehe fachlich hinter jeder Zeile. Das Badge ändert daran nichts, es macht nur sichtbar, an welcher Stelle im Prozess die KI mitgeschrieben hat.

Für einen Blog, der öfter über KI-Architekturen schreibt als die durchschnittliche Konkurrenz, wäre es unpassend gewesen, selbst intransparent zu bleiben, wo der eigene Text herkommt. Wer im eigenen Unternehmen irgendwann offenlegen muss, welche Inhalte KI-unterstützt entstanden sind, kann sich das Prinzip gerne kostenlos abschauen.

Warum “einfach selbst hosten” an der Kostenrealität scheitert

Ein Modell in Frontier-Qualität - GPT-, Claude- oder Gemini-Klasse - selbst zu betreiben, ist keine Option, die für ein Team mit fünf, fünfzig oder hundert Leuten realistisch auf dem Tisch liegt. Diese Modelle laufen auf Clustern mit zwei- bis dreistelliger H100-Anzahl. Selbst wer sich das leisten kann, bekommt nie die gleiche Modellqualität wie die Anbieter selbst, die kontinuierlich nachtrainieren.

Die eigentlich interessante Erkenntnis: Man braucht diese Modellklasse gar nicht für jede Anfrage. Ein Großteil dessen, was in Unternehmen an ein LLM geschickt wird, ist trivial - Zusammenfassen, Umformulieren, Kategorisieren, einfache Extraktion. Dafür reicht ein 8B- oder 14B-Modell auf einer einzelnen Consumer-GPU völlig aus. Die Frage ist also nicht “eigenes Rechenzentrum oder Cloud”, sondern: welche Anfrage braucht wirklich das teure Modell, und welche nicht.

Das eigentliche Problem ist der Kontext, nicht das Modell

Datensouveränität wird gern als Deployment-Entscheidung behandelt: “Wir nutzen jetzt ein On-Premise-Modell.” Das greift zu kurz. Die Frage, ob eine Anfrage die eigene Infrastruktur verlassen darf, lässt sich nicht auf Modellebene beantworten, sondern nur pro Anfrage - auf Ebene des Kontexts, der gerade im Prompt steckt.

Zwei Support-Tickets aus derselben Warteschlange können völlig unterschiedliche Anforderungen haben. “Wie ändere ich mein Passwort?” ist unkritisch für die Cloud. “Herr Meier, geboren am 3.4.1981, Kundennummer 88213, beschwert sich über die Abrechnung seiner Berufsunfähigkeitsversicherung” ist es nicht. Ein statisches Deployment - alles lokal oder alles Cloud - behandelt beide Fälle gleich und ist damit entweder unnötig teuer oder unnötig riskant.

Der Router: ein sensitivity-aware Gateway statt Bauchgefühl

Die Komponente, die diese Entscheidung trifft, bevor irgendein Modell die Anfrage sieht, hat in der Praxis mehrere Namen, je nachdem aus welcher Ecke man kommt. Als AI Gateway bzw. LLM Gateway bezeichnen es Anbieter, die den Fokus auf PII-Erkennung¹ legen: Der Prompt wird am Gateway gescannt, und bei einem Treffer geht die Anfrage automatisch an ein On-Premise-Modell statt an die Cloud-API. In der Forschung zu Routing-Architekturen taucht der Begriff Sensitivity-aware Routing bzw. Semantic Routing auf - ein Router vor der Inference-API entscheidet anhand von Datensensitivität, Aufgabenkomplexität und Nutzergruppe, welches Modell die Anfrage bekommt. Am nächsten an dem, was ich mir vorstelle, kommt die Hybrid Local-Cloud Architecture: ein vertrauenswürdiger, lokaler “Local Controller” übernimmt Planung, Routing und einfaches Reasoning selbst und delegiert nur bei Bedarf an ein nicht-vertrauenswürdiges “Cloud Language Model”.²

Wichtig ist das Prinzip, nicht der Name: Klassifizierung passiert, bevor ein Prompt irgendeine Grenze überschreitet, und im Zweifel wird lokal verarbeitet, nie im Zweifel an die Cloud delegiert. Fail closed, nicht fail open. In Code sieht die Entscheidungslogik - bewusst vereinfacht - etwa so aus:

 1// Route entscheidet, welche Stufe des Stacks eine Anfrage bearbeitet.
 2// Sensible Kontexte verlassen die eigene Infrastruktur nie - auch dann nicht,
 3// wenn das lokale Modell für die Aufgabe eigentlich zu schwach ist.
 4func Route(ctx context.Context, req Prompt) Tier {
 5	if classifier.ContainsSensitiveContext(ctx, req) {
 6		return TierDatacenterGPU
 7	}
 8	if req.Complexity <= complexityTrivial {
 9		return TierLocalOllama
10	}
11	return TierCloud
12}

Die Klassifizierung selbst muss dabei nicht kompliziert sein. Ein Regelwerk aus Regex-Mustern für Kundennummern, IBANs und Namen aus dem eigenen CRM erkennt einen Großteil der Fälle. Für alles, was Muster-basiert nicht sauber zu fassen ist, reicht oft ein sehr kleines lokales Modell - etwa ein 1B- bis 3B-Modell, das nur eine Frage beantwortet: “Enthält dieser Text personenbezogene oder vertrauliche Informationen? Ja/Nein.” Das läuft in Millisekunden auf jeder halbwegs aktuellen GPU und muss selbst nicht gut im eigentlichen Task sein - nur beim Erkennen, wann Vorsicht angebracht ist.

Die kaskadierte Architektur: Workstation → lokale GPU im Netz → Cloud

Aus dem Routing-Prinzip ergibt sich daraus eine dreistufige Kaskade:

 1Anfrage
 2│
 3▼
 4Sensibler Kontext erkannt? ──ja──▶ lokale GPU im Datacenter (RTX 3090, Qwen2.5-14B o.ä.)
 5│ nein
 6▼
 7Trivial genug für die Workstation? ──ja──▶ Ollama lokal auf dem Laptop
 8│ nein
 9▼
10Cloud-Modell (Claude, GPT, Gemini, ...)

Stufe 1 - Ollama auf der Workstation. Autocomplete, kurze Zusammenfassungen, einfache Umformulierungen laufen direkt auf den Rechnern der Mitarbeitenden, ohne dass überhaupt eine Netzwerkanfrage nötig ist. Latenz nahe null, Kosten nahe null.

Stufe 2 - eine GPU im eigenen Netz. Alles mit sensiblem Kontext, das mehr Leistung braucht als ein Laptop liefert, geht an eine zentrale GPU im Datacenter oder Homelab, bedient über vLLM oder Ollama im Server-Modus. Diese Stufe ist der eigentliche Kern der Datensouveränität: Sie macht “lokal” praktikabel, ohne dass man gleich einen Cluster braucht. Mit entsprechender Queue ist das auch für Teams mit mehreren gleichzeitigen Nutzern skalierbar.

Stufe 3 - Cloud. Alles, was weder sensibel noch trivial ist, geht dorthin, wo die beste verfügbare Modellqualität liegt. Das ist der pragmatische Teil: Man muss nicht jede komplexe Aufgabe lokal lösen wollen, nur weil man kann.

Was eine RTX 3090 für ~5 Mitarbeitende leistet

Die 24 GB VRAM der RTX 3090 sind der Grund, warum sie in Homelab- und Kleinteam-Setups so oft auftaucht: genug für 8B-Modelle in kaum verlustbehafteter Quantisierung und für 14B-Modelle in Q4, mit noch Luft für Kontext.

¹ Öffentlich kursierende Richtwerte für Einzel-Anfragen, keine eigenen Messungen - für den produktiven Einsatz mit mehreren gleichzeitigen Nutzern vorher selbst benchmarken, insbesondere bei parallelen Requests.

Für ein Team von fünf Leuten, das die GPU nicht dauerhaft sättigt, reicht eine einzelne 3090 für die zweite Stufe der Kaskade in der Regel aus. Wenn es mehr sein soll, ein DGX Spark für wenige tausend Euro. Immer vorausgesetzt, die wirklich rechenintensiven Aufgaben landen ohnehin in Stufe 3. Die Rechnung dahinter, überschlagen: 350 Watt TDP, sagen wir 6 Stunden aktive Last pro Arbeitstag, macht bei 20 Arbeitstagen im Monat rund 42 kWh - bei 30 Cent/kWh knapp 13 Euro Strom. Dazu die Abschreibung der Karte über zwei bis drei Jahre. Das liegt weit unter dem, was fünf Personen an Cloud-API-Kosten verursachen würden, wenn jede sensible Anfrage an ein Frontier-Modell ginge - vor allem, weil Compliance relevante Anfragen tendenziell lang sind (viel Kontext, viele Dokumente) und damit bei tokenbasierter Abrechnung überproportional teuer.

Grenzen: wann lokale Modelle für den Job einfach zu schwach sind

Der ehrliche Teil dieser Architektur: Ein Qwen2.5-14B in Q4 ist kein Ersatz für ein Frontier-Modell. Bei komplexem Reasoning, langen Dokumenten mit vielen Querverweisen oder Aufgaben, die echtes Weltwissen jenseits der Trainingsdaten brauchen, stößt man schnell an Grenzen. Wem das nicht bewusst ist, der bekommt am Ende schlechtere Ergebnisse und rechtfertigt diese als Datenschutz-Kompromiss - was auf Dauer niemand mitträgt.

Die Lösung ist nicht, die Grenze zu verschieben, sondern eine dritte Option zwischen “lokal, aber schlechter” und “Cloud, aber riskant” einzuziehen: Redaction vor dem hand-off an die Cloud. Namen, Kundennummern und andere Identifikatoren werden vor dem Cloud-Call durch Platzhalter ersetzt und nach der Antwort wieder eingesetzt. Das lokale Modell übernimmt dabei nur die Anonymisierung - eine Aufgabe, für die auch ein kleines Modell gut genug ist -, während die eigentliche, komplexe Aufgabe an ein starkes Cloud-Modell geht, ohne dass Klartext-PII die eigene Infrastruktur verlässt. Das ist mehr Aufwand als reines Routing, aber deutlich weniger als ein eigenes Frontier-Modell zu betreiben.

Was das für eine Organisation bedeutet

Das Prinzip dahinter ist dasselbe wie bei der Netzwerksegmentierung meiner IoT-Geräte: Man vertraut nicht blind dem gesamten System, sondern definiert Grenzen, durch die bestimmte Daten schlicht nicht durch können. Und das unabhängig davon, ob eine Anwendung sich später falsch verhält. Bei IoT-Geräten sind das VLANs und Firewall-Regeln. Bei LLM-Anfragen ist es ein Router vor der Inference-API.

Skaliert man das von einem Fünf-Personen-Team auf eine größere Organisation, wird aus dieser technischen Entscheidung schnell eine Governance-Frage: Wer pflegt die Klassifizierungsregeln, wenn sich die Datenkategorien ändern? Wie weist man gegenüber Kunden oder Aufsichtsbehörden nach, dass ein bestimmter Prompt tatsächlich nie die eigene Infrastruktur verlassen hat? Genau dieser Audit-Trail ist der Punkt, an dem “wir nutzen ein lokales Modell” zu einer belastbaren Aussage wird statt zu einer Behauptung. Aus einer Homelab-Lösung mit einer einzelnen GPU wird auf einmal eine Lösung, die man auch einem Wirtschaftsprüfer erklären kann.

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!