Funktioniert suexec/fcgi nicht mit mod-rewrite?

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von Beme, 22. Nov. 2009.

  1. Beme

    Beme New Member

    Hallo!

    Mir ist aufgefallen, dass laut Prozessliste suexec/fcgi nur funktioniert, wenn die PHP-Skripte direkt im Docroot des Webs abgelegt sind. Wenn nicht, wird PHP offenbar direkt von www-data ausgeführt.

    Beispiel:

    Code:
    www1:/# ps faux
    root     21033  0.0  0.3 161208  7412 ?        Ss   13:28   0:00 /usr/sbin/apache2 -k start
    root     23498  0.0  0.3  39088  6884 ?        S    13:53   0:00  \_ vlogger (access log)
    www-data 23499  0.0  0.1 160364  3956 ?        S    13:53   0:00  \_ /usr/sbin/apache2 -k start
    www-data 23500  0.0  0.1 160704  3976 ?        S    13:53   0:00  \_ /usr/sbin/apache2 -k start
    web6     23768  1.1  2.9 205204 62248 ?        S    13:53   0:00  |   \_ /usr/bin/php-cgi -d open_basedir=/var/www/clients/client3/web6 -d upload_tmp_dir=/var/www/clients/client3/web6/tmp -d session.save_pat
    web60    23817  4.0  1.2 178156 26148 ?        S    13:55   0:00  |   \_ /usr/bin/php-cgi -d open_basedir=/var/www/clients/client2/web60 -d upload_tmp_dir=/var/www/clients/client2/web60/tmp -d session.save_p
    www-data 23501  0.0  0.3 591460  8084 ?        Sl   13:53   0:00  \_ /usr/sbin/apache2 -k start
    
    Bei web6 und web60 ist es so, dass die Domains direkt ohne Redirect auf das Docroot zeigen, d.h. die PHP-Dateien liegen direkt in /var/www/clients/client2/web60/web und /var/www/clients/client3/web6/web.

    Bei den meisten anderen Webs habe ich eine Ordnerstruktur unterhalb von "web" angelegt, auf diese verweisen dann mittels mod-rewrite (also in ISPConfig mit redirect L) Subdomains und Aliasdomains. Die Unterordner und Dateien bekommen natürlich die passenden Userrechte. Bsp.:
    Code:
     RewriteCond %{HTTP_HOST}   ^subdomain1.beispiel.de [NC]
    RewriteRule   ^/(.*)$ /var/www/clients/client1/web15/web/subdomain1/$1  [L]
    Die PHP-Skripte in diesen Unterordnern werden offenbar nicht via suexec gestartet! Wenn ich den apache per "ps" oder "top" beobachte, werden beim Aufruf solcher Seiten keine Apache-Instanzen mit dem entsprechenden User gestartet. Es funktioniert scheinbar nur, wenn kein mod_rewrite dazwischen sitzt.


    Ist das ein normales Verhalten? Beißen sich suexec und mod_rewrite?

    Komischerweise habe ich aber trotzdem keine Rechteprobleme z.B. beim Uploaden von Dateien in denjenigen Domains, die scheinbar nicht mit suexec laufen (dabei sind Joomla, Typo3, Wordpress etc.; Funktioniert alles bestens).

    Vielleicht hat ja jemand von Euch Ideen. Mir wäre es nämlich Recht, wenn wirklich alles unter suexec laufen würde.

    Viele Grüße,
    Benjamin
     
    Zuletzt bearbeitet: 22. Nov. 2009
  2. Till

    Till Administrator

    Das ist normelaerweise nicht so. Ich vermute mal, Du hast da irgendwo in einem Unterverzeichnis eine .htaccess Dateim die den PHP handler überschreibt und das fcgi-pho mit mod_php überschreibt.
     
  3. Beme

    Beme New Member

    Hm, das kann ich definitiv ausschließen, außerdem ist mod_php bei mir gar nicht mehr aktiviert. Der einzige Unterschied zum Debian-Howto: Ich habe den apache-worker installiert.

    aktivierte Module:
    Code:
    actions alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi cgid dav dav_svn deflate dir env fcgid include mime negotiation rewrite setenvif ssl status suexec suphp
    Eigentlich bleibt dem gar nichts anderes übrig als für PHP über fcgi zu gehen.

    Habe es jetzt gerade nochmals getestet. Nachdem ich eine Seite aus dem Unterordner "cms" in das docroot verschoben und in ISPConfig den Redirect deaktivert habe, funktioniert alles wie es soll und ein Prozess für den entsprechenden User wird (nach erneutem Aufruf) in Reserve gehalten:
    Code:
    root     25478  0.0  0.3 161064  7204 ?        Ss   Nov22   0:02 /usr/sbin/apache2 -k start
    root      5133  0.0  0.3  39088  6888 ?        S    05:04   0:00  \_ vlogger (access log)
    www-data  5134  0.0  0.1 160352  3752 ?        S    05:04   0:00  \_ /usr/sbin/apache2 -k start
    www-data  5135  0.0  0.1 160560  3784 ?        S    05:04   0:00  \_ /usr/sbin/apache2 -k start
    web23     5456  0.5  1.5 178768 32872 ?        S    05:04   0:01  |   \_ /usr/bin/php-cgi -d open_basedir=/var/www/clients/client4/web23 -d upl
     
    Zuletzt bearbeitet: 24. Nov. 2009
  4. Till

    Till Administrator

    Du kannst es ja mal im Bugtracker zusammen mit den geneuen Detials posten, also wie genau due eine Domain weitergeleitet hast, dann können wir das mal testen.
     
  5. Beme

    Beme New Member

    Hallo Till!

    Ich denke, habe den Fehler gefunden!
    So sieht ja der Standard suexec/FastCGI-Eintrag in der jeweiligen config des Webs aus:

    Code:
         # suexec enabled
        SuexecUserGroup web10 client1
        # php as fast-cgi enabled
        <Directory /var/www/domain.de/web>
            AddHandler fcgid-script .php .php3 .php4 .php5
            FCGIWrapper /var/www/php-fcgi-scripts/web10/.php-fcgi-starter .php
            Options +ExecCGI
            AllowOverride all
            Order allow,deny
            Allow from all
        </Directory>
    Damit der php-fcgi-starter aber auch bei redirects auf Unterverzeichnisse korrekt aufgerufen wird und die FastCGI-Prozesse nicht sofort wieder beendet werden, muss auch noch das eingefügt werden:
    Code:
    <Directory /var/www/clients/client1/web10/web>
            AddHandler fcgid-script .php .php3 .php4 .php5
            FCGIWrapper /var/www/php-fcgi-scripts/web10/.php-fcgi-starter .php
            Options +ExecCGI
            AllowOverride all
            Order allow,deny
            Allow from all
        </Directory>
    Suexec funktioniert zwar auch ohne den Eintrag, aber das Skript wird sonst nicht aufgerufen.

    Also nochmal, ohne zusätzlichen Eintrag ist die Ausgabe von ps faux während dem Aufruf:
    Code:
    web10    18752  1.1  0.8 254436 18340 ?        S    10:12   0:03  |   \_ /usr/bin/php-cgi 
    und der Prozess wird gleich nach dem Aufruf wieder gelöscht!

    Mit zusätzlichem Eintrag ist die Ausgabe dann:
    Code:
    web10    18752  0.8  0.8 254436 18340 ?        S    10:12   0:03 /usr/bin/php-cgi -d open_basedir=/var/www/clients/client1/web ...........
    und der Prozess wird für PHP_FCGI_MAX_REQUESTS vorgehalten.

    Gruß
    Benjamin
     
  6. Till

    Till Administrator

    Ich habs in den Bugtracker mit aufgenommen.

    Hast Du mal versucht, alternativ satt:

    Code:
         # suexec enabled
        SuexecUserGroup web10 client1
        # php as fast-cgi enabled
        <Directory /var/www/domain.de/web>
            AddHandler fcgid-script .php .php3 .php4 .php5
            FCGIWrapper /var/www/php-fcgi-scripts/web10/.php-fcgi-starter .php
            Options +ExecCGI
            AllowOverride all
            Order allow,deny
            Allow from all
        </Directory>
    einfach nur:

    Code:
         # suexec enabled
        SuexecUserGroup web10 client1
        # php as fast-cgi enabled
        AddHandler fcgid-script .php .php3 .php4 .php5
        FCGIWrapper /var/www/php-fcgi-scripts/web10/.php-fcgi-starter .php
        Options +ExecCGI
    
    zu nehmen? Also dass der fcgi wrapper direkt im vhost aktiviert wird und nicht innerhalb eines directory Eintrages? Ich weiß, dass addhandler direkt in vhost zulässig ist, konnte aber auf die Schnelle nicht finden, ob FCGIWrapper auch ohne directory drum herum definiert werden kann. Denn dann würde sich die Konfiguration auf den ganzen vhost auswirken und der 2. von Dir vorgeschlagene Eintrag wäre vermutlich nicht notwendig.
     
  7. Beme

    Beme New Member

    Hallo Till,

    leider scheint das nicht zu funktionieren, beim Aufruf von PHP-Dateien erhalte ich bei Deinem Vorschlag, die Directory-Direktive wegzulassen, einen 403 Forbidden.

    Ich habe auch mal ausprobiert ob nur die eine Directory-Direktive mit dem vollen Pfad ausreicht:
    Code:
    <Directory /var/www/clients/client1/web10/web>
    ...
        </Directory>
    Dies ist aber nicht der Fall! Denn dann werden die Skripte von webs, die ohne Redirect angelegt wurden und direkt im Hauptverzeichnis liegen, nicht über den korrekten Wrapper gestartet.
     
    Zuletzt bearbeitet: 27. Jan. 2010
  8. Till

    Till Administrator

    Ok. Dann kommt es halt zukünftig doppelt in die vhost Konfiguration, einmal für den real path und einmal für den symliked path.
     

Diese Seite empfehlen