FREETZ Paket Halt-On-Lan (HOL)

@Ralf: Es war eher nicht die Größe dabei gemeint, sondern der Umfang. Geh bitte auf die zweifach zitierte Webseite drauf. Erstaunlicherweise hat der Autor von poweroff alles knapp und bündig auf einer Webseite erläutert. Wenn du es diagonal liest, wirst du feststellen, wie umfangreich die Funktionalitäten vom Programm sind. Du kannst sowohl vom Programm selbst (als GUI oder per Commando) diverse Rechner hoch und runterfahren (sowohl localhost, als auch remote), kannst diverse Meldungen verschicken, Benutzer ausloggen lassen, Monitor ausschalten, und, und, und.... Das ist schon viel weiter als nur poweroff. Ich hatte in meinem FREETZ-Paket ja auch nur 2-3 Commandos implementiert, wenn überhaupt.
Außerdem funktioniert dieses poweroff.exe-Dingens nicht ganz so wie es soll. Es ist anscheinend doch nicht so leicht einen Systemdienst zu schreiben, den du auch noch als nicht-Admin konfigurieren könntest. Das Hauptproblem am poweroff.exe liegt darin, dass du es nur dann im Vollen Umfang nutzen kannst, wenn du es explizit als Benutzer im Benutzermodus startest. Das ist die leichteste Variante und das wollte ich eben ausdrücklich nicht. Du kannst poweroff.exe auch als System laufen lassen, allerdings läuft das Ding in diesem Fall völlig blind und du hast als Normalbenutzer überhaupt keine Chance etwas per GUI zu verstellen oder zu steuern. In diesem Modus läuft allerdings komischerweise die rudimentäre Funktion des Herunterfahrens. D.h., wenn du den Rechner von extern ansprichst, dann fährt er ohne wenn und aber (und leider auch ohne Warnmeldungen, weil GUI ja nicht vernünftig mit dem Dienst "redet") herunter.
Das sind eben die Eigenarten und die Krankheiten von poweroff.exe. Angeblich existieren auch irgendwo Quellen für dieses Windows-Programm. Aber wie gesagt, eigentlich wollten wir es hier nicht diskutieren. Die Idee, die dahinter steckt und die SMTP-ähnliche Protokollierung imponiert mir dennoch.

MfG

@ka1477: Die Funktionen, die du beschrieben hast würden vollkommen ausreichen. Das ist genau das, was ich meinte, als ich sagte, dass poweroff.exe kompliziert ist. Ich würde aber an dem Syntax von poweroff.exe bleiben, damit der Nutzer zwischen deinem schlanken exe-Tool und dem poweroff.exe frei wählen kann.
Dies als Programm im Tray laufen zu lassen ist keine große Kunst. Es als Systemdienst vernünftig zu realisieren ist eine Herausforderung. Heutzutage hat man typischerweise mehrere Konten auf einem Rechner aktiv. Wer das nicht hat, der ist eher Sonderfall oder hat die Vorteile einer Benutzerverwaltung noch nicht begriefen. Bei mir laufen auf jedem Rechner zuhause mindestens 4 bis 5 Accounts für jedes Familienmitglied. Es existieren Zustände, wo der Rechner zwar hochgefahren ist, jedoch kein Benutzer angemeldet ist. In diesem Fall kannst du mit einem exe-Programm nichts tun, wenn es nicht als Dienst konfiguriert und vor allem kompiliert ist. Alle M$-Tricks mit srvany funktionieren nur bis zur nächsten Abmeldung, denn Windows killt alle exes, die für Usermode kompiliert sind automatisch beim Abmelden und das kannst du nicht unterbinden. Deswegen war mir ein echtes Service wichtig. Und das tut poweroff.exe wenigstens halbwegs.
Deswegen nochmal bitte: Wenn du dich an die Syntax-Regeln von poweroff.exe wenigstens für die von dir beschriebenen Funktionen hälts, brauchst du nichts auf FREETZ-Seite tun, denn mein Paket ist fertig und sogar per UI konfigurierbar. hol-Shellskript liegt separat unter /usr/bin und kann mit Parameter aufgerufen werden. Du brauchst dann nicht das Rad neu erfinden. Wenn du allerdings dein eigenes Standard einführen willst und dich am Protokoll von poweroff.exe nicht hälts, dann musst du von vorne anfangen. Und das ist kontraproduktiv.
@Ralf: Ich will, dass die Syntax von poweroff.exe erhalten bleibt, mir würden aber elementare Funktionen, wie Herunterfahren, Reboot und vielleicht noch StandBy ausreichen. Das Ding muss nicht wie poweroff.exe aktiv agieren und Aktionen auf fremden Rechner auslösen.

Allerdings würde ich von StandBy und Ruhezustand dringends abraten. Beide Modis vertragen sich sehr schlecht mit einem echten WOL. Das heißt im Klartext, dass man den Rechner nachher kaum aufgeweckt bekommt.

MfG

ok, danke! Sobald du was hast, melde dich einfach, dann versuchen wir es zusammenzuführen. Ich bin bereit in meinem HOL-Paket auch was anzupassen, wenn es erforderlich wäre.
@ka1477: Wie planst du nachher deine exe-Datei zu verbreiten? Legst du auch Quellen frei, wie es GPL-mäßig üblich ist, oder willst du sie für dich behalten? Es wäre in diesem Fall ganz gut, wenn du irgendwo extern auf einem Server die Datei und die Quellen ablegen könntest und wir aus WIKI heraus und von hier aus darauf verweisen könnten.

Und noch bitte ein Aufruf an alle Linux-Profis: Kann bitte jemand durch meine Geschreibsel für Linux-Rechner durchschauen (im Posting 1 zu finden), ob es denn so akzeptabel wäre. Das wäre nämlich der andere Weg für diejenigen, die Linux und nicht Windows nutzen. Ich wäre auch demjenigen dankbar, der die Weiterentwicklung von diesem Linux-Part übernehmen könnte und daraus eine vernünftige Installation (vielleicht auf Shell-Basis) basteln könnte. Oder wäre es leichter die Quellen von ka1477 auch Linux-tauglich zu machen?

MfG

@linuxkasten: Machst du da Parallelentwicklung zu ka1477? Kann es sein, dass du keinen richtigen Dienst kompiliert hast. Wie gesagt, man kann auch mit srvany jede Datei zu einem Dienst erklären. Das läuft jedoch in die Hose, sobald windows an diese exe-Datei so eine Art kill (ich weiß nicht, wie das in M$-Welt heißt) schickt. Echte Dienste ignorieren diese kill-Anfrage, gewöhnliche exe-Dateien beenden sich. So eine kill-Abfrage wird z.B. bei jedem Abmelden an alle exe-s geschickt. Das ist die übliche Methode von M$ alle Prozesse von einem Benutzer zu terminieren, wenn er sich abmeldet. Ich vermute, dass bei standby und Co. etwas ähnliches passiert.
@ka1477: Dein Syntax jetzt ist aber wieder weit davon entfernt, was ich unter HOL implementiert hatte. Wie gesagt, du kannst es gerne per telnet direkt ansprechen, dann erfindest du das Rad aber neu. Schau doch in mein HOL-Paket rein (Posting #1).
@doppelfritz: Danke! Allerdings nicht alle haben Debian oder Ubuntu. Warum kann man es nicht als sh-Installationdatei implementieren?
Zu inetd habe ich grundsätzlich keine Bedenken. Was zusammenführen beider Shell-Skripte angeht, muss ich schauen, warum und wozu ich sie getrennt hatte.
@Silent-Tears: Es ginge darum alles möglichst auf einen gemeinsamen Nenner zu bringen, damit man mit der Syntax von poweroff.exe alle Rechner ansprechen könnte und EINE GUI unter FREETZ dafür verwenden könnte und nicht Tausende Lösungen anbieten. Klar, sind die Linux-Benutzer meistens weiter entwickelt als ihre Windows-Kollegen. Es gibt aber heute druchaus viele, die zwar Linux verwenden, von der Installation, Kommandozeile, Shell aber wenig Ahnung haben. Für die galt es eben so ein Installationskript zu entwickeln, damit man es etwas automatisieren kann. Die Praxis ist übrigens in der Linux-Welt ziemlich verbreitet, solche Installationskripte anzubieten.

MfG

@linuxkasten: Danke! Ich habe mir die Beschreibung angeschaut, allerdings habe noch nicht versucht es zu installieren. Wenn du eine korrigierte Version fertig hast, melde dich hier bitte. Wo hostest du deine Binary/Sourcen? Ich spekuliere mal damit, dass HOL irgendwann mal in FREETZ einfließt. Damit die Benutzer nachher nicht leer stehen, wenn dein Server nicht geht und du aus diesem Forum warum auch immer weg bist (nicht persönlich gemeint, es gibt leider genügend Beispiele dazu in IPPF), sollte man sich überlegen, wo man die Sourcen und die Binaries redundant hostet.
@doppelfritz: Ich bin leider kein Debian-Experte und kann mit den deb-Packages wenig anfangen, als sie zu installieren. Kannst du bitte deine Änderungen als gepackte Shell-Skripte oder als patches posten?

@all:
Die Interesse scheint doch etwas mehr angestiegen zu sein, als zuvor gemeldet. Vor allem bin ich positiv überrascht, dass sich mehrere Helfer aus Windows- und Linux-Ecken gemeldet haben. Ich warte noch auf Rückmeldungen der beiden Client-Fraktionen und überlege mir langsam, was man an HOL noch verbessern und erweitern kann.

MfG

@doppelfritz: Danke für die Aufklärung. Jetzt habe ich verstanden, was du mit dem integrieren von do_action.sh meintest. Die Idee mit dem inetd ist ziemlich pfiffig, setzt allerdings inetd voraus, was vielleicht nicht immer vorhanden sein könnte (ich sage nur SuSE und mehr nichts...).
Die Idee mit cat ist auch nicht schlecht und meint wahrscheinlich die Methode, wo du per cat alles bis zum EOF aus dem Code auslesen kannst und irgendwochin cat-en kannst.
Wenn ich Zeit habe und du nichts dagegen hast, würde ich versuchen aus unseren beiden Lösungen eine gemeinsame zu entwickeln, die Folgendes beinhalten wird:
1. Es wird nur eine sh-Datei, die man als sudo ausführen sollte.
2. Die Datei wird mit "dateiname install" und "dateiname uninstall" aufgerufen werden können.
3. Beim Installieren wird gescheckt, ob inetd existiert und ob deine Methode angewendet werden kann.
4. Wenn ja, wird nur poweroff.sh gecatet und deine inetd-Befehle ausgeführt.
5. Wenn kein inetd vorhanden werden mein rc-Skript und auf netcat-basierter Daemon an die entsprechenden Stellen gecatet und beim Bedarf gestartet.
6. Uninstall-Sektion dürfte sich relativ einfach gestalten: Alles löschen und inetd austragen.

Somit hätten wir eine mehr oder weniger universelle Lösung für alle Linux-Systeme.

Anstatt einer etwas unübersichtlicher cat-Methode kann man die Dateien auch alle als tar.bz2 verpacken und drinne eine Datei namens "install" mit Ausführungsrechten beipacken. Der Benutzer muss dann lediglich archiv.tar.bz2 entpacken und install ausführen, was in der Linux-Welt ziemlich oft verbreitet ist. In diesem Fall kann man die Dateien etwas besser pflegen, als wenn sie alle cat-präpariert in einer langen sh-Datei versteckt werden.

MfG