Logikbaustein 12749_ServiceCheck

[max999]

Möchte gerade einen PING check machen, ob ein Ubiquti AP verfügbar ist. Habe den Baustein eingebaut, die Ubiquiti AP haben auch SSH Zugriff - darum habe ich SSH gewählt. Wenn ich mit Putty probiere klappt der Zugriff, man braucht keinen Benutzer nur ein Passwort - das habe ich eingertagen. Ich bekomme aber immer eine "1" am Ausgang. Stehe ich hier auf derf Leitung? Hat jemand vielleicht einen Tipp?
31-10-_2021_14-23-21.png

[markusmos]

Möchte die NTP Server im HS prüfen, ob diese erreichbar sind.
NTP Abfragen z.B:ntp://ntp1.t-online.de

Da kommt nichts zurück und der Baustein deaktiviert sich.
Ist das mit diesem Baustein möglich?

[charlez]

Es liegt nicht an 4.9 oder sonstigem sondern ist der Nebeneffekt das ab 4.9 das hs_main (Das Homeserverprogramm) nicht mehr als root läuft.
Das lässt sich aus dem Programm heraus natürlich nicht ändern (wäre ja witzlos wenn man kein Admin mehr ist das man sich selbst wieder dazu machen könnte)
Um das von HostCheck, LogikPing?, oder auch dem Programm Ping verwendete ICMP Protokoll nutzen zu können, muss man einen so genannten RAW Socket aufmachen (das erfordert root Rechte).

Es gibt eine Möglichkeit dem Programm hs_main diese Rechte wieder zu geben ohne das das Programm wieder mit Root Rechten läuft (http://man7.org/linux/man-pages/man7...ilities.7.html)

Ich habe bereits Gira/Dacom darüber informiert und darum gebeten das die Capabilities CAP_NET_BIND_SERVICE und CAP_NET_RAW dem hs_main über setprivs beim Starten zurück gegeben werden. Wir werden sehen wie sie sich dazu entscheiden. DU könntest das natürlich auch selber machen, indem du die Firmware manipulierst.

Alle nötigen Programme dafür sind auf dem HS vorhanden. Nur die veränderte Firmware darf natürlich keiner zur Verfügung stellen.

Was hat Dacom geändert, damit Raw Sockets in Version 4.11 wieder funktionieren?

[annihilator]

Hallo,

ich habe den Baustein jetzt schon längere Zeit dazu verwendet, um eine openDtu abzufragen. Das hat auch immer zuverlässig funktioniert, doch seit den letzten Wochen fällt mir immer wieder auf, dass der Baustein deaktiviert wird und keine aktuellen Werte mehr einliest. Scheinbar ist der Server der openDtu zeitweise nicht erreichbar. Der Baustein wirft eine BadStatusLine Exception

File "<12749_ServiceCheck_0_PY_VER_2.7.16>", line 295, in _worker
File "<12749_ServiceCheck_0_PY_VER_2.7.16>", line 1429, in _check
File "<12749_ServiceCheck_0_PY_VER_2.7.16>", line 971, in check_http
File "/usr/lib/python2.7/httplib.py", line 448, in begin
version, status, reason = self._read_status()
File "/usr/lib/python2.7/httplib.py", line 412, in _read_status
raise BadStatusLine("No status line received - the server has closed the connection")
BadStatusLine: No status line received - the server has closed the connection
Baustein 224 deaktiviert

Zu einem späteren Zeitpunkt ist der openDtu-Server wieder erreichbar. Kann ich das irgendwie abfangen, so dass der Baustein nicht deaktiviert wird?
Ich verwende Experte 4.13. Die Abfrage-Logik habe ich recht einfach gehalten.
image.png

[concept]

Betreff: Zwei Probleme: Hostname-Aufloesung bei HTTP/HTTPS, und Eingabefeld verstuemmelt lange URLs


Hallo NilsS

vielen Dank fuer den Baustein! Ich bin auf zwei getrennte, reproduzierbare Probleme gestossen.

Umgebung:
- HS4, Firmware 4.13
- ServiceCheck Baustein V0.59
- Anwendungsfall: zyklischer Aufruf einer DDNS-Update-URL (DuckDNS)

PROBLEM 1: Automatische Hostname-Aufloesung bei HTTP/HTTPS funktioniert nicht

Bei jeder normalen http:// oder https:// URL mit Hostnamen (z.B. https://www.duckdns.org/update?... oder auch einfache Test-URLs wie https://icanhazip.com, http://neverssl.com) bleibt A2 Responsetime dauerhaft beim Initialwert -1. Es wird nie ein Ergebnis geliefert, auch keine Exception im Protokoll, unabhaengig von Zykluszeit, Timeout oder Neuuebertragung/VM-Neustart.

Eingrenzung:
1. Netzwerk/Internetzugriff des HS grundsaetzlich funktionsfaehig bestaetigt (Pushover-Baustein laeuft parallel einwandfrei).
2. http://1.1.1.1 (reine IP, kein Hostname) -> funktioniert einwandfrei, A2 = 29.85ms, A3/A6 liefern den erwarteten Redirect-Body.
3. dns://8.8.8.8/google.com -> funktioniert einwandfrei, A1=1, A2=15.36ms, A3=216.58.206.14, korrektes JSON.
4. Als Workaround versucht: die per DNS ermittelte IP von DuckDNS direkt in die HTTPS-URL eingesetzt (https://<IP-von-duckdns.org>/update?...) -> Verbindung/TLS klappt (ssl_cipher_rating: A), aber HTTP-Status 404, da DuckDNS hostnamenbasiertes Routing verwendet und die nackte IP nicht aufloesen kann.

Fazit: Die interne automatische Namensaufloesung fuer normale HTTP/HTTPS-URLs scheint nicht zu funktionieren, waehrend die explizite dns://-Abfrage einwandfrei laeuft.

PROBLEM 2: Eingabefeld fuer E2 Check URL verstuemmelt lange Werte beim erneuten Oeffnen

Beim Eintragen einer laengeren URL (ca. 100+ Zeichen) in E2 Check URL fehlt nach dem Speichern und erneutem Anzeigen ein Zeichen mitten im Wert: das "&" vor "token=" ist verschwunden. Das ist unabhaengig von der reinen Anzeige-Kuerzung mit "..." am Ende der Zeile im Ueberwachen-Tab (die nur die Spaltenbreite betrifft) - das fehlende "&" liegt deutlich vor dieser Kuerzung und ist damit ein tatsaechlicher Datenverlust, kein reines Anzeigeproblem:

Eingegeben: https://<IP-von-duckdns.org>/update?domains=meinesubdomain&token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&ip=
Nach erneutem Oeffnen/Bearbeiten (Ausschnitt vor der Anzeige-Kuerzung): ...domains=meinesubdomaintoken=xxxxxxxx-xxxx...

Das deutet auf einen Speicherfehler bei laengeren Texteingaben hin, der zu echtem Datenverlust fuehrt (nicht nur eine Darstellungsfrage).

Update: Habe das Feld komplett geleert und die korrekte URL per Copy-Paste neu eingefuegt, sofort mit Ok bestaetigt und uebertragen, ohne das Feld zwischenzeitlich nochmal zu oeffnen. Beim erneuten Kontrollieren fehlte das "&" vor "token=" trotzdem wieder. Der Fehler tritt also reproduzierbar auf, nicht nur bei mehrfachem Bearbeiten.

Frage: Gibt es zu Problem 1 bereits bekannte Einschraenkungen unter 4.13, und ist bei Problem 2 eine maximale Zeichenlaenge fuer Texteingaenge bekannt/dokumentiert?

Zusatzinfo (evtl. hilfreich fuer die Fehlersuche): Beim Entpacken der .hslz-Datei sehe ich, dass die eigentliche Baustein-Logik im HSL2-Format als marshal-serialisierter, base64/zlib-komprimierter Python-Bytecode vorliegt, mit getrennten Blobs fuer Python 2.6 und Python 2.7 (sys.version-Weiche). Da Python 2.x ab der naechsten HS-Version komplett nicht mehr unterstuetzt wird, waere der Baustein ohnehin von einer Migration auf HSL3/Python 3 betroffen - evtl. gibt es dazu schon Plaene oder eine aktualisierte Version?

Noch ein konkreterer Hinweis zur eigentlichen Ursache: Ich habe zum Vergleich auch den Pushover-Baustein (12742) entpackt, der bei mir einwandfrei funktioniert. Dort liegt der Code unverschluesselt vor (base64-kodiert, aber als Klartext-Python kompiliert, kein Bytecode) und enthaelt direkt am Anfang folgenden Patch:

## Fix Broken DNS
global socket
import socket
## nur wenn noch nicht vorhanden und FW <4.9
if not hasattr(socket,"_hs_dnsresolver") and not hasattr(self.MC,"StaticFiles"):
socket._socket_getaddrinfo = socket.getaddrinfo
socket._hs_dnsresolver = self.MC.DNSResolver.getHostIP
def _hsgetaddrinfo(host, port, family=0, socktype=0, proto=0, flags=0):
return socket._socket_getaddrinfo(socket._hs_dnsresolver( host),port,family,socktype,proto,flags)
socket.getaddrinfo = _hsgetaddrinfo

Pushover patcht also aktiv socket.getaddrinfo, um Hostnamen ueber den internen HS-DNS-Resolver (self.MC.DNSResolver.getHostIP) aufzuloesen, offenbar weil die normale System-DNS-Aufloesung auf dem HS bekanntermassen fehlerhaft ist ("Fix Broken DNS"). Vermutung: ServiceCheck wendet diesen (oder einen aequivalenten) Patch nicht an bzw. nicht mehr korrekt auf meiner Firmware, wodurch normale Hostnamen in HTTP/HTTPS-URLs scheitern, waehrend die explizite dns://-Syntax (vermutlich ein eigener Codepfad ohne socket.getaddrinfo) und reine IP-Adressen weiterhin funktionieren. Koennte das die Ursache sein?

Danke und Gruss

Heinz