Das deutsche Python-Forum

Hab in "/etc/inetd.conf" folgendes eingetragen: und in "/etc/services" das: Der Server läuft anscheinend auch, wenn ich auf Port 9000 eine Anfrage stelle, allerdings funktioniert es nicht wirklich... Es kommen merkwürdige Fehlermeldungen an...

Kann man es garnicht so einfach zusammen basteln?

Ich hab leider nicht sehr viel Ahnung und wenig Informationen zu inetd gefunden...

Ja wahnsinn, ich bin an genau dem gleichen dran: Python Server mit inetd. DU musst aufpassen, du darfst dort keine sockets nutzten nur stdin und stdout, siehe mein Prog. Das geht.

Achso, dann ist inetd also quasi schon ein HTTP Server und ich dachte er statet nur einen entsprechenden Server, wenn auf Port xy eine Anfrage gestellt wurde...

Wie sieht es dann mit CGI Geschichten aus?

Nein, der inetd ist kein HTTP Server. Der inetd überwacht nur die in der /etc/services.conf angegebenen posts und wenn dort ein Request ist, startet er das in der /etc/inetd.conf aufgeführte Programm. Dabei erstellt er selbst ein Socket, so dass alles was bei stdout raus geht zum Client geschickt wird, und alles was in stdin reingeht zu deinem Programm geschickt wird. In inetxmlrpc.py habe ich das so gelöst, dass ich erstmal den HTTP Header einlese, den mir der Client schickt, dann Content-Length auswerte, und danach so weit eben lese. Also das Müsste dann der Content sein. Diesen Content, der als POST reinkommt, lasse ich von der xmlrpclib parsen, rufe die Funktionen auf und lasse der Ergebnis von der xmlrpclib erstellen, bevor ich es dann einfach ohne weiteres an den Client schicke. Das ist zwar nicht wirklich ein vollwertiger XML-RPC Server, denn er kann nicht wirklich HTTP, aber das reicht mir schon.

Hmmm... d.h. ich müßte mich selber um die HTTP Header kümmern... d.H. also von Browser die Headerinformation vom Request auswerten und für mein CGI Programm zusammenstellen...

Gibt es einen einfacheren Weg quasi die Funktionalität und Einfachheit eines CGIHTTPServer mit inetd zu paaren?
Kann man irgendwie den Socket übergeben, oder so?

Anonymous hat geschrieben:Gibt es einen einfacheren Weg quasi die Funktionalität und Einfachheit eines CGIHTTPServer mit inetd zu paaren?
Kann man irgendwie den Socket übergeben, oder so?

Nein, ich ahbe bis jetzt keine Möglichkeit gefunden, ich habe überlegt im BaseServer self.socket durch ein durch fromfd generiertes socket aus dem stdin zu machen, aber das wollte nicht

Wahrscheinlich ist es auch so gut wie unmöglich das ganze mit TLSlite zu koppeln um HTTPs zu erhalten, was?

jens hat geschrieben:Wahrscheinlich ist es auch so gut wie unmöglich das ganze mit TLSlite zu koppeln um HTTPs zu erhalten, was?

Ich nehme mal an dass es möglich wäre, aber einfach ist das auf jeden Fall nicht. inetd ist vom konzept her imho Schrott, zumindest für Programme die mit Sockets umgehen.

Eine möglichkeit ist es vielleicht, inetd nur dazu zu nutzen, der Server zu starten... Das dürfte aber zumindest nicht so ohne weiteres auf dem selben Port geschehen, denn den reserviert ja schon inetd...

Ab wann schließt inetd denn den Socket? Kann man evtl. ganz doof, im Server-Start Skript ein time.sleep() einbauen?

jens hat geschrieben:Ab wann schließt inetd denn den Socket? Kann man evtl. ganz doof, im Server-Start Skript ein time.sleep() einbauen?

Ich dneke der inetd schließt den Socket, nachdem das Programm das aufgerufen wird ein EOF schickt, bin mir aber nicht sicher.

Hm! Dann könnte es ja vielleicht so ablaufen, das dem Brower erstmal eine Minimale-HTML-Datei geschickt wird, mit einem http-equiv="refresh"... Danach wird dem inetd ein EOF gesendet und der eigentliche Python CGI-Server gestartet, der dann auf dem gleichen Port läuft...

Man kann bei inetd auch noch einen stream-typ bestimmen... u.a. gibt es raw Ob dann kein socket benutzt wird?

jens hat geschrieben:Man kann bei inetd auch noch einen stream-typ bestimmen... u.a. gibt es raw Ob dann kein socket benutzt wird?

The socket-type should be one of ``stream'', ``dgram'', ``raw'', ``rdm'', or ``seqpacket'', depending on whether the socket is a stream, datagram, raw, reliably delivered message, or sequenced packet socket.

-vs-

SOCK_STREAM
SOCK_DGRAM
SOCK_RAW
SOCK_RDM
SOCK_SEQPACKET
These constants represent the socket types, used for the second argument to socket(). (Only SOCK_STREAM and SOCK_DGRAM appear to be generally useful.)

Also ist raw nur eine Unterart der Sockettypen.

Schade
Dann bleibt noch die umständliche Browser-Refresh Variante...

jens hat geschrieben:Dann bleibt noch die umständliche Browser-Refresh Variante...

Wie wäre es, wenn du inetd gar nicht benutzt? Dann hättest du das Ding vom Hals.

So kann man Probleme auch Lösen

(Bisher starte ich meinen Python-Server immer per Hand mit Putty...)

jens hat geschrieben:(Bisher starte ich meinen Python-Server immer per Hand mit Putty...)

Bau dir doch ein hübsches init Script auf Grundlage der /etc/init.d/skeleton und wunderbar is.

Das ist definitiv eine Lösung, so läuft ja auch mein Apache-Test-Server... Mir gefällt allerdings an der inetd Variante, das der Server nur dann läuft, wenn er gebraucht wird!

jens hat geschrieben:Mir gefällt allerdings an der inetd Variante, das der Server nur dann läuft, wenn er gebraucht wird!

Kann ich gut verstehen, deswegen habe ich ja auch meinen XMLRPC brutal in stdio eingebettet, wie man an dem seltsamen Quellcode sieht

Anscheinent kann man Apache auch für inetd konfigurieren, wenn man "ServerType inetd" in die httpd.conf setzt... Ich weiß nur nicht genau, ob es nur mit der 1.3er geht, oder auch mit der 2er Version...

Hab hier noch was gefunden:
http://www.amk.ca/python/simple/identd.py.html

EDIT: Zum Problem siehe auch http://python.sandtner.org/viewtopic.php?t=2990