[HowTo] PHP4/PHP5 als CGI - gepatcht (deutsches HowTo)

  • Thread starter Thread starter server4downs
  • Start date Start date
Hallo,

Erstmal vielen Dank für das HowTo.


Nun zu meinem Problem :)


Hat soweit alles super geklappt.


Code:
/usr/bin/php4# ./php -v
PHP 4.4.7 (cgi) (built: May 25 2007 18:05:23)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

Wie man sieht hab ich das ganze mit php4 gemacht.

Beim Apache restart kommt folgendes

Code:
Syntax error on line 8 of /etc/apache2/httpd.conf:
Invalid command 'Action', perhaps misspelled or defined by a module not included
 in the server configuration
 failed!

So sieht es in meiner httpd.conf aus


Code:
<Directory "/usr/bin/php4">
AllowOverride None
Options +ExecCGI +FollowSymLinks
Order allow,deny
Allow from all
</Directory>
ScriptAlias /php4rocks /usr/bin/php4
Action php4-cgi application/php4rocks/php
AddType application/php4-cgi .php4

Die error.log

Code:
[Fri May 25 18:15:18 2007] [notice] caught SIGTERM, shutting down


Mein System:

Debian Etch
Apache 2.2.3
Confixx 3.3
 
Du musst das Modul "action" aktivieren. Dann sollte es gehen.
Google ist dein Freund ;)
 
Danke.. :)


Es war schon spät :D


EDIT:

Hab das ganze mal auf nem Suse System getestet.

Auch alles wunderbar. ABer wenn ich jetzt z.B die Datei php.php4 aufrufe...

erhalte ich eine weiße Seite.

error.log

Code:
[Mon May 28 14:02:10 2007] [warn] Cannot get media type from 'php4-cgi'
[Mon May 28 14:02:10 2007] [error] [client XXX.XXX.XX.XXX] Premature end of script headers: php


System:

SuSe 10.1
Confixx 3.2
 
Last edited by a moderator:
Hallo.

Also "Cannot get media type from 'php4-cgi'" hat nicht viel zu sagen. Einfach in httpd.conf ErrorLevel auf error stellen.
Schau bitte mal in die suexec.log. Die sollte mehr erzählen.

Bist du den kompletten HowTo-Thread hier schon durchgegangen? Eigentlich sollten hier alle Probleme bereits beschrieben und gelöst worden sein!

Schöne Grüße aus Florida!
 
Habe die Anleitung soweit befolgt...wenn ich die Datei über den Browser ansteuer, wird die aber nicht gefunden. Die error_log spuckt folgendes aus:

[Mon Jun 04 12:52:46 2007] [error] [client xxx.xxx.xxx.xxx] File does not exist: /usr/local/php5/info.php5

Wieso sucht er die Datei in dem Verzeichnis?

Konfiguration ist Plesk + Apache2.

Was hab ich falsch gemacht?
 
PHP4 mit openbasedir Patch in suPHP

Also auf meinem Server läuft PHP4 als suphp und PHP5 als gepatchtes FCGI, wie hier im Thread angegeben.
suPHP deshalb, weil der Application Pack von Confixx suphp braucht.

Hier fällt ja nun leider das open_basedir weg.

Das möcht ich aber ganz gern wieder haben ;-)

Kann ich PHP4 einfach wie hier im Forum angegeben neu kompilieren und das open_basdir patchen und das dann in suPHP verwenden?

Oder gibts es Gründe das nicht zu tun?
 
Hallo Raufi.

Vergess dieses HowTo für deine Zwecke bitte.


sollte dir mehr helfen.

Du brauchst in diesem Falle keine open_basedir anzugeben/zu patchen. Das wird alles durch Confixx erledigt, da jeder User seine eigene php.ini erhalten wird.
 
Hallo

Also ich komme auch nicht weiter, hab die Anleitung zur installieren von php5 befolgt und dann suexec wie in dem anderen Thread beschrieben neu kompiliert.

Also mein System:
Apache/2.0.53 (Linux/SUSE)
SuSE Linux 9.3 Professional inkl. Plesk 8.1

Wenn ich eine php5 Datei ausführe kriege ich den Fehler:
Premature end of script headers: php

Ist ja nicht selten das man das hier sieht.

Ausgabe von suexec2 -V:
Code:
 -D AP_DOC_ROOT="/usr/bin/php5"
 -D AP_GID_MIN=100
 -D AP_HTTPD_USER="wwwrun"
 -D AP_LOG_EXEC="/var/log/apache2/suexec.log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=100
 -D AP_USERDIR_SUFFIX="public_html"

und die vhost.conf von dem entsprechend eingerichtetem Space:
Code:
<Directory "/usr/bin/php5">
AllowOverride None
Options +ExecCGI +FollowSymLinks
Order allow,deny
Allow from all
</Directory>
ScriptAlias /php5-cgi /usr/bin/php5
Action application/php5-cgi /php5-cgi/php
AddType application/php5-cgi .php5

Hab auch schon gegoogelt und komm einfach nicht weiter.

Hat jemand noch eine Idee?
Wenn mehr Informationen benötigt werden kann ich diese nachliefern.
 
Hallo.

Was sagt der suexec Log?
Da stehen die interessanten Meldungen ;)
 
In der suexec.log steht folgendes zu verschiedenen Zeiten:

Code:
[2007-07-22 00:48:11]: uid: (10004/djrecall) gid: (10001/10001) cmd: php
[2007-07-22 00:48:11]: uid: (10004/djrecall) gid: (10001/10001) cmd: php
[2007-07-22 00:48:12]: uid: (10004/djrecall) gid: (10001/10001) cmd: php
[2007-07-22 00:48:40]: uid: (10004/djrecall) gid: (10001/10001) cmd: php
[2007-07-22 00:58:19]: uid: (10004/djrecall) gid: (10001/10001) cmd: php
[2007-07-22 00:58:20]: uid: (10004/djrecall) gid: (10001/10001) cmd: php
[2007-07-22 00:58:20]: uid: (10004/djrecall) gid: (10001/10001) cmd: php
[2007-07-22 00:58:25]: uid: (10004/djrecall) gid: (10001/10001) cmd: php
[2007-07-22 01:27:35]: uid: (10004/djrecall) gid: (10001/10001) cmd: php

Hilft mir aber irgendwie auch nicht weiter.
 
Debian / Plesk 8.2 / PHP5 als cgi

Hallo,

Als allererstes mal einen großen Reskpekt an den Macher dieses Threads, richtige coole Leistung. Nachdem ich mir diesen und ich glaube so 100 andere durchgelesen hatte um endlich php5 parallel zu php4 als cgi laufen zu lassen hab ich quasi eine IDEE kombiniert aus diesem Thread und einem aus dem Plesk Forum genutzt um dies quasi innerhalb von 2 Minunten zu bewerkstelligen, das wollte ich den Rest der evtl. mit gleicher Config wie ich, also Debian, Plesk 8.2 usw arbeitet, wissen lassen.

Man kann sagen das ist die Methode für faule bzw. Leute die nicht groß am System fummeln wollen.

1. Ins Plesk Control Panel gehen auf den "Updater" und "SiteBuilder and Sitebuilder module for Plesk" herunterladen.

Hintergrund: Dieser installiert das Plesk eigene php5-cgi binary mit.

2. suexec neu kompilieren wie in https://serversupportforum.de/threads/mini-howto-suexec-neukompilieren.2540/ beschrieben, allerdings mit den Anpassungen suexec.h:

Code:
#ifndef AP_HTTPD_USER
#define AP_HTTPD_USER "www-data"
#endif

Code:
#ifndef AP_LOG_EXEC
#define AP_LOG_EXEC "/var/log/apache2/suexec.log" /* Need me? */
#endif

Code:
#ifndef AP_DOC_ROOT
#define AP_DOC_ROOT "/var/www/vhosts"
#endif

besonders die letzte Änderung hier bewirkt das wir hinterher das php Binary im Pfad der jeweiligen Domain "/var/www/vhosts/domain.tld/bin" ausführen können ohne dass das File dem FTP-Benutzer gehören muss und wir trotzdem immernoch eine eigene "php.ini" pro Domain verwenden können.

Änderungen an der suexec.c (von Freel@ncer14):

Code:
    /*
     * Error out if the target name/group is different from
     * the name/group of the cwd or the program.
     */
    if ((uid != dir_info.st_uid) ||
        (gid != dir_info.st_gid) ||
        (uid != prg_info.st_uid) ||
        (gid != prg_info.st_gid)) {
        log_err("target uid/gid (%ld/%ld) mismatch "
                "with directory (%ld/%ld) or program (%ld/%ld)\n",
                uid, gid,
                dir_info.st_uid, dir_info.st_gid,
                prg_info.st_uid, prg_info.st_gid);
        exit(120);
    }

ändern in:

Code:
    /*
     * Error out if the target name/group is different from
     * the name/group of the cwd or the program.
     */
[COLOR="Red"]/* Disabled[/COLOR]
    if ((uid != dir_info.st_uid) ||
        (gid != dir_info.st_gid) ||
        (uid != prg_info.st_uid) ||
        (gid != prg_info.st_gid)) {
        log_err("target uid/gid (%ld/%ld) mismatch "
                "with directory (%ld/%ld) or program (%ld/%ld)\n",
                uid, gid,
                dir_info.st_uid, dir_info.st_gid,
                prg_info.st_uid, prg_info.st_gid);
        exit(120);
    }
[COLOR="Red"]*/[/COLOR]

3. Unter "/var/www/vhosts/domain.tld/conf/" oder "/var/www/vhosts/domain.tld/subdomain/name/conf" (falls Subdomain) eine vhost.conf mit folgendem Inhalt anlegen:

ScriptAlias /php5-cgi-custom /var/www/vhosts/domain.tld/bin
Action application/x-httpd-php5-custom "/php5-cgi-custom/php5"
AddType application/x-httpd-php5-custom .php

Wobei "domain.tld" natürlich zu ersetzen ist mit euren Daten. Ich habe mir wie man oben sieht unter "/var/www/vhosts/domain.tld/bin" die php5 binary abgelegt.

Das php5 binary was Ihr braucht befindet sich in "opt/php52/bin" und heißt "php5-cgi". Nach obigem Beispiel der vhost.conf also:

cp /opt/php52/bin/php5-cgi /var/www/vhosts/domain/bin/php5
cd /var/www/vhosts/domain
chown -R root.root bin/
chmod 755 bin/

Wer noch eine php.ini Datei "pro User" verwenden möchte, kopiert in den gleichen Pfad noch die entsprechende php.ini:

cp /opt/php52/etc/php5/cgi/php.ini /var/www/vhosts/domain/bin
cd /var/www/vhosts/domain/bin
chown root.root php.ini
chmod 644 php.ini

Damit das ganze nun greift, wie üblich bei Plesk einmal:

/opt/psa/admin/sbin/websrvmng -a -v

ausführen und die vhost.conf wird für die jeweilige Domain mit verwendet.

Die entsprechende php.ini für die CGI Version findet man unter "/opt/php52/etc/php5/cgi/" und kann diese gemäß seinen Vorstellungen anpassen.

Im Control Panel von Plesk sollte man schließlich noch php und cgi für die Domain aktivieren und schon läuft das ganze und zwar einfach ohne weiter etwas machen zu müssen, weder braucht man suexec noch php5 selbst kompilieren. Um das ganze wieder loszuwerden, also die Domain wieder unter php4 als mod laufen zu lassen einfach das jeweilige vhost.conf file löschen und nochmal

/opt/psa/admin/sbin/websrvmng -a -v

ausführen.


Wer möchte kann natürlich auch in dem vhost.conf file einfach die Zeile

AddType application/x-httpd-php5-custom .php

in

AddType application/x-httpd-php5-custom .php5

ändern und hat so den Effekt das alle php Dateien die mit .php5 enden mit der CGI Version ausgeführt werden, der rest mit php4 als mod.

Natürlich wird aufgrund der bereits vorhandenen SuExexUserGroup Direktive die Plesk ja anlegt (/var/www/vhosts/domain/conf/httpd.include) alles brav als der jeweils richtige Benutzer ausgeführt.

Im Endeffekt haben wir das gleiche was "server4downs" mit seinem Patch gemacht hat, allerdings wie ich finde auf einen etwas schnelleren weg, außerdem angepasst an Plesk ohne viel Aufwand. Zusätzlich können wir noch pro Domain eine php.ini benutzen (optional) was mit seiner Methode nicht möglich war, wobei das natürlich sicherlich realisierbar ist.

Im Anhang hier noch die angepasste suexec.h und suexec.c

Gruß nEUTRon.
 

Attachments

Last edited by a moderator:
ist es bei deinem Howto nicht so, das für jeden Benutzer die selbe php.ini benutzt wird? Ist das dann nicht käse, wenn alle z.B. als TMP das selbe Verzeichnis haben? Oder kann man dann mit individuellen Einstellungen in der vhost.conf auch diese Parameter beeinflussen? Oder habe ich da nen Gedankenfehler? :eek:
 
Ja ist richtig, für alle die gleiche php.ini, ich sagte ja, quick'n'dirty. Wenn jemand ne Idee hat wie man da noch ne eigene php.ini für jeden Benutzer hinkriegt, ich höre zu :)


EDIT: Kommando zurück, wenn man eine php.ini mit in das "/var/www/vhosts/domain/bin/" Verzeichnis kopiert, wird diese bevorzugt benutzt (automatisch).

Passe ich oben in der How-To an.
 
Last edited by a moderator:
Was mir gerade einfällt wo ich mir das alles nochmal durchlese, eigentlich braucht man doch mit dieser Methode den open_basedir patch gar nicht, da ich ja jedem Kunden einzeln per php.ini das korrekt open_basedir setzen kann. Da müsste aber mal "server4downs" sollte er diesen Thread noch lesen was zu sagen, kann auch sein das ich nen Denkfehler mache und Mist erzähle.
 
Hallo.
Theoretisch richtig, was du da sagst, jedoch sollte dann beachtet werden, dass die php.ini nicht dem FTP-Benutzer gehören sollte und nur eben Leserechte für alle Benutzer/Gruppen hat.
Ansonsten wäre das ja nicht ganz im Sinne des Erfinders, wenn der FTP-Benutzer die open_basedir und weitere Einschränkungen einfach wieder aufheben könnte.
 
Ok..also Vorteil an deiner Methode ist mit Sicherheit das durch den Patch die open_basedir Direktive in der vhost.conf oder ähnlichem wieder vorgenommen werden kann, wenn ich das richtig verstehe. Außerdem liegt das binary in /usr/bin mit root als Besitzer, was besagtes Problem eliminiert. Hab ich das soweit richtig verstanden? Korrigier mich wenn ich einen Denkfehler habe.

Das nun der FTP-Benutzer dem ja auch die Dateien "gehören" diese einfach ändern kann passt mir auch nicht, ist mir aber erst hinterher klar geworden. Wenn nun die php.ini root gehört und ich dort einen chmod 644 mache, kann zumindest der ftp benutzer diese Datei nicht verändern, jedoch, und das verstehe ich gerade nicht, löschen. Ich nehme an das liegt daran das der Ordner "bin" ja immernoch dem FTP-Benutzer mit der Gruppe psacln gehört, richtig? Dies kann ich allerdings nicht ändern, sonst gibts einen 500'er Error auf dem Indianer. Ebenso wenn das php Binary root gehört, 500'er.

Ich habe nun quasi einen kleinen Workaround in dem ich einen chmod 111 auf das bin/ verzeichnis gemacht habe, ergo NUR ausführen Rechte, ebenso hab ich dem php binary nur ein ausführen durch den Owner gestattet (chmod 100) und die php.ini gehört root mit 644, wobei die letzten beiden Sachen wahrscheinlich nicht nötig wären, den nun ist für den FTP-User das "bin" Verzeichnis einfach leer und er kann logischerweise auch "bin" nicht löschen.


Ist da nun irgendwo noch ein Sicherheitsrisiko bei oder könnte man das soweit verwenden?
 
Also das hat mir keine Ruhe gelassen :) Im Prinzip denke ich habe ich es nun geschafft das man das "bin" verzeichnis komplett root übereignen kann, somit kann kein normaler FTP-User mehr die php.ini oder das binary editieren, löschen oder Rechte ändern. Erreicht habe ich das dadurch das ich suexec wie in deinem anderen Thread neu kompilier habe, aber unter Punkt 6. habe ich nun:

Code:
#define AP_DOC_ROOT "/var/www/vhosts"

ansonsten noch die restlichen Änderungen die "Freel@ncer14" vorgeschlagen hatte (suexec ist Blöd usw ... :)).

Ich habe nun quasi (ohne auch nur deine Arbeit irgendwie schmälern zu wollen) das gleiche wie du erreicht aber mit dem Zusatz das

a) das PHP Binary samt .ini Datei geschützt ist
b) man OPTIONAL pro User eine eigene php.ini Datei haben KANN (und somit in dieser auch die open_basedir variable setzen kann)

Wenn du Zeit hast schau mal drüber, ich aktualisier mal mein kleines HowTo weiter oben, ob da nun irgendwie noch Denkfehler/Sicherheitsbedenken bestehen.
 
Hi

@server4downs
@Freel@ncer14
@neutron
erstmal danke euch 3 für die gute arbeit :)

mal ne frage bevor ich mich auch mal dran wage;)

wie kann ich das in plesk am besten realisieren, das jeder neue Kunde auch seine php.ini bzw. auch eine vhost.conf bekommt? Wie habt Ihr das gelöst?
Über den "event handler"?

Danke und Gruß
ACID25
 
Hallo.
Das ist leider hiermit nicht möglich. Da müsstest du auf suPHP zurückgreifen. Ein HowTo hierzu findest du z.B. hier:


Alles hat so seine Vor- und Nachteile. Sonst wäre die Welt ja auch langweilig.
Ich arbeite derzeit an einer besseren Lösung zur Einbindung von suPHP/FastCGI für Plesk (über das Controlpanel).
 
Back
Top