RaspberryMatic – Neue Docker/Container-Alpha-Testversion

[jmaus]

Hallo Zusammen,

nun liegt Weihnachten 2020 schon wieder zwei Wochen hinter uns und ich hoffe jeder konnte sich ausreichend erholen und neue Kräfte für das Jahr 2021 tanken. Und auch wenn ich mich selbst recht gut erholen konnte, so sind die Arbeiten an RaspberryMatic in der Tat selbst über Weihnachten und Neujahr nicht gänzlich zum erliegen gekommen.

Schon länger gab es ja bereits den Plan nach der Einführung der Unterstützung virtueller OVA-basierter Platformen (ESXi, Proxmox, etc.) auch sich einmal damit zu beschäftigen, ob auch eine Docker/Container Implementation von RaspberryMatic nun durch die unter anderem vor kurzen umgesetzte 64bit/32bit multilib Umgebung einfacher möglich geworden ist. Und dankenswerterweise ist die RaspberryMatic-Community gerade zum Jahresende 2020 um einige Personen angewachsen, die nicht nur regelmäßige WebUI Patches eintrudeln lassen (danke dafür nochmal besonders an @jp112sdl), sondern vor einigen Tagen ist der Nutzer @vegetto (in GitHub: @angelnu) auf mich mit einem exzellenten PullRequest (PR) zugekommen der nicht nur eine erste grundlegende Möglichkeit einer Docker/Container-Implementation von RaspberryMatic aufgezeigt hat. Dieser PR hat sich sogar in kurzer Zeit mehr als nur brauchbar herausgestellt. Und was soll ich sagen, aus der hervorragenden Vorarbeit von @vegetto ist in einer gemeinschaftlichen Arbeit über ein paar Tage eine erste Docker/Container Implementation hervorgebracht worden, die es meiner Meinung schon jetzt Wert ist diese einem größeren Testerkreis als Alphaversion an die Hand zu geben um so erste Erfahrungen, Fehlerberichte und ähnliches einzusammeln.

Wem also der Begriff "Docker" bzw. Linux "Container" kein Fremdwort ist und wer vielleicht sogar schon länger auf solch eine Umsetzung gewartet hat um RaspberryMatic auf einem bestehenden x86/amd64 oder arm/arm64 Linux-basiertem bzw. Raspbian/RaspberryPiOS-System in einer Docker-Umgebung lauffähig zu bekommen, dem sei die aktuellen Alphaversionen dieser Docker Implementation ans Herz gelegt. Und wer aber mit diesen Begriffen (noch) nichts angefangen kann, dem sei gesagt, dass mit der hervorragenden Umsetzung durch @vegetto ein weiterer Schritt getan wurde die RaspberryMatic-Familie zu erweitern.

Wer also gerne auf seinem bestehenden Linux-System (wenn auch nur aus interesse) die aktuelle Alphaversion der Docker-Implementation von RaspberryMatic installieren und hoffentlich sogar testen will, dem sei die folgende temporäre Installationsanleitung an die Hand gegeben:

https://github.com/jens-maus/RaspberryMatic/wiki/Docker

Auf dieser (momentan nur englischsprachigen) Seite sollten die grundlegenden Schritte dokumentiert sein, die man durchführen muss um die Alphaversion des Docker Container auf seinem existierenden Linux system herunterzuladen, zu starten und zu nutzen. Wie schon erwähnt ist das mometan alles "Work in Progress" und folglich wird sich auch an dieser Anleitung sicherlich noch einiges ändern und auch im Container kann sich natürlich noch das Eine oder Andere so ändern, das er vielleicht mit Vorversionen inkompatibel wird. Aber für erste Tests und zum Einsammeln von Rückmeldungen, Fehlerberichten und Featureerweiterungen sollte es grundsätzlich reichen.

BITTE BEACHTEN:
Bitte noch beachten, dass bei Nutzung eines Funkmodules (RPI-RF-MOD, HM-MOD-RPI-PCB) es notwendig wird die von Alexander Reinert im Rahmen des piVCCU Projektes dankenswerterweise entwickelten Kernelmodule im Hostsystem selbst (auf dem der Docker gestartet wird) vor Nutzung der Docker-Variante zu installieren. Das beschränkt momentan die Nutzung auf Debian-basierte Systeme wie Debian, Ubuntu oder Raspbian/RaspberryPiOS. Der in der Anleitung genannte "deploy.sh" Skript versucht zwar diese Kernelmodule sowie andere Abhängigkeiten voll-automatisch zu installieren. Trotzdem sei hier erwähnt, das bei der Nutzung (vor allem wegen dem Alphastadium der Umsetzung) Vorsicht geboten ist, denn es werden hier Veränderungen am Host-System vorgenommen und momentan gibt es noch kein "undeploy.sh" skript um diese Änderungen wieder in einfacher weise rückgängig zu machen.

Wer also entsprechende Vorkenntnisse hat oder den Mut mitbringt das einmal selbst zu testen, ist gerne aufgerufen das aktiv zu tun. Und vielleicht schaffen wir es dann sogar so weit, das mit der nächsten geplanten Release-Version die Docker Variante auch gleich unter die breite Nutzerschaft geworfen werden kann. Für Rückmeldungen, Fehlerreports, etc. kann zusätzlich zu diesem Beitrag hier, auch gerne das passende Issue-Ticket im GitHub (siehe https://github.com/jens-maus/RaspberryMatic/issues/786) genutzt werden.

Bitte also reichlich testen und hier rückmelden wenn es Erfolge, Misserfolge oder auch Fragen bzgl. der Docker/Container Implementation gibt.

Viel Spass damit!

[deimos]

Hi,

leider erwähnst du nicht die riesige Einschränkung des ganzen: Es funktionieren nur Debian basierte Host Systeme, welche von piVCCU unterstützt werden, weil ungefragt die piVCCU Pakete genutzt werden und auch bei jeder Installation über meinen Server runtergeladen werden. Und das Deploy Script macht auch genau das, was ich bereits bei YAHM als extrem störend empfunden habe, es ändert ungefragt Systemparameter und installiert Pakete per apt mit dem sehr gefährlichen Parameter "-y", welches ein System durchaus mal komplett unbrauchbar machen kann.

Viele Grüße
Alex

[jmaus]

leider erwähnst du nicht die riesige Einschränkung des ganzen: Es funktionieren nur Debian basierte Host Systeme, welche von piVCCU unterstützt werden

Oh, stimmt natürlich, das habe ich in der Euphorie komplett übersehen, werde ich aber natürlich entsprechend noch anpassen und dir auch entsprechende Credits geben, denn ohne deine Kernel Module wäre das natürlich auch nur eingeschränkt möglich gewesen. Also Mea culpa und ich werde Dokumentation&co natürlich anpassen.

weil ungefragt die piVCCU Pakete genutzt werden und auch bei jeder Installation über meinen Server runtergeladen werden.

Oh, an das belasten deiner Bandbreite habe ich natürlich gar nicht gedacht. Wenn du kein Problem damit hast, kann ich gerne auf meinen Servern einen mirror deiner Pakete einrichten und dann in dem deploy Skript meinen mirror einstellen damit die RaspberryMatic Nutzer diesen nutzen und dein Server nicht unnötig belastet wird . Wäre das ok für dich?

Und das Deploy Script macht auch genau das, was ich bereits bei YAHM als extrem störend empfunden habe, es ändert ungefragt Systemparameter und installiert Pakete per apt mit dem sehr gefährlichen Parameter "-y", welches ein System durchaus mal komplett unbrauchbar machen kann.

Das ist ein guter Hinweis, danke. Wie schon erwähnt ist das momentan alles noch sehr WIP und ist sicher nicht der Endstand. Ich werde mir das also alles noch einmal genauer (auch aus diesem Aspekt) anschauen. Danke noch einmal.

[ProfDrYoMan]

Super! Wie groß ist die Chance, dass auch für Synology/QNAP/... zu sehen? Es braucht ja für HMIP auf jeden Fall das Modul per USB angebunden.

[Psi]

Coole Sache eigentlich. Allerdings ist ein privileged container mit Abhängigkeit zu einem Kernel Modul schon nicht so cool, gerade da die ccu ja ein einziges Sicherheitsloch ist.

Die Kommunikation läuft doch über uart oder? Kann das nicht über den userspace laufen?

[deimos]

Hi,

Die Kommunikation läuft doch über uart oder? Kann das nicht über den userspace laufen?

Nein, die tty Kernel Module in Linux haben eine viel zu hohe Latenz, weil die auf hohen Durchsatz optimiert sind und nicht auf extrem niedrige Latenz bei den an sich verschwindend geringen Datenmengen.

Viele Grüße
Alex

[jmaus]

Coole Sache eigentlich. Allerdings ist ein privileged container mit Abhängigkeit zu einem Kernel Modul schon nicht so cool, gerade da die ccu ja ein einziges Sicherheitsloch ist.

Ich denke diese Einschränkung ist durchaus vernachlässigbar. Und wer z.B. kein Kernel Modul braucht (wenn man nur BidCos-RF LAN Gateways nutzt) kann ja gerne das priviledged flag weg lassen. Und wer einen höheren Sicherheitsbedarf als normal hat setzt eben auf die ova variante oder stellt sich doch einen RaspberryPi hin. Oder er lässt die Kirche einfach im Dorf und nutzt die oci variante mit priviledged flag

[jmaus]

Super! Wie groß ist die Chance, dass auch für Synology/QNAP/... zu sehen? Es braucht ja für HMIP auf jeden Fall das Modul per USB angebunden.

Das kann noch nicht abgeschätzt werden und hängt davon ab welche Kernel versionen dort von Synology/QNAP eingesetzt werden und ob sich jemand hinsetzt und da versucht etwas zu basteln Oder aber man nutzt dann eben die ova variante wenns schon unbedingt ein Synology oder QNAP NAS sein muss auf dem man RaspberryMatic laufen lassen will. Man ist ja nicht gezwungen zu Dockern

[Psi]

Warum ist das flag überhaupt nötig? Wird nicht nur das device in den Container gelegt?

[jmaus]

Warum ist das flag überhaupt nötig? Wird nicht nur das device in den Container gelegt?

Es ist momentan aus verschiedenen gründen notwendig:

1. werden der "mount" Befehl innerhalb des containers benötigt um gewisse verzeichnisse im Nachhinein zu mounten (könnte man sicher lösen)
2. muss der multimacd beim starten in der lage sein seine /dev/mmd_hmip und /dev/mmd_bidcos devices dynamisch anzulegen
3. während des starts muss der container in der lage sein das Funkmodul via sysfs zugriff zu resetten

Du kannst dich aber natürlich gerne an der Weiterentwicklung bzw. Verbesserungen hier beteiligen und dem Container mit den letzten Schliff geben. Noch ist er ja nicht final und lediglich WIP. Wenn du also konkrete Verbesserungsideen hast, immer her damit!

Glücklich bin ich aber bereits recht stark mit der priviledged variante, denn die docker version ermöglich nun z.B. auch die gesamte CI Umgebung von RaspberryMatic vielleicht so zu erweitern das damit dann auch automatisierte Tests möglich werden um ReGaHss, die WebUI, etc. etc. automatisch durchtesten zu lassen