[Philipp]

Jeder vernünftige Dienstleister darf bei den Kundenscripten keine Auswahl treffen. Das währe ja selbstmord, Kunde bezahlt für den Account und der Provider schmeißt die Scripten wieder runter, wenn sie ihm nicht gefallen.

Bei mod_perl schon . Keiner der grossen Provider bietet es an ausser natürlich auf dedizierten Servern. Provider die es doch anbieten werden auf Boards wie www.webhostingtalk.com meistens verrissen. Dabei handelt es sich meistens um kleine 1 Mann Provider die mit wenig Erfahrung einen Server z.b. um $99 Mieten und dann ihren Kunden tolle Features wie mod_perl bieten.

Übrigens bei vielen Servern ist mod_perl zwar installiert wird aber nicht verwendet z.b. bei Cobalt RaQ Servern. Das normale Verzeichnis für mod_perl Scripte ist perl-bin

Das kommt nur bei Wohnzimmerprovider vor, die einen schwachen Rechner haben, und keiner eine Serverlast erzeugen darf. Sonst geht der Compi mit 128 Ram gleich in die Knie
Ausserdem ist es egal was die Kunden raufladen, du kannst mit Apachemodule die Prozessorzeit und den Ramverbrauch steuern, so kann keiner den Server mit einem Prozess abschießen.

Ich würde Tera-Byte nicht unbedingt bei 1 Mio Kunden und 22000 TB/Transfer als Wohnzimmerprovider bezeichnen. Das gleiche gilt für Ventures Online die vor 2 Monaten YaBB/UBB von ihren Servern gebannt haben.

2, Für das gibt es Suexec: Das steuert den Zugriff auf Scripten und ist gnadenlos beim Überwachen und ausführen (siehe meinen Thread über Suexec)

Vielleicht hilft das bei den Resourcen aber was ist mit den Root Privilegen von mod_perl? Da es nicht als CGI läuft und daher nicht an User und deren Verzeichnisse gebunden ist öffnet es eigentlich ein relativ grosses Sicherheitsloch.

3, Hä, 2 Apachen am selben Port

Ich kann ja dann nachschauen aber soviel ich mich erinnern kann werden alle Scripte im /perl-bin Verzeichnis am zweiten Server ausgeführt