Guten Tag,

in einer Mail erhalten Benutzer von mir einen Link in etwa der
folgenden Art:

http://testserver.example.com:8001/index.php?code=4711

Um einen solchen URL auszuwerten, moechte ich keinen kompletten
HTTP-Server installieren, sondern lediglich per [x]inetd am Port
8001 lauschen und den uebergebenen Code mit einem PHP-Skript
auswerten, um eine bestimmte Aktion zu veranlassen.

Der angegebene URL ist nicht zwingend vorgegeben, es soll durch
Benutzer lediglich an einem Port eine bestimmte Kennung abgekippt
werden, die von einem Skript validiert und weiterverwertet wird.

PHP ist deshalb meine Wunschsprache, weil ich da am besten mit
zurechtkomme.

Welche Literatur fuehrt mich auf den richtigen Weg?

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!

Peter Blancke wrote:

Hallo,

> Um einen solchen URL auszuwerten, moechte ich keinen kompletten
> HTTP-Server installieren, sondern lediglich per [x]inetd am Port
> 8001 lauschen und den uebergebenen Code mit einem PHP-Skript
> auswerten, um eine bestimmte Aktion zu veranlassen.

Gestartet von inetd sollte das lesen/schreiben über stdin und
stdout ausreichen:

Creating a Gopher server with PHP and InetD
http://www.rooftopsolutions.nl/article/100

#!/usr/bin/php
<?php
$data =3D fgets(STDIN);
echo('You said: ' . $data);
?>


tschuess
[|8:)

Ad 2007-11-14, Sven Drieling <sd [at] sven-drieling.de> dixit:
> Peter Blancke wrote:

>> Um einen solchen URL auszuwerten, moechte ich keinen kompletten
>> HTTP-Server installieren, sondern lediglich per [x]inetd am Port
>> 8001 lauschen und den uebergebenen Code mit einem PHP-Skript
>> auswerten, um eine bestimmte Aktion zu veranlassen.

> Gestartet von inetd sollte das lesen/schreiben über stdin und
> stdout ausreichen:
>
> #!/usr/bin/php
> <?php
> $data = fgets(STDIN);
> echo('You said: ' . $data);
> ?>

Danke. Dieses kurze Skript ueber xinetd eingebunden ist schon die
Loesung. Ein Aufruf von

http://localhost:8000/the_quick_brown_fox

bringt als Antwort:

You said: GET /the_quick_brown_fox HTTP/1.1

Das auszuwerten ist keine Schwierigkeit, eine Rueckantwort mit
korrekten HTTP-Headern zu senden natuerlich auch nicht.

Allenfalls musz ich ueberlegen, was da an Sicherheitsproblematik
drohen kann. Ueberlange Zeichenketten vielleicht.

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!

Peter Blancke schrieb:
> Ad 2007-11-14, Sven Drieling <sd [at] sven-drieling.de> dixit:
>> Peter Blancke wrote:
>
>>> Um einen solchen URL auszuwerten, moechte ich keinen kompletten
>>> HTTP-Server installieren, sondern lediglich per [x]inetd am Port
>>> 8001 lauschen und den uebergebenen Code mit einem PHP-Skript
>>> auswerten, um eine bestimmte Aktion zu veranlassen.
>
>> Gestartet von inetd sollte das lesen/schreiben über stdin und
>> stdout ausreichen:
>>
>> #!/usr/bin/php
>> <?php
>> $data =3D fgets(STDIN);
>> echo('You said: ' . $data);
>> ?>
>
> Danke. Dieses kurze Skript ueber xinetd eingebunden ist schon die
> Loesung. Ein Aufruf von
>
> http://localhost:8000/the_quick_brown_fox
>
> bringt als Antwort:
>
> You said: GET /the_quick_brown_fox HTTP/1.1
>
> Das auszuwerten ist keine Schwierigkeit, eine Rueckantwort mit
> korrekten HTTP-Headern zu senden natuerlich auch nicht.
>
> Allenfalls musz ich ueberlegen, was da an Sicherheitsproblematik
> drohen kann. Ueberlange Zeichenketten vielleicht.

Evtl. magst du noch in Richtung RPC bzw. XMLRPC gucken. Dafuer gibts
auch was in PEAR bzw. was auf SF.net.

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Peter Blancke wrote:

> Ad 2007-11-14, Sven Drieling <sd [at] sven-drieling.de> dixit:
>> Peter Blancke wrote:
>
>>> Um einen solchen URL auszuwerten, moechte ich keinen kompletten
>>> HTTP-Server installieren, sondern lediglich per [x]inetd am Port
>>> 8001 lauschen und den uebergebenen Code mit einem PHP-Skript
>>> auswerten, um eine bestimmte Aktion zu veranlassen.
>
>> Gestartet von inetd sollte das lesen/schreiben über stdin und
>> stdout ausreichen:
>>
>> #!/usr/bin/php
>> <?php
>> $data = fgets(STDIN);
>> echo('You said: ' . $data);
>> ?>
>
> Danke. Dieses kurze Skript ueber xinetd eingebunden ist schon die
> Loesung. Ein Aufruf von
>
> http://localhost:8000/the_quick_brown_fox
>
> bringt als Antwort:
>
> You said: GET /the_quick_brown_fox HTTP/1.1
>
> Das auszuwerten ist keine Schwierigkeit, eine Rueckantwort mit
> korrekten HTTP-Headern zu senden natuerlich auch nicht.
> Allenfalls musz ich ueberlegen, was da an Sicherheitsproblematik
> drohen kann. Ueberlange Zeichenketten vielleicht.

Hallo,
nur als kleine Warnung: im Prinzip ist das alles machbar, nur stelle ich die
vorsichtige Frage, ob das wirklich der richtige Weg ist. Das sieht sehr
nach einem Anfang aus, der schon hunderte Mal von tausenden von Leuten
beschritten wurde:
- schlank, einfach, "nur für diesen Anwendungsfall", ...
- und dann kommen im Laufe der Zeit hier eine Erweiterung, dort eine
Unterscheidung, eine weitere Anwendung, ...
- und man landet ganz schnell wo ? beim Programmieren eines
minimalisitischen _http-Servers_. Ooops...

Wie wär's alternativ mit einem solchen, die gibt es doch schon zuhauf
fertig. Sooo immens ist deren Footprint im System nicht, lassen sich prima
minimalistisch skalieren. Und bringt den riesigen Vorteil, dass man nicht
alle Fehler, die alle anderen schon hinter sich haben auch wieder macht.

Ist aber natürlich nur ein Gedanke, wenn er auch aus mehrfacher eigener
Erfahrung entstammt :-)
---
arkascha

Ad 2007-11-16, arkascha <no_spam [at] no_spam.org> dixit:
^^^^^^^^
Wer?

> Peter Blancke wrote:

>>> Gestartet von inetd sollte das lesen/schreiben über stdin und
>>> stdout ausreichen:
>>>
>>> #!/usr/bin/php
>>> <?php
>>> $data = fgets(STDIN);
>>> echo('You said: ' . $data);
>>> ?>

>> Danke. Dieses kurze Skript ueber xinetd eingebunden ist schon die
>> Loesung. Ein Aufruf von
>>
>> http://localhost:8000/the_quick_brown_fox
>>
>> bringt als Antwort:
>>
>> You said: GET /the_quick_brown_fox HTTP/1.1
>>
>> Das auszuwerten ist keine Schwierigkeit, eine Rueckantwort mit
>> korrekten HTTP-Headern zu senden natuerlich auch nicht.
>> Allenfalls musz ich ueberlegen, was da an Sicherheitsproblematik
>> drohen kann. Ueberlange Zeichenketten vielleicht.

> - schlank, einfach, "nur für diesen Anwendungsfall", ...

Ja, genau.

Trotzdem sind Deine Bedenken korrekt; es geht aber wirklich nur
darum, dasz eine einzige Antwort ausgewertet werden soll und
vielleicht maximal noch ein korrektes HTTP-Dokument zurueckgereicht
werden soll.

Vielleicht hast Du hierfuer noch eine Loesung:

Trotz Suche in allen xinetd-Dokumenten finde ich keine Moeglichkeit,
einen Timeout zu konfigurieren, falls jemand mit

telnet host 8000

eine Verbindung zum PHP-Programm oeffnet und die einfach stehen
laeszt. Ich habe den Verdacht, dasz ein Timeout auch gar nicht die
Aufgabe des xinetd ist, sondern die des PHP-Programms, welches
dadurch gestartet wurde. Leider kriegt man in den Aufruf des
Serverprozesses den Befehl "timeout" nicht korrekt rein.

Gibt es unter PHP eine Moeglichkeit, dasz ein Skript sich selbst
nach einer gewissen Zeit beendet, ohne dasz ich da via Polling
dauernd CPU-Last erzeuge? Irgendwie einen Event-Handler, der nach
voreingestellter Zeit ausloest. Ich finde in den PHP-Dokumenten
nichts passendes dazu. Perl hat so etwas, aber ich wuerde gerne bei
PHP bleiben. Diskussionen, die ich dazu fand, sagen, dasz es so
etwas bei PHP nicht gebe.

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!

Peter Blancke:

> Gibt es unter PHP eine Moeglichkeit, dasz ein Skript sich selbst
> nach einer gewissen Zeit beendet

max_execution_time
<http://de.php.net/manual/en/ref.info.php#ini.max-execution-time>
--
Mit PHP Kontonummern auf Gültigkeit prüfen:
<http://bav.malkusch.de/>

Ad 2007-11-18, Markus Malkusch <markus [at] malkusch.de> dixit:
> Peter Blancke:

>> Gibt es unter PHP eine Moeglichkeit, dasz ein Skript sich selbst
>> nach einer gewissen Zeit beendet

> max_execution_time
><http://de.php.net/manual/en/ref.info.php#ini.max-execution-time>

Ja, ist aber eine globale Einstellung. Das Skript sollte "sich
selbst" beenden, damit ich nicht all die anderen Skripte, die auch
noch laufen, beeintraechtige. Im speziellen Falle moechte ich einen
Abbruch nach 5 Sekunden haben.

Uebrigens hilft mir set_time_limit() im Skript selber auch nicht:

,----
| ~$ time php -r "set_time_limit(3); sleep(30);"
|
| real 0m34.176s
| user 0m0.036s
| sys 0m0.040s
`----

Aus dem Handbuch dazu:

,----
| This function has no effect when PHP is running in safe mode. There
| is no workaround other than turning off safe mode or changing the
| time limit in the php.ini.
`----

Der safe_mode steht aber auf off.

Ein neuer Gedankenansatz ist der, dasz ich doch eine Schleife baue,
die einfach nachschaut, ob auf STDIN Daten liegen, dann 5 Sekunden
wartet, noch einmal nachschaut und sich dann beendet. Da fehlt mir
aber augenblicklich noch die STDIN-Pruefung. Ob das ueberhaupt geht?
Ein "$data=fgets(STDIN);" bleibt hier ja haengen.

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!

Peter Blancke schrieb:

> Uebrigens hilft mir set_time_limit() im Skript selber auch nicht:
>
> ,----
> > ~$ time php -r "set_time_limit(3); sleep(30);"
> >
> > real 0m34.176s
> > user 0m0.036s
> > sys 0m0.040s
> `----

Das liegt am sleep(), dass hier etwas "besonders" reagiert. So funktioniert
das:
| php -r "set_time_limit(4); while (true) {}"


> > > Trotz Suche in allen xinetd-Dokumenten finde ich keine
> > > Moeglichkeit, einen Timeout zu konfigurieren, falls
> > > jemand mit
> > >
> > > telnet host 8000
> > >
> > > eine Verbindung zum PHP-Programm oeffnet und die einfach
> > > stehen laeszt.

Hier könnte evtl. eher max_input_time [1] ansetzten.


> > > > > > > Um einen solchen URL auszuwerten, moechte ich keinen
> > > > > > > kompletten HTTP-Server installieren, sondern lediglich
> > > > > > > per [x]inetd am Port 8001 lauschen und den uebergebenen
> > > > > > > Code mit einem PHP-Skript auswerten, um eine bestimmte
> > > > > > > Aktion zu veranlassen

Evtl. hilft dir bei deinem Problem auch dieses weiter: PEAR::HTTP_Server [2]


Gruß
Carsten


[1] http://de.php.net/manual/en/ref.info.php#ini.max-input-time
[2] http://pear.php.net/package/HTTP_Server

Ad 2007-11-18, Carsten Wiedmann <carsten_sttgt [at] gmx.de> dixit:
> Peter Blancke schrieb:

>> Uebrigens hilft mir set_time_limit() im Skript selber auch nicht:

>> ,----
>> > ~$ time php -r "set_time_limit(3); sleep(30);"
>> >
>> > real 0m34.176s
>> > user 0m0.036s
>> > sys 0m0.040s
>> `----

> Das liegt am sleep(), dass hier etwas "besonders" reagiert.

Vermutlich ist da sleep() nicht allein etwas "besonderes", und: Was
ist das Besondere?

> So funktioniert das:
>| php -r "set_time_limit(4); while (true) {}"

Ja, das geht. Danke. Aber:

,----
| #!/usr/bin/php
| <?php
| set_time_limit(2);
| $data = fgets(STDIN);
| echo('You said: ' . $data);
| ?>
`----

So geht es nicht. Das Skript bleibt haengen, bis auf STDIN etwas
hereinkommt.

Da Dein "while (true) {}" ja funktioniert, nehme ich an, die Sache
scheitert, sobald eine PHP-interne Funktion aufgerufen wird, wie das
sleep() oder aber das bei mir verwendete fgets(). Diese Funktionen
lassen sich nicht vom set_time_limit() beeindrucken. Der Abbruch
greift erst, wenn aus diesen Funktionen zurueckgekehrt wird. Das ist
vermutlich auch das "Besondere", was Du bei sleep() meintest.

> Hier könnte evtl. eher max_input_time [1] ansetzten.

Die Zeit kann wiederum aber das Skript nicht setzen. Mindestens tut
im Skript der Befehl "ini_set('max_input_time', '2');" nicht das,
was ich erhoffte.

> Evtl. hilft dir bei deinem Problem auch dieses weiter:
> PEAR::HTTP_Server [2]

> [2] http://pear.php.net/package/HTTP_Server

Da will ich mir mal den Source anschauen, das kann schon einmal
nicht schaden.

Danke fuer Deine Anregungen!

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!

Peter Blancke schrieb:

> Ad 2007-11-18, Carsten Wiedmann <carsten_sttgt [at] gmx.de> dixit:
> > Peter Blancke schrieb:
>
> > > Uebrigens hilft mir set_time_limit() im Skript selber auch nicht:
>
> > > ,----
> > > > ~$ time php -r "set_time_limit(3); sleep(30);"
> > > >
> > > > real 0m34.176s
> > > > user 0m0.036s
> > > > sys 0m0.040s
> > > `----
>
> > Das liegt am sleep(), dass hier etwas "besonders" reagiert.
>
> Vermutlich ist da sleep() nicht allein etwas "besonderes", und: Was
> ist das Besondere?
>
> > So funktioniert das:
> > > php -r "set_time_limit(4); while (true) {}"
>
> Ja, das geht. Danke. Aber:
>
> ,----
> > #!/usr/bin/php
> > <?php
> > set_time_limit(2);
> > $data = fgets(STDIN);
> > echo('You said: ' . $data);
> > ?>
> `----
>
> So geht es nicht. Das Skript bleibt haengen, bis auf STDIN etwas
> hereinkommt.
>
> Da Dein "while (true) {}" ja funktioniert, nehme ich an, die Sache
> scheitert, sobald eine PHP-interne Funktion aufgerufen wird, wie das
> sleep() oder aber das bei mir verwendete fgets(). Diese Funktionen
> lassen sich nicht vom set_time_limit() beeindrucken. Der Abbruch
> greift erst, wenn aus diesen Funktionen zurueckgekehrt wird. Das ist
> vermutlich auch das "Besondere", was Du bei sleep() meintest.
>
> > Hier könnte evtl. eher max_input_time [1] ansetzten.
>
> Die Zeit kann wiederum aber das Skript nicht setzen. Mindestens tut
> im Skript der Befehl "ini_set('max_input_time', '2');" nicht das,
> was ich erhoffte.
>
> > Evtl. hilft dir bei deinem Problem auch dieses weiter:
> > PEAR::HTTP_Server [2]
>
> > [2] http://pear.php.net/package/HTTP_Server
>
> Da will ich mir mal den Source anschauen, das kann schon einmal
> nicht schaden.
>
> Danke fuer Deine Anregungen!
>
> Grusz,
>
> Peter Blancke
>

Peter Blancke schrieb:

> > Das liegt am sleep(), dass hier etwas "besonders" reagiert.
>
> Vermutlich ist da sleep() nicht allein etwas "besonderes", und: Was
> ist das Besondere?

Unter *nix zählt sleep() nicht zur max_execution_time hinzu. Unter Windows
schon, das merkt er aber erst, nachdem die sleep() Zeit abgelaufen ist...


> ,----
> > #!/usr/bin/php
> > <?php
> > set_time_limit(2);
> > $data = fgets(STDIN);
> > echo('You said: ' . $data);
> > ?>
> `----
>
> So geht es nicht. Das Skript bleibt haengen, bis auf STDIN etwas
> hereinkommt.

Muss gerade feststellen, dass das Lesen von STDIN wohl nicht zur
max_input_time gehört. Vielleicht weiss hier ja jemand ob das so sein soll,
oder ob die Anwendung für max_input_time was anderes sein soll?

stream_set_timeout(9 scheint beim STDIN auch nichts zu bewirken.


So könnte dein Script in etwa funktionieren (nur unter *nix):
| <?php
| set_time_limit(5);
| stream_set_blocking(STDIN, false);
|
| $str = '';
| while ("\n" != substr(($str .= fread(STDIN, 1024)), -1, 1)) {
| }
| echo 'You said: ' . $str;
| ?>


> > Hier könnte evtl. eher max_input_time [1] ansetzten.
>
> Die Zeit kann wiederum aber das Skript nicht setzen. Mindestens tut
> im Skript der Befehl "ini_set('max_input_time', '2');" nicht das,
> was ich erhoffte.

Mal abgesehen davon, dass 'max_input_time' hier wohl nicht hilft (s.o.),
kann man dieses nicht mit ini_set() setzen, Aber so würde das gehen:
| ./php -d max_input_time=5 test.php


Gruß
Carsten

Ad 2007-11-18, Carsten Wiedmann <carsten_sttgt [at] gmx.de> dixit:
> Peter Blancke schrieb:

>> [Durch xinetd gestartetes PHP-Skript]

> So könnte dein Script in etwa funktionieren (nur unter *nix):
>| <?php
>| set_time_limit(5);
>| stream_set_blocking(STDIN, false);
>|
>| $str = '';
>| while ("\n" != substr(($str .= fread(STDIN, 1024)), -1, 1)) {
>| }
>| echo 'You said: ' . $str;
>| ?>

Danke, Carsten!

So geht es hier auf einem Debian/PHP5 tatsaechlich.

Allerdings musz man die Anzahl Sekunden auf das Notwendigste
beschraenken, denn die While-Schleife verursacht natuergemaesz eine
unheimliche CPU-Last. Fuer meine Anwendung ist da eine Sekunde aber
voellig ausreichend, da das Skript einen HTTP-Request entgegennimmt
und lediglich ein paar Byte auszuwerten hat. Auszerdem ist das keine
Massenanwendung, sondern lediglich eine Loesung fuer einen sehr
kleinen Benutzerkreis.

stream_set_blocking() war neu fuer mich, in diese Richtung werde ich
mich lesend weiterbemuehen.

Damit der xinetd ueber die Fehlermeldung des Skriptabbruches nichts
sicherheitsbedenkliches nach drauszen verraet, habe ich noch ein
error_reporting(0) eingebaut.

Trotzdem werde ich nochmals nach meinem alten Perl-Buch schauen,
dort kann ich -- mir so erinnerlich -- einen Handler programmieren,
der durch ein in Sekunden einstellbares ALARM-Signal ausgeloest
wird.

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!

Peter Blancke schrieb:

> > So könnte dein Script in etwa funktionieren (nur unter *nix):
> > > <?php
> > > set_time_limit(5);
> > > stream_set_blocking(STDIN, false);
> > >
> > > $str = '';
> > > while ("\n" != substr(($str .= fread(STDIN, 1024)), -1, 1)) {
> > > }
> > > echo 'You said: ' . $str;
> > > ?>
>
> Allerdings musz man die Anzahl Sekunden auf das Notwendigste
> beschraenken, denn die While-Schleife verursacht natuergemaesz eine
> unheimliche CPU-Last.

Stimmt. Evtl. eine gute Idee, in der while Schleife ein usleep() mit
reinzunehmen.

Gruß
Carsten

Peter Blancke schrieb:
> in einer Mail erhalten Benutzer von mir einen Link in etwa der
> folgenden Art:
>
> http://testserver.example.com:8001/index.php?code=3D4711
>
> Um einen solchen URL auszuwerten, moechte ich keinen kompletten
> HTTP-Server installieren, sondern lediglich per [x]inetd am Port
> 8001 lauschen [...]
> PHP ist deshalb meine Wunschsprache, weil ich da am besten mit
> zurechtkomme.

Ich hoffe mal, dass "lediglich" sich nicht darauf bezieht, dass du
meinst, so eine schlanke Lösung hinzubekommen. PHP ist keine Sprache fü=
r
schlanke Lösungen und das "möchte keinen kompletten HTTP-Server
installieren" ist eher als "bin zu faul um" zu werten und nicht als "der
ja hier wohl Overkill wäre".

Für schlanke Bedürfnisse gibt es schlanke Server, und wenn er nicht
bereits installiert ist, dann ist das Installieren eines Apache
wahrscheinlich wirklich Overkill. Aber

http://en.wikipedia.org/wiki/Comparison_of_web_servers

zeigt, dass es nicht nur einen Webserver gibt. Für geringen
Speicherverbrauch gibt es zum Beispiel lightttpd, der im Gegensatz zu
vielen anderen schlanken Servern inzwischen eine gut unterstützte
Community hat. Eventuell ist auch mini_httpd oder thttpd oder ein ganz
anderer Server die Lösung. Ein ständig laufendes PHP-Skript ist es
hingegen wahrscheinlich nicht.

Dieser Post soll kein Rüffel sein, er soll nur verhindern, dass du unte=
r
falschen Voraussetzungen PHP als Lösung heranziehst. Der Post las sich
für mich nämlich wie "wenn man einen schönen funkelnden Hammer hat,=
dann
ist alles ein Nagel".

OLLi

--
Menschen machen Fehler - deswegen haben Bleistifte hinten ein
Radiergummi dran.
[Edel und Starck]

Oliver Grätz schrieb:
> Ein ständig laufendes PHP-Skript ist es
> hingegen wahrscheinlich nicht.

Aus diesem Grund wollte er das Script nur auf Anfrage ueber inetd oder
dergleichen starten.

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Ad 2007-11-20, Oliver Grätz <oliver.graetz [at] gmx.de> dixit:
> Peter Blancke schrieb:

>> in einer Mail erhalten Benutzer von mir einen Link in etwa der
>> folgenden Art:
>>
>> http://testserver.example.com:8001/index.php?code=4711
>>
>> Um einen solchen URL auszuwerten, moechte ich keinen kompletten
>> HTTP-Server installieren, sondern lediglich per [x]inetd am Port
>> 8001 lauschen [...] PHP ist deshalb meine Wunschsprache, weil ich
>> da am besten mit zurechtkomme.

> Ich hoffe mal, dass "lediglich" sich nicht darauf bezieht, dass du
> meinst, so eine schlanke Lösung hinzubekommen.

Doch, klar kriege ich die hin, aus vorangegangener Diskussion
allerdings nicht mit PHP. Mein Perl-Skript ist so gut wie fertig
durchdacht, ich ueberlege nur noch, ob ich einen kleinen
Multi-Threaded-Server permanent laufen lasse oder ob ich bei der
(x)inetd-Loesung bleibe.

> PHP ist keine Sprache für schlanke Lösungen

Warum nicht? PHP erledigt hier beispielsweise seit langem meine
halbjaehrliche Domainabrechnung fuer einige hundert Domains -- als
php-cli gestartet: Holt sich die Daten aus der Datenbank, stellt die
Werte zusammen, parst ein LaTeX-Template, erzeugt daraus PS und PDF,
druckt das PS automatisch aus und jagt das PDF am Ende per Mail
inklusive Begleittext zu den Kunden raus. Ganz hervorragend. Und
schlank, sag ich Dir!

> und das "möchte keinen kompletten HTTP-Server installieren" ist
> eher als "bin zu faul um" zu werten

Deine Wertungen in Ehren, ich werde sie Dir nicht krumm nehmen! Es
geht darum, dasz ich einen Port an einem dyn-IP-Rechner oeffnen
musz, auf welchem ansonsten die strenge Vorgabe gilt, dasz -- auszer
unter 22 -- nichts nach drauszen zu lauschen hat. Da will ich keine
Herumfummelei von besuchern, die danach suchen, was es da wohl noch
alles gibt. Da soll lediglich der o. a. Aufruf kurz und knackig
entgegengenommen und ausgewertet werden, mehr nicht. Und ja, ich
weisz, was "tainted" Variablen unter Perl sind.

> Für schlanke Bedürfnisse gibt es schlanke Server,

Und fuer noch schlankere Beduerfnisse gibt es den ohnehin laufenden
(x)inetd und ein Skript, welches aus nicht mehr als 20 Zeilen
besteht.

> Aber
>
> http://en.wikipedia.org/wiki/Comparison_of_web_servers
>
> zeigt, dass es nicht nur einen Webserver gibt.

Ich halte Dir mal zugute, dasz Du mich einfach nicht kennst.
HTTP-Server installiere ich in jeglicher Form, seit es welche gibt.

Ich schrieb nicht, dasz ich einen HTTP-Server wollte, ich schrieb,
dasz ich einen HTTP-Request entgegennehmen wollte. Nun ja, das ist
ja eigentlich auch schon ein Server.

> Für geringen Speicherverbrauch gibt es zum Beispiel lightttpd,

Du meinst lighttpd. Ja.

> Eventuell ist [...] ein ganz anderer Server die Lösung. Ein
> ständig laufendes PHP-Skript ist es hingegen wahrscheinlich nicht.

Haette PHP -- wie Perl mit seinem %SIG -- beispielsweise einen
Sig-Haendler fuer SIGALRM oder SIGCHLD, koennte es Prozesse forken,
dann koennte es auch PHP mit seinen Socket-Moeglichkeiten durchaus
sein. Das mache ich dem leistungsfaehigen PHP natuerlich nicht zum
Vorwurf, letztendlich ist PHP dafuer wohl auch nicht konzipiert
worden, sondern eher dafuer, dasz man dynamische Webseiten erzeugt..

Doch unterschaetze mir die php-cli-Variante nicht, da steckt fuer
den, der ohnehin viel mit PHP zu tun hat, viel Leistung drin, auch
auf der Kommandozeile.

> Dieser Post soll [...] nur verhindern, dass du unter falschen
> Voraussetzungen PHP als Lösung heranziehst.

PHP ist fuer diese gewuenschte Anwendung vom Tisch; es waere nur
schick gewesen, weil ich einige Klassen des in Frage kommenden
Projektes, die beispielsweise die SQL-Datenbank bedienen und Mails
behandeln, gleich haette mitbenutzen koennen. So setze ich mich
unter Perl noch einmal dran.

Perl erledigt jetzt die Anforderung in Kuerze. Aber da verlaeszt die
Thematik hier die Gruppe.

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!

Ad 2007-11-21, Peter Blancke <blancke [at] gmx.de> dixit:

> Haette PHP -- wie Perl mit seinem %SIG -- beispielsweise einen
> Sig-Haendler fuer SIGALRM oder SIGCHLD,

Ergaenzend:

Ich kriege gerade in einer anderen Neuigkeitengruppe folgenden
Verweis zum Studium:

http://www.linuxformat.co.uk/wiki/index.php/PHP_-_Alarm_func tions

Ich habe es allerdings noch nicht durchgearbeitet.

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!

..oO(Peter Blancke)

>Ad 2007-11-20, Oliver Grätz <oliver.graetz [at] gmx.de> dixit:
>
>> Eventuell ist [...] ein ganz anderer Server die Lösung. Ein
>> ständig laufendes PHP-Skript ist es hingegen wahrscheinlich nicht.
>
>Haette PHP -- wie Perl mit seinem %SIG -- beispielsweise einen
>Sig-Haendler fuer SIGALRM oder SIGCHLD, koennte es Prozesse forken,
>dann koennte es auch PHP mit seinen Socket-Moeglichkeiten durchaus
>sein. Das mache ich dem leistungsfaehigen PHP natuerlich nicht zum
>Vorwurf, letztendlich ist PHP dafuer wohl auch nicht konzipiert
>worden, sondern eher dafuer, dasz man dynamische Webseiten erzeugt..

Process Control Functions
http://www.php.net/manual/en/ref.pcntl.php

Micha

Ad 2007-11-21, Michael Fesser <netizen [at] gmx.de> dixit:
> .oO(Peter Blancke)

>> Haette PHP -- wie Perl mit seinem %SIG -- beispielsweise einen
>> Sig-Haendler fuer SIGALRM oder SIGCHLD, [...]

> Process Control Functions
> http://www.php.net/manual/en/ref.pcntl.php

Ja, klar. Damit geht es wirklich. Ich werde mein "PHP5 - Die
praktische Referenz, Verlag Markt & Technik" morgen verschenken. Das
schweigt sich ganz dazu aus. Und die Dinge gibt es schlieszlich
nicht erst seit PHP5.

Folgendes Programm ist ein funktionierender Testansatz, bei welchem
die CPU nicht mehr heisz wird:

#!/usr/bin/php
<?php

declare(ticks = 1);

function signal_handler($signal)
{
if (SIGALRM===$signal)
{
die();
}
}

pcntl_signal(SIGALRM, "signal_handler");
pcntl_alarm(10);

$data=fgets(STDIN);
print "You said: ".$data;

?>

Danke, Michael. Jetzt lege ich das Perl-Handbuch doch erst mal
wieder auf die Seite, mit PHP bin ich vertrauter.

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!

Peter Blancke schrieb:
>> Für schlanke Bedürfnisse gibt es schlanke Server,
>
> Und fuer noch schlankere Beduerfnisse gibt es den ohnehin laufenden
> (x)inetd und ein Skript, welches aus nicht mehr als 20 Zeilen
> besteht.

Mit "schlank" meinte ich den Speicherverbrauch und nicht die Zeilenzahl.
Ich ging zu dem Zeitpunkt allerdings fälschlicherweise auch noch von
einem ständig laufenden Skript aus, dass selbst Server spielen soll. In=

dem Fall wäre PHP deplatziert gewesen, denn hier wäre mit 3MB oder no=
ch
deutlich mehr Speicherverbrauch zu rechnen, verglichen mit unter 100kB
bei Servern, die nur für diesen Zweck geschrieben wurden. Ein nur auf
Anforderung laufendes Skript ändert die Bewertung natürlich.

Zu den Alarm-Funktionen: Ich habe ticks einmal vor zwei Jahren
ausprobiert und da ist mir gleich PHP komplett abgestürzt. Ich hoffe
mal, dass sich das inzwischen gebessert hat.

OLLi


--
\let\thepage\relax

Hi,

Peter Blancke schrieb am Mittwoch, 21. November 2007 18:06:

> Und fuer noch schlankere Beduerfnisse gibt es den ohnehin laufenden
> (x)inetd und ein Skript, welches aus nicht mehr als 20 Zeilen
> besteht.

das aber die Berechtigungen des inetd erbt, und der läuft
normalerweise unter root.

Grüße,
Holger

Holger Schröck schrieb:
> Peter Blancke schrieb am Mittwoch, 21. November 2007 18:06:

>> Und fuer noch schlankere Beduerfnisse gibt es den ohnehin laufenden
>> (x)inetd und ein Skript, welches aus nicht mehr als 20 Zeilen
>> besteht.

> das aber die Berechtigungen des inetd erbt, und der läuft
> normalerweise unter root.

service <service_name>
{
<attribute> <assign_op> <value> <value> ...
...
}

user

Determines the uid for the server process. The user attribute can either
be numeric or a name. If a name is given (recommended), the user name
must exist in /etc/passwd. This attribute is ineffective if the
effective user ID of xinetd is not super-user.

group

Determines the gid for the server process. The group attribute can
either be numeric or a name. If a name is given (recommended), the group
name must exist in /etc/group. If a group is not specified, the group of
user will be used (from /etc/passwd). This attribute is ineffective if
the effective user ID of xinetd is not super-user and if the groups
attribute is not set to 'yes'.

--
"Faulheit ist die Wurzel allen Fortschritts!"
(Inhalt eines Knallbonbons, 2002)