nächstes »

[kalessin]

Eine kurze Bitte: könnte ggf. Cheetah installiert werden? Ist eine Template-Bibliothek für Python, ist relativ "Standard" und gut unterstützt und sehr nützlich.

Etwas anderes: eine kurze Suche hat zwar ergeben, daß das Thema "mod_python" schon einmal aufgekommen ist. Ruhe läßt mir das allerdings so nicht.

Der Geschwindigkeitsunterschied zwischen CGI-Python und mod_python ist sehr wohl merklich und fällt aufgrund des deutlichen Overheads beim ständigen Neuladen des Pythoninterpreters sogar stärker aus als z.B. bei Perl (obwohl auch mod_perl nicht ohne Grund existiert).

Offenkundig ist PHP in Form von mod_php installiert, zumindest mußte ich noch keine .php-Seiten ausführbar machen und mit "#!/usr/bin/php" in der ersten Zeile versehen. PHP als CGI zu benutzen ist denn auch nicht ohne Grund sehr selten, und einige PHP-Software läuft auch mit CGI-PHP nur mit deutlichen Anpassungen (oder sogar gar nicht). Wenn es also bei PHP üblich ist, warum geht es nicht mit Python (bzw. Perl)?

Um es anders zu formulieren: ich mag PHP nicht, benutze es aber momentan notgedrungen. Ich würde gerne Python benutzen, aber solange der einzige Weg dazu über CGI führt, ist es als Alternative unattraktiv. Um es noch schärfer zu formulieren: wenn ich einen bezahlbaren Webspace-Anbieter finden sollte, der annähernd das gleiche Preis/Leistungsverhältnis liefert wie Profihost, aber zusätzlich mod_python, würde ich wahrscheinlich sogar wechseln, weil das für mich schlußendlich auf "PHP oder Python" hinausläuft. Und damit bin ich bestimmt nicht allein. Es ist also ein ernsthafter Wettbewerbsnach- bzw. -vorteil.

Es muß doch irgendwie zu machen sein. mod_{php,perl,python} gäbe es nicht, wenn man die nicht auch in Webhosting-Umgebungen sicher verwenden könnte. Und einen vServer nur deswegen anzuschaffen widerstrebt mir. Statements, irgendwer?

[ProfiHost - Technik]

Alle Scriptsprachen auch PHP laufen als CGI.

Da sich die entsprechenden Sprachen ansonsten nicht 100% sicher eingrenzen lassen bzgl. CPU, Laufzeit sicher chroot Umgebung usw.

Dies ist zu unserer Sicherheit und zur Sicherheit der Kunden. Wer als Provider auf diese Sache verzichtet geht ein erhebliches Sicherheitsrisiko ein.

Bzgl. der Templateengine müßte ich nachfragen - dies kann ich nicht sofort beantworten.

[kalessin]

Alle Scriptsprachen auch PHP laufen als CGI.

Da sich die entsprechenden Sprachen ansonsten nicht 100% sicher eingrenzen lassen bzgl. CPU, Laufzeit sicher chroot Umgebung usw.

Dies ist zu unserer Sicherheit und zur Sicherheit der Kunden. Wer als Provider auf diese Sache verzichtet geht ein erhebliches Sicherheitsrisiko ein.

Hmm, soll das also heißen, daß PHP in einer suexec-Umgebung läuft? Aber wie, so rein neugierdehalber? Ich habe ja auch schonmal PHP unter Apache eingerichtet, und CGI-Skripte müssen normalerweise generell (auch wenn sie in PHP geschrieben sind, das spielt keine Rolle) a) ausführbar sein und b) den Interpreter in der ersten Zeile stehen haben (da sie durch die Shell ausgeführt werden). Insofern würde mich wirklich mal interessieren, wie die hiesige PHP-Konfiguration funktionieren soll (denn weder Ausführbarkeit noch Interpreterangabe sind notwendig)... und es bleibt immer noch der Overhead dadurch, daß jedesmal beim Seitenaufruf der Interpreter neugestartet werden muß. Und insbesondere bei mehreren Dutzend virtuellen Servern kann sich das schnell aufaddieren. Es sei denn, ihr benutzt ein FastCGI-Setup, und da ergeben sich IMHO prinzipiell dieselben Sicherheitsimplikationen wie bei mod_php...

Bzgl. der Templateengine müßte ich nachfragen - dies kann ich nicht sofort beantworten.

Das wäre nett, danke. Cheetah ist eine der weiter verbreiteten Bibliotheken zum Templaten, und dynamische Erzeugung von Webseiten so ganz ohne Trennung von Logik und Inhalt ist... unschön. Da könnte ich ja meine Seiten auch gleich wieder in Perl implementieren (schauder).

[ProfiHost - Technik]

Wir setzen einen eigenen Wrapper ein, der dies ermöglicht. Es handelt sich dabei um eine Eigenentwicklung - mehr darf ich dazu nicht sagen.

Bzgl. der Template Engine - kann man diese nicht lokal im Webspace per SSH kompilieren?

[kalessin]

Wir setzen einen eigenen Wrapper ein, der dies ermöglicht. Es handelt sich dabei um eine Eigenentwicklung - mehr darf ich dazu nicht sagen.

Ich wußte nicht, daß das so ein Riesengeheimnis ist, aber okay, danke für die Auskunft.

Bzgl. der Template Engine - kann man diese nicht lokal im Webspace per SSH kompilieren?

Klar geht das (gerade getestet). Mal abgesehen von den 300-500k zusätzlichen Speicherverbauchs (die wurmen zwar, bringen mich aber nicht um) ist es umständlich, aber es geht.

[ProfiHost - Technik]

Ich wußte nicht, daß das so ein Riesengeheimnis ist, aber okay, danke für die Auskunft.

Ist es - es gibt nicht viele Provider die soetwas überhaupt einsetzen - spontan bekannt sind mir nur 6-8 unter anderem Domainfactory, 1und1 und ein paar weitere.

Und dies ist - ein enormer Wettbewerbsvorteil - zumindest sehen wir dies so. Es gab vor kurzem mal einen Test (Zeitschrift gerade vergessen) - da war es sogar bei Größen wie Hosteurope möglich, einfach Daten aus fremden Kundenverzeichnissen zu lesen und festzustellen welche Domains auf dem Server liegen...

Die mod_{...} Module werden Sie bei keinem GUTEN Hoster finden, der ernsthaft Interesse an der Sicherheit der Kundendaten und seiner Server hat. mod_{...} - geht nur mit echtem Server oder VServer, wobei letztere auch oft Probleme machen (zu wenig RAM, haken öfter, teilweise Buggy und und und).

Bzgl. des Moduls - sehr gut :-) Ich denke die 500kb lassen sich verkraften und es ist so erstmal einfacher (für uns) und für Sie sofort nutzbar. Deswegen bieten wir unter anderem den SSH Zugang inkl. Compilertools an.

[kalessin]

Bzgl. des Moduls - sehr gut :-) Ich denke die 500kb lassen sich verkraften und es ist so erstmal einfacher (für uns) und für Sie sofort nutzbar. Deswegen bieten wir unter anderem den SSH Zugang inkl. Compilertools an.

Nun, in diesem Fall ging es sogar mit simplem Hineinkopieren. Der SSH-Zugang ist bei den kleineren Paketen ja nicht vorhanden (nicht offiziell jedenfalls)... und bislang brauchte ich auch noch kein größeres.

[lheuer]

Hi kalessin,

ich habe spaßeshalber versucht Python hier zu verwenden, aber das läßt sich kaum sinnvoll machen.
Ich hatte Quixote verwendet aber alles lief schleppend langsam. Darum glaube ich kaum, daß Dir Cheetah Spaß machen wird. Eine Möglichkeit wäre, daß Du auf Deinem lokalen Rechner mittels Cheetah die Seiten statisch generierst und diese dann hochlädst. Ist natürlich nicht sehr elegant..

Leider, leider ist PHP defacto Standard für Webscripte aber ich wünschte mehr Provider würden auch Python sinnvoll anbieten. PHP ist einfach unelegant, wenn man ersteinmal Python kennengelernt hat.

Ggf. mußt Du für Python einen anderen Hoster suchen eine Übersicht findest Du hier:
http://wiki.python.org/moin/PythonHosting. Die Preise lassen sich natürlich nicht mit denen von Profihost vergleichen.

Vielleicht würde SCGI http://www.mems-exchange.org/software/scgi/ aus dem mod_python Dilemma helfen?

Ich nutze nun leider wieder PHP für die Webseite.

Viele Grüße,
Lars

[lheuer]

Hmm, soll das also heißen, daß PHP in einer suexec-Umgebung läuft? Aber wie, so rein neugierdehalber?

Hier ist eine Möglichkeit:
http://www.debianhowto.de/howto-archiv/de/apache2-phpfcgi-sarge/index.html


Eine interessante Konfiguration für Python bietet auch dieser Artikel:
http://hugo.muensterland.org/2005/07/27/django-lighttpd-and-fcgi-second-take/. Der ist nun auf das Django Projekt bezogen, aber ich denke, daß sich die Konfiguration verallgemeinern läßt.

Grüße,
Lars