akede wrote:
Nun es gibt einen Weg drumrum, der hintergrund des Problems ist ja bei Safe-Mode, dass der Apache-User vom FTP User des Kunden abweicht. Damit stimmen die Dateirechte nicht überein und damit funktioniert eine nachträgliche Installationvon CMT's nicht mehr.
Ja genau, bei abweichenden Usern
und wenn das System dann diese Abweichung prüft,
dann gibt es die Probleme.
Safe_mode abzuschalten, um dieser Prüfung aus dem Weg zu gehen, ist aber der denkbar schlechteste Weg, weil damit ein großes Stück Sicherheit aufgegeben wird (zumindestens solange PHP noch so wenig Sicherheitsfeatures bietet und es diesen safe_mode gibt. In Version 6 soll er ja endlich aufgegeben werden - aber dann wird es eben andere Mechanismen geben.)
Was muss man also versuchen?
--> Dafür sorgen, das PHP-User und System-User (FTP) identisch sind!
Wie macht man das?
1) PHP als CGI-Modul:
Hier kommen wrapper zum Einsatz, die serverseitig dafür sorgen, das PHP-Scripte mit dem Systemuser laufen. Dies ist der anwenderfreundlichste Fall - für die Hoster oft aber nicht der "lukrativste", weil damit die Serverlast stark ansteigt. Auswirkung: Weniger mögliche Kunden auf einem Server.
Gerne wird behauptet, das PHP als CGI langsamer ist. Das ist Quatsch! Die Scripte werden genauso schnell ausgeführt! Allerdings muss bei jeder Scriptausführung das PHP-Binary geladen werden und das erzeugt viel Overhead in Form von Speicher, Festplatten und CPU-Belastung. Das Laden selbst benötigt wenige Millisekunden und ist i.d.R. vom Webseitenbesucher nicht spürbar (vor allem mit PHP4, dessen Binary noch angenehm klein ist).
Nebenbei: PHP als CGI hat ggf. Nachteile für Einzelfälle: Es funktionieren dann ein paar Apache-Spezialitäten nicht (z.B. Header-Änderung, HTTP-Authentifizierung). .
2) PHP als Apache-Modul:
Die einfachste Art PHP zu installieren. Es wird quasi mit dem Apache zusammen gestartet. Der Apache stellt im Server immer eine vorher definierte Anzahl Prozesse in den Speicher. Diese warten dann auf ihren Einsatz und müssen nicht neu geladen werden. PHP ist dann schon mit "dabei".
Feine Sache, aber leider arbeitet PHP dann mit dem User des Apachen. Dieser ist i.d.R. serverweit derselbe (wwwrun, www-data, nobody und wie sie alle heissen), sofern man keine andere Techniken wie z.B. eine chroot-Umgebung für jeden Kunden einsetzt.
Um hier auch als Kunden (ohne Zugriff auf den Apache-User) Joomla! sinnvoll benutzen zu können, muss man dafür sorgen das Joomla! mit den Rechten des Apache-Users hochgeladen wird. Der Hoster könnte die Dateien zur Verfügung stellen oder aber man installiert sich zunächst einen File-Explorer (z.B. den Quix-Explorer
http://quixplorer.sourceforge.net/) und lädt damit die Dateien für Joomla auf den Webspace. Danach kann man das Joomla-Setup problemlos ausführen.
Anschließend sollte man in Joomla dann die Jommla-Komponente dieses Explorers einbinden (
http://developer.joomla.org/sf/projects/joomlaxplorer). Jezt kann man alle Dateioperationen (sofern überhaupt notwendig) innerhalb des Joomla-Verzeichnisbaum mit dem Explorer lösen. FTP hat hier nichts mehr zu suchen. Man hat dann einen homogenen Verzeichnisbaum, der unter den Rechten des PHP-Users angelegt wurde.
Fragen:
* Sind die Dateien nicht unsicher, wenn man im Fall 2) einen globalen User verwendet?
Nein, wenn man zusätzlich weitere Sicherheitsfeatures bei PHP aktiviert (z.B. das openbasedir).
* safe_mode=on verhindert aber uploads in Foren und bei Gallerien!
Nein, nicht wenn man uploads in der PHP-Konfiguration zuläßt und sinnvolle Werte für bestimmte Restrictions setzt.
* Die Menalto-Gallerie läuft nicht mit sf=on
Das ist korrekt! Die Menalto-Gallerie kann nicht benutzt werden. Das liegt aber nicht an Joomla oder der Bridge zur Gallery, sondern an der Gallery selbst. Leider gibt es heute immer noch Programme, die den sf=off zwingend benötigen. Hier muss man auf Konkurenzprodukte ausweichen. Bislang ist mir noch kein Jomla/Mambo-Modul über den Weg gelaufen der zwingend sf=off benötigt.
* sf=on verhindert den Zugriff auf weitere externe Programm (ImageMagick u.a.)
Ja genau, das soll ja auch so sein!!
Typische externe Tools können vom Hoster jedoch problemlos auch bei sf=on den Kunden zur Verfügung gestellt werden. Dazu kann man in PHP eigene Verzeichnisse definieren, die für diese Zugriffe freigeschaltet sind. Der Hoster muss deswegen diese Tools kein zweites mal installieren. Sie werden über Symlinks in das Verzeichnis gelinkt.
* Ich glaub das alles nicht, das das so einfach gehen soll!
Bei ernsthaftem Interesse und seriösen Anfragen, stelle ich gerne Demo-Accounts zur Verfügung (nach Fall 1).
* Warum gibt es dann so viele Probleme bei zig Hostern?
Darüber erlaube ich mir kein Urteil. Fragen Sie die Hoster.
Meines Erachtens sollte die Comunity eine Art "Zertifikat" verleihen oder eine Liste tatsächlich geprüfter Hoster zur Verfügung stellen, damit sich die potentiellen neuen Joomla-User besser orientieren können. Zu verbreiten, das der safe_mode zwingend auf "off" stehen sollte, ist jedenfalls der falsche Weg. Das führt nur dazu das laufend diese Wünsche an die Hoster weitergeleitet werden (ich bekomme fast täglich solche Anfragen) und diese dann denken, das sie nur Erfolg mit unsicheren Konfigurationen haben werden. So mancher Wohnzimmerprovider erfüllt nur allzu gerne die Kundenwünsche - wenn er dann mal einen Kunden abbekommt.
Ich führe noch viele Diskussionen in anderen Foren, auch einigen Webdesigner-Foren. Joomla! hat dort einen schlechten Ruf. Haupsächlich weil es keinen validen Code erzeugt und Tabellenstrukturen verwendend. Es ist dort immer dieselben Grundsatzdiskussion mit bestimmten Code-Fetischisten. Das Joomla! dann auch noch zwingend unsichere Servereinstellungen benötigt, ist oft ein weiteres Argument der Gegner. Es ist ein Kampf gegen Windmühlen... wenn dies selbst in der Joomla!-Community so kommuniziert wird. Das sollte die Community endlich richtig stellen!