Mein Webhoster bietet mir keinen Shell-Zugang. Ich kann zwar mühselig mit einer PHP-Shell arbeiten, aber PHP wird unter dem Account des Webservers ausgeführt. Also jede Datei die neu angelegt wird gehört dem Webserver-Benutzer und nicht mir. Daher kann ich sie über FTP auch nicht löschen, sondern wieder nur über PHP. Alles nicht so der Hammer...
Daher habe ich mir eine simple Python-Shell gebastelt. Auf dem Webserver muss sie als XML-RPC-Server gestartet werden. Daheim möchte ich mich dann als Client verbinden. Ich schicke lediglich Befehle rüber und der Server schickt mir die Ausgabe zurück.
Damit das alles noch unter meinem Account läuft, kann ich Python-Programme als Cronjob starten. Der XML-RPC-Server soll also auf dem Webserver per Cronjob angeworfen werden. Soweit so gut.
Für die Kommunikation brauche ich einen Port. Wie kriege ich raus, welchen Port ich dafür benutzen kann. Es gibt ja Portscanner (hab hier auch schon einige in Python geschriebene gefunden).
Außerdem: Ich brauche ja auch noch einen Host. Nun kenne ich zwar meine Web-Adresse und auch die IP des Servers, aber ist das dann auch gleichzeitig mein Host?
Python-Shell und Portscan beim Webhoster
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Warum das ganze so aufwendig? Eine Shell bekommst du schon schon als einfaches CGI hin. Ohne XML-RPC und cronjobs...
Ich hab sowas mal als Plugin für PyLucid geschrieben, sollte sich relativ einfach auch als einfaches CGI umformen lassen: http://pylucid.net/trac/browser/PyLucid ... vilEval.py
Ich hab sowas mal als Plugin für PyLucid geschrieben, sollte sich relativ einfach auch als einfaches CGI umformen lassen: http://pylucid.net/trac/browser/PyLucid ... vilEval.py
Hmmm. Deine Python-App produziert HTML-Code... ich möchte aber lieber eine schwarze Konsole As simple as possible.
Der Umweg über Cronjobs muss nur deshalb sein, weil alles was über den Webserver läuft unter dem Webserver-Account gestartet wird. Bei PHP weiß ich es ganz sicher. Die Hoster setzen kein suPHP oder PHP über FastCGI ein, wo die Skripte über meinen Account gehen. Ein Cronjob wird aber unter meinem Account gestartet. Ich muss den XML-RPC-Server ja nur einmal anschubsen.
Mit CGI kenne ich mich Null aus (ja, es ist eine Schnittstelle). Mit Python schon eher... Was mich reizt ist dass ich auf der Serverseite kein CGI voraussetzen muss, sondern nur Python. Das funzt auf einem PC ohne Webserver ebenso wie auf einem (Symbian)-Handy oder Windows CE PDA. Daher hätte ich gern einen SimpleXMLRPCServer.
Der Umweg über Cronjobs muss nur deshalb sein, weil alles was über den Webserver läuft unter dem Webserver-Account gestartet wird. Bei PHP weiß ich es ganz sicher. Die Hoster setzen kein suPHP oder PHP über FastCGI ein, wo die Skripte über meinen Account gehen. Ein Cronjob wird aber unter meinem Account gestartet. Ich muss den XML-RPC-Server ja nur einmal anschubsen.
Mit CGI kenne ich mich Null aus (ja, es ist eine Schnittstelle). Mit Python schon eher... Was mich reizt ist dass ich auf der Serverseite kein CGI voraussetzen muss, sondern nur Python. Das funzt auf einem PC ohne Webserver ebenso wie auf einem (Symbian)-Handy oder Windows CE PDA. Daher hätte ich gern einen SimpleXMLRPCServer.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ich denke es geht darum, das du bei deinem WebHoster dir einen "Zugang" baust?
IMHO musst du dann immer damit leben, das dein Skript mit User/Gruppe des WebServers ausgeführt wird.
Wenn der WebServer richtig eingerichtet bzw. abgesichert ist, solltest du eigentlich auch nicht so einfach einen Dienst auf einem Port öffnen können.
IMHO musst du dann immer damit leben, das dein Skript mit User/Gruppe des WebServers ausgeführt wird.
Wenn der WebServer richtig eingerichtet bzw. abgesichert ist, solltest du eigentlich auch nicht so einfach einen Dienst auf einem Port öffnen können.
Ich glaube kaum, dass die Gateway-Firewall des Anbieters für deinen Server irgendeinen obskuren Port durchlassen wird. Zudem könntest du ein ganz kleines bisschen Ärger mit dem Anbieter bekommen. Tunnel nach außen graben ist im Vertrag wohl kaum erlauben und ergo ein Kündigungsgrund.
Wenn du Shellzugang willst, dann solltest du erwähnte Webvariante verwenden oder lieber gleich zu einem vernünftigen Anbieter wechseln.
Webserver sind halt Webserver und keine Rootserver Deswegen gibts auch nur Web und keine Shell...
Edit: Wenn du's trotzdem probieren willst, Ports > 1000 sollten eigentlich offen sein. Du könntest drei zufällige Ports zwischen 1000 und 10000 definieren. Der erste ist Standard, die zwei anderen dienen als Fallback für den Fall, dass ein Port bereits belegt ist. Dein Client versucht dann, sich nacheinander mit allen drei Ports zu verbinden. Kommt von einem Port was sinnvolles zurück, dann passts, wenn nicht, dann läuft der Server höchstwahrscheinlich auch nicht und die Anwendung hat eventuell nur mit einem anderen Server gesprochen ...
Wenn du Shellzugang willst, dann solltest du erwähnte Webvariante verwenden oder lieber gleich zu einem vernünftigen Anbieter wechseln.
Webserver sind halt Webserver und keine Rootserver Deswegen gibts auch nur Web und keine Shell...
Edit: Wenn du's trotzdem probieren willst, Ports > 1000 sollten eigentlich offen sein. Du könntest drei zufällige Ports zwischen 1000 und 10000 definieren. Der erste ist Standard, die zwei anderen dienen als Fallback für den Fall, dass ein Port bereits belegt ist. Dein Client versucht dann, sich nacheinander mit allen drei Ports zu verbinden. Kommt von einem Port was sinnvolles zurück, dann passts, wenn nicht, dann läuft der Server höchstwahrscheinlich auch nicht und die Anwendung hat eventuell nur mit einem anderen Server gesprochen ...
Zuletzt geändert von lunar am Donnerstag 15. Februar 2007, 20:46, insgesamt 3-mal geändert.
Jepp, das trifft es: ich "baue" mir einen Zugang. Da ich Cronjobs habe, kann ich prinzipiell alles tun, wozu ich berechtigt bin. Also schreibe ich mir momentan immer Python-Skripte mit `os.system()`-Befehlen, um z.B. Tar-Archive auszupacken. Würde ich das über die PHP-Shell machen, startet der tar-Prozess unter dem Webserver-Account. Alle entpackten Dateien gehören dann nicht mehr mir -> Löschen und Bearbeiten geht dann nur noch über die PHP-Shell und nicht über FTP.
Es ist ein Workaround der gut funktioniert, aber nervt. Ich muss z.B. immer sowas hier machen:
Der Cronjob wiederholt sich jede Minute, damit ich einfach nur die zugehörige Python-Datei ändern muss. Also muss ich auch checken, ob eine Aktion nicht schonmal durhcgeführt wurde... extreeem nervig.
Daher möchte ich wenigstens probieren, ein Python-Skript als Server zu starten. Mir fehlen allerdings ein paar Vorkenntnisse -> hat jemand nen Vorschlag welche Ports so üblicherweise offen sind oder wie ich das rauskriegen kann?
Es ist ein Workaround der gut funktioniert, aber nervt. Ich muss z.B. immer sowas hier machen:
Code: Alles auswählen
#!/usr/bin/python
import os
os.chdir("/srv/www/htdocs/web123/html")
if not os.path.exists("foo"):
os.system("tar xfvz foo.tar.gz")
Daher möchte ich wenigstens probieren, ein Python-Skript als Server zu starten. Mir fehlen allerdings ein paar Vorkenntnisse -> hat jemand nen Vorschlag welche Ports so üblicherweise offen sind oder wie ich das rauskriegen kann?
Nix für ungut, aber aus eigener Erfahrung kann ich nur sagen, dass es sich wirklich lohnt, einen vernünftigen Shell-Zugang zu haben. Mein Tipp: Wechsel auf ein umfassenderes Angebot, und wenn es ein Root-Server ist.
- nkoehring
- User
- Beiträge: 543
- Registriert: Mittwoch 7. Februar 2007, 17:37
- Wohnort: naehe Halle/Saale
- Kontaktdaten:
das mit den offenen ports ist kein großes ding.
du koenntest einfach netcat im servermodus starten und schauen ob du connecten kannst... und damit hast du dann auch ne moeglichkeit fuer eine konsole (falls netcat mit der option GAPING_SECURITY_HOLE compiliert wurde). ansonsten kannst du aber wenigstens die ports durchprobieren.
geht natuerlich auch mit python... schau dir einfach mal das "socket"-modul an.
ich geh jetzt schlafen... gut nacht
du koenntest einfach netcat im servermodus starten und schauen ob du connecten kannst... und damit hast du dann auch ne moeglichkeit fuer eine konsole (falls netcat mit der option GAPING_SECURITY_HOLE compiliert wurde). ansonsten kannst du aber wenigstens die ports durchprobieren.
geht natuerlich auch mit python... schau dir einfach mal das "socket"-modul an.
ich geh jetzt schlafen... gut nacht
[url=http://www.python-forum.de/post-86552.html]~ Wahnsinn ist auch nur eine andere Form der Intelligenz ~[/url]
hackerkey://v4sw6CYUShw5pr7Uck3ma3/4u7LNw2/3TXGm5l6+GSOarch/i2e6+t2b9GOen7g5RAPa2XsMr2
hackerkey://v4sw6CYUShw5pr7Uck3ma3/4u7LNw2/3TXGm5l6+GSOarch/i2e6+t2b9GOen7g5RAPa2XsMr2
Einen Root-Server will ich nicht pflegen, wenn dann schon eher ein Dedicated Root Server... Ansonsten habe ich lange nach einem passenden Hoster gesucht und bin recht zufrieden, außer:Y0Gi hat geschrieben:Nix für ungut, aber aus eigener Erfahrung kann ich nur sagen, dass es sich wirklich lohnt, einen vernünftigen Shell-Zugang zu haben. Mein Tipp: Wechsel auf ein umfassenderes Angebot, und wenn es ein Root-Server ist.
1) kein suPHP (hat aber keiner in der Preisklasse)
2) keine Shell (haben auch nur die wenigsten)
Dafür unterstützt mein Hoster Symlinks. Das ist mir sehr wichtig. Bei vielen anderen Anbietern (die dann z.B. eine Shell haben) sind Symlinks verboten. Wäre suPHP vorhanden, dann könnte ich auch mit einer PHP-Shell leben.
Zum `socket`-Modul. Ich hab schonmal eine Server-/Client-Software mit Python und dem `socket`-Modul gebaut, fand es jedoch wesentlich umständlicher als einen SimpleXMLRPCServer aufzusetzen.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Du meinst wohl Managed? Na, die sind dann "etwas" teurer.droptix hat geschrieben:Einen Root-Server will ich nicht pflegen, wenn dann schon eher ein Dedicated Root Server...
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ja da hast du wohl recht... verirrt im Webserver-WirrwarrLeonidas hat geschrieben:Du meinst wohl Managed?
Preis spielt halt auch eine Rolle. Daher "nur" ein normales Webhosting-Paket ohne Root- oder Managed Server.
Es gibt auch VServer ab 5,- EUR, aber billig ist echt nicht immer gleich gut. 10,- EUR/Monat reize ich nicht aus, weil mir da auch zuviel dabei ist. Ich bin derzeit bei 2,50 EUR
Wir driften hier aber vom Thema ab. Nicht dass es jetzt Preisempfehlungen hagelt...
1) ich möchte/kann meinen Anbieter nicht zu einem angemessenen Preis wechseln
2) ich hab außer bei Cronjobs keine Möglichkeit, Befehle unter meinem Benutzeraccount auszuführen
3) ich hab keinen Shell-Zugang, aber ich hätte gern einen
Die Frage ist löst eine Python-Shell dieses Problem und ist das legal?
Wir driften hier aber vom Thema ab. Nicht dass es jetzt Preisempfehlungen hagelt...
1) ich möchte/kann meinen Anbieter nicht zu einem angemessenen Preis wechseln
2) ich hab außer bei Cronjobs keine Möglichkeit, Befehle unter meinem Benutzeraccount auszuführen
3) ich hab keinen Shell-Zugang, aber ich hätte gern einen
Die Frage ist löst eine Python-Shell dieses Problem und ist das legal?
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Genau aus dem Grunde habe ich die Seite [wiki]Python Webspace[/wiki]gemacht.
Ich bin z.Z. bei GPcom. Dort habe ich zwar einen shell Account, kann damit aber recht wenig machen. Der Server ist generell sehr konservativ Konfiguriert. Also an allen Ecken und Enden wird man eingeschränkt.
@droptix: Du sagst, das PHP mit den Webserver-Account läuft. Und Python??? Python CGI Skripte sollten eigentlich auch mit den Rechten der Webservers laufen.
Warum schaufelst du die Archiv Datei nicht direkt per Upload hoch? Ein Skript auf dem Server könnte es theoretisch entpacken und per FTP speichern. Ist zwar auch sehr umständlich, aber dann hast du keine Probleme mit den Dateirechten.
Ich bin z.Z. bei GPcom. Dort habe ich zwar einen shell Account, kann damit aber recht wenig machen. Der Server ist generell sehr konservativ Konfiguriert. Also an allen Ecken und Enden wird man eingeschränkt.
@droptix: Du sagst, das PHP mit den Webserver-Account läuft. Und Python??? Python CGI Skripte sollten eigentlich auch mit den Rechten der Webservers laufen.
Warum schaufelst du die Archiv Datei nicht direkt per Upload hoch? Ein Skript auf dem Server könnte es theoretisch entpacken und per FTP speichern. Ist zwar auch sehr umständlich, aber dann hast du keine Probleme mit den Dateirechten.
Python verarbeitet der Webserver nicht, also kann keine Python-Skripte als URL aufrufen. Aber ein Cronjob startet Befehle auf dem Betriebssystem (nicht dem Webserver). Cronjobs kann ich jede Minute starten. Daher habe ich eine Datei "cronjob.py" in meinem Speicher liegen, die jede Minute aufgerufen wird. Wenn ich die nun jede Minute bearbeite und einen neuen Befehl reinschreibe, habe ich eine 1-Minute-Shell Also rein technisch kann ich alles machen, nur eben seeehr langsam und aufwändig.jens hat geschrieben:Du sagst, das PHP mit den Webserver-Account läuft. Und Python??? Python CGI Skripte sollten eigentlich auch mit den Rechten der Webservers laufen.
Mach ich ja: ich schaufel beispielsweise das tar.gz-Archiv hoch und starte dann als Cronjob den tar-Befehl zum entpacken. Anschließend lösche ich das tar.gz-Archiv und leere den Cronjob.jens hat geschrieben:Warum schaufelst du die Archiv Datei nicht direkt per Upload hoch? Ein Skript auf dem Server könnte es theoretisch entpacken und per FTP speichern. Ist zwar auch sehr umständlich, aber dann hast du keine Probleme mit den Dateirechten.
Was wie bereits gesagt für mich keinen Sinn macht.
1) Hab ich bei preislich vergleichbaren Anbietern keine Symlinks.
2) Nützt mir Python über CGI auch nichts, wenn die Skripte nicht unter meinem Account ausgeführt werden.
1) Hab ich bei preislich vergleichbaren Anbietern keine Symlinks.
2) Nützt mir Python über CGI auch nichts, wenn die Skripte nicht unter meinem Account ausgeführt werden.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Shell, Symlinks und fastCGI habe ich bei GPcom schon. Allerdings hast du recht, die Skripte werden mit den Rechten vom WebServer ausgeführt. Das ist IMHO bei allen Shared-Webhostern leider so
Ansonsten wäre das PyHosting Projekt was für sich: ##pyhosting @ irc.freenode.net Aber eigentlich ist der Server dort dicht.
Ansonsten wäre das PyHosting Projekt was für sich: ##pyhosting @ irc.freenode.net Aber eigentlich ist der Server dort dicht.
Tja für CGI gibt's ja mod_suexec, um die unter Benutzerrechten auszuführen. Speziell für PHP gibt's suPHP.
Leider benutzt das kaum ein Webhoster. Zumindest kenne ich keinen. Die Webserver sollen angeblich ein wenig an Performance einbüßen, wenn man diese sinnvollen Möglichkeiten einsetzen würde.
Leider benutzt das kaum ein Webhoster. Zumindest kenne ich keinen. Die Webserver sollen angeblich ein wenig an Performance einbüßen, wenn man diese sinnvollen Möglichkeiten einsetzen würde.