98_WOL: Neue Version zum Testen

[Phil1602]

Hi,

Vielleicht macht es Sinn das Thema etwas generischer anzugehen. Einfach ein Attribut wie von Phil1602 vorgeschlagen

Code Auswählen Erweitern


Ich hab das Modul mal um einen "CMD" Mode erweitert, sodass ein Command (Fhem, Perl oder System) ähnlich des ShutdownCmd definiert werden kann und dann direkt aufgerufen wird ohne dass Etherwake oder Wakeonlan verwendet wird. Den Entwurf davon werde ich mal im zugehörigen Forum posten.

Finde das besser, bietet viel mehr Möglichkeiten da losgelöst von ssh oder Docker.

sorry erstmals, dass ich meinen Ansatz damals nur als Idee geteilt hatte und nicht den Code, habe KernSani meine Änderung nun zukommen lassen und auch nochmal hier angehängt.

Sicherlich kann man daran aber auch noch was verbessern, war von mir wie gesagt eher ein Quickfix, da ich im Bridged Docker Netzwerk laufen wollte und hatte dann die Idee die FritzBox API (über das FB Device) für WOL zu nutzen.

Ich habe dazu einfach einen zusätzliche Mode "wolCmd" hinzugefügt.
Falls es auch jemand über die FB realisieren möchte, der wolCmd sieht bei mir dann wie folgt aus:

Code Auswählen Erweitern

get <FritzBoxDevice> tr064Command Hosts:1 hosts X_AVM-DE_WakeOnLANByMACAddress NewMACAddress "XX:XX:XX:XX:XX:XX"

LG
Phil

[kadettilac89]

Ich habe dazu einfach einen zusätzliche Mode "wolCmd" hinzugefügt.
Falls es auch jemand über die FB realisieren möchte, der wolCmd sieht bei mir dann wie folgt aus:

Code Auswählen Erweitern

get <FritzBoxDevice> tr064Command Hosts:1 hosts X_AVM-DE_WakeOnLANByMACAddress NewMACAddress "XX:XX:XX:XX:XX:XX"

LG
Phil

Alternativ über SSH würde es so aussehen wobei die Parameter bzw. der wake-Befehl abhängig vom Host-OS sind. Alles in Anführungszeichen funktioniert.

Code Auswählen Erweitern


"ssh <user host>@<ip host> -p <ssh-port>  sudo wake <interface> <mac_addr>"
Beispiel "ssh fhem_USR@192.168.2.99 -p 50 sudo wake em0 33:96:1F:1F:1F:1F"


[kadettilac89]

Phil1602 hat vorgelegt. Mir gefällt das ssh-Command als Text einzutragen irgendwie nicht. Ich habe um SSH-Mode erweitert ... damit können die ssh-Werte per Attribut gesetzt werden. Für die meisten hier wird die Anpassung von Phil1602 ausreichen. Ob du SSH auch einbaust überlasse ich dir KernSani ... die Attribute sind nur ein paar Zeilen, jedoch die Rückfragen zu ssh landen dann hier . Ich kann es für mich dann auch modifizieren.

Ich habe der Datei ".ssh" angehängt damit man sie unterscheiden kann. Die Endung muss entfernt werden.

[KernSani]

Hallo zusammen,

ich bin endlich dazu gekommen, mir die patches anzusehen. Was mir vorschwebt:
* es gibt ein WOLCmd Attribut, welches das bisherige sysCmd-Attribut ersetzt
* das neue Attribut kann FHEM, Perl oder SysCmd enthalten
* Wenn SSH-Host gesetzt ist, wird der Befehl (der dann logischerweise zwingend ein SysCmd sein muss) über SSH ausgeführt
* Die zusätzliche SSH Option wird auch im shutdownCmd genutzt, oder gibt es aus eurer Sicht Fälle, wo wake-up über ssh und shutdown nicht SSH sind (oder umgekehrt)? Sprich, müsste man das nochmal irgendwie trennen?

Grüße,

Oli

[kadettilac89]

ich editiere mal ohne Zitate ...

* es gibt ein WOLCmd Attribut, welches das bisherige sysCmd-Attribut ersetzt
==> macht Sinn, wüsste nicht was dagegen spricht
* das neue Attribut kann FHEM, Perl oder SysCmd enthalten
==> OK
* Wenn SSH-Host gesetzt ist, wird der Befehl (der dann logischerweise zwingend ein SysCmd sein muss) über SSH ausgeführt
==> OK
* Die zusätzliche SSH Option wird auch im shutdownCmd genutzt, oder gibt es aus eurer Sicht Fälle, wo wake-up über ssh und shutdown nicht SSH sind (oder umgekehrt)? Sprich, müsste man das nochmal irgendwie trennen?
==> Ich nutze das nicht, aber du sprichst was an was aus Usability Sicht nicht so einfach ist. Wenn ich über SSH ein WOL machen will habe ich einen "Jump-Server" der etherwake o. ä. ausführt da das Ziel noch offline ist (Sinn von WOL).
Das Runterfahren wird aber, sinnvollerweise, direkt auf dem Ziel ausgeführt. Man bräuchte eigentlich 2 SSH destinations. Außer man bedient sich dem Jump-Server und legt dort ein Script ab, aber dann wirds mit Rückgabe und Fehler abfangen komplexer.
==> Oder meintest du was anderes?

Folgendes könnte man machen:
- SSH Connection string nicht über 4 Attribute sondern nur eines ... Format, "fhem_WOL@192.168.0.2 -p 500" ... generell schöner.

Um WOL und Shutdown über SSH vollständig abzudecken bedarf es 4 Parameter. Ich schau mal vielleich komm ich am Abend dazu das mal zu bauen und einen Screenshot zu posten.

"sshConnectionWOL    fhem_WOL@192.168.0.2 -p 500"
"sshConnectionDWN    fhem_DWN@192.168.0.4 -p 200"
"WOLCmd      wake em0"
"DWNCmd      shutdown now"

Mit 2 Parameters wäre es relativ einfach das auszufähren, wenn SSH-String gefüllt einfach verketten ... $qxWOL = "ssh ".$sshConnectionWOL." -t ".CmdWOL ..... wenn SSH-String leer dann Befehl direkt ausführen ...

Mit dem Connection string wäre es auch einfach das Attribut schon beim Anlegen zu testen was späteren Support einfacher macht (was nicht funktioniert wird nicht gespeichert) ....
$ ssh -q $sshConnectionWOL exit
$ echo $?

[kadettilac89]

schau dir das mal an, ich denke das wäre verständlich und für mich OK

SSH im angehängten Modul quick'n'dirty eingebaut. Perl ist nicht meine Mutter-Programmier-Sprache, mehr dirty ....

Attibute:

Code Auswählen Erweitern


defmod WOL_PC WOL 34:97:FF:FF:FF:FF 192.168.0.22 SSH
attr WOL_PC CmdDWN shutdown now  <----
attr WOL_PC CmdWOL wake em0  <----
attr WOL_PC sshConnectionDWN fhem_WOL@192.168.0.22 -p 24   <---
attr WOL_PC sshConnectionWOL fhem_WOL@192.168.1.25 -p 50    <---
attr WOL_PC webCmd on off


Log:

Code Auswählen Erweitern


2020.01.09 18:19:02.776 3: [WOL_PC] set Device: on  Cmd: >"ssh fhem_WOL@192.168.1.25 -p 50 sudo wake em0 34:97:FF:FF:FF:FF"< executed
2020.01.09 18:18:57.138 3: [WOL_PC] set Device: off  Cmd: >"ssh fhem_WOL@192.168.0.22 -p 24 sudo shutdown now"< executed


Meldung wenn eine SSH-Verbindung eingetragen wird die nicht funktioniert (zum Test nur beim WOL-String):

Code Auswählen Erweitern


[WOL_PC] SSH-Login on Host failed: timeout or invalid ssh String <fhem_WOL@192.168.1.25 -p 55>

--> Die Prüfung ist streng, aber reduziert die Supportanfragen zu "deinem" Modul. In der Commandref könnte man auf die Anleitungen von Otto123 verweisen wenn er nihcts dagegen hat, der hat in seinem Blog zu Fhem auch Anleitungen wie SSH mit key zu konfigurieren ist.

Fragen: möchtest du per Definition die MAC immer am Ende des WOL-CMD anhängen, oder Platzhalter $mac, $ip o. ä. zulassen und dann im Sourcecode ersetzen? Ich möchte ungern die MAC direkt im Attribut setzen da diese Information in der DEF enthalten ist. Wenn du die MAC fest am Ende anhängst wird jedoch CMD nicht funktionieren. Platzhalter würden es sehr dynamisch machen.

Wenn du schon Modul änderst, kleiner Bug ... der Ping hat zwar -c 2 -t 2 aber dennoch läuft der Befehl länger als die 4 Sekunden die als Timeout gesetzt sind. Ggf. Timeout höher setzen und im qx ein ... timeout 5 ... o. ä. mitgeben.

Code Auswählen Erweitern


2020.01.09 18:40:38.827 1: Timeout for WOL_Ping reached, terminated process 16623


[KernSani]

Hi, danke erstmal:-D Schau ich mir später an. Ich hatte gestern vergessen zu erwähnen: Ich daxhte an Platzhalter


Kurz, weil mobil

[KernSani]

Hallo zusammen,

danke für den Input. Neben ein paar kleineren Code-Bereinigungen und vereinzelt besserem Fehler-Handling ist in angehängter Version ist nun folgendes umgesetzt:
* Für bestehende WOL Devices ändert sich nichts (sprich: abwärtskompatibilität sollte bestehen)
* Es gibt im DEF die neue Option CMD (alternativ zu BOTH, EW und UDP)
* Es gibt folgende neue Attribute:
   * wolCmd: kann FHEM, Perl (in {}) oder Systemkommando (in "") sein. Dieses Kommando wird ausgeführt, wenn mode CMD gesetzt ist
   * sshHost: ist ein SSH Ziel in der Form user@host:port (wobei user@ und port optional sind). Wenn sshHost gesetzt ist (und mode CMD), wird wolCmd als ssh Befehl ausgeführt, dabei ist es unerheblich, ob der Befehl in "" gesetzt ist, oder nicht.
   * sshHostShutdown: identisch zu sshHost, das (bereits bestehende) shutdownCmd wird über ssh ausgeführt, dabei ist es unerheblich, ob der Befehl in "" gesetzt ist, oder nicht.

Commandref fehlt noch, und ich habe zwei Fragen in die Runde:
1. Derzeit werden die remote Kommandos durch das Modul fest vorgegeben mit "sudo" ausgeführt. Sollte man das besser dem user überlassen (er schreibt selbst sudo ins wolCmd oder per Attribut steuern ("useSudo")? Ich persönlich würde es dem User überlassen (er schreibt's ins wolCmd)
2. Aktuell kann über das wolCmd letztendlich alles auf dem sshHost ausgeführt werden, was der (sudo) user darf. Im vorgeschlagenen Code war angedeutet, dass man das evtl. beschränken könnte. Ich persönlich denke, ein Beschränkung würde nur die Möglichkeiten des WOL-Moduls beschränken und keine zusätzliche Sicherheit bieten (im Zweifelsfall führe nehme ich halt nicht WOL sondern die Kommandozeile)

Ich habe die Coding-Änderungen soweit mir das möglich ist getestet und habe die angehängte Version in meinem Produktivsystem am Laufen, wäre aber dankbar, wenn ein paar Leute das in ihrer Umgebung testen könnten - sowohl mit alten "klassischen" WOLs als auch mit den neuen Möglichkeiten- bevor ich es einchecke. Bis dahin gibt es dann auch noch eine erweiterte CommandRef.

EDIT: Ich hatte vergessen zu erwähnen, sowohl im shutdownCmd als auch im wolCmd können die Platzhalter $IP und $MAC verwendet werden.

Danke,

Grüße,

Oli

[kadettilac89]

1. Derzeit werden die remote Kommandos durch das Modul fest vorgegeben mit "sudo" ausgeführt. Sollte man das besser dem user überlassen (er schreibt selbst sudo ins wolCmd oder per Attribut steuern ("useSudo")? Ich persönlich würde es dem User überlassen (er schreibt's ins wolCmd)

auch OK.

2. Aktuell kann über das wolCmd letztendlich alles auf dem sshHost ausgeführt werden, was der (sudo) user darf. Im vorgeschlagenen Code war angedeutet, dass man das evtl. beschränken könnte. Ich persönlich denke, ein Beschränkung würde nur die Möglichkeiten des WOL-Moduls beschränken und keine zusätzliche Sicherheit bieten (im Zweifelsfall führe nehme ich halt nicht WOL sondern die Kommandozeile)

auch OK. Ggf. ein Hinweis in die Commandref, dass es empfohlen wird einen eingeschränkten User auf dem Host zu nutzen und nicht unbedingt root.

Ich habe das Modul mal eingespielt. WOL hat funktioniert. Ich teste am Wochenende noch ein wenig

[Otto123]

Hallo Oli,

ich wäre dafür sudo unbedingt dem User zu überlassen! Normalerweise braucht es doch kein sudo für ssh.
Ich wäre auch noch für eine Änderung des Default Verhaltens: Das ist derzeit BOTH - also wenn man der DEF nichts mitgibt.
Das halte ich für Unsinn, default sollte UDP sein, das reicht normalerweise aus. BOTH führt beim nicht nachdenkenden Benutzer lediglich dazu, das er etherwake nachinstalliert und dadurch gezwungen anfängt das Ganze mit erhöhten Rechten zu betreiben.

Mir erscheint das mit den ssh Attributen etwas überattribusiert

Gruß Otto

[KernSani]

Hi Otto,

ich wäre dafür sudo unbedingt dem User zu überlassen! Normalerweise braucht es doch kein sudo für ssh.

der sudo wird dem remote-Kommando vorangestellt, sehe ich aber genauso (hatte ich ja oben auch geschrieben) und werde das heute Abend rausnehmen

Ich wäre auch noch für eine Änderung des Default Verhaltens: Das ist derzeit BOTH - also wenn man der DEF nichts mitgibt.
Das halte ich für Unsinn, default sollte UDP sein, das reicht normalerweise aus. BOTH führt beim nicht nachdenkenden Benutzer lediglich dazu, das er etherwake nachinstalliert und dadurch gezwungen anfängt das Ganze mit erhöhten Rechten zu betreiben.

Guter Punkt. Ich wollte mir auch etwas einfallen lassen, dass der User nicht zwingend MAC und IP mitgeben muss bei der DEF.

Mir erscheint das mit den ssh Attributen etwas überattribusiert

sind ja "nur" drei neue Attribute Weniger ging nicht... Wobei die ssh- und command-Optionen tatsächlich den eigentlichen Sinn von WOL etwas ad absurdum führen. In diesem Modus wird WOL zu einer billigen Ausgabe eines PRESENCE Devices das zufällig Commands absetzen kann...  Allerdings ermöglicht es natürlich alle Devices (egal ob echtes WOL oder WOL über ssh) gleich zu behandeln.

Grüße,

Oli 


Gruß Otto
[/quote]

[Frank_Huber]

wäre es nicht eleganter ein Attribut "command_Type" zu haben mit drop down auswahl und ein zweites Attribut für die commands? (on und off command per pipe getrennt z.B.)

[Otto123]

Naja das mit der IP kommt ja daher, das WOL auch Presence macht. Der Gedanke laut commandref ist ja noch, wenn man sie nicht weiß, die Broadcast Adresse mitzugeben.
Dazu hätte ich noch die Idee, dass man die eventuell fehlenden Broadcast Adresse aus der IP Adresse ableiten kann. Bei all meinen bisherigen Umgebungen und Versuchen schlug eine fehlende Broadcast Adresse für Magic Paket bisher immer fehl - sicher weil dann ein Broadcast an ALLE gemacht wird, den mittlerweile jede Netzwerktechnik verwirft. Also wenn überhaupt, dann geht sowieso nur ein gezielter Broadcast an die richtige Netzwerkadresse.
Wenn die fehlt (weil vom User nicht angegeben) halte ich es für legitim die aus der IP abzuleiten und zu setzen. Immer noch besser als die Aussage "funktioniert nicht"

Gruß Otto

[KernSani]

wäre es nicht eleganter ein Attribut "command_Type" zu haben mit drop down auswahl und ein zweites Attribut für die commands? (on und off command per pipe getrennt z.B.)

Verstehe ich nicht ganz. Was verstehst du unter command_Type? Perl/FHEM/System?

Danke,

Oli

[Frank_Huber]

Verstehe ich nicht ganz. Was verstehst du unter command_Type? Perl/FHEM/System?

Danke,

Oli

Ja, genau. Dann brauchst nicht für alles ein eigenes Attribut.

Gesendet von meinem Doogee S60 mit Tapatalk