Definieren von PHP in VirtualHost

[kos]

Hallo,

jaja mal wieder ein PHP Thema das wohl scohn des öfteren durchgekaut wurde.
Meine Kostellation sieht wie folgt aus, auf einem Debian (mittlerweile Etch) Server läuft Confixx, PHP4, Apache 2.2 mit mod_php (libapache2-mod-php4).
Nun ist mein Vorhaben, gezielt für speziefische VirtualHosts (durch eintrag der httpd-Specials in Confixx) PHP5 zu aktivieren. Hierbeit soll allerdings auch der normale Type .php ersetzt werden, so das nicht alle Dateien in .php5 umbenannt werden müssen.
Andererseits möchte ich natürlich auch nicht manuell für jeden anderen User in Confixx einen httpd-Eintrag für PHP4 erstellen.

Da "php5" und oder "libapache2-mod-php5" nicht durch den Paktmanager installiert werden kann, ohne das PHP4 deinstalliert wird, habe ich mir gedacht "php5-cgi" zu nutzen, welches sich neben den anderen Paketen wie php5-common und php5-mysql ohne Probleme installieren lassen.

Gesagt getan, ich habe also einen httpd-Eintrag (innerhalb des VirtualHost) in dieser Form erstellt und Apache neu gestartet:

Code: Select all

AddType application/x-httpd-php5 .php
Action application/x-httpd-php5 "/usr/bin/php5"

In dieser Variante sagte mit mein Apache schlichtweg "404 Not found". Also habe ich es mal wie in diversen Anleitungen beschrieben dochmal hiermit versucht:

Code: Select all

AddType application/x-httpd-php5 .php
ScriptAlias /php5 "/usr/bin/php5"
Action application/x-httpd-php5 "/php5"

Davon lies sich Apache aber auch nicht sonderlich beeindrucken sonder lieferte mir kurzerhand die Testdatei phpinfo.php als Downlad aus. (jedoch mit 0 Byte)
Mal von der Tatsache abgesehen das ich nicht verstehe warum man dem Action zwangsweise einen ScriptAlias definieren muss (der wohl in der Regel auf ein Verzeichnis, in diesem Fall von mir aber auf die Datei direkt verweist) um das ganze an das bin zu übergeben.

Die Frage ist nun zum einen, kann man zum einen die AddType "einfach so" innerhalb eine VirtualHost definieren oder überschreiben?
Und zum anderen, wie kann ich das nun bewerkstelligen was ich vorhabe, bzw. was habe ich vergessen?

Ich möchte nur ungern auf mod_php4 verzichten und auch nicht php5 global freigeben, aus den oben genannten Grund. Später möchte ich auch gern mod_php5 nutzen und damit mod_php4 ablösen, dort aber ggf. den spieß wie ich es jetzt mit php5 vorhabe umdrehen.
Sollten noch Fragen offen sein, versuche ich diese gern zu beantworten.

[Roger Wilco]

Code: Select all

ScriptAlias /php5-cgi "/usr/bin/php5" # HINT: Bist du dir sicher, dass das der richtige Pfad ist? ;)
Action php5-cgi /php5-cgi
AddHandler php5-cgi .php

Mal von der Tatsache abgesehen das ich nicht verstehe warum man dem Action zwangsweise einen ScriptAlias definieren muss (der wohl in der Regel auf ein Verzeichnis, in diesem Fall von mir aber auf die Datei direkt verweist) um das ganze an das bin zu übergeben.

Der Grund steht in der Beschreibung zu der Direktive unter http://httpd.apache.org/docs/2.2/mod/mo ... criptalias.

Die Frage ist nun zum einen, kann man zum einen die AddType "einfach so" innerhalb eine VirtualHost definieren oder überschreiben?

http://httpd.apache.org/docs/2.2/mod/mo ... ml#addtype -> Context.

[kos]

Code: Select all

ScriptAlias /php5-cgi "/usr/bin/php5" # HINT: Bist du dir sicher, dass das der richtige Pfad ist? ;)
Action php5-cgi /php5-cgi
AddHandler php5-cgi .php

Ich gehe mal davon aus, wenn das Commando "/usr/bin/php5 -v" etwas wie dieses ausgibt

Code: Select all

PHP 5.2.0-8+etch10 (cli) (built: Jan 18 2008 18:52:58)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies

das dies der korrekte Pfad ist. Oder wie meinst du das genau, das es wirklich nur ein Verzeichnis sein darf?

Also ich hab es jetzt mal anstatt dem AddType, wie du es gemacht hast mit AddHandler versucht. Nun bietet er es wenigstens nicht mehr zum Download an, sonder stellt einfach nur den selben inhalt (also nichts) im Browser dar. Das werte ich schonmal als verbesserung.

Wenn ScriptAlias nur ein Verzeichnis sein darf, wie soll ich dann verhindern das jemand etwas anderes ausser das php5 ausführt. Wobei, eigentlich soll ja garkeiner Zugriff auf die php5 Binaries haben, ausser der Apache zum Parsen.
Achja, und ich hab folgendes auch mal versucht, ist aber das selbe ergebnis wie wenn ich ScriptAlias direkt auf die Datei setzte.

Code: Select all

ScriptAlias /php5-cgi "/usr/bin/"
Action php5-cgi /php5-cgi/php5
AddHandler php5-cgi .php

Oder muss jetzt zudem trozdem noch ein AddType genutzt werden? Sorry für meine nicht so fortschrittliches wissen :roll:

[Roger Wilco]

Ich gehe mal davon aus, wenn das Commando "/usr/bin/php5 -v" etwas wie dieses ausgibt

Code: Select all

PHP 5.2.0-8+etch10 (cli) (built: Jan 18 2008 18:52:58)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies

das dies der korrekte Pfad ist.

Dann schau doch mal, was in den Klammern hinter der Versionsangabe steht oder welche Dateien überhaupt in dem Paket php5-cgi enthalten sind...

Oder wie meinst du das genau, das es wirklich nur ein Verzeichnis sein darf?

Nein, es muss schon der vollständige Pfad zu dem PHP-Interpreter (CGI) sein.

[kos]

Dann schau doch mal, was in den Klammern hinter der Versionsangabe steht oder welche Dateien überhaupt in dem Paket php5-cgi enthalten sind...

Du Spielst jetzt drauf an, das php5 die cli Version ist, aber ich bin ja nicht unbedingt ganz so blöd wie ich mich manchmal verhalte und hab es daher ja vorher auch mit /usr/bin/php5-cgi versucht, welches ja auch meiner Meinung nach korrekt diese Ausgabe zurück gibt:

Code: Select all

PHP 5.2.0-8+etch10 (cgi-fcgi) (built: Jan 18 2008 18:39:55)

Wie gesagt sowohl als auch habe ich getestet, das Ergebnis ist das selbe: leere Seite.

[Roger Wilco]

Du Spielst jetzt drauf an, das php5 die cli Version ist

Korrekt.

aber ich bin ja nicht unbedingt ganz so blöd wie ich mich manchmal verhalte und hab es daher ja vorher auch mit /usr/bin/php5-cgi versucht

In deinen Posts hast du auf jeden Fall konsequent das falsche Binary verwendet.

[kos]

aber ich bin ja nicht unbedingt ganz so blöd wie ich mich manchmal verhalte und hab es daher ja vorher auch mit /usr/bin/php5-cgi versucht

In deinen Posts hast du auf jeden Fall konsequent das falsche Binary verwendet.

Ist absolut korrekt und nehme ich auch so zur Kenntnis. Dennoch ändert es nichts am Stauts. ;)

Habe aber eben nochmal die Logs geprüft und mir ist da ein interessanter Fehler aufgefallen.
/var/log/apache2/error.log:

Code: Select all

[Thu Mar 13 13:02:15 2008] [error] [client xx.xx.xx.xx] suexec policy violation: see suexec log for more details
[Thu Mar 13 13:02:15 2008] [error] [client xx.xx.xx.xx] Premature end of script headers: php5-cgi

/var/log/apache2/suexec.log

Code: Select all

[2008-03-13 13:02:44]: uid: (1004/web2) gid: (1004/1004) cmd: php5-cgi
[2008-03-13 13:02:44]: command not in docroot (/usr/bin/php5-cgi)

Hm ... also daraus schließe ich, das er php5-cgi es irgendwo innerhalb von "/var/www/web2/html" erwartet, da "DocumentRoot /var/www/web2/html".
Ich denke da eventuell an ein Symlink? Aber muss es denn in web2/html sein, kann man das dann nicht ggf. auch in web2/php oder so legen, oder ein gemeinsames Verzeichnis für alle webs (sofern natürlich die Regelung in VirtualHost sitzt)

[Roger Wilco]

Hm ... also daraus schließe ich, das er php5-cgi es irgendwo innerhalb von "/var/www/web2/html" erwartet, da "DocumentRoot /var/www/web2/html".

Eher unterhalb von /var/www. Schau dir doch einfach die Ausgabe von `suexec -V` oder `suexec2 -V` an.

Ich denke da eventuell an ein Symlink?

Das mag suexec nicht.

[kos]

Eher unterhalb von /var/www. Schau dir doch einfach die Ausgabe von `suexec -V` oder `suexec2 -V` an.

Das hatte ich auch eben festgestellt.

Ich denke da eventuell an ein Symlink?

Das mag suexec nicht.

Hm das hab ich auch festgestellt. Da kommt ein schlichtes:
[2008-03-13 13:22:05]: cannot stat program: (php5-cgi)

Alternative `cp /usr/bin/php5-cgi /var/www/php5-cgi/` (einschließlich der Pfadanpassung des ScriptAlias) wirft dies aus:
[2008-03-13 13:25:27]: target uid/gid (1004/1004) mismatch with directory (0/0) or program (0/0)

Vielleicht noch eine Idee?

[Roger Wilco]

2 Möglichkeiten:
1. SuExec deaktivieren.
2. Wrapperskript für den PHP-Interpreter mit den korrekten Rechten und im richtigen Verzeichnis erstellen.

Alternativ kannst du auch SuPHP installieren und PHP5 darüber einbinden.

[kos]

Hm SuExec will ich nicht wirklich deaktivieren.
Naja das mit dem kopiern der Datei wäre ja auch nur ne Quick&Dirty Lösung, da ja bei einem (Security)Update von PHP dann manuell alle Dateien austauschen (oder per Script, aber das müsste auch manuell angestoßen werden).
Eine Möglichkeit hab ich noch gelesen, SuExec neu zu compilieren und dabei die Prüfung auf die Rechte der Datei entfernen. Aber das finde ich, ist auch ne fragliche maßnahme.

Was SuPHP angeht, da hab ich an diversen Stellen gelesen das dies nicht sehr Performant sei und viel Resourcen frisst bzw. recht langsam wäre?

[Roger Wilco]

Naja das mit dem kopiern der Datei wäre ja auch nur ne Quick&Dirty Lösung, da ja bei einem (Security)Update von PHP dann manuell alle Dateien austauschen (oder per Script, aber das müsste auch manuell angestoßen werden).

Mit einem Wrapperskript umgehst du dieses Problem.

Eine Möglichkeit hab ich noch gelesen, SuExec neu zu compilieren und dabei die Prüfung auf die Rechte der Datei entfernen.

Dann kannst du das mit SuExec auch gleich sein lassen.

Was SuPHP angeht, da hab ich an diversen Stellen gelesen das dies nicht sehr Performant sei und viel Resourcen frisst bzw. recht langsam wäre?

SuPHP ist einfach nur ein "erweitertes" SuExec. Die Performance ist also die gleiche, wie bei deinem angestrebten Setup. Schneller wird es nur mit FastCGI oder eben als Apache-Modul.

[kos]

Mit einem Wrapperskript umgehst du dieses Problem.

Einen Wrapper hab ich bisher noch nicht geschrieben, daher also keine Erfahrung damit.

SuPHP ist einfach nur ein "erweitertes" SuExec. Die Performance ist also die gleiche, wie bei deinem angestrebten Setup. Schneller wird es nur mit FastCGI oder eben als Apache-Modul.

Gut dann werde ich mir wohl mal das eine oder andere SuPHP HowTo ansehen.

Hab vielen Dank! Bin auf jeden Fall schonmal weiter. Sobald ich einer Möglichkeit gefolgt bin, meld ich mich nochmal.

[kos]

So ich hab jetzt nochmal ein paar Seiten im Netz gelesen und bin jetzt am grübeln, was wohl sinnvoller wären.
SuPHP oder mit dem libapache2-mod-fcgid in verbindung mit SuExec.'

Wie sieht das denn z.B. mit Variablen wie PHP_AUTH_USER die ja prinzipiell nur mit libapache2-mod-php* funktionieren. In Verbindung mit SuPHP habe ich gelesen, funktioniert das ebenfalls. Klappt das auch mit mod-fcgid?

[Joe User]

funktioniert das ebenfalls. Klappt das auch mit mod-fcgid?

Ja, zudem ist fcgid erheblich schneller als suphp.

[kos]

Ist schon jemandem ein vollständiges HowTo für die Installation mit fcgid in Etch (ggf. in Verbindung mit Confixx 3.3) unter berücksichtigung der verfügbaren Pakete bekannt?
Unter debianhowto.de ist nur ein Beitrag angefangen, jedoch noch nichts von der Installation.