Re: php-cgi Port

From: Benjamin Thelen (CCGIS) <thelen(at)ccgis.de>
Date: Tue, 19 Aug 2003 18:04:32 +0200 (CEST)

> On 18.08.2003 19:02, Benjamin Thelen (CCGIS) wrote:
>
>>> On 18.08.2003 17:00, Benjamin Thelen (CCGIS) wrote:
>>>>> On 15.08.2003 19:18, Benjamin Thelen (CCGIS) wrote:
>>>>>> Moin zusammen,
>>>>> Selber Moin, vor zwölf, echt und so munter, elend :-)
>>>>> [...]
>>>>>> Danach habe ich wie oben beschrieben, das php-binary eben nach
.../www/cgi-bin kopiert und es funktionierte auch.
>>>>>> Mit dem php4-cgi Port geht das so aber nicht. Muss ich was anderes
machen oder ist meine Vorgehensweise doch richtig?
>>>>>> Vielen Dank,
>>>>>> Benjamin
>>>>>> PS: Genau das gleiche Problem habe ich auf debian woody auch. Hier
gibt
>>>>>> es ein php4-cgi deb-Paket. Das habe ich nicht mit der oben
>>>>>> beschriebenen
>>>>>> Art und Weise ans laufen bekommen. Als Apache Modul, alles kein
Problem.
>>>>>> PHP läuft.
>>>>> Was steht denn in den /var/log/httpd-error.log und
>>>>> /var/log/httpd-suexec.log
>>>>> (je nach httpd.conf entsprechend anders)?
>>>>> So long,
>>>>> Jens
>>>> Moin Jens,
>>>> Wie vor zwölf?? War doch früher Abend!
>>> Tja, 'Moin' und mitten in der Nacht gelesen (ich) hat halt
>>> falschen Schluss gefolgert :-)
>>> Bitte immer die Liste CC'en!
>> Das war ein Versehen. Ich hätte mich wahrscheinlich recht lange
gewundert,
>> wo meine Mail bleibt! :-)
>>>> Zu Deiner Frage:
>>>> Ich habe lediglich eine httpd-access.log und eine httpd-error.log?!
In der httpd-access.log steht nur, dass zugegriffen wurde, mehr
nicht.
>>>> Folgendes habe ich ausprobiert:
>>>> 1. php-binary liegt im cgi-bin-Verzeichnis
>>>> (manuell kopiert von /usr/local/bin/ nach /usr/local/www/cgi-bin)
>>> Steht als erstes im PHP-Skript ein She-Bang für /usr/local/bin/php?
Sollte in etwa so aussehen:
>>> #!/usr/local/bin/php
>> Es erscheint leider nachwievor die gleiche Fehlermeldung.
>
> Ist das Zeilenformat Unix (zeigt 'vi datei.php' komische ^M's)?

Moin Jens,

Ja.
Bisher hat der Windows-Zeilenumbruch der Funktionalität auf keinem unserer
Unix/Linux Server einen Abbruch gemacht :-). Beispielsweise sind die
phprojekt-Skripte (www.phprojekt.de) wohl alle unter MS-Windows entwickelt
worden und somit voll von Windows-Zeilenumbrüchen, funktionieren aber
dennoch auf einem debian-woody Server mit php als Apache Modul.

>
>> Mein PHP-Kollege meinte allerdings auch, dass das bei php nicht nötig
wäre. Es steht in keinem einzigen unserer Skripte.
>
> Doch, bei CGI ist es nötig, da der Web-Server es ausführt.

Wunderbar, Du sagst so, mein php-Kollege bleibt bei seiner Meinung :-). Er
meint, dass wäre absolut nicht nötig, sondern würde in der httpd.conf
konfiguriert und sei nicht zuletzt antiquiert. Nun, ich stehe zwischen
Euren Aussagen.
Nun zu meiner Meinung :-): Es findet sich z.B. in keinem php-Skript von
Squirrelmail, welches ausdrücklich php als cgi wünscht (aber auch bisher
ohne Probleme mit php als Modul funktioniert), ein She-Bang.
Nicht zuletzt kann ich nur wiederholen, dass der von mir beschriebene
FreeBSD 4.7 Server mit dem von mir zum cgi "verbogenen" ports/www/mod_php4
(mod_php4-4.3.1,1 PHP4 module for Apache) auch ohne She-Bang klar kommt!

>
>> Die Skripte funktionieren ja auch, wenn php4 als Apache-Modul
>> installiert
>> ist und sie funkionieren auch auf dem FreeBSD 4.7 mit dem von mir
verbogenen mod_php4. Auf diesem Rechner läuft php4 definitiv als cgi, die
>> LoadModule Zeile in der httpd.conf ist auch auskommentiert.
>
> Sind auch alle anderen PHP-bezogenen Sachen draußen?

Ich denke schon:

#LoadModule php4_module libexec/apache/libphp4.so
#AddModule mod_php4.c

Es gibt noch was unterhalb von "DirectoryIndex:" und unterhalb von
"LanguagePriority". Sieht zum Beispiel so aus: <IfModule mod_php4.c>.
Daraus würde ich aber schließen, dass das nur zum Tragen kommt, wenn php
als Modul läuft.

>
>>>> httpd-error.log: kein Eintrag
>>>> Browser: "Parse error: parse error in /usr/local/www/cgi-bin-dist/php
on
>>>> line 6930"
>>> Als was wird die Datei vom Browser erkannt?
>> Kann ich Dir so nicht sagen. Der Quelltext zeigt einfach nur folgendes
an:
>> <br />
>> <b>Parse error</b>: parse error in
>> <b>/usr/local/www/cgi-bin-dist/php</b>
>> on line <b>6930</b><br />
>
> Was benutzt Du für einen Browser?

Zt. hauptsächlich Opera. Jedoch erhalte ich auf Internet Explorer sowie
Mozilla und Konquerer die gleichen Fehlermeldungen.

>
> [...]
>
>>>> Ich habe auch noch mal das debian Package php4-cgi (äh, auf einem
debian-Rechner, natürlich) installiert. Interessanterweise befindet sich
>>>> nach der Installation ein php-binary im cgi-Verzeichnis. Zwar bekomme
ich
>>>> php-Skripte zum Download angeboten - was ich auch nicht verstehe -
aber
>>>> das ist eine andere Baustelle.
>>> Der Apache weiss, dass das keine HTML-Dateien, sondern PHP-Skripte
sind,
>>> und setzt den MIME-Type entsprechend. Dann weiss der Browser nix damit
anzufangen und bietet das Speichern an.
>> Was ich nicht verstehe, ist dass so lange ich php als Apache Modul
laufen
>> habe, beide Rechner, von denen ich hier gerade schreibe, php-Skripte
wunderbar ausführen und man diese auch im Browser angucken kann. Alles
funktioniert. Dann deinstalliere ich php4 (oder mod_php4) und
>> installiere
>> php4-cgi und nix funktioniert mehr.
>
> Da sollte sich mal jemand mit CGI beschäftigen, hm?
> CGI ist ein Kommunikationsprotokoll zwischen Web-Server und
> ausführbarer! Datei, wobei der Web-Server die Parameter
> vom Browser dem Skript in STDIN übergibt und die Ausgabe auf
> STDOUT erwartet.

Hm, so lange etwas einfach funktioniert, reicht es dass es funktioniert.
Ich mein, ich habe ohne Erfahrung einen FreeBSD 4.7 Server aufgesetzt,
apache 1.3.27 installiert, die ports/www/mod_php4 zum cgi verbogen und
mapserver ans Laufen bekommen. Wieso nun, wenn es netterweise einen
php4-cgi Port gibt, soll cgi nicht mehr so funktionieren wie früher??

Mir fehlt halt auch die Zeit, sonst hätte ich sicherlich schon längt ein
Buch darüber gelesen, wobei mir aber das was Du oben beschreibst soweit
auch schon klar ist. Allerdings dachte ich auch, dass sich einfach nur das
Handling von dem php4-cgi Port etwas geändert hat und das nicht so eine
aufwendige Geschichte würde!

>
> D.h.:
> 1) Skripte und Binaries müssen ausführbar sein (x-bit)

Nun, dass das php-binary ausführbar ist, davon ist ja auszugehen, da ich
es ja zum einen über die Ports-Collection installiert habe und zum anderen
ja auch "php -f dateiname" aus ausführen konnte.

Was die Skripte angeht, so sind alle 664. Eine Änderung mit +x hat bei
meinem Problem nicht geholfen. Selbstverständlich habe ich das auch in
Kombination mit einem She-Bang getestet.

> 2) Skripte müssen einen gültigen She-Bang haben

s.o.

> 3) Skripte müssen im Unix-Fileformat vorliegen.

s.o.

>
>> Im obigen Fall setzt doch dann offensichtlich der Webserver den
MIME-Type
>> falsch (obwohl er ihn zuvor als php4 noch als Modul lief richtig
setzte).
>> Das macht doch keinen Sinn?
>
> Doch, macht es. Leider ziehen wir grade um, und ich kann Dir keine
Literaturempfehlung raussuchen, aber http://www.w3c.org/ und
> http://httpd.apache.org/ wird Dir sicher auch Klarheit verschaffen
können.
>
>> Übrigens sind bei Rechner in der Lage php-Skripte lokal zu parsen! Also
sowas wie php -f file.php.
>
> Und was ist mit './file.php'? Wenn das nicht geht, wird's im Web-Server
nie klappen.

Klappt.

>
> Wie sieht es mit den Zugriffsrechten des Web-Servers auf die Dateien aus
(user,group,other)? Ist su-exec installiert?

Dateien inkl. Skripte 664
Verzeichnisse zusätzlich +x

su-exec ist nicht installiert.

>
>>>> Ich schließe jedoch daraus und daraus, dass dass mit meinem
>>>> "umgebogenen"
>>>> mod_php4-Port bisher so funktionierte, dass sehr wohl ein php-binary
im
>>>> cgi-Verzeichnis zu liegen hat. Richtig?
>>> Möglich, kommt auf Dein Skript an.
>> Muss ich passen. Verstehe ich nicht. Deine Aussage verstehe ich so,
dass
>> es skriptabhängig ist?? Je nachdem wie ich das php-Skript schreibe muss
der "cgi-server" anders konfiguriert werden? Ich glaube, dann werde ich
zum Hirsch. :-)
>
> Nein. Ich meinte eher, Du hast u.U. einen Fehler im Skript, der es
benötigte, den php-Interpreter lokal liegen zu haben.

Was meinst Du mit "lokal liegen haben"? /usr/local/bin ist doch lokal??

>
>> Wie kann das denn so kompliziert sein mit dem dämlichen cgi? Das geht
mir
>> einfach nicht ein. Installiere ich php4 als Apache-Modul funktioniert
auf
>> beiden Rechner alles auf Anhieb.
>
> Dann nimm das Modul.

Oh Mann, da sagst Du was. Dann könnten wir uns das alles hier sparen und
mehr noch...aber php-mapscript benötigt nun mal php als cgi kompiliert.

>
>> Kann es denn sein, dass debian das anders handhabt und das php-binary
gar
>
> Nein.
>
>> nicht unbedingt im cgi-Verzeichnis liegen muss? Aber irgendwie muss dem
Webserver das doch auch klar gemacht werden, woher er sein php-binary
bekommt...?
>
> Ja, aus dem She-Bang.
>
> --- BEGIN DEMO CGI SCRIPT
> #!/usr/local/bin/php
> <HTML><HEAD><TITLE>Hallo Welt</TITLE></HEAD><BODY>
> <?PHP
>
> echo "<H1>Hallo Welt</H1>\n";
> echo htmlentities( "Es grünt so grün wenn Spaniens Blüten " .
> "blühen" ) . "<BR>\n";
>
> ?>
> </BODY></HTML>
> --- END DEMO CGI SCRIPT
>
> $ ls -l demo.cgi
> -rwxr-xr-x [...] demo1.php
>
> Gruss,
> Jens
>
>
>

All diesen Problemen widerspricht unser FreeBSD 4.7 Server auf dem ich wie
oben ja schon gesagt ../ports/www/mod_php4 "verbogen" habe, womit dieser
Port dann eben als cgi läuft. Hier laufen exakt die gleichen Skripten und
sie sind auch NICHT ausführbar!!

Nun, ich habe weiter probiert:

Möglicherweise passt meine httpd.conf nicht auf den neuen php4-cgi-Port.
Zwei der relevanten Abschnitte habe ich mal rauskopiert. So, wie es da
steht funktioniert das auf oben beschriebenem 4.7er FreeBSD-Server.

.
.
.
    ScriptAlias /cgi-bin/ "/usr/local/www/cgi-bin/"

    #
    # "/usr/local/www/cgi-bin" should be changed to whatever your
    # ScriptAliased CGI directory exists, if you have that
    # configured.

    <Directory "/usr/local/www/cgi-bin">
        AllowOverride None
        Options None
        Order allow,deny
        Allow from all
    </Directory>
.
.
.

    #
    # AddType allows you to tweak mime.types without actually editing it,
# or to make certain files to be certain types.
    #
    AddType application/x-tar .tgz
    AddType image/x-icon .ico

    # Added by Benjamin
    AddType application/x-httpd-php .php3
    AddType application/x-httpd-php .phtml
    AddType application/x-httpd-php .php

    Action application/x-httpd-php /cgi-bin/php

1. Kommentiere ich "Action application..." aus, werden mir die php-Skripte
zum Download angeboten. Das passiert auf dem Testserver, sowie auf dem
4.7er Produktionsserver.

2. Bin ich bisher davon ausgegangen, dass diese Zeile angibt, wo der
Parser zu finden ist. Nicht zuletzt deshalb passt das auch für den FreeBSD
4.7 Server, bei dem ich ja die php-executable auch dorthin kopiert habe.

3. Ich konnte jedoch festellen, dass diese "Action..."-Zeile auf dem
Testserver, ein komische Verhalten hervorruft, je nachdem, was ich am
Schluss angebe.
Z.B. Ich rufe http://wms2/mapbender/welcome.php auf und bekomme die
Fehlermeldung "The requested URL /cgi-bin/php/mapbender/welcome.php was
not found on this server" im Browser. Ändere ich die Zeilt Application am
Schluss in /usr/local/bin/php, würde ich adäquat dazu "The requested URL
/usr/local/bin/php/mapbender/welcome.php was not found on this server" im
Browser vorfinden.

Zur Info:
Auf dem Server sieht es folgendermaßen aus:
Es gibt /usr/local/www/cgi-bin und /usr/local/www/data/mapbender. In
mapbender liegen alle Skripte (und in cgi-bin hätte ich eigentlich das
php-binary hinkopiert, aber das geht ja nun nicht mehr).

Da offensichtlich die Skripte an anderer Stelle erwartet werden habe ich
dann das mapbender-Verzeichnis nach cgi-bin kopiert. Nachdem ich dann die
Berechtigungen des ganzen Verzeichnisses auf auf +x gesetzt habe,
funktionieren manche php-Skripte, manche aber wiederum nicht.
Die, die nicht funktionieren haben folgende Fehlermeldung im Browser
zurück: "500 Internal Server Error"

In der httpd-error.log sieht das folgendermaßen aus:

[Tue Aug 19 14:17:34 2003] [error] (8)Exec format error: exec of
/usr/local/www/
cgi-bin/php/mapbender/dhtml/index.php failed
[Tue Aug 19 14:17:34 2003] [error] [client 192.168.2.109] Premature end of
scrip
t headers: /usr/local/www/cgi-bin/php/mapbender/dhtml/index.php

Gruß,
Benjamin

To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 19 Aug 2003 - 18:09:15 CEST

search this site