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
Received on Wed 20 Aug 2003 - 01:26:34 CEST