# Funktioniert suexec/fcgi nicht mit mod-rewrite?



## Beme (22. Nov. 2009)

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:


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

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


----------



## Till (23. Nov. 2009)

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.


----------



## Beme (24. Nov. 2009)

Zitat von Till:


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


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:

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

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


----------



## Till (24. Nov. 2009)

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.


----------



## Beme (27. Jan. 2010)

Hallo Till!

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


```
# 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:

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

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

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


----------



## Till (27. Jan. 2010)

Ich habs in den Bugtracker mit aufgenommen.

Hast Du mal versucht, alternativ satt:


```
# 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:


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


----------



## Beme (27. Jan. 2010)

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:

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


----------



## Till (27. Jan. 2010)

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.


----------

