FHEM Forum

FHEM => Anfängerfragen => Thema gestartet von: riker1 am 27 August 2019, 19:14:12

Titel: (solved) ssh suspend in fhem geht nicht aber als cli vom fhem server unklar ?
Beitrag von: riker1 am 27 August 2019, 19:14:12
Hallo

habe ein notify mit ssh

defmod UB11_standby notify UB_Action:UB11_Standby {system('ssh -t root@192.168.0.11 systemctl suspend')}

dann erscheint das im log und return code ist -1 , sende das ist ok.
aber er macht nichts.

019.08.27 19:06:32.913 5 : Triggering UB11_standby
2019.08.27 19:06:32.914 4 : UB11_standby exec {system('ssh -t root@192.168.0.11 systemctl suspend')}
2019.08.27 19:06:33.008 3 : UB11_standby return value: -1


das gleiche wenn ich in der Fhem commandozeile den systembefehl eingebe.

{system('ssh -t root@192.168.0.11 systemctl suspend')}

wenn ich aber als cli:

ssh -t root@192.168.0.11 systemctl suspend

geht der Rechner in suspend.

Was mache ich da in fhem denn falsch?

Danke

VG T



Solution: SSH Key von fhem user neu verteilt. !!!
Titel: Antw:ssh suspend in fhem geht nicht aber als cli vom fhem server unklar ?
Beitrag von: Otto123 am 27 August 2019, 19:47:30
Zitatreturn code ist -1 , sende das ist ok.
nein: der Return Code von system in FHEM ist immer -1!

Hast Du ssh denn ohne Passwort für user fhem eingerichtet?

Zitatwenn ich aber als cli:
Mit welchem user?
Titel: Antw:ssh suspend in fhem geht nicht aber als cli vom fhem server unklar ?
Beitrag von: kadettilac89 am 27 August 2019, 20:01:34
Zitat von: Otto123 am 27 August 2019, 19:47:30
nein: der Return Code von system in FHEM ist immer 1!

Hast Du ssh denn ohne Passwort für user fhem eingerichtet?
Mit welchem user?

wenn man in der befehlszeite oben einen befehl mit system eingibt kommt immer -1 zurück. Das sagt nur dass was ausgeführt wurde.

mach mal statt {system(...)} ein {qx(...)} dann siehst du was der befehl zurückliefert.

ich vermute du nutzt auf der Konsole einen anderen User als fhem. ... wie Otto schon sagte ...
Titel: Antw:ssh suspend in fhem geht nicht aber als cli vom fhem server unklar ?
Beitrag von: kadettilac89 am 27 August 2019, 20:16:29
Ein Hinweis zu ... ssh -t root@192.168.0.11 systemctl suspend

Ich würde nicht root für ssh login konfigurieren wenn es nur darum geht einen Rechnern in den Standby zu setzen. Du kannst dir einen User anlegen und sudo einrichten damit das suspend funktioniert. Wenn jemand auf deinen Raspberry (den Fhem Server) kommt kann er auf den Rechner 192.168.0.11 und hat dort alle Rechte.
Titel: Antw:ssh suspend in fhem geht nicht aber als cli vom fhem server unklar ?
Beitrag von: riker1 am 27 August 2019, 22:11:40
Zitat von: kadettilac89 am 27 August 2019, 20:16:29
Ein Hinweis zu ... ssh -t root@192.168.0.11 systemctl suspend

Ich würde nicht root für ssh login konfigurieren wenn es nur darum geht einen Rechnern in den Standby zu setzen. Du kannst dir einen User anlegen und sudo einrichten damit das suspend funktioniert. Wenn jemand auf deinen Raspberry (den Fhem Server) kommt kann er auf den Rechner 192.168.0.11 und hat dort alle Rechte.

stimmt, werde ich mal umbauen
Titel: Antw:ssh suspend in fhem geht nicht aber als cli vom fhem server unklar ?
Beitrag von: riker1 am 27 August 2019, 22:20:24
Zitat von: Otto123 am 27 August 2019, 19:47:30
nein: der Return Code von system in FHEM ist immer -1!

Hast Du ssh denn ohne Passwort für user fhem eingerichtet?
Mit welchem user?

Hi Otto,
stimmt, top Hinweis wieder. Dachte es geht direkt mit dem ssh root@ egal von welchen user aus. ....Denkfehler meinerseits.

Lag daran, das ich fhem  auf einen neuen Server kopiert hatte und nicht den sshkey neu verteilt hatte. Allerdings kam auch kein Fehler im Log obwohl verbose 5....Hatte auch andere SSH-Commands die gingen, aber auf dem alten Server....Regressionstests.....

Scheint nun zu gehen...

Danke Otto

VG Thomas



Titel: Antw:(solved) ssh suspend in fhem geht nicht aber als cli vom fhem server unklar ?
Beitrag von: Otto123 am 27 August 2019, 22:30:18
Die Ausgabe eines system() Kommandos hat mit verbose Level von FHEM nichts zu.
stdout wandert aber beim system() Aufruf im Log - einfach so, ohne Timestamp und unformatiert.
Wenn ich das richtig verstehe (kenne die Option nicht) bewirkt -t die Verwendung eines anderen Buffers und dieser landet nicht im stdout. Was wiederum erklären würde warum Du nichts gesehen hast. ;)