SSH Verbindung und Ausführen von Script via URL triggern
Hallo,
ich möchte folgendes realisieren:
Wenn ich eine bestimmte URL auf meinem Debian Webserver aufrufe, soll dieser sich per SSH mit meinem Mac verbinden und dort ein AppleScript ausführen.
Ich habe versucht, dies über ein Shell Script zu lösen. Das Script an sich funktioniert (Login per SSH, dann ENDSSH, dann osascript script.scpt). Allerdings kann ich es nicht über eine URL triggern. Genau dies ist aber wichtig. Ich möchte mit Llama auf meinem Android eben etwas automatisieren ("wenn verbunden mit Heimetzwerk, rufe URL auf" --> die URL triggert über Debian den Mac).
Der Umweg über Debian ist gewollt, denn ich habe vor, in Zukunft einen raspberry pi mit raspbian als Server laufen zu lassen. Hierüber sollen auch andere Automatisierungen stattfinden, sodass es mir nichts bringen würde, diesen Einzelfall direkt von Android nach Mac zu realisieren, selbst wenn das möglich wäre.
Ich bin ein ziemlicher Anfänger auf diesem Gebiet, daher bitte ich um Nachsicht. Vielleicht könnt Ihr mir ja weiterhelfen ?
Danke & beste Grüße
ich möchte folgendes realisieren:
Wenn ich eine bestimmte URL auf meinem Debian Webserver aufrufe, soll dieser sich per SSH mit meinem Mac verbinden und dort ein AppleScript ausführen.
Ich habe versucht, dies über ein Shell Script zu lösen. Das Script an sich funktioniert (Login per SSH, dann ENDSSH, dann osascript script.scpt). Allerdings kann ich es nicht über eine URL triggern. Genau dies ist aber wichtig. Ich möchte mit Llama auf meinem Android eben etwas automatisieren ("wenn verbunden mit Heimetzwerk, rufe URL auf" --> die URL triggert über Debian den Mac).
Der Umweg über Debian ist gewollt, denn ich habe vor, in Zukunft einen raspberry pi mit raspbian als Server laufen zu lassen. Hierüber sollen auch andere Automatisierungen stattfinden, sodass es mir nichts bringen würde, diesen Einzelfall direkt von Android nach Mac zu realisieren, selbst wenn das möglich wäre.
Ich bin ein ziemlicher Anfänger auf diesem Gebiet, daher bitte ich um Nachsicht. Vielleicht könnt Ihr mir ja weiterhelfen ?
Danke & beste Grüße
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 263347
Url: https://administrator.de/contentid/263347
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
15 Kommentare
Neuester Kommentar
Hi.
Das einezige was mir gerade auf die schnelle auffällt ist das "home"-Verzeichnis.
PHP wird von Apache ausgeführt und Apache läuft als welcher User, vermutlich www-data. und genau... dieser User hat kein Homeverzeichnis also auch keinen SSH-ID mit der er sich gegenüber anderen Identifizieren könnte. Evtl. (reine spekulation) benötigt der Parameter "-i" sogar auch einen Dateinamen und nciht nur den Pfad. Also scheitet es so schon bei der SSH Verbindung.
Ich habe da aber etwas anderes !
Ich selber habe hier auch ein RasPi "rumliegen" das unter anderem als Internetradio verwendet wird (mpd) und dessen Steuerung (play/stop/volume) habe ich über ein "Webinterface" eingerichtet bzw. über URL Aufrufe so wie du es im Grunde auch vor hast.
Mit xinetd binde ich ein Bash-Script an einen Port bzw. lasse Anfragen an diesen Port an das Script weiterleiten. Das Script wertet die Anfrage aus und ruft dan die gewünschte Funktion auf. Die wiederum kann alles was die Bash zu bieten hat.
Sehe gerade das das Script dann mit ROOT-Rechten läuft... das sollte man vieleicht auf "pi" abändern.
Und im BASH-Script dan etwa wie folgt: (She-Bang nicht vergessen)
Aufrufen tue ich das ganze dann allerdings über eine selbsterstellte Android-App mit der ich nun in Wlan reichweite meinen Musik steuern kann.
Die GPIOs können so auch angesprochen werden... wollte diese verwenden um meinen Verstärker ein und aus schalten zu können... das ist mir aber noch nicht geglückt Dauerbetrieb das Verstärkers ist ja auch doof
Was mir nur bis jetzt noch nicht eingefallen war, war die automatisierung mittels Llama (das ich bereits in verwendung habe) um die Wiedergabe zu starten wenn ich nach hause komme / stoppen beim verlassen.
Dafür danke ich dir !
Achso, gerichtet habe ich mich damals nach diesem Artikeln: http://www.debian-administration.org/article/371/A_web_server_in_a_shel ...
~Arano
Das einezige was mir gerade auf die schnelle auffällt ist das "home"-Verzeichnis.
PHP wird von Apache ausgeführt und Apache läuft als welcher User, vermutlich www-data. und genau... dieser User hat kein Homeverzeichnis also auch keinen SSH-ID mit der er sich gegenüber anderen Identifizieren könnte. Evtl. (reine spekulation) benötigt der Parameter "-i" sogar auch einen Dateinamen und nciht nur den Pfad. Also scheitet es so schon bei der SSH Verbindung.
Ich habe da aber etwas anderes !
Ich selber habe hier auch ein RasPi "rumliegen" das unter anderem als Internetradio verwendet wird (mpd) und dessen Steuerung (play/stop/volume) habe ich über ein "Webinterface" eingerichtet bzw. über URL Aufrufe so wie du es im Grunde auch vor hast.
Mit xinetd binde ich ein Bash-Script an einen Port bzw. lasse Anfragen an diesen Port an das Script weiterleiten. Das Script wertet die Anfrage aus und ruft dan die gewünschte Funktion auf. Die wiederum kann alles was die Bash zu bieten hat.
# /etc/xinetd.d/"PORTSCRIPT"
#
# > ## default: off
# > # description: An xinetd internal service which echo's characters back to
# > # clients.
# > # This is the tcp version.
# > service portscript
# > {
# > socket_type = stream
# > protocol = tcp
# > port = 33000
# > type = UNLISTED
# > wait = no
# > user = root
# > server = /home/pi/portscript.sh
# > #server_args = Hallo Welts!
# > }
Und im BASH-Script dan etwa wie folgt: (She-Bang nicht vergessen)
# lese komando ein
read command
echo "Read: $command" >>$LOG
# zerlege $command anhand der leerzeichen in "brocken"
# $1 = hauptCommand
# $2 = parameter 1
# $3 = para2 , ...
IFS=" "
set -- $command
# fuere aktion zu $command aus
case $1 in
test)
echo "TEST"
;;
play)
exe "$command"
mpc play >>$LOG 2>&1
ret=$?; [ $ret -ne 0 ] && err "002" "Komando meldet Fehlercode $ret" "$ret"
;;
*)
err "001" "Server kennt Komando \"$command\" nicht" "1"
;;
esac
Aufrufen tue ich das ganze dann allerdings über eine selbsterstellte Android-App mit der ich nun in Wlan reichweite meinen Musik steuern kann.
Die GPIOs können so auch angesprochen werden... wollte diese verwenden um meinen Verstärker ein und aus schalten zu können... das ist mir aber noch nicht geglückt Dauerbetrieb das Verstärkers ist ja auch doof
Was mir nur bis jetzt noch nicht eingefallen war, war die automatisierung mittels Llama (das ich bereits in verwendung habe) um die Wiedergabe zu starten wenn ich nach hause komme / stoppen beim verlassen.
Dafür danke ich dir !
Achso, gerichtet habe ich mich damals nach diesem Artikeln: http://www.debian-administration.org/article/371/A_web_server_in_a_shel ...
~Arano
Hi,
das wird wohl doch schwerer als gedacht...
Nein, mit dem Apache sollte das keine Probleme geben !
Wegen den SSH-Keys die nur für root gelten, das könnte man auch ändern/anpassen aber das lassen wir jetzt mal lieber.
Wegen dem Script, das ganze ist EIN Bash-Script und wegen der Frage wo die She-Bang hin soll, müsste jetzt ein Bash-Grundkurs folgen. Um diesen muss du dich aber selber kümmern wenn du auf diesem Weg bleiben möchtest (ich kenne aber auch keinen anderen).
Mein Script ist da noch ein Stück komplexer und ich habe nur die relevanten Teile gepostet die du dann selber zusammensetzen solltest. Die She-Bang stellt dabei die erste Zeile in der Datei dar, damit beim ausführen das Betriebssystem erkennen kann um was für ein Script es sich handelt. Könnte ja auch ein Sh-Script oder ein Perl-Script oder PHP, oder viele andere sein. Anschließend wird der Dateiinhalt an das entsprechende Programm/Interpreter weitergegeben und dieser interpretiert es / arbeitet es ab. Hier wäre /bin/bash der passende Interpreter / die auszuführende Datei und die She-Bang dazu: "#!/bin/bash"
Wie gesagt, Bash-Grundkurs möchte ich hier nicht geben:
Möglicherweise ist das ganze so auch viel zu komplex für dich, denn der Browser sendet ja auch nicht nur einfach den "Befehl" der generiert einen kompletten HTTP-Header (denn das ist ja seine Aufgabe als Browser). Darum auch der Link zum Ende des Posts, dort habe ich ja auch abgeschaut.
s. Step 2+3
In Step 3 verwenden wir den Dateinamen dann als Schlüsselwort um unsere gewünschten Aktionen ausführen zu lassen.
Und anstelle von Step 4 (auslieferung der Datei) erfolgt dann unsere definition der Aktionen - in meinem Script das CASE.
Je nach Schlüselwort/Befehl/Command wird dann NUR ein anderer Teil des Scripts aufgeführt (play/pause/volume,ect.)
Und ja, hier hast du das richtig erkannt, zwischen ) und ;; stehen dann weitere Bash-Komandos.
Wie du ds ganze dann zusammenstellst bleibt dir überlassen, allerdings alles an einzelne Ports zu hängen tu absolut nicht not ! Dann müsstest du für jeden Befehl ein Port belegen, ein xinetd-Anweisung erstellen und je ein separates Script erstellen.
ODER man Schreibt ein Script, das je nach Befehl etwas anders macht und hängt es an einen einzigen Port. Das ist auch viel einfacher erweiterbar, einfach das Script erweitern und das wars.
Wenn ja dann fang doch klein an.
Lasse das Script doch einfach nur die Zeit in eine Datei schreiben, dann kannst du das Triggern per Browser testen. Und wenn das funktioniert, dann wird halt erweitert: HTTP-Header auslesen, auseinandernehmen, Schlüsselwort suchen, je nach Schlüsselwort etwas anders in die Datei schreiben und zu letzt das ausführen der Aktionen.
Zum entwicklen ruhig immer in zwischenschritten etwas in die Datei mit hinein schreiben, dann kann man ganz gut mitverfolgen wie weit das Script gekommen ist bis es "nicht mehr weitere ging" und hat so einen anhalspunkt an dem man nach einem Fehler suchen kann.
Solange xinetd aber mit einer Fehlmeldung restartet (bzw. NICHT startet), macht das ganz sicherlich keinen Sinn !
Mit
Mein Anweisung für xinetd sieht wie folgt aus:
~Arano
Ich probiere gerade mein Script unter "pi" laufen zu lassen aber schainbar ist mein internetradiostream gerade... "lautlos" *fg* Verbunden wird zwar und es wird wiedergegeben... aber ich höre nichts !? Naja, mal schaun.
das wird wohl doch schwerer als gedacht...
Nein, mit dem Apache sollte das keine Probleme geben !
Wegen den SSH-Keys die nur für root gelten, das könnte man auch ändern/anpassen aber das lassen wir jetzt mal lieber.
Wegen dem Script, das ganze ist EIN Bash-Script und wegen der Frage wo die She-Bang hin soll, müsste jetzt ein Bash-Grundkurs folgen. Um diesen muss du dich aber selber kümmern wenn du auf diesem Weg bleiben möchtest (ich kenne aber auch keinen anderen).
Mein Script ist da noch ein Stück komplexer und ich habe nur die relevanten Teile gepostet die du dann selber zusammensetzen solltest. Die She-Bang stellt dabei die erste Zeile in der Datei dar, damit beim ausführen das Betriebssystem erkennen kann um was für ein Script es sich handelt. Könnte ja auch ein Sh-Script oder ein Perl-Script oder PHP, oder viele andere sein. Anschließend wird der Dateiinhalt an das entsprechende Programm/Interpreter weitergegeben und dieser interpretiert es / arbeitet es ab. Hier wäre /bin/bash der passende Interpreter / die auszuführende Datei und die She-Bang dazu: "#!/bin/bash"
Wie gesagt, Bash-Grundkurs möchte ich hier nicht geben:
- Weil ich mich dafür nicht als geeignet sehe (Ich kann zwar vieles aber eben nicht alles und wenn man lehr, dann richtig oder gar nicht !)
- gibts davon schon viele und
- um eigene Erfahrung kommt man nun mal nicht herrum
Möglicherweise ist das ganze so auch viel zu komplex für dich, denn der Browser sendet ja auch nicht nur einfach den "Befehl" der generiert einen kompletten HTTP-Header (denn das ist ja seine Aufgabe als Browser). Darum auch der Link zum Ende des Posts, dort habe ich ja auch abgeschaut.
s. Step 2+3
In Step 3 verwenden wir den Dateinamen dann als Schlüsselwort um unsere gewünschten Aktionen ausführen zu lassen.
filename = command
Und anstelle von Step 4 (auslieferung der Datei) erfolgt dann unsere definition der Aktionen - in meinem Script das CASE.
Je nach Schlüselwort/Befehl/Command wird dann NUR ein anderer Teil des Scripts aufgeführt (play/pause/volume,ect.)
Und ja, hier hast du das richtig erkannt, zwischen ) und ;; stehen dann weitere Bash-Komandos.
Wie du ds ganze dann zusammenstellst bleibt dir überlassen, allerdings alles an einzelne Ports zu hängen tu absolut nicht not ! Dann müsstest du für jeden Befehl ein Port belegen, ein xinetd-Anweisung erstellen und je ein separates Script erstellen.
ODER man Schreibt ein Script, das je nach Befehl etwas anders macht und hängt es an einen einzigen Port. Das ist auch viel einfacher erweiterbar, einfach das Script erweitern und das wars.
- Willst du hier überhaupt weitermachen ?
Wenn ja dann fang doch klein an.
Lasse das Script doch einfach nur die Zeit in eine Datei schreiben, dann kannst du das Triggern per Browser testen. Und wenn das funktioniert, dann wird halt erweitert: HTTP-Header auslesen, auseinandernehmen, Schlüsselwort suchen, je nach Schlüsselwort etwas anders in die Datei schreiben und zu letzt das ausführen der Aktionen.
Zum entwicklen ruhig immer in zwischenschritten etwas in die Datei mit hinein schreiben, dann kann man ganz gut mitverfolgen wie weit das Script gekommen ist bis es "nicht mehr weitere ging" und hat so einen anhalspunkt an dem man nach einem Fehler suchen kann.
Solange xinetd aber mit einer Fehlmeldung restartet (bzw. NICHT startet), macht das ganz sicherlich keinen Sinn !
Mit
netstat
kannst du schauen ob, NACHDEM xinetd OHNE Fehler startet, ob der Port belegt ist:pi@raspberrypi /etc/xinetd.d $ sudo netstat -tapen | grep 33000
tcp 0 0 0.0.0.0:33000 0.0.0.0:* LISTEN 0 61020 6778/xinetd
pi@raspberrypi /etc/xinetd.d $
Mein Anweisung für xinetd sieht wie folgt aus:
pi@raspberrypi /etc/xinetd.d $ cat portscript
# default: off
# description: An xinetd internal service which echo's characters back to
# clients.
# This is the tcp version.
service portscript
{
socket_type = stream
protocol = tcp
port = 33000
type = UNLISTED
wait = no
user = root
server = /home/pi/portscript/script.sh
#server_args = Hallo Welts!
}
pi@raspberrypi /etc/xinetd.d $
~Arano
Ich probiere gerade mein Script unter "pi" laufen zu lassen aber schainbar ist mein internetradiostream gerade... "lautlos" *fg* Verbunden wird zwar und es wird wiedergegeben... aber ich höre nichts !? Naja, mal schaun.
Hi,
Den schließlich bekommst du FEHLERmeldungen...
Die Variable $LOG ist nicht definiert, deswegen gibt es kein Umleitungsziel und das erzeugt den Fehler. $LOG sollte den Pfad und Dateinamen der gewünschten Logdatei enthalten.
"err" ist eine Funktion die ich in meinem Script erstellt habe. Sie bekommt drei Parameter und ist dann für ein gewisses Maß an Logging, Fehlerbehandung und Rückgabewert (für meine App) verantwortlich.
Ich sag doch, fange klein an !
~Arano
Stimmt etwas mit meiner portscript.sh nicht?
Na sicher stimmt damit etwas nicht !Den schließlich bekommst du FEHLERmeldungen...
/home/raspi/portscript.sh: Zeile 5: $LOG Mehrdeutige Umlenkung
echo "Read: $command" >>$LOG
/home/raspi/portscript.sh: Zeile 32: err: Kommando nicht gefunden.
err "001" "Server kennt Kommando \"$command\" nicht" "1"
Ich sag doch, fange klein an !
~Arano
Hallo
Ach her je... wo soll ich da nur anfangen ...will ich das überhaupt !?
Ich kann es nur wiederholen: Fange klein an und schau was passiert !
Das die Hälfte nicht funktioniert ist bei dem Script kein Wunder !
Ich weis schon warum nicht
Was meinst du warum ich die ganze Zeit davon spreche klein anzufangen und Schritt für Schritt vorzugehen, mit dem Hinweis sich Dinge anzeigen zu lassen !? Dan hättest du zumindes gesehen, das in der Variable die komplette GET-Zeile steht.
Mit dem Zusatz von
Darum Funktionieren nur die Abschnitte in dem zweitem CASE weil hier die Variable "$2" (die den Pfad bzw. den Befehl beinhaltet) ausgewertet wird. Darum funktionieren auch nur die Abschnitte /3 und /4.
s. Step 2 aus dem Link
Und ja richtig, in meinem Script taucht dieser Part nicht auf. Aber ich sagte ja auch bereits, das ich das anders handhabe. Denn ich verarbeite nicht den HTTP-Request, ich habe mir meinen eigenen Request konstruiert um mehrere Informateionen übertragen zu können da ich das mit meiner App triggere (Die Webversion war nur der Anfang)
Naja, wie auch immer, da das Script noch so enige Macken hat fält es mir schwer zu glauben das es so "korrekt" funktioniert...
Ich vermute mal, das du nur die Fehler nicht siehst und deswegen glaubst alles sei in Ordnung. (Nun, das geht aber wohl jedem Anfänger so - Mann will ein Ergebniss, alles andere ist egal )
Ich habe noch ein Backup meiner Webversion gefunden:
(Funktioniert auch mit dem Smartphone Standardbrowser einwandfrei)
Ach her je... wo soll ich da nur anfangen ...will ich das überhaupt !?
Ich kann es nur wiederholen: Fange klein an und schau was passiert !
Das die Hälfte nicht funktioniert ist bei dem Script kein Wunder !
da Datum und Kommando in verschiedene Zeilen geschrieben werden
Jup, du hast es ja auch so geschrieben. Mit zwei separaten Kommandos.echo "`date` Kommando: $command" >> $LOG
Also localhost:45000/1 triggert in diesem Fall tatsächlich /1). So weit, so gut. /1), /2) und /4) funktionieren allerdings nicht.
Hä ? Wird "/1" nun getriggert oder nicht !?Ich weis schon warum nicht
Grundsätzlich funktioniert nun also das Triggern per Webinterface.
Wie jetzt, eben hast du doch gesagt das 75% NICHT funktionieren !?Wenn ich diese (extra Script) über das Terminal ausführe, funktioniert sie.
Ja klar, aber dann läuft es auch in deiner User-Umgebung. Wenn es unter xinetd läuft ist es eine andere Umgebung bzw. wohl die vom User root. Es wird also von ganz anderen Standpunkten ausgegangen. Wenn nicht sogar die Login-Session eine weitere Rolle dabei spielt !?Im Browser erscheint nach dem Bruchteil einer Sekunde immer wieder
Fehler: Verbindung unterbrochen
Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.
Jup... dazu hatte ich auch schon erwähnt, das eine Browser einen vollständingen HTTP-Request sendet ! Bei mir sind es insgesamt ACHT ZEILEN und die wollen ausgelesen werden.Fehler: Verbindung unterbrochen
Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.
GET /kommando HTTP/1.1
Host: localhost:33000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
<-- eine leerzeile !!!
Aus irgend einem für mich nicht nachvollziehbaren Grund funktionieren in diesem Script erst Befehle _nach_ "case $2 in". Würde ich den Inhalt von /3) in /1) oder /2) kopieren und aufrufen, würde gar nichts passieren.
Für mich ganz verständlich und sorry, aber ich muss wieder auf die erste GET-Zeile verweisen.Mit dem Zusatz von
set -- $command
wird (um es einfach zu halten) der Inhalt von $command anhand der Leerzeichen getrennt und auf $1,$2,$3,$... -$9 aufgeteilt.Darum Funktionieren nur die Abschnitte in dem zweitem CASE weil hier die Variable "$2" (die den Pfad bzw. den Befehl beinhaltet) ausgewertet wird. Darum funktionieren auch nur die Abschnitte /3 und /4.
GET /kommando HTTP/1.1
$1 $2 $3
Was mich noch stört, ist die Ausgabe auf dem Webinterface bzw. die Weiterleitung. Unter Android versucht Chrome, die Seite wieder und wieder zu laden, was zu mehrfachem Triggern der Befehle führt. Dies passiert auf dem Rechner nicht, aber kurze Fehlermeldung, dann Seitenladefehler finde ich trotzdem nicht so toll gelöst.
Nun, du verwendest ja auch einen Browser der für HTTP-Request geschaffen wurde. Wenn man den zweckentfremden möchte, muss man sich halt an seine Regeln halten.s. Step 2 aus dem Link
Und ja richtig, in meinem Script taucht dieser Part nicht auf. Aber ich sagte ja auch bereits, das ich das anders handhabe. Denn ich verarbeite nicht den HTTP-Request, ich habe mir meinen eigenen Request konstruiert um mehrere Informateionen übertragen zu können da ich das mit meiner App triggere (Die Webversion war nur der Anfang)
Edit: Problem gelöst. Die commands werden nun per tcp über ein php-Script direkt an den Port weitergeleitet und werden korrekt ausgeführt.
Öhm... das verstehe ich nicht !?Naja, wie auch immer, da das Script noch so enige Macken hat fält es mir schwer zu glauben das es so "korrekt" funktioniert...
Ich vermute mal, das du nur die Fehler nicht siehst und deswegen glaubst alles sei in Ordnung. (Nun, das geht aber wohl jedem Anfänger so - Mann will ein Ergebniss, alles andere ist egal )
Ich habe noch ein Backup meiner Webversion gefunden:
(Funktioniert auch mit dem Smartphone Standardbrowser einwandfrei)
#!/bin/bash
##
## Browser sendet vollständigen Request:
##
#
# > GET /kommando HTTP/1.1
# > Host: localhost:31313
# > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
# > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
# > Accept-Language: de-de,en-us;q=0.7,en;q=0.3
# > Accept-Encoding: gzip, deflate
# > Connection: keep-alive
# > <-- eine leerzeile !!!
#
# lese die erste Headerzeile des Browserrequests
read request
# $request = "GET /kommando HTTP/1.1"
# lese die restlichen Headerzeilen aus der Eingabe
while /bin/true; do
read header
# wenn Leerzeile erreicht sind alle Header ausgelesen
[ "$header" == $'\r' ] && break;
done
# extrahiere den Pfad aus dem Request
command="${request#GET /}" # "kommando HTTP/1.1"
command="${command% HTTP*}" # "kommando"
# führe aktion je nach Anfrage durch
case $command in
a)
echo "aaaa"
;;
b)
echo "bbbb"
;;
1)
echo "1111"
;;
2)
echo "2222"
;;
3)
echo "3333"
;;
4)
echo "4444"
;;
*)
echo "default
Das Triggern erfolgt durch einen Browserrequest:
http://localhost:33000/KOMMANDO
Es gibt die folgenden KoMmandos:
a = http://localhost:33000/a
b = http://localhost:33000/b
1 = http://localhost:33000/1
2 = http://localhost:33000/2
3 = http://localhost:33000/3
4 = http://localhost:33000/4
Jedes andere Kommando zeigt diese default-Ausgabe."
;;
esac
# ENDE
exit 0
Nabend
Nach dem erfolgreichen SSH-Login befindest du dich auf der remote-box. Das Scriopt wird aber local ausgeführt: Schritt für Schritt. Das heist das dein locales Script erst auf die beendigung des letzten Befehls (SSH) wartet bevor es mit dem Nächstem weiter macht. Mit anderen Worten die SSH Verbindung muss erst beendet werden damit das Script weiterläuft.
Um es gerade mal auf den Punkt zu bringen, du verwendest die ganze Zeit ein fehlerhaftes SSH-Kommando (s. man ssh)
Funktionieren könnte:
Übergebe SSH das was du remote ausführen willst als einen Parameter.
~Arano
Ich habe den Fehler jetzt mehrmals gegoogelt, aber nichts gefunden, was mir weiterhilft. Da steht "wanted `ENDSSH'" statt 'ENDSSH', aber jede andere Schreibweise gibt den gleichen Fehler aus.
Mit der HereDoc-Notation bei SSH kenne ich nicht aus, das habe ich noch nie verwendet.Dann lädt und lädt und lädt die Seite, nichts passiert.
Jup, das kann ich erklären.Nach dem erfolgreichen SSH-Login befindest du dich auf der remote-box. Das Scriopt wird aber local ausgeführt: Schritt für Schritt. Das heist das dein locales Script erst auf die beendigung des letzten Befehls (SSH) wartet bevor es mit dem Nächstem weiter macht. Mit anderen Worten die SSH Verbindung muss erst beendet werden damit das Script weiterläuft.
Um es gerade mal auf den Punkt zu bringen, du verwendest die ganze Zeit ein fehlerhaftes SSH-Kommando (s. man ssh)
Funktionieren könnte:
ssh user@ip 'osascript ~/scripts/runme.scpt'
~Arano