PHP fastcgi

C

CEW4

Member
Hallo,

ich habe auf einem V-Server unter ubuntu v10.04 und Plesk v11.5 eine zusätzliche PHP-Version installiert. Eine phpinfo()-Seite zeigt Erfolg, die neue Version läuft also prinzipiell. Auch bestimmte Tests (Contao bietet z.B. eine Art "Voraussetzungs-Check" an) laufen ohne ersichtliches Problem.

Aber Typo3 ist mit der neuen Version nicht zufrieden. Anstatt Frontend oder Backend erscheint nur ein weißer Bildschirm mit "No input file specified." Das Apache-Log zeigt jedoch keinen Fehlereintrag. Die Typo3-Installation ist samt Datenbank direkt von einem Production-Host kopiert und sollte für sich in Ordnung sein, wenn ich eine bereits laufende Installation vom alten PHP (5.3.x) auf das neue (5.4.x) umschalte, erhalte ich dasselbe Ergebnis. Das alte PHP funktioniert auch als FastCGI (default Apache Modul) fehlerfrei.

Hat jemand eine Idee, an welcher Stelle ich weitersuchen könnte?

MfG
 
Was sagt der PHP Error log? Eventuell in der php.ini das Error Level hochstellen.
Vielleicht liegt es an openbase_dir...
 
djrick said:
Was sagt der PHP Error log? Eventuell in der php.ini das Error Level hochstellen.
Click to expand...
Nichts, aber möglicherweise habe ich hier etwas falsch konfiguriert. Ich benutze die Development.Version der php.ini und habe eingetragen:

Code: 
error_log = /var/log/php_5.5.14_errors.log

Aber diese Datei wird nicht erstellt. Ist die Verzeichnisangabe falsch, gibt es da vielleicht ein Rechte-Problem? Was verwendet man denn hier "üblicherweise"?

Vielleicht liegt es an openbase_dir...
Click to expand...
Daran habe ich schon gedacht, aber müsste das nicht als Fehler im Apache-Log auftauchen?

MfG
 
CEW4 said:
Aber diese Datei wird nicht erstellt. Ist die Verzeichnisangabe falsch, gibt es da vielleicht ein Rechte-Problem? Was verwendet man denn hier "üblicherweise"?
Click to expand...

Gut möglich. Abhängig von deiner Konfiguration wird PHP entweder unter dem Apache-User (bei Debian-Systemen z.B. www-data) oder dem User laufen, den du ggfl. per suexec konfiguriert hast. Entweder die Datei händisch anlegen und den User per chown anpassen oder ein Unterverzeichnis, das temporär über weitreichende Rechte verfügt und das Log dorthin schreiben lassen (die Rechte vom Verzeichnis dann aber spätestens anpassen, sobald die Log-Datei erstellt wurde).
 
danton said:
Entweder die Datei händisch anlegen und den User per chown anpassen oder ein Unterverzeichnis, das temporär über weitreichende Rechte verfügt und das Log dorthin schreiben lassen (die Rechte vom Verzeichnis dann aber spätestens anpassen, sobald die Log-Datei erstellt wurde).
Click to expand...
Was passiert denn, wenn ich nur

Code: 
error_log = datei.log
statt

Code: 
error_log = /ein/pfad/zu/datei.log
schreibe? Sollte die Datei dann nicht im Documentroot der Seite erstellt werden, auf die der Webserver ja sicher ausreichende Schreibrechte hat? Dies funktioniert hier nämlich ebenfalls nicht. Aus der phpinfo()-Seite sehe ich, daß sich der Inhalt von error_log schon ändert wie geplant, ich also die korrekte ini bearbeite. Aber ich kann trotzdem keine Logdatei finden.

MfG
 
Die Datei liegt dann nicht zwingend relativ zur aufgerufenen PHP-Datei. Ich weiß aber nicht genau, wie PHP das dann handhabt - es könnte dann auch z.B. relativ zur php.ini oder dem PHP Binary sein.
Du kannst die Logdatei auch z.B. nach /tmp schreiben lassen, da sollten auf jedem Fall ausreichend Rechte sein, um die Datei zu erstellen (außer open_basedir ist bei dir aktiv). Das mache ich ganz gerne, wenn ich mal eben schnell temporär ein Log zum Debuging brauche (sofern im Log keine zu sensiblen Daten landen)
 
Ok, Fortschritt: Ich habe mir jetzt eine mit absicht defekte php-Datei gebaut, um mutwillig einen Fehler zu erzeugen.

Bei Aufruf wird mir dieser Fehler sowohl im Browser angezeigt als auch in die Logdatei (/tmp hat schließlich funktioniert) eingetragen.

Aber zu meinem ursprünglichen Problem sehe ich nach wie vor keine Fehlermeldung.

MfG
 
Das Problem scheint mit SymLinks zusammenzuhängen:

DocumentRoot/readme.txt -> ok
DocumentRoot/phpinfo.php -> ok

DocumentRoot/Symlink/readme.txt -> ok
DocumentRoot/Symlink/phpinfo.php -> "No input file specified."

Ich habe die Zeile "open_basedir" in der php.ini (Plesk legt hier je virtual host eine eigene an) sogar schon komplett auskommentiert. Laut phpinfo() ist die Variable auch leer ("no value"), aber der Aufruf über einen Symlink hinweg funktioniert trotzdem nicht.

MfG
 
Na, wie gesagt:

Eine statische Textdatei über einen Symlink anzuzeigen funktioniert. Für mich bedeutet das, daß Apache kein Problem mit Symlinks hat (wäre auch verwunderlich, weil sich an dem ja auch nichts verändert hat.)

Eine PHP-Datei über einen Symlink anzuzeigen funktioniert nicht. PHP hat also ganz offensichtlich ein Problem mit Symlinks. Nur gibt es keine Fehlermeldung und keinen Eintrag in php_errors.log.


Tatsächlich habe ich inzwischen auch Berichte von anderen gelesen, die dieses Problem ebenfalls hatten, teilweise bereits Jahre alt, aber immer in der Kombination Plesk/PHP. Zwei Lösungsvorschläge wurden gegeben:

a) Änderung in der Apache Config, sodaß index.php vor index.pl gelesen wird -> steht bei mir bereits so

b) Änderung in der vhost.conf zwecks manuellem Einschalten von "Options +ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch" -> bringt bei mir keine Besserung.


MfG
 
Heureka:

Wenn PHP eine Datei nicht lesen kann (R-Recht auf der Datei), dann erhält man eine Fehlermeldung (angezeigt und/oder in der Logdatei.)

Wenn PHP nicht in ein Verzeichnis wechseln kann (X-Recht auf dem Verzeichnis), dann erhält man _keine_ Fehlermeldung.

Der Prozess der neuen PHP-Version läuft jetzt offenbar unter einem anderen Benutzer als vorher (auch anders als das alte PHP/FastCGI.) Deshalb braucht ein bestimmtes Verzeichnis jetzt auf einmal ein Recht other-X, wo vorher ein user-X bzw. ein group-X reichte.

Die statische Datei war im Gegensatz zum php-Skript aus demselben Verzeichnis lesbar, weil Apache unter einem "berechtigten" User läuft und das group-X genügte.

MfG
 
You must log in or register to reply here.
Back
Top