Nachdem ich heute ne Weile darueber gegruebelt habe, wie ich unter Debian Lenny und suphp sowohl meine vhosts unter /var/www zum laufen bekomme, als auch das phpmyadmin, welches apt nach /usr/share installiert wurde zum laufen zu bekommen kam ich auf folgende Konfigurationsanpassung.
Diese ist noetig, da suPHP aus Sicherheitsgruenden die Ausfuehrung von php Dateien die z.B. root gehoeren und/oder ausserhalb /var/www liegen, Verweigert.
Debian bereitet die /etc/apache2/mods-available/suphp.conf schon richtig vor, im Verzeichniss /usr/share ist suphp also abgeschaltet. Nun hilft es leider nicht, einfach mod_php hinzu zuladen.
Vorher muss man die config des su_php leicht umschreiben nach folgendem Muster:
in der Datei /etc/suphp/suphp.conf die Zeile:
application/x-httpd-php=php:/usr/bin/php-cgi
in:
application/x-httpd-suphp=php:/usr/bin/php-cgi
aendern. Also ein “su” in den apptype hinzufuegen.
Ebenso in der Datei /etc/apache2/mods-available/suphp.conf:
AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml
suPHP_AddHandler application/x-httpd-php
in:
AddType application/x-httpd-suphp .php .php3 .php4 .php5 .phtml
suPHP_AddHandler application/x-httpd-suphp
aendern. Hier also 2 Zeilen zu aendern.
Nun kommen sich die beiden php Arten nicht mehr in die Quere und man kann mit a2enmod php5 modphp wieder zuschalten, sofern man dies noch nicht getan hat.
Mit dieser Aenderung sollte jedes Zentral per apt installiertes script funktionieren, solange nicht vergessen wird, fuer den vhost oder alias die suphp engine abzuschalten, solange es sich nicht in /usr/share befindet.
Warum Debian dies nicht gleich so macht, ist mir allerdings ein Raetsel.
Uebrigens: ich hatte waehrend meiner Tests nen wunderbaren Bug im Firefox gefunden. Bot dieser einmal bei einem alias wie /phpmyadmin/ die index.php zum download an, weil noch kein handler installiert war, cached diese diese Information. Man kann am Server nun konfigurieren was man will…