Zugriff auf XMLRPC Schnittstelle erst nach vollständigem Bootvorgang

[jp112sdl]

Eher beiläufig über den Foren-Beitrag über die OpenJDK-Version bin ich auf den von Deimos verlinkten Beitrag zu debmatic gestoßen.
Darin führt er ein sehr interessantes Feature auf:

Der Zugriff auf die XMLRPC Schnittstellen ist jetzt nur noch möglich, wenn debmatic komplett gestartet ist. Dies verhindert eine Art DoS, welcher von externen Systemen wie IOBroker oder openHab beim Start vorhanden war, weil die über die XMLRPC Schnittstelle geschickt haben, die aber noch nicht beantwortet haben und dadurch dann die für den Start wichtigen Requests der Rega blockiert haben.

Mir hat ioBroker mit seiner "Anfragen-Wut" in der Vergangenheit sehr häufig den Reboot der RaspberryMatic vermiest.

Wäre eine Implementation analog zu Debmatic auch bei RM denkbar?

Mein Woraround ist derzeit, dass ich beim Herunterfahren der RaspberryMatic die Homematic-spezifischen ioBroker-Instanzen remote stoppe und sie zeitverzögert nach dem Hochfahren wieder starte.

[jens-maus]

Klar gerne! Wenn du mir technische Details dazu lieferst wie das bei debmatic umgesetzt ist kann ich das gerne Analog so umsetzen. Alternativ wäre sicherlich die nutzung der firewall dazu (erst gabz am ende alles freischalten) ggf denkbar. Aber erstmal schauen wie @alexreinert dss bei debmatic umgesetzt hat.

[jp112sdl]

An die Firewall habe ich auch schon gedacht, jedoch müsste man sich "merken", ob die betreffenden Ports nicht schon vom User gewollt blockiert wurden.

[Baxxy13]

Hmm, ioBroker setze ich nicht ein. Dafür aber Homeassistant und NodeRed. Beide "docken" ja auch am XMLRPC an.
Probleme konnte ich damit auf RaspberryMatic-Seite noch keine sehen.
Die Homematic(IP) Lokal - Integration (in HA) bekommt den Reconnect nach Zentralenstart sauber hin, NodeRed ist da zickiger und muss dann meist neu gestartet werden. (ist aber ein NR - Problem). In NR kann ich dabei sehen wie die RM "bombardiert" wird.

Eine Frage wäre auch ob wirklich die Versuche des Andockens am RPC problematisch sind oder aber vielleicht die zyklischen Remote-Scripte auf die ReGa (SysVars einlesen usw.)

Grundsätzlich sehe ich das aber als gute Idee die Zentrale erstmal unbehelligt starten zu lassen und erst dann den Zugriff zu gewähren.

[jp112sdl]

Ich habe immer nur die Folgen gespürt: Hängende WebUI, eine Bedienung war kaum möglich. Und in dem Zustand festgefahren ließen sich auch die ioBroker Instanzen nicht mehr sauber beenden.

[alexreinert]

Die Zugriffe auf die XmlRPC Schnittstellen sind nur indirekt das Problem, da diese aber für die Authentifizierung über den lighttpd gehen, blockieren diese die Request Queue bis sie in Timeouts laufen und dadurch wird der HmIPServer beim Zugriff auf die Rega blockiert.

Meine Umsetzung ist im Grunde nur ein lua Interceptor Skript im lighttpd, welches prüft, ob die startupFinished Datei vorhanden ist und im Negativfall sofort einen 503 wirft, anstatt auf ein Timeout zu warten: https://github.com/alexreinert/debmatic/blob/master/debmatic/usr/share/debmatic/bin/lighttpd_waitstartup.lua

In Verbindung mit Openhab hat das den Start deutlich verbessert.

[jens-maus]

Nachdem nun der neueste RaspberryMatic Release draussen ist, habe ich mich mal daran gemacht und eine ähnliche Methode wie @alexreinert bei debmatic implementiert damit die RemoteAPI Skriptports erst nach dem erfolgreichen Start für einen Remote-Zugriff freigegeben und ansonsten 503 Service Unavailable Statuscodes zurückgegeben werden. Das ganze sollte morgen mit dem nächsten nightly snapshot dann kommen. Wäre schön wenn der Eine oder Andere (@Baxxy13,@jp112sdl ?) das dann mal in den nächsten Tagen auf Herz und Nieren testen könnte.

Zusätzlich hab ich heute auch mal (nach dem dankenswerten Hinweis von @alexreinert) die mitgelieferte Javaversion testweis auf die aktuellste LTS Version 17.0.8 gesetzt. Wäre also auch diesbzgl. schön wenn das bitte auf Herz+Nieren getestet werden könnte das der HmIPServer damit hoffentlich problemlos klarkommt. Auch müsste man vmtl. mal testen ob auch CCU Historian nicht in irgendein problem rennt mit der aktuelleren Java version (was ich nicht vermute).

[Baxxy13]

Mal eine kurze Meldung hierzu.

503 Service Unavailable
Mein Homeassistant mit der Homematic(IP) Local - Integration wirft 1-2 zusätzliche Fehlermeldungen wenn ich die RM neu starte.
Ist aber völlig unkritisch und der ReConnect von HA funktioniert weiterhin problemlos.
NodeRed habe ich jetzt nicht getestet, das ist je eh recht zickig was Disconnects betrifft. Außerdem hängt das noch am BinRPC von CUxD.
Hier halte ich es weiterhin wie @jp112sdl mit dem ioBroker... ich stoppe NR beim Shutdown der RM und starte NR nachdem RM wieder "online" ist.

Java LTS Version 17.0.8
Bisher nix auffälliges.
Auch Historian schnurrt als AddOn einer RM-VM wie eh und jeh fehlerfrei vor sich hin.