Hi! Michael Vogel writes:
> Okay. Ich hab' mich mit PHP als CGI schon lange nicht mehr besch�ftigt, > zuletzt, als mein Provider es dann endlich geschafft hatte, PHP als Lib zu > installieren. Der �bliche Weg. Wenn es als Modul in Apache drin ist, dann l�uft es i.A. viel besser. > Und die Performance? CGI soll ja langsamer sein. Ist es im Prinzip auch. Der Server startet ja dann f�r die einzelne Seite einen neuen Proze�, der irgendwelchen HTML-Output erzeugt und sich dann sofort wieder beendet. Vom Standpunkt der Performance eigentlich die denkbar schlechteste L�sung. Dementsprechend f�r stark besuchte Seiten nicht zu empfehlen. Die L�sung mit PHP als CGI bietet aber insbesondere in Verbindung mit SuExec eine interessante M�glichkeit. Ich hatte die Tage mal �ber eine Implementierung einer Admin-Oberfl�che f�r die Konfig-Dateien unter ~/etc nachgedacht. Meine �berlegung war, da� dieses Admin-Tool per Rewrite-Rule in die Bereiche der Paket-Admins eingeblendet werden kann. Der Trick sollte sein, da� die Oberfl�che mit den Benutzerrechten des Paket-Admins l�uft und so die Rechte zur �nderung der Dateien hat, ohne da� es z.B. als root laufen mu� und so 'aus Versehen' eine System- konfiguration zerschie�en kann. Dummerweise funktioniert das wirklich nur per SuExec, d.h. es mu� als CGI laufen. Als Modul im Apache mit Safe-Mode kann ich zwar Dateien anlegen, die ich dann aber nicht wieder �ffnen darf, weil sie nicht mir geh�ren. F�r die Admin-Oberfl�che w�re die Performanceeinbu�e sicherlich noch tragbar, da der Traffic dort noch �berschaubar sein sollte. Der Vorteil zu Perl w�re in meinen Augen, da� in PHP eine Menge an System-, Datenbank- und Netzwerkfunktionen bereits eingebunden sind, die ich in Perl per einzelner CPAN-Module installieren m��te. -- Stefan _______________________________________________ Global mailing list [EMAIL PROTECTED] http://lists.hostsharing.net/mailman/listinfo/global
