rfc1437.de: new entries tagged with Apache

Vampire

Fri, 9 Dec 2005 21:15:41 +0100

Vampire - Erweiterung von mod_python, mit dem es etwas Entwicklerfreundlicher wird. Zum Beispiel kann es dann auch automatischen Code-Reload.

Overview of new features in Apache 2.2 - Apache HTTP Server

Wed, 30 Nov 2005 10:22:51 +0100

Overview of new features in Apache 2.2 - Apache HTTP Server - was alles so neues in Apache 2.2 kommt. Sehr interessant: der Event-MPM. Damit meldet Apache bei Keep-Alive-Sessions endlich wieder zurück an der Spitze (bisher muss Apache pro Keep-Alive einen Worker reservieren, was Apache für Streaming bei grösserer Client-Zahl nahezu unbrauchbar macht).

Django, Apache and FCGI

Wed, 3 Aug 2005 18:03:45 +0200

In Django, lighttpd and FCGI, second take I described a method how to run Django with FCGI behind a lighttpd installation. I did run the Django FCGIs as standalone servers so that you can run them under different users than the webserver. This document will give you the needed information to do the same with Apache 1.3.

Update: I maintain my descriptions now in my trac system. See the Apache+FCGI description for Django.

(to read more about this, click on the article title)

Apache mod_auth_tkt

Wed, 20 Jul 2005 08:24:51 +0200

Apache modauthtkt ist ein Framework für Single-Signon in Apache-basierten Lösungen über Technikgrenzen (CGI, mod_perl und was sonst noch so existiert) hinweg. Müsste ich mir mal angucken, könnte für mich interessant sein.

Erste Django Tutorials online

Sun, 17 Jul 2005 10:47:05 +0200

Die Django-Programmierer legen mit den Tutorials los. Das erste Tutorial beschäftigt sich primär mit der Erstellung des Datenbankmodells und des Grundcodes für die zu verwaltenden Objekte und das zweite Tutorial beschäftigt sich mit der automatisch generierten Administrationsoberfläche. Sehr nett, das ganze.

Das System ist natürlich stark auf Content-Erstellung und Verwaltung ausgerichtet - aber trotzdem allgemein genug, so das man es auch für anders gelagerte Inhalte nutzen kann. Die ganze Administration wird automatisch aus dem Objektmodell und einigen Hints erstellt, orientiert sich also immer an den realen Daten im System. Und die Default-Optik ist auch recht ansprechend.

Die Serverintegration geschieht einfach über modpython - also über den Apache. Was ebenfalls ein Vorteil ist, denn modpython bietet sehr hohe Performance schon von Hause aus. Und für heftigere Fälle gibts ja das Caching in Django. Ich muss sagen, was ich bisher von Django sehe gefällt mir ausgesprochen gut.

Ein wichtiger Hinweis fehlt in der Installationsanleitung: Apache2 ist zwingend nötig, und daher auch ModPython in der entsprechenden Version. Mac OS X liefert aber nur Apache 1.3 und viele andere Server haben auch nur den 1.3er Apache zur Verfügung, da hat Django also noch ein echtes Manko.

Wer übrigens auf Debian von Apache zu Apache2 upgraden will: wenn modperl im Einsatz ist, vergesst es. Das modperl2 für den Apache2 in der Debian Sarge ist kompletter Schrott - als ob die API-Änderungen in modperl2 im Vergleich zum alten modperl nicht schon nervig genug wären. Im Prinzip kriegt man damit keine Perl-Module mehr so einfach zum Laufen.

Update: Übrigens ist gerade im Subversion zu Django eine Menge Aktivität drin um die Pflicht für Apache zu beseitigen. Ein einfacher Entwicklungsserver ist schon drin, man wird also in Zukunft für erste Spielereien keinen Apache mehr benötigen. Und auch das Deployment könnte man damit auf Dauer auch auf andere Beine stellen - z.B. FCGI hinter lighttpd.

Update 2: Das dritte Tutorial ist da und beschäftigt sich mit der Sicht für den Besucher. Die haben ein ganz schön heftiges Tempo im Moment bei Django.

Spyce

Sat, 9 Jul 2005 09:38:36 +0200

Spyce ist ein Webframework in Python mit verdammt guter Performance: eine einfache Seite mit einem Template hinterlegt bringt auf meiner Kiste über 90 Hits pro Sekunde (Spyce über mod_python in den Apache integriert, Memory-Cache). Take that, PHP!

mod_fastcgi und mod_rewrite

Tue, 22 Feb 2005 22:38:34 +0100

Tja, da hab ich das doch glatt mal ausprobiert mit dem PHP als FastCGI - unter anderem weil ich dann auch gleich ein neueres PHP benutzen könnte. Und was ist? Nix ist. Und zwar gab es ein massives Problem mit modrewrite Regeln. In der .htaccess vom WordPress wird nämlich alles auf die index.php umgeschrieben. Dazu wird der eigentliche Pfad der angesprochen wurde als PATHINFO an die index.php angehängt. Tja, und das PHP flöht dann diese Informationen da wieder raus und macht das richtige.

Aber als ich FastCGI aktiviert hatte, klappte das nicht - das PHP behauptete immer, das kein Input-File übergeben wurde. Also als hätte ich das PHP ohne Parameter aufgerufen. Die WordPress Administration - die mit normalen PHP Files arbeitet - funktionierte wunderbar. Und auch die Rechtegeschichte klappte gut, alles lief unter meinem eigenen User.

Nur die Rewrite-Rules halt nicht - und damit die ganze Site nicht. Ziemlich blöd, das ganze. Vor allem weil ich das nicht vernünftig testen kann ohne meine Hauptsite runterzureissen. Blöd ist auch, das scheinbar suexec die eigentlichen FCGI-Starter in der Document-Root des primären virtuellen Servers sucht - nicht in denen der eigentlichen Virtuellen Server. Macht die ganze Situation etwas unübersichtlich, da die Programme (die Starter sind ja kleine Shellscripte) nicht da liegen, wo die Dateien liegen. Ausser man hat seine virtuellen Server unterhalb des primären virtuellen Servers angelegt - aber das halte ich persönlich für hochgradig schwachsinnig, da man dann unter Umständen durch direkte Pfadangaben über den Default-Server an im virtuellen Server geladenen Perl-Modulen vorbeikommen kann.

Ergo: ein Reinfall. Leider. Ärgerlich. Jetzt muss ich mir irgendwie erstmal eine Testkiste zusammenstellen mit der ich dieses Problem analysieren kann ...

Update: ein bischen Suchen und Wühlen im Netz und ein kurzer Test und ich bin schlauer: PATH_INFO bei PHP als FCGI-Version unter Apache ist kaputt. Scheinbar kriegt PHP den falschen PATHINFO Eintrag geliefert und den falschen SCRIPTNAME. Dadurch findet der Interpreter bei gesetztem PATHINFO einfach schlicht sein Script nicht und nix geht mehr. Jetzt muss ich also weiter suchen, ob es eine Lösung gibt. cgi.fixpathinfo = 1 (was allgemein als Hilfe dafür geboten wird) funktioniert jedenfalls nicht. Aber wenn ich das richtig sehe gibts keine brauchbare Lösung dafür - jedenfalls keine für mich offensichtliche. Mist.

Update 2: Ich hab eine Lösung gefunden. Diese basiert darauf einfach nicht den Apache zu benutzen, sondern den lighttpd - und den Apache nur als transparenten Proxy vorne vor zu stellen. Das geht ganz gut, vor allem wenn ich den Apache stark entkerne und das PHP dort rauswerfe wird er auch deutlich schlanker. Und lighttpd kann unter verschiedenen User-Accounts laufen, dadurch spare ich mir auch das wilde gehacke mit suexec. Allerdings läuft dann pro User ein lighttpd Prozess (lighttpd braucht nur einen Prozess pro Server, da es mit asynchroner Kommunikation arbeitet) und die PHPs toben sich als FastCGI Prozesse aus, nicht als Apache-integrierte Module. Apache selber ist dann nur für rein statische Präsenzen oder Sites mit Perlmodulen zuständig - davon habe ich nämlich noch eine ganze Reihe. Im Moment habe ich da nur eine Spiel-Site laufen, aber vielleicht wird das in den nächsten Tagen umgestellt. Die Methode wie cruft-free URIs produziert werden ist übrigens recht witzig: bei WordPress kann man einfach das index.php als Error-Document eintragen: ErrorDocument 404 /index.php?error=404 wäre der Eintrag in der .htaccess, bei lighttpd gibt es eine äquivalente Eintragung. Dadurch werden automatisch nicht existierende Files (und die cruft-free URIs existieren ja nicht als physikalische Files) auf WordPress umgeleitet. Dort wird dann geguckt ob wirklich keine Daten da sind für die URI und wenn doch was da ist (weil es eine WordPress URI ist), wird einfach der Status zurückgesetzt. Für letzteres musste ich einen kleinen Patch in WordPress einbauen. Dadurch spart man sich die ganzen RewriteRules und kommt mit fast jedem Server zurecht. Und weil jetzt 1:41 ist, geh ich jetzt mal pennen ...

Apache2, php5-fcgi, php4-fcgi, mod_fastcgi HowTo

Tue, 22 Feb 2005 10:15:50 +0100

Apache2, php5-fcgi, php4-fcgi, mod_fastcgi HowTo liefert alles was man wissen muss um PHP als FCGI-Prozess laufen zu lassen. Und sogar in Deutsch. Das bischen Apache2 da drin kann man selber auf Apache 1.3 umdenken, der Apache ist eigentlich kaum betroffen.

FCGI bietet über Kombination mit suexec die Möglichkeit um PHP pro virtuellem Host unter einem dedizierten User laufen zu lassen und damit die Möglichkeit in shared hosting Umgebungen Files in einem virtuellen Host so anzulegen das ein anderer User mit seinem PHP diese nicht auslesen kann. Man könnte sogar die FCGI-PHPs in einem chroot Jail laufen lassen, um sie noch stärker abzuschotten.

Ausserdem ist FCGI für PHP oft deutlich resourcenschonender, da weniger PHP-Prozesse als Apache-Prozesse laufen können und die Apache-Prozesse nicht so aufgeblasen werden. Wenn man natürlich viele virtuelle Hosts hat, kann das dazu führen das die FCGI-Prozesse wieder an Anzahl gleichziehen - aber dann sollte man sowieso überlegen ob die FCGI-Prozesse nicht besser auf einer dedizierten Maschine laufen sollten.

Für simon wär das genau das richtige, zumal ich dann den anderen Usern auch PHP erlauben könnte.

Alternative Rewrite Rules

Thu, 17 Feb 2005 00:57:32 +0100

Alternative Rewrite Rules ergeben eine wesentlich einfachere .htaccess, vor allem eine die nicht ständig von WordPress aktualisiert werden muss. Gerade wenn man selber die .htaccess für andere Sachen noch mitbenutzt ist das praktisch. Ausserdem wird der Apache durch die komplizierten Rewrite-Rules von WordPress auch nicht unbedingt schneller. Ich hab die bei mir mal aktiviert, mal schauen wie sich WordPress 1.5 mit diesen Eintragungen macht. Wenns keine Probleme gibt, bleiben die so drin, denn sie gefallen mir wesentlich besser als die andere Variante. Und sie haben nicht die Probleme die die anderen haben - alte mod_rewrite können nur greedy matching, was die Erstellung von komplizierten Listen von Rewrites ziemlich haarig macht ...

Und nochmal Logfiles

Sun, 13 Feb 2005 15:39:54 +0100

Da ich ja nun ein interessantes Studienobjekt hatte, wollte ich mal gucken inwieweit ich mit ein bischen Clusteranalyse in meinen Logfiles irgendwas interessantes zutagefördern würde. Ich habe also eine Matrix angelegt aus Referrern und zugreifenden IP-Adressen und mir damit mal einen Überblick über typische Userszenarien gemacht - also wie sehen normale User aus im Log, und wie sehen Referrer-Spammer aus und wie sieht unser Freund aus.

(to read more about this, click on the article title)

ModSecurity - Web Intrusion Detection And Prevention / mod_security

Tue, 25 Jan 2005 22:35:52 +0100

ModSecurity - Web Intrusion Detection And Prevention / mod_security ist ein Apache-Modul das in Requests reinguckt und aufgrund von Filtern entscheidet ob ein Request durchgeht oder eine Filtermassnahme (Script, Log etc.) gestartet werden soll. Ganz interessant, auch wenn ich Regelbasiertes Filtern gegen Attacken generell eher skeptisch gegenüber stehe - die finden eben nur bekannte oder erwartete Angriffe. Das gefährliche sind da aber die unerwarteten Angriffe ...

CVS Module for Apache

Mon, 5 Jan 2004 11:11:12 +0100

CVS Module for Apache - Ein Apache-Modul welches Dateien aus einem CVS-Repository ausliefert und bei Bedarf einen checkout macht