Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[KlausStoertebeker]

@asgothian
Ja, ich lese, was Ihr schreibt. Und alles, was Thomas aufgelistet hat, habe ich durchexerziert und bis auf die Versionsnummern war alles so wie berschrieben:

Ich HABE eine sudo-Gruppe
Ich HABE einen Standardnutzer in der sudo-Gruppe (Nutzer iobroker ist da übrigens auch drin, weil ich den mal wegen eines anderen Problems dort eintragen musste)
Ich HABE sowohl Betriebssystem UND ioBroker nebst Adaptern auf dem aktuellen Stand

Das Einzige, was sich unterscheidet, ist das Repsotory. Das steht bei mir auf "latest", weil ich von dort Adapter nutze, die nicht im "stable" verfügbar sind.

Und was hilft mir das jetzt bei meinem Problem? Sollte es funktionieren?

[Thomas Braun]

@klausstoertebeker sagte in Problem mit dem Blockly-Block "exec":

(Nutzer iobroker ist da übrigens auch drin, weil ich den mal wegen eines anderen Problems dort eintragen musste)

Das ist schon falsch. Der iobroker gehört unter keinen Umständen in die Gruppe 'sudo' rein.

Was ergibt denn der Selbstversuch nun?

[KlausStoertebeker]

Hallo j_paul,

die Idee ist nicht schlecht, aber ich möchte auch andere Geräte per Remote herunterfahren oder eventuell auch starten (mit "etherwake" zum Beispiel). Daher wäre es schön, wenn ich den Blockly-Block "exec" nutzenkönnte.
Wenn ich Deinen Vorschlag aber richtig interpretiere, schlägst Du vor, auf dem QNAP ein Skript laufen zu lassen, das regelmäßig über einen Webhook den Wert des Datenpunktes abfragt, oder? Und dieses Skript müsste ich dann auf dem QNAP als cron-Job starten?

Viele Grüße
"Klaus"

[haus-automatisierung]

Warum eigentlich so kompliziert mit "sshpass"?

• Für den iobroker Linux-User ein Keypair erstellen
• Den public key auf dem QNAP in die authorized_keys eintragen
• fertig

[BananaJoe]

@j_paul sagte in Problem mit dem Blockly-Block "exec":

@klausstoertebeker
Wäre der umgekehrte Weg eine Option für Dich?
Ich habe einen DP den ich auf true setzen kann und das QNAP „guckt“ da nach, setzt den wieder auf false und fährt runter.

Moin,
die Lösung würde ich zu gerne sehen!
Ich fahre das QNAP bisher auch per ssh herunter, was das QNAP dann Zeitweise bemängelt (Das es nicht ordentlich heruntergefahren wurde).
Hochfahren per Magic-Paket funktioniert ohne Probleme.

[KlausStoertebeker]

@thomas-braun
Nachdem ich den Nutzer iobroker aus der sudo-Gruppe wieder herausgenommen habe und deinen Befehl in einem Terminal eingegeben hatte, passierte nichts.Nach dem Drücken der Eingabetaste kam sofort der nächste Eingabeprompt und auf dem QNAP passierte auch nichts.

[KlausStoertebeker]

@haus-automatisierung
Wenn ich wüsste, wie das mit dem ganzen Schlüssel-Gedöns funktionieren würde, hätte ich das bestimmt schonmal versucht. Aber das und auch diese Zertifikatsdinge sind ein Buch mit sieben Siegeln (noch) und ich greife da eher auf "einfache" Sachen zurück.
In einem ganz normalen Terminal funktioniert das ja auch einwandfrei, ich kann Nutzernamen und Passworte aus versteckten Dateien extrahieren und einen Befehl zusammen"bauen" und mein QNAP damit herunter fahren.
Das Ganze funktioniert auch unter Blockly mit dem einzigen Unterschied, dass der zusammen"gebaute" Befehl nicht ausgeführt wird...

[BananaJoe]

@klausstoertebeker wechsle doch in einer SSH-Sitzung einmal ganz zum Benutzer ioBroker:

sudo -u iobroker /usr/bin/bash

Gib dann noch mal deinen SSH-Befehl ein wie du ihn im Skript hast.
Die Fehlermeldung sollte die Lösung bringen. Er wird irgendetwas nicht dürfen bzw. vermutlich musst du einmal den SSH-Host-Key aktzeptieren, der wird dann gespeichert und danach geht es.

Mit exit verlässt du die Sitzung wieder.

Edit: Alternativ musst du sshpass bzw. ssh mit den zusätzlichen Parametern aufrufen:

sshpass -pMeinPasswort ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

Dann ignoriert er den Host-Key ohne Warnung

[KlausStoertebeker]

@BananaJoe
:-( Funktioniert leider nicht. Und eine Fehlermeldung kommt auch nicht, sondern einfach nur der nächste Eingabeprompt..

[BananaJoe]

@klausstoertebeker poste hier noch mal den genauen, vollständigen String den du getestet hast, nur das Passwort ersetze mit etwas unverfänglichen.

[Thomas Braun]

@klausstoertebeker

Ich würde das per key machen. Ob das auf einem QNAP funktioniert weiß ich allerdings nicht. Sollte aber eigentlich.

https://linuxconfig.org/passwordless-ssh

[Dolomiti]

@thomas-braun
Das funktioniert definitiv. Ich lege so mein Qnap schlafen mittels

exec('ssh admin@192.168.1.151 /etc/init.d/pw_sleep.sh', function (error, result, stderr) {....

Habe mir ein Schlüsselpaar erstellt und in die authorized_keys auf dem Qnap eingetragen so wie @haus-automatisierung es oben beschrieben hat.
@haus-automatisierung Muss der public key nicht in die authorized_keys?

[BananaJoe]

@dolomiti sagte in Problem mit dem Blockly-Block "exec":

/etc/init.d/pw_sleep.sh

ich hab bisher poweroff aufgerufen (ist auch ein Skript), ich schau mal was da anders ist.

Edit: Gefunden: Funktioniert bei meinem QNAP nicht (ist kein x86 System sondern mit ARM CPU)

[Dolomiti]

@bananajoe
poweroff fährt das System runter. Ich schicke meins nur in Standby.

[haus-automatisierung]

@dolomiti sagte in Problem mit dem Blockly-Block "exec":

@haus-automatisierung Muss der public key nicht in die authorized_keys?

Ja, logisch. Danke habs angepasst.

[KlausStoertebeker]

@thomas-braun und alle anderen helfenden Poster:

Ich habe es auch mit den Schlüsseln hingekommen - ganu nach der Anleitung, die Thomas als Link eingefügt hat. Das Thema war dann für alle QNAP's in fünf Minuten erledigt und ich kann sie ganz normal runterfahren :-)
Jetzt muss ich das nur noch auf meinem Rechner zu Hause hinbekommen, wenn ich wieder dort bin...
Vielen Dank für die Hilfe und viele Grüße

"Klaus"

[BananaJoe]

@dolomiti sagte in [gelöst] Problem mit dem Blockly-Block "exec":

@bananajoe
poweroff fährt das System runter. Ich schicke meins nur in Standby.

stimmt, das war es, das kann mein System nicht