[Announce] WakeMeUp - Server-0.14 / Client-0.9

  • Hallo,


    hier die neue Version meiner alternativen "VDR-Aufwachlösung".


    Angefangen hatte es in diesem Thread: [PoC]: WakeMeUp - beliebige (VDR-)Rechner lassen sich per WoL wecken... .
    Nunja, entgegen meinem ursprünglichen Willen habe ich mich nun doch noch hingesetzt und das Ganze nochmal gründlich überarbeitet...


    Ciao,
    Matze




    Beschreibung:


    WakeMeUp benutzt ausschließlich Wake-on-LAN, um Rechner aufzuwecken.
    Das setzt natürlich voraus, dass man einen Rechner zur Verfügung hat, der ständig läuft - bei mir ist das zum Beispiel die Linux-Firewall.
    Rein von der Theorie her funktioniert diese Lösung auch über Netzgrenzen (also auch Internet) hinweg - das habe ich allerdings noch nicht getestet.


    Edit: Seit Server Version 0.13 bzw. Client Version 0.8 können nun alternativ auch alle vom Programm 'sispmctl' unterstützten USB-Steckdosenleisten angesteuert werden.
    Die entsprechende Beschreibung dazu ist in diesem Beitrag zu finden. Leider kann ich den Beitrag nicht mehr bearbeiten, um die nunmehr alten Versionen zu löschen.

    (2008-02-23)


    Funktionsweise:


    Der Client - z.B. ein VDR - baut eine Verbindung zum Server auf, teilt diesem seinen nächsten Aufwachtermin mit und fährt sich anschließend herunter.
    Ist der Zeitpunkt erreicht, sendet der Server ein sogenanntes 'Magic'-Paket an die MAC-Adresse vom Client, welcher daraufhin aufwacht.
    Der Vergleich mit einem Hotelgast, der die Rezeption mit einem Weckruf beauftragt, trifft zu 100% den Nagel auf den Kopf :-)



    Voraussetzungen:


    Server
    - Perl
    - Programm 'at'
    - Programm 'arp' oder alternativ: MAC-Adressen fix eintragen


    Client
    - sinnvollerweise VDR ;-)
    - Programm 'netcat'



    Installation auf Debian-basierten Systemen:


    Server
    - apt-get update
    - apt-get install perl libgetopt-mixed-perl libsys-syslog-perl at net-tools
    - apt-get install wakeonlan (optional)
    - apt-get install sispmctl (optional)
    - dpkg -i wakemeup-server_0.14_i386.deb
    - wakemeup-server --help (für Hilfe zu den Optionen)
    - nano /etc/default/wakemeup-server (evtl. Optionen anpassen, ENABLED=1 setzen)
    - /etc/init.d/wakemeup-server start


    Client
    - apt-get update
    - apt-get install netcat
    - dpkg -i vdr-addon-wakemeup_0.9_i386.deb
    - nano /etc/default/vdr-addon-wakemeup (IP des Servers anpassen, ENABLED=1 setzen)



    Installation des Servers auf anderen Systemen (ungetestet):
    - Perl installieren und folgende Bibliotheken: IO::Socket, Sys::Syslog, Getopt::Long
    - arp, at installieren
    - wakeonlan installieren (optional)
    - sispmctl installieren (optional)
    - tar -xzf wakemeup-server_0.14.tar.gz
    - cd wakemeup-server-0.14
    - cp wakemeup.pl /usr/bin/wakemeup-server
    - cp wakeup.pl /usr/bin/wakeup
    - wakemeup-server --help (für Hilfe zu den Optionen)



    Änderungen seit den letzten Versionen:
    - Änderungen an den Timern des Clients werden nun vollständig berücksichtigt (vorher wurde der Client bei nachträglich veränderten Timern auch zu allen anderen Zeiten geweckt)
    - Löschen eines Timers auf dem Client hat nun auch ein Löschen auf dem Server zur Folge (wurde vorher gar nicht berücksichtigt)
    - nahezu komplette Kontrolle über das Programm 'at' (vorher konnten nur neue Jobs hinzugefügt werden)
    - Verbesserungen in den Funktionen zur Berechnung des Aufwachzeitpunkts (vorher gab es teilweise Toleranzen von bis zu 1 Minute)
    - Verbesserungen im PID-File-Handling (neu u.a.: Nutzung von Datei-Locks, 'stale' Pidfiles werden erkannt etc.)
    - Prozess-Priorität des Dienstes kann beeinflusst werden
    - BugFix: Online-Hilfe lässt sich nun auch als normaler User aufrufen
    - BugFix: Server läßt sich nun nicht mehr mit nmap o.ä. abschießen (war unschön, aber nicht sicherheitskritisch)
    - Logging im Shutdown-Hook hinzugefügt, diverse kleinere Fehler korrigiert
    - Sonstiges: Code aufgeräumt, kleinere Fehler korrigiert, Tonnen von überflüssigem Code entsorgt...



    Edit: Server-Version 0.14 und Client-Version 0.9 angehangen, Changelog s.u..
    (2008-03-10)

  • Cool! Das könnte ja die lösung für meine SMT sein!
    Hab aber leider nur ne Fritzbox SL... könnte man das da auch integrieren? Ich meine als Server...

    Alles ist wie immer...nur schlimmer...*mist* :-(



    SMT 7020+120Gig-Hdd 2.5", DVD-Brenner an USB2 ----- NATÜRLICH mit GEN2VDR2!!! Echt der hammer!
    In Arbeit: Sempron "Sparta" 64 LE1100+MSI K9MM-V+320Seagate HDD SATA, 512MB DDR-2, Case SuperFlower SF101BK

  • @ arneproft
    wird bei der smt nur klappen wenn du es packts das mainboard so umzulöten das es die wol packets überhaupt annimmt
    auf dem board ist nämlich kein saft somit geht das nicht
    es ist zwar laut ethtool unterstützt und aktiviert
    aber ohne strom geht da nichts

  • Zitat

    Original von arneproft
    Hab aber leider nur ne Fritzbox SL... könnte man das da auch integrieren? Ich meine als Server...


    Ein Fritz!box und Perl? Da bin ich aber gespannt. Ich schätze mal da geht der SL die Puste
    aus.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • aaahhhh, das sind ja gleich 2 schlechte nachrichten... hmmm also denn ist das Thema also nix für mich.

    Alles ist wie immer...nur schlimmer...*mist* :-(



    SMT 7020+120Gig-Hdd 2.5", DVD-Brenner an USB2 ----- NATÜRLICH mit GEN2VDR2!!! Echt der hammer!
    In Arbeit: Sempron "Sparta" 64 LE1100+MSI K9MM-V+320Seagate HDD SATA, 512MB DDR-2, Case SuperFlower SF101BK

  • Unter Suse 10.3 kommt (auf dem Server) :


    Code
    1. ...Insecure $ENV{ENV} while running with -T switch ...


    Ich habe jetzt in ungefähr Zeile 385 stehen, damit es geht - sonst raucht jedesmal der server ab :


    Code
    1. # clear path environment as described in the "Perl Taintmode FAQ"
    2. $ENV{'PATH'} = "";
    3. # set path environment
    4. $ENV{'PATH'} = "/usr/local/bin:/usr/bin:/bin:/usr/sbin";
    5. # untaint for variables
    6. $ENV{'ENV'} = "";


    und es stören die Pfade zu wakeonlan - das heisst unter Suse wol und der Pfad zu arp ist da auch nicht /usr/sbin... - das ist leider alles hart verdrahtet - etwas unschön.


    Das Paket wird nun gesendet - nur manchmal wacht die Büchse auf - und manchmal nicht

  • magicamun :


    Was soll das denn Deiner Meinung nach bewirken

    Code
    1. $ENV{'ENV'} = "";

    ???


    Wenn die Pfade bei Dir nicht stimmen, wäre es sehr nett, wenn Du die mal hier postest - dann kann ich sicher auch sagen, was dafür im Environment noch fehlt.



    Übrigens heißt das verwendete Programm schon wakeonlan, siehe hier: http://gsd.di.uminho.pt/jpo/software/wakeonlan/.
    Ein Programm namens wol finde ich im Debian-Repository gar nicht.



    Was meinst Du damit, dass Deine Büchse manchmal aufwacht und manchmal nicht ? Hast Du mal in den Logs nachgesehen ?

  • Server (Suse 10.3) :


    Code
    1. amun:/usr/local/src # rpm -qa | grep wol
    2. wol-0.7.1-74
    3. amun:/usr/local/src # type wol
    4. wol is /usr/bin/wol
    5. amun:/usr/local/src # type arp
    6. arp is /sbin/arp


    warum ich das ENV-Thema machen musste - weil wie gesagt sonst der Server an dieser Stelle abschmirgelte :


    Code
    1. &logger("WakeMeUp list ...");
    2. chomp (@list = `/usr/bin/at -l 2>/dev/null`);
    3. &logger("WakeMeUp list1 ...");


    wobei mir die "logger" - Aufrufe beim finden des Problems geholfen haben.



    Warum er nur manchmal aufwacht - das hab ich noch nicht rausgefunden - da suche ich noch


    Vorschlag für dei Pfade - machs als Parameter in die conf/default

  • magicamun :


    Ok, wenn Du folgende Zeile

    Code
    1. $ENV{'PATH'} = "/usr/local/bin:/usr/bin:/bin:/usr/sbin";

    in

    Code
    1. $ENV{'PATH'} = "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin";

    änderst, sollte er nicht mehr mit "Insecure dependency..." abbrechen.
    Dein Code dürfte rein theoretisch gar nichts bewirkt haben, denn Du leerst damit nur eine Umgebungsvariable mit Namen ENV.


    Im Übrigen kann man sich bei so etwas temporär behelfen, indem man in der ersten Zeile vorübergehend das große "T" entfernt:
    #!/usr/bin/perl -Tw



    Zum Debuggen der Anwendung kannst Du den Dienst ja mal per Hand starten und laufen lassen.


    Hier mal eine grobe Vorgehensweise:
    - Dienst beenden z.B. mittels /etc/init.d/wakemeup-server stop oder kill `cat /var/run/wakemeup-server.pid`
    - danach händisch starten: wakemeup-server (Abbruch mit STRG+C)
    - auf einem Client folgendes eingeben: echo $[`date +%s`+600] | nc -n 10.1.1.1 9999 (hier natürlich eigene IP und verwendeten Port angeben)
    - wenn alles ok ist, die Job-Liste von at aufrufen mit: at -l und den zur eben gesetzten Uhrzeit passenden Job raussuchen (die Nummer)
    - Job anzeigen lassen mit: at -c $JOBNUMMER
    - Befehlszeile am Ende des Jobs händisch testen


    Gruß,
    Matze

  • Hi,


    es gibt wieder ein Update für den Server, aktueller Stand ist jetzt 0.10.



    Changelog:
    - '/sbin' in die Umgebungsvariable $PATH aufgenommen
    - Funktion 'find_executables' hinzugefügt, nun werden benötigte Programme im gesamten Pfad gesucht
    - Script 'wakeup' hinzugefügt, sodass 'wakeonlan' jetzt entfallen kann :strike1 (das bischen Magic über UDP versenden kann ich doch auch ohne fremde Programme) :lol2



    Gruß,
    Matze

  • klasse - mach ich gerne heute Abend - auch wenn es bei mir ja nun prinzipiell in der von mir hingefrickelten Variante tut - feedback kommt.

  • Hi,


    und hier wieder eine neue Version für den Server, Stand ist jetzt 0.12.


    Changelog:
    - Tippfehler in Kommandozeilen-Option 'wakeupbefore' behoben
    - Tippfehler in Kommandozeilen-Option 'nicelevel' behoben
    - Logging der Prozess-ID verändert, vorher konnte es auf manchen Systemen zu Perl-Warnings kommen


    Alles in Allem also nur kosmetische Änderungen...


    Gruß,
    Matze

  • Hi,


    es gibt wieder neue Versionen ;)


    Ich habe nun noch Support für alle USB-Steckdosenleisten eingebaut, welche vom Programm sispmctl unterstützt werden.


    Ich selbst besitze die revolt "Intelli-Plug" Steckdosenleiste mit Ü-Schutz USB von Pearl, die auch unter dem Namen 'GEMBIRD SiS-PM' bekannt ist.


    Da ich dieses Feature noch als experimentell bezeichnen würde, hänge ich die entsprechenden Versionen vorerst nur in diesem Beitrag an.
    Selbstverständlich funktioniert in dieser Version auch die Wake-On-LAN-Methode weiterhin wie gehabt.


    Ich habe lange überlegt, wie ich es hinbekomme, dass ich diese USB-Leiste zum Aufwachen benutzen kann UND den VDR trotzdem auch zwischendurch einschalten kann - denn das ginge ja bei ausgeschalteter Steckdose nicht...
    Die einzige Lösung, die mir sinnvoll erschien, ist die Steckdose unter Strom zu lassen und sie lediglich 1 Minute vor dem Aufwachtermin abzuschalten.
    Zum Aufwachtermin wird sie dann natürlich wieder eingeschaltet.


    Damit das funktioniert, muss im BIOS des aufzuweckenden Rechners eingestellt sein, dass er nach einem Stromausfall hochfährt.
    Bei meinem Rechner (Award BIOS) sieht es so aus:
    Power Management Setup
    ** Power Up Control **
    AC PWR Loss Restart: ENABLED

    Viel Spaß damit !


    Gruß,
    Matze

  • Zitat

    Original von magicamun
    klasse - mach ich gerne heute Abend - auch wenn es bei mir ja nun prinzipiell in der von mir hingefrickelten Variante tut - feedback kommt.


    Wollte nochmal nachfragen, ob es bei Dir mit den neuen Versionen besser geklappt hat ? Hast Du nun schon herausgefunden, warum Dein Rechner nicht immer aufwacht ?


    Gruß,
    Matze

  • Ich hatte mir die alte Version ja "hingefrickelt" - die neue habe ich dann doch nicht wie angekündigt ausprobiert.


    Mach ich aber noch - nur nicht mehr diese Woche.


    Die Ursache der WakeUP-Probleme liegt ausserhalb des Servers/Clients - das ist ein Hardware-Thema - die Büchse geht zwar "an" - Stromtechnisch - steht dann aber hin - kommt in seltenen Fällen auch mir dem IR-Einschaler vor. Da ich keinen Monitor dranhab, sehe ich in diesen Fällen nie, was wirklich los ist/war - ein Reset hilft dann i.d.R.

  • hi,


    ich hatte nun hier und da mal einige kleine Probs mit dem Hack.
    Soweit ich das verstehe, wird *nur* ein Job erstellt, wenn der vdr runterfaehrt, der die naechste Startzeit enthaelt?


    Ich habe automatisch erstellte Timer aus Suchworten im EPG und nur einen Job in der Liste.


    EON hatte heute ein wenig am Netz gebastelt und oefter mal den Strom abgestellt. Da is der vdr nicht wieder aufgewacht.


    Hast Du nicht Lust ein Realtime-Update der Jobliste daraus zu basteln? :)
    (ie. bei Timererstellung gleich einen Job generieren)
    Ich weiss, das erfordert etwas mehr Verwaltungsaufwand, weil die Jobnummern eben nix mit der Timerliste zu tun haben...


    Waer schon was....
    Gruss...

  • Zitat

    ich hatte nun hier und da mal einige kleine Probs mit dem Hack.


    Wäre interessant zu wissen, was das für Probleme waren/sind, damit ich sie ggf. fixen kann.



    Zitat

    Soweit ich das verstehe, wird *nur* ein Job erstellt, wenn der vdr runterfaehrt, der die naechste Startzeit enthaelt?


    Ja.
    Das ist ja ein shutdown-hook, und da gibts halt immer nur den nächsten Timer - ist bei anderen Lösungen (z.B. nvram-wakeup) genauso.



    Zitat

    EON hatte heute ein wenig am Netz gebastelt und oefter mal den Strom abgestellt. Da is der vdr nicht wieder aufgewacht.


    Hmm, aber das ist doch kein Problem mit dem Skript, sondern eine Frage der BIOS-Einstellung (siehe weiter oben: Power Up Control) - oder habe ich das falsch verstanden ?



    Zitat

    Hast Du nicht Lust ein Realtime-Update der Jobliste daraus zu basteln?


    Hmm, die Lust steigt bei mir immer annähernd linear zum Feedback - und im Moment bin ich nicht grad hoch motiviert ;)


    Ich sehe eigentlich keinen Sinn darin, die Timer sofort beim Erstellen auf den Server (wakemeup) zu schreiben und dann auch noch alle... (bei nvram ginge letzteres auch gar nicht)


    Aber ich kann Dir vielleicht eine Quick-and-Dirty-Lösung anbieten, die periodisch (z.B. per cron alle 5 Minuten) den nächsten Timer ausliest und sofort im Server setzt.
    Würde das ausreichen ?


    Gruß,
    Matze