Apache2 + php5: fastCGI _ohne_ suexec?

[dev]

[Gelöst] Apache2 + php5: fastCGI _ohne_ suexec?

Moin,

ich bin gerade am Testen und Lesen, was PHP und den Apachen betrifft. Dabei hätte ich gerne eine soliden Kompromiss aus Schnelligkeit und Sicherheit. Auf dem Root laufen nur eigene Projekte (kein shared Host). OS: Debian Etch'n half, Apache2, php5-cgi

Folgendes konnte ich herausfinden:

1) mod-php5 fkt. nur mit dem Prefork-Apachen, ist schnell, aber offen wie ein Scheunentor
2) suPHP soll grottenlahm sein, dafür unkompliziert zu installieren
3) fCGI + suEXEC ist wohl so schnell wie 1), so sicher wie 2), aber aufwendiger zu konfigurieren

Da bin ich nun beim Knackpunkt: Ich habe es nicht geschafft, fcgi + suexec zum Laufen zu bringen. Die Skripte erzeugten immer einen 500er. Selbst nach dem Compilen von suEXEC mit eigenen Parametern - keine Chance. Irgendwo ist da noch ein Luschigkeitsfehler drin und ich finde ihn im Moment nicht.

Nun meine Frage: Funktioniert eigentlich PHP als fastCGI-Modul im mpm-worker auch ohne suEXEC? Also ohne Nachteil? Die Skripte laufen hier bei mir natürlich, nur kann ich nicht einschätzen, ob ich mir bis auf die Eigentümergeschichte keine anderen Nachteile einhandle?!

Danke,

/dev

 

[bibabu]

Hallo,

PHP + FastCGI benötigt immer suexec. Was steht im error / suexec log?

Du brauchst für jedes Projekt eine eigenes Starterscript. Dieses musst du dann als FCGIWrapper dem Apache2 mitteilen.

- libapache2-mod-fcgid installiert?
- php5-cgi installiert?

Wichtig sind die Rechte. Denn das Startscript sowie der Ordner in dem das Startscript liegt müssen dem Benutzer gehören. Daher du brauchst für jedes Projekt einen eigenen Ordner mit einem eigenen Startscript.

Beispiel:

/var/www
../web1/html
../web1/config
../web1/log
../web2/html
../web2/config
../web2/log

Die Startscripte kannst du dann einfach in dem Ordner config ablegen. Wichtig ist das du jedes Startscript durch "chattr -i startscript" unveränderbar machst.

Der Name des Startscripts darf im übrigen keinen Punkt enthalten.

- php5-starter => geht!
- php5-starter.sh => geht nicht!

I

 

[XioniX]

Was sagen die Logs nach einem Error 500? Meist sind die Eigentümer der Dateien nicht richtig gesetzt.

Wenn man php-cgi ohne suexec einsetzt hat man ja eigentlich schon den Hauptvorteil verspielt und man könnte auch getrost zu mod_php greifen.

 

[dev]

Liebe Leute,

danke für Eure Anteilnahme und Tips.

PHP + FastCGI benötigt immer suexec.

PHP läuft im Moment bei mir problemlos als FastCGI ohne suEXEC? Ich habe das Modul mit "a2dismod suexec" ganz deaktiviert...

Eure Fragen:

Ich habe mir vorher natürlich alle Dokus/Anleitungen zu Suexec angesehen und denke schon, dass ich alles im Überblick hatte (vor der Installation).

- libapache2-mod-fcgid installiert?
- php5-cgi installiert

Ja. Beides Mods sind auch enabled. In der VM-Box läuft diese Paketauswahl:

apache2.2-common (2.2.3-4+etch5)
apache2-mpm-worker (2.2.3-4+etch5)
apache2-threaded-dev (2.2.3-4+etch5)
libapache2-mod-fcgid (1:1.10-2)

Ein

a2enmod suexec
a2enmod fcgid

wurde ausgeführt.

Anschliessend habe ich das folgende PHP5 installiert:

php5-cgi (5.2.0-8+etch11

)

Die Verzeichnisstruktur habe ich natürlich erstellt und ein User wurde auch angelegt, für den die Verzeichnisse als 750 chmod'et' wurden. Das Starterscript existiert mit richtigem Namen, das immutable Bit ist auch gesetzt, die Seite ist unter "/etc/apache2/sites-available" per VHost eingebunden und aktiviert. Erstelle ich nun eine phpinfo.php und lege diese mit korrekten chmods in das html-Verzeichnis, springt laut error.log suexec auch an. Allerdings bekomme ich in der suexec.log das hier:

[2008-09-29 05:58:37]: uid: (1003/example) gid: (1004/1004) cmd: php-fcgi-starter
[2008-09-29 05:58:37]: (8)Exec format error: exec failed (php-fcgi-starter)

/dev

 

[bibabu]

Hallo,

zeig uns mal den Inhalt des Startscripts.

Im übrigen bringt dir FastCGI ohne suexec nicht wirklich etwas. Denn ohne suexec läuft php unter dem Benutzer des Webservers. Daher muss auch das Startscript und der Ordner darüber dem Benutzer des Webserver gehören.

Hooray: Das war mein 500er Beitrag ;-)

 

[dev]

Ok, alles klar. Dann wäre es ja toll, wenn ich Suexec zum Laufen bekomme, ich bin auch gerne bereit, noch einmal ein paar Stunden zu investieren *ächz*.

PHPRC="/srv/www/example.com/conf/"
export PHPRC
exec /usr/bin/php5-cgi

Aufgerufen wird es vom virtuellen Host:

<VirtualHost *>
ServerAdmin [email protected]
ServerName example.com
SuexecUserGroup example example
AddHandler fcgid-script .php
DocumentRoot "/srv/www/"
DirectoryIndex index.htm index.html index.php
LogLevel debug
ServerSignature On

<Directory "/srv/www/example.com/docs">
SetHandler fcgid-script
Options Indexes -MultiViews FollowSymLinks +ExecCGI
#FCGIWrapper /usr/bin/php-cgi .php
FCGIWrapper /srv/www/example.com/conf/php-fcgi-starter .php
Order allow,deny
allow from all
</Directory>

#ErrorLog /srv/www/example.com/logs/error.log
#CustomLog /srv/www/example.com/logs/access.log combined

</VirtualHost>

Dazu muss ich noch sagen, dass ich Suxec neu kompiliert habe, um meinen Pfad "/srv/www" benutzen zu können:

-D AP_DOC_ROOT="/srv/www"
-D AP_GID_MIN=100
-D AP_HTTPD_USER="www-data"
-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="/srv/www"

Rechte sind für die neue Binary so gesetzt:

28 -rwsr-xr-x 1 root root 24663 2008-09-29 02:08 /usr/lib/apache2/suexec

Ich kann keinen offensichtliche Fehler entdecken. Error by obfuscation sozusagen...

Vielleicht sollte ich mal die Default-Installation mit /var/www probieren

/dev

 

[combie]

1) mod-php5 fkt. nur mit dem Prefork-Apachen, ist schnell, aber offen wie ein Scheunentor
2) suPHP soll grottenlahm sein, dafür unkompliziert zu installieren
3) fCGI + suEXEC ist wohl so schnell wie 1), so sicher wie 2), aber aufwendiger zu konfigurieren

suPHP soll grottenlahm sein <<-- das halte ich für völlig überzogen
suEXEC ist wohl so schnell wie 1 <<-- auch das halte ich für ein Gerücht
Gibt es irgendwo Zahlen, welche das belegen?
Bzw. eine vergleichs Tabelle?

Bei mir kommt suPHP zum Einsatz und ich bin eigentlich rundrum zufrieden. Wenn da allerdings "richtig" was rauszuholen ist, würde ich evtl. umbauen.

 

[dev]

@combie: Ich bin bei meinen Recherchen auf Faktoren von 2x so langsam bis 5x so langsam gestossen (für suPHP). FastCGI ist etwas schneller. So richtig konkret ist das alles nicht.


Ich bin etwas weiter. Habe nun eine Default FCGI/SUXEC Installation des Apachen gemacht. SuEXEC bricht bei Aufruf des Wrappers ab.

Ich habe in diesen mal ein paar Syntaxfehler gebaut - das stört ihn gar nicht. SuEXEC meckert vorher schon:

[2008-09-29 08:22:48]: uid: (1004/myuser) gid: (1005/1005) cmd: php-fcgi-starter
[2008-09-29 08:22:48]: (8)Exec format error: exec failed (php-fcgi-starter)

Das heisst für mich, dass SuEXEC den Wrapper aufrufen will aber nicht ausführen kann. Ok, wie kann ich das Problem weiter eingrenzen?

/dev

 

[dev]

Ich kipp' um!

Habe den Fehler gefunden. Es fehlte die folgende Zeile in meinem Starter-Skript:

#!/bin/sh

Nun funktioniert es:

#!/bin/sh
PHPRC="/var/www/vhosts/projekt/conf/"
export PHPRC
exec /usr/bin/php5-cgi

Diese 9 Zeichen haben mich nun insgesamt 10 Stunden gekostet. Dafür habe ich 'ne Menge gelernt.

Frage nun: Bin ich zu doof oder ist das normal?

Erbitte mir ehrliche Antworten!

/dev

 

[marneus]

Du lernst laufen nur durch auf die Fresse fallen. Insofern alles "richtig" gelaufen

--marneus

 

[dev]

Na dann ist es ja gut, wenn es nicht nur mir so geht. Aber ich habe mittlerweile das Gefühl, dass man bei Linux öfters mal richtig auf den Deckel bekommt

Mittlerweile läuft es ausgezeichnet. Den Apache mit den Modi kriege ich nun innerhalb von 5-10 Minuten installiert. Ich habe die Konfiguration im Griff und innerhalb von ein paar Minuten auch die Webuser mitsamt den Ordnern, Wrapper und Inis auf der Konsole angelegt.

Nach dem ersten Rumprobieren muss ich sagen, das mir im Vergleich zu SuPHP die FCGI/SUEXEC Variante schneller vorkommt. Aber das ist subjektiv. Für mich auch neu ist das Ausführen der Skripte als User - keine "nicht löschbaren Dateien" mehr, ich finde es super.


Und mit der Kombination aus FastCGI/SuEXEC/PHP5-CGI mit Suhosin und ausschliesslichem SFTP Zugriff für die minderpriveligierten Webuser ist das Gesamtkonzept wohl einigermassen ok was die Sicherheit betrifft.


Danke für Eure Hilfe,

/dev

 

[Roger Wilco]

Nach dem ersten Rumprobieren muss ich sagen, das mir im Vergleich zu SuPHP die FCGI/SUEXEC Variante schneller vorkommt. Aber das ist subjektiv.

Nein, das ist i. d. R. nicht subjektiv. Mach dir doch einfach einmal den Unterschied klar: bei SuPHP wird für jeden Request ein neuer Interpreter gestartet, bei FastCGI gibt es persistente Prozesse, die über mehrere Requests laufen. Rein bei der Ausführungsgeschwindigkeit der Skripte gibt es keinen Unterschied, aber der Overhead bei einem Request, der normalerweise weit schwerer ins Gewicht fällt, ist bei FastCGI wesentlich geringer.

 

[dev]

Jup, darüber gelesen hatte ich, aber da ich ja nur in einer VM Box rumprobiere und im Moment noch zu geringe Erfahrung mit der Lastverteilung habe, bleibe ich mit meinen Aussagen lieber unverbindlich

Deswegen ruckt es wohl beim ersten Mal immer etwas und danach ist es dann wesentlich "smoother" beim erneuten Request.

Wann werden die Prozesse wieder entladen? Wahrscheinlich kann man das konfigurieren oder?

/dev

 

[Roger Wilco]

Wann werden die Prozesse wieder entladen? Wahrscheinlich kann man das konfigurieren oder?

Richtig. Entweder die Prozesse laufen ewig weiter (bzw. bis der Elternprozess - z. B. der Apache httpd - beendet wird), werden nach einer bestimmten Anzahl Requests neugestartet oder werden nach einer bestimmten Zeit beendet.

 

[dev]

Was für ein geiler Baukasten

/dev

 

[bibabu]

Was für ein geiler Baukasten

Welcome to Linux

 

[Operaiter]

Frage nun: Bin ich zu doof oder ist das normal?

Weiß nicht! aber wenn es dich beruhigt:

Ich hatte GENAU das selbe Problem, und bin durch deinen Post darauf aufmerksam geworden, und bin dann erst mal nachgucken gegangen. Siehe da, der selbe Fehler *grins* :]

In diesem Sinne: Danke! :]

 

[dev]

Hehe, dank sei Open Source

Im Übrigen passieren mir immer noch ab und zu solche Sachen, allerdings geht es mittlerweile schneller, den Fehler zu finden. Habe neulich aus einer virtuellen Maschine mit aktivierten Netfilter-Regeln keine Verbindung auf meine Requests "zurück" (also INPUT-Chain) bekommen. Hat auch eine Weile gedauert um festzustellen, dass das State-Modul für iptables für folgende Regel nicht durch OpenVZ in der vz.conf geladen wurde:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Waren aber nur 2 Stunden