Über einige Jahre hinweg liefen bei mir einige Fujitsu Futro S920 als verlässliche, lautlose Server für verschiedene Netzwerkdienste im lokalen Netz. Mittlerweile habe ich die Infrastruktur schrittweise erneuert und die alten Instanzen durch neuere Futro S9010 ersetzt.

Bevor die ausgemusterten S920-Geräte demnächst auf eBay 🛒Affiliate-Link: Bei einem Kauf über diesen Link erhalten ich möglicherweise eine kleine Provision – ohne zusätzliche Kosten für dich. Ein Weg, meine Arbeit zu unterstützen. den Besitzer wechseln, folgt hier eine sachliche Zusammenfassung zu Hardware, Stromverbrauch und OpenBSD-Kompatibilität. Auch wenn die Architektur nicht mehr ganz taufrisch ist, leisten diese Thin Clients als stromsparende Nodes nach wie vor gute Dienste.

Es wurde mal wieder Zeit: Der letzte größere Upgrade-Sprint in den OpenBSD-Ports lag bereits eine Weile zurück, und auf meiner To-Do-Liste hatten sich etliche Pakete angesammelt, die dringend etwas Zuneigung brauchten. Wer das OpenBSD-Ports-Ökosystem kennt, weiß, dass ein solches Update selten nur aus dem Anpassen einer Makefile-Versionsnummer besteht. Es ist vielmehr eine muntere Entdeckungsreise durch Abhängigkeitsbäume, Build und Test Changes, Build Fehler, etc.

In den vergangenen Tagen und Wochen habe ich mich durch verschiedene Themengebiete gearbeitet: Von Software Defined Radio (SDR) über Pentesting- und Web-Security-Tools bis hin zur Infrastruktur-Automatisierung mit OpenVOX und der digitalen Forensik rund um Plaso. Hier ist ein Überblick über die Arbeit und die Geschichten hinter den Commits.

Ein verlässliches Arbeitstier ist etwas Feines. Über Jahre hinweg leistete mir ein betagter Desktop-Knecht treue Dienste für das tägliche Internet-Browsing, kleine Admin-Aufgaben und das gelegentliche Kompilieren von Ports unter OpenBSD. Es handelt sich um einen HP Compaq Pro 6300 SFF (hergestellt um das Jahr 2012).

Hier ist der vollständige Kernel-Log (dmesg) des alten HP-Systems zum Nachlesen:

“Alle an Bord, Scotty?“

Wer openHAB kennt, weiß: Die Lernkurve ist steil, aber die Möglichkeiten sind extrem vielseitig. Schnell wird einem klar, dass starre Zeitpläne ein Haus noch nicht smart machen. Ein echtes Smart Home muss wissen, wer an Bord ist, um die Lebenserhaltungssysteme (Heizung, Licht, Alarmanlage) sinnvoll zu steuern.

Als alter Trekkie stand das Design für mein Dashboard schnell fest: Die klassische TOS-Crew (The Original Series) sollte unsere fünfköpfige Familie abbilden. Wenn ein Crewmitglied an Bord ist, leuchtet das Avatar-Bild im UI-Widget farbig. Verlässt jemand das Schiff, schaltet die Anzeige auf Grayscale (Graustufen) und signalisiert den “Away Mission”-Status.

Meine Hausautomation läuft vollständig auf OpenBSD, ein solides Fundament für die Verwaltung unseres Haushalts. Doch selbst auf einem sicheren Betriebssystem kann die interne Familienlogistik eine Herausforderung sein – besonders wenn die Kinder entdecken, dass sie den Fernseher im Wohnzimmer von ihren Tablets aus ausschalten oder versehentlich an den Einstellungen des Hauptthermostats herumspielen können.

Mit dem Ausbau meines Smart Homes stand ich vor einer klaren Notwendigkeit: Ich musste bestimmte Geräte und sensible Steuerelemente vor meinen Kindern verbergen, während für die Erwachsenen weiterhin alles sichtbar bleiben sollte.

Wer meine bisherigen Beiträge zum Thema Home Automation verfolgt hat, weiß, dass ich mich seit einiger Zeit mit Zigbee beschäftige. Alles begann mit dem Mitschneiden von Frames im Artikel Zigbee-Sniffing unter OpenBSD: Deep Dive mit dem TI CC2531. Aus Neugier habe ich mir dann einen neueren Zigbee-Koordinator besorgt und im Folgeartikel Zigbee Home Automation auf OpenBSD: Sonoff Dongle-M und openHAB über die Anbindung an eine Automatisierungsplattform berichtet.

Vor Kurzem habe ich einen Posten gebrauchte Thin Clients ergattert, die sich als perfekte Hardware für einen dedizierten Smart-Home-Controller herausgestellt haben. Hier beschreibe ich, wie ich ein stabiles, isoliertes Gateway auf Basis von OpenBSD 7.9-snapshot, Zigbee2MQTT, Mosquitto und openHAB aufgebaut habe.