Re: php-cgi Port (Solution)

From: Benjamin Thelen (CCGIS) <thelen(at)ccgis.de>
Date: Sat, 30 Aug 2003 22:21:20 +0200 (CEST)

Kein topposten, deshalb gaaanz weit unten :-)!

> On 19.08.2003 18:04, Benjamin Thelen (CCGIS) wrote:
>>> 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.
>
> PHP selbst erkennt das. Jedoch nicht der exec(3) call (bzw., was
> letztendlich den Interpreter anhand des She-Bang läd).
>
>>>> 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.
>
> Probier mal meinen Vorschlag, und wenn's dann nicht klappt, gebe ich
> mich geschlagen.
>
>> 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!
>
> Dann verwende mal das PHP Modul. Vielleicht reicht das ja schon.
>
>>>> 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.
>
> Yup, ist damit auch egal.
>
> [...]
>>> Was benutzt Du für einen Browser?
>>
>>
>> Zt. hauptsächlich Opera. Jedoch erhalte ich auf Internet Explorer sowie
>> Mozilla und Konquerer die gleichen Fehlermeldungen.
>
> Im Mozilla kannst Du Dir mit einem Rechts-Klick in die Seite die
> Seiten-Info's anzeigen lassen. Dann erfährst Du den Mime-Type und
> einiges mehr.
>
>> 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??
>
> CGI geht immer wie's konfiguriert ist. Wir müssen solch philosophischen
> Fragen jetzt nicht diskutieren. Lösen wir Dein Problem, dann wirst Du
> alles vielleicht ein bisschen besser verstehen.
>
>> 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!
>
> Ist auch nicht aufwändig. Ist halt nur wie Gott es schuf, und nicht,
> wie's umgebogen wurde :-)
>
>>> 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
>
> Vertrauen ist gut, Kontrolle ist besser.
>
>> ja auch "php -f dateiname" aus ausführen konnte.
>
> Das sagt gar nichts, denn damit kann ich jede Datei ausführen, die
> ich lesen kann.
>
>> Was die Skripte angeht, so sind alle 664. Eine Änderung mit +x hat bei
>
> 'chmod a+rx *.php'?
>
>> meinem Problem nicht geholfen. Selbstverständlich habe ich das auch in
>> Kombination mit einem She-Bang getestet.
>
> Und?
>
>>> 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.
>
> $ ./file.php
> oder
> $ php -f ./file.php
> ?
>
>>> 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
>
> Auch dateien +x!!!!!
>
>> su-exec ist nicht installiert.
>
> Ist schonmal gut für die Problemlösung, schlecht für
> Produktionsserver.
>
>>>>>> 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??
>
> Mit lokal meinte ich ./
>
>>>> 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.
>
> php ist i.allg. nicht kompiliert. IMHO ist CGI nur für die Kommunikation
> mittels POST-Data (FORMS) entscheidend (Art der Programmierung der
> Verarbeitung).
>
>>>> 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!!
>
> Wir sollten uns erstmal auf die Problemlösung und später auf die
> Ursachenforschung konzentrieren.
>
>> 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>
>> .
>> .
>> .
>
> Sieht ok aus.
>
>>
>> #
>> # 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
>
> Das muss raus!
>
>> 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.
>
> War zu erwarten.
>
>> 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.
>
> Macht IMHO keinen Sinn.
>
>> 3. Ich konnte jedoch festellen, dass diese "Action..."-Zeile auf dem
>> Testserver, ein komische Verhalten hervorruft, je nachdem, was ich am
>> Schluss angebe.
>
> Siehe dazu httpd.apache.org
>
>> 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).
>
> Warum nicht?
>
>> 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
>
> Das bedeutet im Klartext: Führe die Datei mal am Prompt aus und gucke,
> was geschrieben stehen wird :-)
> Ausführen heisst:
> $ cd /usr/local/www/cgi-bin/php/mapbender/dhtml/
> $ ./index.php
>
> Gruss,
> Jens
>
>
> To Unsubscribe: send mail to majordomo.FreeBSD.org
> with "unsubscribe de-bsd-questions" in the body of the message
>
>

Moin Jens,

ich habe jetzt zumindest einen Weg gefunden, wie php als cgi so
funktioniert, wie ich es kenne:

Ich erhielt ja u.a. die Fehlermeldung "parse error" im Browser bzw.
"Premature end of script headers" in der httpd-error.log. Nun, ich habe
mir die php Sourcen gezogen und einfach mal "./configure" ausgeführt, dass
binary nach /usr/local/www/cgi-bin kopiert und siehe da php funktionerte!!
Die Konfiguration der httpd.conf sieht aus, so, wie ich es immer hatte:

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

<Directory /usr/local/www/cgi-bin>
    AllowOverride None
    Options ExecCGI
    Order allow,deny
    Allow from all
</Directory>
.
.
.
AddType application/x-httpd-php .php

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

Ich habe darauf hin sämtliche Schalter gecheckt und fand heraus, dass
sobald php mit "--enable-discard-path" kompiliert wird und das ist bei
ports/php4-cgi der Default, die oben genannten Fehlermeldungen erscheinen
und php nicht funktionert.
Einzige Lösung diesen Schalter dennoch zu verwenden ist die von Dir
genannte, die aber eben auch voraussetzt, dass alles was nicht Script ist
außerhalb von cgi-bin liegt (da sonst ALLES geparsed wird) und alles was
ausgeführt werden soll innerhalb, a+x sein muss und #!/usr/local/bin/cgi
in jeder ersten Zeile enthalten muss.

Um das php so zu kompilieren, dass es als cgi funktioniert, habe ich (mal
wieder :-)) ports/lang/php4/Makefile verändert:

CONFIGURE_ARGS= --enable-versioning \
                --enable-force-cgi-redirect \
                --with-regex=system \
                --enable-memory-limit \
                     --with-layout=GNU \
                --with-zlib-dir=/usr \
                --disable-all

#.if !defined(WITH_REGEX_TYPE) || ${WITH_REGEX_TYPE} == "php"
#CONFIGURE_ARGS+=--with-regex=php
#.else
#.if ${WITH_REGEX_TYPE} == "system"
#CONFIGURE_ARGS+=--with-regex=system
#.else
#.if ${WITH_REGEX_TYPE} == "apache"
#CONFIGURE_ARGS+=--with-regex=apache
#.endif
#.endif
#.endif

sowie:

#.if defined(WITHOUT_APACHE)
#CONFIGURE_ARGS+=--enable-discard-path
#PLIST_SUB+= APACHE="@comment "
#.else
#PLIST_SUB+= APACHE=""
#.endif

Wie Du siehst habe ich auch mal wieder das Problem mit --with-regex=system
etwas anders, als gedacht gelöst. Leider. Ich habe gesehen, dass Anfang
Juli auf Dein Bitten (Hierfür noch mal Danke!) hin
(http://www.freebsd.org/cgi/query-pr.cgi?pr=54061) der "WITH_REGEX_TYPE
knob" hinzugefügt wurde, was ja auch an dem von mir auskommentierten Teil
des Makefiles nicht zu übersehen ist. Allerdings würde ich gerne
verstehen, wie man diesen Schalter dem make übergibt. Vielleicht ist die
Lösung mal wieder sehr offensichtlich, aber alles was ich ausprobiert habe
(u.a. ~/php4-options-file) funktioniert nicht, bzw. die Options, die darin
bereits enthalten sind, natürlich schon!. Seltsam finde ich auch, dass
dieser "knob" nicht unter ALL_OPTIONS im Makefile steht, aber hier steht
ja auch WITH_LZW nicht dabei, welches ich auch nicht dem make mitgeben
konnte!

Hast'n Tip? :-)

Nun stellt sich natürlich auch die Frage, was es mit dem discard-path auf
sich hat, wieso der Maintainer Alex Dupres das fest miteingebaut hat und
wieso dann php als cgi mit meiner httpd-Konfiguration nicht läuft.

Auf zwei FreeBSD Rechnern habe ich nun diese Änderungen vorgenommen und es
funktioniert auf Anhieb.

Sorry for bothering you again, aber ich denke, dass das für Dich auch
interessant ist!

Würde mich über einen Kommentar von Dir hierzu sehr freuen!

Einen schönen Abend!
Benjamin

PS: Unter debian konnte ich das übrigens exakt reproduzieren! Naja,
funktioneren tut es jetzt und ich hoffe Verstehen kommt dann auch langsam!
:-)

To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 30 Aug 2003 - 22:26:36 CEST

search this site