Selbermachen

Es hat ein ganzes Stück gedauert um ein Haar in der Docker-Suppe zu finden, jetzt ist es so weit: Irgendwie kann man aus einem Docker-Container heraus kein WakeOnLan Magic Packet versenden. Und das trifft eines der coolsten FHEM/Telegram Features, nämlich dass man den Backup-/Seafile-Server von unterwegs in sage und schreibe 4 Sekunden aus den Standby zum Laufen bekommt.
Durch einen Umweg, von hinten mit dem Messer durch die Brust, geht es allerdings doch: Wenn mit Telegram der Befehl zum Starten rein kommt, dann startet FHEM im Container nicht mehr etherwake direkt, sondern loggt sich auf dem Host per ssh ein und startet es dort. Die Lösung ist nicht wirklich sauber und verstößt wahrscheinlich gegen die reine Docker-Lehre, funktioniert aber prima!

Seit Donnerstag ist der neue Rechner online und der Raspberry aus. Der Wechsel hat, abgesehen von ein paar Kleinigkeiten, eigentlich reibungslos geklappt. Das System ist pfeilschnell, Ziel erreicht! Und noch viel mehr: alles läuft in Docker-Containern, auf btrfs, mit Snapshots bei Updates und seit heute mit Git verwaltet auf einem eigenen Gitea-Server eingecheckt.
Die letzte Woche war nicht nur sehr lehrreich sondern auch kräftezehrend, mehr als 5 Stunden Schlaf waren es nie, dafür viel zu viel Kaffee. Aber das Ergebnis kann sich sehen lassen. DevOps@Home, so viel IT gab es hier schon lang nicht mehr. Ich bin stolz.

Bei Docker ist auch nicht alles Gold was glänzt, soviel vorab. Also das mit Docker ist so wie mit jedem anderen komplexen System, man muss sich schon etwas damit beschäftigen und es ist am Anfang noch recht unübersichtlich. Deshalb war der Plan eine grafische Oberfläche dafür zu installieren, z.B. Portainer. Wenn man da etwas sucht, findet man auch schöne Anleitungen. Aber irgendwie wollte sich das aktuelle Portainer-Image nicht mit Docker verbinden, zum Kotzen. Gestern wurde dann genau nach dieser Anleitung vorgegangen und wieder nichts! Auf Git habe ich dann den entscheidenden Tipp gefunden und kurzerhand mal eine alte Version installiert:
sudo docker run -d --name="portainer" --restart on-failure -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer:1.16.2
Genau hier sieht man dann die Vorzüge und Nachteile von Docker – man kann ohne weiteres unterschiedliche Versionen parallel installieren, ist aber bei der Verwendung von fremden Images darauf angewiesen dass die auch fehlerfrei funktionieren. Langer Rede kurzer Sinn: Läuft endlich! Danach dann gleich noch MQTT hinterher, funktioniert auch. Und MySQL auch. Heute steht dann FHEM auf der Agenda, das wird kein Selbstläufer, aber ich bin guter Dinge!

Mühsam ernährt sich das Eichhörnchen. Heute wurde Ubuntu 18.04 LTS mit btrfs installiert, eigentlich sollten die Snapshots wie beim Server Anfang des Jahres umgesetzt werden, ganz zufällig bin ich aber auf apt-btrfs-snapshot gestoßen, ein Glückstreffer. apt-btrfs-snapshot ist ein „Hook for providing apt based btrfs snapshots“, macht also einen Snapshot bevor mit apt was installiert wird. Einen Rollback gibt es mit apt-btrfs-snapshot set-default Backupname. Funktioniert, sau cool!
Hier ist dann noch ganz schön beschrieben wie man VNC auf Ubuntu einrichtet und sich den Desktop dann am Mac anschaut. Das gsettings set org.gnome.Vino require-encryption false ist wichtig. Kann man bestimmt auch mal gebrauchen.
Portainer wollte heute wieder nicht laufen, verbindet sich zwar, kann aber nichts auslesen. Das ist ärgerlich, aber wenigstens konnte zurückgerollt werden und et voila schaut das System wieder so aus als ob es noch niemals Docker gesehen hat.

Die Sache mit dem Raspberry und der kaputten SD-Karte hat mir keine Ruhe gelassen! Bei Amazon gibt es günstige Mini-PCs als Raspberry-Alternative, bei ARLT sind sie etwas teuerer aber dafür gleich zum Mitnehmen und mit besserer Hardware. Läuft.
Das Ziel für dieses Wochenende war klar: Ubuntu LTS samt Btrfs drauf, dann Docker und danach eine Docker-basierte FHEM-Installation. Samstag Abend ist Ubuntu LTS mit Snapper gelaufen, Sonntag Mittag FHEM auf Docker, Sonntag Abend ist der Plan für Montag eine Neuinstallation. Fakt ist dass die Snapper-Snapshots unter Ubuntu bestenfalls nicht endanwendertauglich sind. Und diese Docker Installation schaut zwar gut aus, schlägt aber in die gleiche Kerbe. Neue Woche neues Glück.

Ach ist das ein Drama. Jetzt wo alle Steckdosen geflasht sind, der Bewegungsmelder Bewegungen meldet und die Früchte dieser Arbeiten mit FHEM fassbar gemacht werden sollen, raucht der FHEM-Raspberry ab. Der Filesystem-Check checkt und checkt und checkt und checkt. Ein Raspberry ist halt kein Server nicht. Heimautomatisierung, Raspberry und Backup das waren bis jetzt zwei getrennte Themen, das war Basteln am Feierabend. Strategisch betrachtet leichtsinnig.

Die Challange gestern Abend war einen Bewegungssensor (PIR) an einen ESP8266 NodeMCU anzuschließen. Die Bewegungsmelder gab es vor einiger Zeit mal im Internet für unter 1 € das Stück und seitdem warten sie darauf sinnvoll eingesetzt zu werden. Wenn man bei Google mal „ESP8266 PIR“ eingibt, dann merkt man schnell dass das Thema keine wirklich große Herausforderung darstellt, aber eben nur auf den ersten Blick, die Tücken stecken nämlich im Detail!
Die PIRs arbeiten mit 5 V und der ESP8266 mit 3,3 V. Schließt man den PIR an einem Arduino an, dann wird der immer funktionieren, schließt man ihn an einem ESP8266 NodeMCU an, dann nur wenn man ihn am VIN Pin anschließt, da liegen nämlich die 5 V vom USB Anschluss an. Von hinten mit dem Messer durch die Brust geht es aber auch, der PIR hat intern einen Spannungswandler, der die Eingangsspannung von 5 V auf die intern verwendeten 3,3 V runter regelt. Überbrückt man das Ganze, dann gehen die PIRs auch direkt mit den 3,3 V des ESP8266!.
Warum ist das wichtig? Wenn man die Schaltung klein halten will, z.B. weil sie in eine Unterputzdose soll, dann wird man nicht den großen ESP8266 NodeMCU mit USB nehmen, sondern eher den mit blanken ESP8266 und da muss man dann ohne 5 V auskommen.