Edgar Ehritt: fastcgi_module auf Apache // Probleme mit FastCgiExternalServer

SELF-Forum

fastcgi_module auf Apache // Probleme mit FastCgiExternalServer

Edgar Ehritt
– Informationen zu den Bewertungsregeln

Hallo,

derzeit habe ich einen Apachen 2.2 mit fastcgi_module und PHP 5.3rc als Testumgebung. Leider verstehen sich die Komponenten nicht sonderlich gut, da PHP extern an einem Socket (/tmp/php.sock) klebt und über diesen angesprochen werden soll. PHP findet ohne Nachhilfe die auszuführenden Scripte jedoch nicht. Folgende Konfiguration benutze ich derzeit:

Alias			/script		/home/eddi/fcgi  
  
FastCgiIpcDir		/tmp  
FastCgiExternalServer	/home/eddi/fcgi	-socket /tmp/php.sock

Dies ist dem letzten Beispiel der FAQ nachempfunden. Das hat zur Folge, dass alle Anfragen unterhalb von http://name.domain/script/ mittels fastcgi_module durch PHP bedient werden.

Soweit ich das bis jetzt eruieren konnte, ist die Direktive FastCgiExternalServer gar nicht darauf ausgerichtet, <Locations> zu bedienen. PHP wird zwar aufgerufen, findet aus den FastCGI-Angaben aber die Dateien nicht und bricht mit einer Fehlermeldung ab:

Warning: Unknown: Filename cannot be empty in Unknown on line 0
Fatal error: Unknown: Failed opening required '' (include_path='.:') in Unknown on line 0

FastCgiExternalServer ist wohl nur dazu bestimmt, ein einzelnes Programm direkt aufzurufen, dem eine Auflösung zu einer real existierenden, zu verarbeitenden Datei daher nicht wichtig ist. Um so erstaunlicher war für mich, dass folgende Konfiguration für ein einzelnes Script erfolgreich ist:

FastCgiExternalServer /home/eddi/public_html/test/info.php -socket /tmp/php.sock

PHP findet aus den FastCGI-Headern zur eigentlichen Datei info.php und führt diese aus. Habe ich nur etwas falsch konfiguriert? (Andernfalls habe ich bereits einen work around.)

Gruß aus Berlin!
eddi

--
(v0.0.3 - also ganz der alte ;)
Beitrag melden
–
Informationen zu den Bewertungsregeln

  1. fastcgi_module auf Apache // Probleme mit FastCgiExternalServer

    mrjerk
    – Informationen zu den Bewertungsregeln

    Hallo,

    Um so erstaunlicher war für mich, dass folgende Konfiguration für ein einzelnes Script erfolgreich ist:
    FastCgiExternalServer /home/eddi/public_html/test/info.php -socket /tmp/php.sock

    Wieso findest Du das erstaunlich? Du sagst Apache (mittels Alias), dass er alle Anfragen die über /script kommen, mit dem Programm "info.php" verarbeiten soll - deswegen wird das logischerweise auch ausgeführt.

    FastCGI verhält sich letztendlich wie ein Server im Server:
    Du gibst einen Prozess an, der sämtliche Anfragen an den Webserver über bestimmte Urls entgegennehmen soll.
    Das Programm selbst (Dein fcgi bzw. info.php) hat mit PHP und Webserver-Konfigurationen erstmal nichts zu tun.

    Bei Deiner ersten Konfiguration, würde also ein
    http://..../script?bla=blubb
    dazu führen, dass das Kommando
    /home/eddi/fcgi
    mit dem Parameter "bla" aufgerufen wird.

    Du könntest (vermutlich) auch etwas basteln wie:

    FastCgiExternalServer /bin/echo -socket /tmp/php.sock[/code]

    Dann würde der Aufruf
    http://..../script?bla=blubb

    eine Ausgabe
    bla=blubb

    zur Folge haben.

    Wenn nun andere PHP-Dateien includet werden sollen, muss Dein Programm (/home/eddi/fcgi) so gebaut sein, dass es aus den Parametern/der URL erkennen kann, wo es die PHP-Dateien herbekommt.

    Hope that helps,

    Jörg

    Beitrag melden
    –
    Informationen zu den Bewertungsregeln

    1. fastcgi_module auf Apache // Probleme mit FastCgiExternalServer

      Edgar Ehritt
      – Informationen zu den Bewertungsregeln

      Hallo Jörg,

      | Alias                        /script                /home/eddi/fcgi
      | FastCgiIpcDir                /tmp
      | FastCgiExternalServer        /home/eddi/fcgi        -socket /tmp/php.sock

      | Um so erstaunlicher war für mich, dass folgende Konfiguration für ein einzelnes Script erfolgreich ist:
      | FastCgiExternalServer /home/eddi/public_html/test/info.php -socket /tmp/php.sock

      Wieso findest Du das erstaunlich? Du sagst Apache (mittels Alias), dass er alle Anfragen die über /script kommen, mit dem Programm "info.php" verarbeiten soll - deswegen wird das logischerweise auch ausgeführt.

      ach ja? Wo?
      Das Problem ist derzeit nur, das ich nicht mehr rekonstruieren kann, wie der Server konfiguriert war, das die letzte Zeile lief. Sonst hätte ich eine komplett adäquate Lösung, die auch ErrorDocument-handling einschließt.

      Du gibst einen Prozess an, der sämtliche Anfragen an den Webserver über bestimmte Urls entgegennehmen soll.
      Das Programm selbst (Dein fcgi bzw. info.php) hat mit PHP und Webserver-Konfigurationen erstmal nichts zu tun.

      Zunächst gibt man ein Programm an. Da ist der entscheidende Punkt. info.php ist kein Programm - hat nicht mal ein shebang. Auch die oben stehende Konfiguration zeigt ins Leere. /home/eddi/fcgi existiert gar nicht. Zum Verständnis genau dieser Details hatte ich aber auf die FAQ verwiesen.

      Bei Deiner ersten Konfiguration, würde also ein
      http://..../script?bla=blubb
      dazu führen, dass das Kommando
      /home/eddi/fcgi
      mit dem Parameter "bla" aufgerufen wird.

      Jain sage ich mal dazu. Entschieden nein dazu, das da gar nichts aufgerufen werden kann und, wie oben konfiguriert ein Unix Socket zur Prozesskommunikation genutzt wird. Und ein Parameter ist es ja in dem Sinne auch nicht, es ist das Adäquat zu einer Umgebungsvariable QUERY_STRING, was mittels Protokoll übergeben wird.

      Wenn nun andere PHP-Dateien includet werden sollen, muss Dein Programm (/home/eddi/fcgi) so gebaut sein, dass es aus den Parametern/der URL erkennen kann, wo es die PHP-Dateien herbekommt.

      Da drückt mir ganz und gar nicht der Schuh.

      Wie auch immer, danke trotzdem!
      eddi

      --
      (v0.0.3 - also ganz der alte ;)
      Beitrag melden
      –
      Informationen zu den Bewertungsregeln