PHP in Multi-User-Umgebungen

[kase]

Wieso sollte er kompatibel sein, ist ein grundlegend anders gestrikter Webserver :P

Weil er versucht sich in einen "Markt" zu drängen, in dem der Apache dominiert. Und da bei sämtlicher Software die rewrite_rules auf den Apache zugeschnitten sind, sollte der Lighty zu diesen kompatibel sein, weil viele Entwickler nicht die Zeit/Lust/Können haben, diese alle umzuschreiben.

So weit ich weiss entwickelt das nur Jan Knetschke.

Und wenn dieser mal keine Lust/Zeit mehr hat, ist das Projekt eventuell nahezu "tot". Genau davor habe ich immer "Angst", bei so kleinen Projekten.

Übrigens setze ich den Lighty auch produktiv ein, würde bei wichtigen und großen Projekten aber immer den Apache bevorzugen.

[Joe User]

bzw teilweise ist er inkompatibel zum Apache (zB mod_rewrite, oder wurde das "gefixed"?)

mod_rewrite wurde bei Lighty effizienter (ressourcenschonender) implementiert, wobei eher selten genutzte und ressorcenfressende Features weggelassen wurden. Dennoch lassen sich fast alle Apache-Rewrite-Rules 1:1 beziehungsweise mit wenig Aufwand übernehmen.

Außerdem sieht zumindest der Trac (Bugs und Tickets) sehr nach einem 1-2 Mann Projekt aus, und bei so Dingen bin ich immer äußerst vorsichtig.

So weit ich weiss entwickelt das nur Jan Knetschke.

Jain, AFAIK hat neben ihm nur eine weitere Person Commit-Rechte, Bugfixe und neue Features stammen hingegen von diversen Entwicklern.

Als Hinweis nebenbei: Wir setzen den LightTPD produktiv ein und das rootforum wird ebenfalls vom lighty ausgeliefert ;)

Die bekanntesten Plattformen die Lighty einsetzen, sind Sourceforge, YouTube und MySpace, mehr unter http://trac.lighttpd.net/trac/wiki/PoweredByLighttpd

[dtdesign]

Weil er versucht sich in einen "Markt" zu drängen, in dem der Apache dominiert.

Gut, aber das muss nicht unbedingt viel heißen. Nur weil der Indianer den Markt beherrscht (wobei ich da auch so die eine oder andere dunkle Wolke in meiner Glaskugel aufkommen sehe *g*), bedeutet das nicht, dass Apache optimal ist.

Es ist meist ein schmaler Grat zwischen Innovation und dem alt bekannten.

Gruß
dtdesign

[ekle]

wenn ich das so lese, wollt ich mal fragen was ihr von folgendem haltet, bin am überlegen ob das so sicher ist:

ein apache2-itk mit mod_chroot einsperren und php dann als mod laufen lassen, wegen der besseren Geschwindigkeit.
beim apache-itk kann man bei jedem vhost einstellen, unter welchem Benutzer er laufen soll.
und mittels mod_chroot den Apache in einen Ordner sperren der nur das nötige erhält.
Dann über die Dateisystem rechte verhindern dass die einzelnen User gegenseitig in ihre Verzeichnisse rein kommen.

^^ ist das so sicher oder gibts was wo da dagegen spricht ?
Hatte es mal in ner Testumgebung so aufgebaut.

[kase]

mod_chroot sperrt glaube ich nur statische Seiten ein. PHP Seiten über mod_php hätten dann immer noch Zugriff auf das ganze System.

Außerdem ist apache2-itk noch nicht 100% stable, kann mich da aber auch irren.

Was spricht denn gegen eine mod_fcgid Konfiguration. Dies würde in Sachen Performance ähnlich gut sein.

[ekle]

http://core.segfault.pl/~hobbit/mod_chroot/
^^ also ich versteh das so das des komplett eingesperrt ist

apache2-mpm-itk
Please note that this MPM is highly experimental, and is not from the same tree as the other MPMs
^^ Tatsache, dachte Debian packt grundsätzlich nur stabile Versionen in die offiziellen Archive ...

mod_chroot, deshalb weils so schön einfach zu konfigurieren und zu warten ist, im vergleich zu einem echten chroot, hab ich zumindest den eindruck.

mod_fcgid deshalb nicht weil die Automatisation mit diesen start Scriptes recht kompliziert ist, wie ich finde.