Re: php-cgi Port

Jens Rehsack wrote:
> 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.

Ich habe es ja auch gestern schon probiert, ich zitiere mich selbst:
"Selbstverständlich habe ich das auch in Kombination mit einem She-Bang
getestet."
Grundsätztlich funktioniert php ja auch. Allerdings halt unter recht
unangenehmen Umständen und mit Problemen, die vorher, auf dem 4.7er
FreeBSD System mit dem umgebogenen mod_php4 und wenn php als
Apache-Modul kompiliert wurde nicht auftreten.

1. Es müßte in jedem php Skript ein She-Bang stehen. Da es sich um
Software handelt, die wir beim Kunden auf unterschiedlichen Systemen
einsetzen, wäre die Verwendung des She-Bang ein erheblicher Aufwand, der
auch natürlich fehleranfällig ist.

2. php-Skripte müssen plötzlich a+x sein.

3. She-Bang macht Probleme.

3.1 #!/usr/local/bin/php zeigt sich plötzlich im Browser, zum Teil bis
zu dreimal, weil wir include-Anweisungen in den php-Skripten verwenden.

3.2 Die eigentliche Funktionalität dieser mit php geschriebenen Software
ist nicht gegeben. Wie ich schon sagte, manche php Skripte werden
ausgeführt (mit der unter 3.1 beschriebenen Einschränkung) und manche
zeigen einfach zu mehrfach den She-Bang und werden aber nicht
ordnungsgemäß ausgeführt.

>
>> 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.

Der umn-mapserver könnte durchaus mit php als Apache-Modul arbeiten.
Mapscript benötigt aber gleich zwei Bedingungen. Zu diesem Thema hatten
wir uns ja schon mal vor einiger Zeit unterhalten, woraufhin Du eine
Mail an die php-Maintainer geschrieben hattest. So ungefähr war das
glaube ich.

Bei der Kompilierung bricht mapscript mit folgender Meldung ab:

checking whether we have PHP3 or PHP4... -DPHP4
checking whether we should use PHP's regex... yes
configure: error:
!!! The current version of PHP MapScript has some problems with !!!
!!! PHP4's bundled regex. Until we figure the solution to the !!!
!!! problem, the workaround is to compile PHP4 with the system regex !!!
!!! Please re-configure and re-compile PHP4 with --with-system-regex !!!
!!! and then re-configure and re-compile MapServer. !!!

Und auf http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?PHPMapScriptCGI
zitiere ich folgendes:

Due to some thread-safety problems (and some heritage from PHP3 in the
php_mapscript.c code), PHPMapScript versions 3.5 (and 3.6-dev at least)
will produce intermittent errors and crashes when used under PHP
configured as an Apache DSO or as an ISAPI module.

Das sind die Gründe für den ganzen Aufwand, den ich hierfür betreibe. :-(

Von dieser Webseite habe ich auch die Idee, mod_php4 umzubiegen, das
php-binary ins cgi-bin Verzeichnis zu kopieren und die drei AddType und
die Action Anweisung wie ich sie schon weiter unten angegeben hatte in
die httpd.conf zu kopieren.

Ich sehe aber gerade in diesem Dokument den Abschnitt "Running only
PHPMapScript scripts as a CGI", der eine AddHandler Anweisung enthält,
auf die ich auch gestoßen bin, in dem Security-Advisory auf
"http://www.php.net/manual/en/security.cgi-bin.php". Diesen Tip hat mir
auch Nicolas Rachinsky von der Liste gestern noch direkt zugeschickt.
In diesem Dokument werden vier Möglichkeiten php als cgi sicher zu
installieren. Eine davon ist die Lösung mit dem She-Bang. Die letzte,
wenn ich das alles richtig verstehe und da bin ich mir aber leider nicht
so sicher, deshalb werde ich es gleich testen, wäre das Hinzufügen von

Action php-script /cgi-bin/php
AddHandler php-script .php

in die httpd.conf.

Das findet sich im Abschnitt "If you want to use server side includes,
or CGI outside ScriptAliased directories, uncomment the following lines"
in der httpd.conf

>
>>>> 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.

Wird mir immer nur text/html oder "various types" (oder so) angezeigt.
Auch auf den Seiten des funktionierenden Servers.

>
>> 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.

Jedoch könnte man vielleicht aufgrund der vollzogenen Änderungen
herausfinden, weshalb es nun zu diesen Problemen kommt.

>
>> 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 :-)

Nun, ich versuche ja auch nicht meine Vorstellungen zu verwirklichen,
sondern habe einfach eine Vorgehensweise im Kopf, die
ich mir ja nicht aus den Fingern gesogen habe, sondern von der oben
genannten mapserver-Seite und die ja auch bisher funktioniert hat. Wenn
ich mich recht erinnere gab es zu Zeiten des 4.7er FreeBSD Release nur
mod_php4 und kein lang/php4 oder www/php4-cgi, sonst hätte ich lang/php4
als cgi kompiliert (Wobei es ja eigentlich heißt, dass php als default
als cgi kompiliert wird...!?). Alternativ hätte ich ja nur php als
original Source von php.net herunterladen können und die
Ports-Collection außen vor lassen können und das wollte ich auch nicht.

>
>>> 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.

Naja komm, der Aufruf php irgendwas funktionierte doch, das wäre ja
nicht möglich gewesen, wenn das php-binary nicht ausführbar gewesen wäre.
>
>> 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'?

Ja, also 755 :-). Ich kannte die Schreibweise von Dir nur vom sehen, ist
aber ja sogar einfacher. Danke!

>
>> meinem Problem nicht geholfen. Selbstverständlich habe ich das auch in
>> Kombination mit einem She-Bang getestet.
>
>
> Und?

Ja, habe ich ja weiter oben schon näher beschrieben, wo die Probleme liegen.

>
>>> 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
> ?
>

$ ./file.php 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
>
>
> Auch dateien +x!!!!!

Dass die Methode mit She-Bang 755 benötigt habe ich nun auch geschnallt.

>
>> 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 ./

Also im gleichen Verzeichnis, wie das Skript??

>
>>>> 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).

Jetzt muss ich doch blöde fragen: Aber php wird doch 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!!
>
>
> 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!

Alles, was unter "Benjamin" steht? Habe ich gemacht. Macht im Ergebnis
jedoch keinen Unterschied.

>
>> 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.

Nun "Action" gibt offensichtlich nicht den Pfad zum Parser an...?

>
>> 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

Die Dokumentation zu cgi finde ich zumindest für mich, nicht besonders
hilfreich, weil nicht ausführlich genug. Ich hatte mir das gestern mal
angesehen.

>
>> 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?

Weil ich dann die Fehlermeldung
Parse error: parse error in /usr/local/www/cgi-bin-dist/php on line 6930
bekomme.
Ich schließe daraus, dass entweder vielleicht etwas in der php.ini
falsch ist oder aber, dass php ausdrücklich in cgi-bin installiert
werden muss, so wie das bei debian passiert ist. Ansonsten weiß ich auch
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

Ich bin der Sache mit dem She-Bang heute noch mal nachgegangen. Obige
Fehlermeldung aus der httpd-error.log wird für JEDE Datei angegeben, die
im Browser aufgerufen wird, sofern kein She-Bang enthalten ist. Also bin
ich Stück für Stück vorgegangen und habe in jede Datei, die in der
errror-log auftauchte einen She-Bang hinzugefügt und siehe da es wurde
langsam. Da es aber so viele sind, habe ich noch nicht alle durch.
Jedoch geht Stück für Stück ein "Internal Server Error weg" bzw. Eintrag
in die error-log.
Jetzt kommt aber der unglaubliche Hammer, der nur völliges Unverständnis
bei mir hervorruft (und bei meinem PHP-Kollegen erst recht). Obige
Fehlermeldung aus der error-log wird nicht nur für php-Skripte
angezeigt, sondern auch für images (gif, jpg, png) und für css! Ich habe
dann und das finde ich unglaublich, in einige der Bilder einen She-Bang
(und in eines der css auch) eingefügt und (ich habe die Bilder mit vi
geöffnet!) und siehe da, ein Bild nach dem anderen tauchte auf.

WAS ABER UM HIMMELSWILLEN (Sorry für's Brüllen! :-)) veranlasst bitte
Apache dazu Bilder und css, also im Grunde alles was sich in cgi-bin
befindet parsen zu wollen/müssen?????????? Das kann und darf nicht sein.

Um mal meine Windows Erfahrungen einzubringen, ein Beispiel aus dieser
Welt. Ich will nicht sagen es ist besser, aber es läßt sich im 0,nix
konfigurieren. Dort weißt man nämlich lediglich im IIS die Erweiterung
.php der Anwendung c:\PHP\bin\php.exe zu und damit ist die Geschicht
erledigt.

Es müßte doch eine Möglichkeit geben, dass in Apache ähnlich zu machen,
also das was der She-Bang an u.u. 1000 Stellen macht, müßte doch an
einer Stelle im Apache zu konfigurieren sein.
Hier dachte ich zu erst an die "Action..."-Zeile. Jetzt hoffe ich, dass
ich mit oben beschriebenen AddHandler-Abschnitt weiterkomme.

>
>
> 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

Funktioniert. Sieht zwar nicht schön aus, aber es kommt was bei rum und
sieht auch richtig aus.

>
> Gruss,
> Jens
>
>
> To Unsubscribe: send mail to majordomo.FreeBSD.org
> with "unsubscribe de-bsd-questions" in the body of the message
>

Gruss,
Benjamin

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 - 18:12:43 CEST