42_SYSMON.pm - Vorschlag zur Erweiterung der SSH Nutzung

Begonnen von Andreas_B, 01 Februar 2022, 08:29:28

Vorheriges Thema - Nächstes Thema

Andreas_B

Hallo.

Als Neuling in diesem Forum ist dies mein erster Beitrag. Sollte etwas zur Diskussion fehlen seht es mir nach... Werde ich dann ergänzen.

Also...

Unter anderem nutze ich FHEM (läuft auf einem RasPi4 Bullseye) um Leistungswerte (CPU Temp, etc.) diverser Komponenten auszulesen, in eine Influxdb zu schreiben und dann per Grafana zu visualisieren.
Das funktioniert bisher für alle Komponenten immer super. Immer mit dem SYSMON Modul.

Vor ein paar Tagen habe ich meine Unifi Dream Machine (UDM) eingebaut. Leider liefert die UDM per SSH bei jedem Verbindungsaufbau eine pre-authentication Banner. Dieser lässt sich auf der UDM nicht (rebootresistent) entfernen. Dummerweise landet dieser Banner auch jedes Mal im FHEM Log, was dazu führte dass mein Log schon nach wenigen Stunden exorbitant groß war.
Mein erster Ansatz war den Banner per ignoreRegexp in global zu Filter. Ohne Erfolg. Testhalber habe ich einige andere Filter gebaut. Diese haben alle funktioniert.
Selbst mit Verbose = 0 in global landet der Banner noch im Log.

Fündig bin ich dann direkt im ssh Aufruf auf dem RasPi geworden. Mit den Schalter "-q" wird der pre-authentication Banner nicht mehr ausgegeben, und landet somit auch nicht mehr im FHEM Log.
Ich habe aber keine Option gefunden "-q" im FHEM Device zum SSH Aufruf zu übergeben.
Letztendlich habe ich in der 42_SYSMON.pm eine Zeile editiert / hinzugefügt:

   SYSMON_Log($hash, 5, "Execute '".$cmd."' by SSH");
   my $p_tmp = '';
   if(defined($port)) {
   #$p_tmp = ' -p '.$port.' '; <-- diese Zeile habe ich auskommentiert
   $p_tmp = ' -q -p '.$port.' '; <-- diese Zeile habe ich hinzugefügt; beim SSH Aufruf wird nun "-q" übergeben
   }


Der Nachteil ist natürlich, dass "-q" nun immer angewendet wird. Mich stört es nicht. Aber mit Sicherheit mag es Szenarien geben, in denen der pre-authentication Banner nicht unterdrückt werden soll.

Ich hoffe soweit ist alles nachvollziehbar....

Ggfs. hat / hatte jemand schon einmal die Selbe "Herausforderung"... ???

Ich fände es total super, wenn das SYSMON Modul ein wenig erweitert werden könnten. Und zwar um die Möglichkeit in jedem SYSMON Device mit mode SSH bestimmte / frei wählbare Schalter mit zu übergeben.

hexenmeister

Moin!
Ein konfigurierbarer Parameter ist eine sehr gute Idee, werde ich einbauen.
Tut mir leid die lange Antwortzeit, komme in der letzten Zeit nicht dazu  :(

VG
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Andreas_B

Cool, super! Das freut mich.
Bei Bedarf kann ich gerne testen.

VG,
Andreas

hexenmeister

#3
Ich habe jetzt ein zusätzliches Attribut 'ssh-param' eingefügt. Bitte ausprobieren, indem man dieses Attribut mit dem gewünschten Parameter -q belegt.

Wenn alles funktioniert, checke ich ein.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Andreas_B

Das ging ja flott, super!

Funktioniert im Prinzip. Der SSH Parameter wird angewendet.
Jedoch wird nach einem (re)start von FHEM beim erstmaligen SSH connect zum Device der SSH Parameter nicht angewendet. Bei allen folgenden Aufrufen schon.
Kann ich dir ggfs. irgendwelche Logs zur Verfügung stellen?

hexenmeister

Ich kann mir denken, woran das liegt. Ich muss den ersen Aufruf zurückhalten, bis alle Attribute angewendet sind. Muss in Ruhe überlegen, wie ich da am besten mache.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Dann bitte diese Version probieren. Ich konnte nur sehr rudimentär testen, daher bitte kritisch anschauen :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Andreas_B

Hi.

Bei mir sieht es unverändert aus.
Beim (re)start von FHEM scheint der SSH Parameter nicht angewendet zu werden. Zumindest taucht der pre-authentication Banner der UDM im Log auf.
Bei allen folgenden Verbindungen wird der Parameter übergeben. Der pre-authentication Banner der UDM taucht im Log nicht mehr auf.

hexenmeister

Habe paar Tage nachgedacht, muss gestehen, ich verstehe nicht, warum das nicht funktioniert hat.
Habe noch eine kleine Änderung eingebaut, bitte ausprobieren!
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Andreas_B

Hi.

Ich habs erneut mit der UDM getestet. Beim FHEM Start taucht der pre-authentification banner noch immer im Log auf.
Aber: ich habe jetzt auch mal mit einem zweiten RasPi getestet. Dort greift der SSH Parameter sofort. Auch beim Start.
Ich vermute daher, dass deine Implementierung tut was sie soll, (wahrscheinlich auch schon beim ersten Versuch. Sorry  :-X) und dass der SSH daemon auf der UDM nur irgendwie "merkwürdig" ist.
Da der Banner bei der UDM mit dem SSH Parameter nur noch beim Start auftaucht, aber nicht im normalen Betrieb, ist das so wie es ist einer super Sache. Vielen, vielen Dank!

hexenmeister

Moin!
Kein Problem, wäre natürlich spannend zu ergründen, warum sich eine Installation so anders verhält.
Mir fällt jedoch keine Erklärung ein.
Aber gut, da es so funktioniert, werde ich die Version dann einchecken. :)

VG
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Andreas_B

Ich habe versucht mich der Ursache zu nähern, weshalb sich ausgerechnet und auch nur der Aufruf bei der UDM anders verhält.
Mit verbose = 5 in global habe ich einen FHEM restart gemacht.

Könnte es ggfs. daran liegen, dass das attr "ssh-params" erst erstmalig angewendet wird, nachdem der erste Durchlauf an SSH Verbindungen durch ist? Siehe fett markierte Zeilen. In den drei SSH Aufrufen fehlt der SSH Parameter "-q".
("event-on-update-reading" taucht schon ganz zu Beginn auf. "room" auch erst zum Schluss.)
Die drei roten Blöcke sind die unliebsamen pre-authentication Banner.


##########################################
2022.03.09 16:43:54 5: Cmd: >define UDM_sysmon SYSMON ssh:XXX@a.b.c.d 5 0 0 0<
2022.03.09 16:43:54 5: SYSMON UDM_sysmon: Define.166 UDM_sysmon SYSMON ssh:XXX@a.b.c.d 5 0 0 0
2022.03.09 16:43:54 5: Cmd: >setuuid UDM_sysmon 6226288f-f33f-5525-d6a8-481ecd53b35f333d<
2022.03.09 16:43:54 5: Cmd: >attr UDM_sysmon event-on-update-reading cpu_temp<
2022.03.09 16:43:54 5: SYSMON UDM_sysmon: Attr.840 event-on-update-reading
2022.03.09 16:43:54 5: SYSMON UDM_sysmon: readPassword.3833 Read password from file
2022.03.09 16:43:54 5: SYSMON UDM_sysmon: Exec_Ssh.4246 Execute '[ -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq ] && echo 1 || echo 0' by SSH
2022.03.09 16:43:54 5: SYSMON UDM_sysmon: Exec_Ssh.4259 Call: 'ssh  -p 22 XXX@a.b.c.d "[ -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq ] && echo 1 || echo 0"'
Welcome to UbiOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement and agree to be bound by its terms.


2022.03.09 16:43:54 5: SYSMON UDM_sysmon: Exec_Ssh.4275 Result '0'
2022.03.09 16:43:54 5: SYSMON UDM_sysmon: readPassword.3833 Read password from file
2022.03.09 16:43:54 5: SYSMON UDM_sysmon: Exec_Ssh.4246 Execute '[ -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq ] && echo 1 || echo 0' by SSH
2022.03.09 16:43:54 5: SYSMON UDM_sysmon: Exec_Ssh.4259 Call: 'ssh  -p 22 XXX@a.b.c.d "[ -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq ] && echo 1 || echo 0"'
Welcome to UbiOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement and agree to be bound by its terms
.

:
:
:
:

2022.03.09 16:43:56 5: SYSMON UDM_sysmon: Exec_Ssh.4275 Result '0'
2022.03.09 16:43:56 5: SYSMON UDM_sysmon: readPassword.3833 Read password from file
2022.03.09 16:43:56 5: SYSMON UDM_sysmon: Exec_Ssh.4246 Execute '[ -f /usr/bin/ctlmgr_ctl ] && echo 1 || echo 0' by SSH
2022.03.09 16:43:56 5: SYSMON UDM_sysmon: Exec_Ssh.4259 Call: 'ssh  -p 22 XXX@a.b.c.d "[ -f /usr/bin/ctlmgr_ctl ] && echo 1 || echo 0"'
Welcome to UbiOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement and agree to be bound by its terms.


2022.03.09 16:43:57 5: SYSMON UDM_sysmon: Exec_Ssh.4275 Result '0'
2022.03.09 16:43:57 5: Cmd: >attr UDM_sysmon room Unifi<
2022.03.09 16:43:57 5: SYSMON UDM_sysmon: Attr.840 room
2022.03.09 16:43:57 5: Cmd: >attr UDM_sysmon ssh-params -q<
2022.03.09 16:43:57 5: SYSMON UDM_sysmon: Attr.840 ssh-params
##########################################


Zum Vergleich hier eine SSH Verbindung etwas später. "-q" ist dabei.

##########################################
2022.03.09 17:07:35 5: SYSMON UDM_sysmon: readPassword.3833 Read password from file
2022.03.09 17:07:35 5: SYSMON UDM_sysmon: Exec_Ssh.4246 Execute '[ -d /proc/ ] && echo 1 || echo 0' by SSH
2022.03.09 17:07:35 5: SYSMON UDM_sysmon: Exec_Ssh.4259 Call: 'ssh  -q  -p 22 XXX@a.b.c.d "[ -d /proc/ ]] && echo 1 || echo 0"'
2022.03.09 17:07:35 5: SYSMON UDM_sysmon: Exec_Ssh.4275 Result '1'
##########################################

hexenmeister

Ja, ganz klar sieht es danach aus, dass die erste Verbindung vor dem Anwenden des Attributes passiert. Ich verstehe nur nicht warum, denn ich habe ja extra so aufgebaut, dass die vollständige Initialisierung angewartet werden soll.
Ich habe noch eine Kleinigkeit eingebaut, wenn das auch nicht hilft, weiß ich erstmal nicht weiter :/
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Andreas_B

Auch mit der neuen Version ist es beim Start unverändert.
Ich werde spätestens am Wochenende intensiv testen. Ggfs. das ganze auch auf einem zweiten RasPi / FHEM nachbauen und dort testen.

Andreas_B

Ich habe nun auf einem zweiten RasPi mit einem frischen FHEM getestet. Selbes Resultat. Beim Start erfolgt die erste Verbindung vor der vollständigen Initialisierung.

Nun hat es mich gejuckt zu versehen warum.... Ich habe mich ganz rudimentär die Modulentwicklung eingelesen und auch mal in das SYSMON Modul reingeschaut.
Wenn ich nun tippen sollte, würde ich vermuten, dass in der Funktion SYSMON_Define der Teil mit "$init_done" nicht berücksichtigt wird. Ggfs. auch in SYSMON_Notify und SYSMON_Update?
Kann das sein?
Falls ja, hättest du etwas dagegen, wenn ich mich mal an dem ein oder anderen Lösungsansatz versuche? Auch wenn ich mich mit Modulentwicklung bisher noch nicht beschäftigt habe...