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.
Ape kann Python-Objekte in Zope transparent auf Filesystemobjekte oder PostgreSQL Datenbanken mappen. Könnte auf der Arbeit sehr interessant sein. Kann auch standalone (ohne Zope) benutzt werden.
Die Schill-Partei in Hamburg löst sich auf - und tschüss. Seht zu das euch die Tür beim Rausgehen nicht in den Arsch knallt. Braucht auch nicht wiederzukommen.
Hingehen, unterschreiben. Jedenfalls wer daran interessiert ist das es weiter eine Privatkopie gibt. Übrigens hat die Aktion auch ein Weblog.
Ian Bicking vergleicht FileSystemView vs. LocalFS als Alternativen um Zope-Objekte im Filesystem zu speichern.
Leica in financial crisis - oh Shit. Hoffentlich klappts trotzdem, oder Hermes schiesst nach. Wär doch schade um Leica.
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 mod rewrite Regeln. In der .htaccess vom WordPress wird nämlich alles auf die index.php umgeschrieben. Dazu wird der eigentliche Pfad der angesprochen wurde als PATH INFO 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 PATH INFO Eintrag geliefert und den falschen SCRIPT NAME. Dadurch findet der Interpreter bei gesetztem PATH INFO einfach schlicht sein Script nicht und nix geht mehr. Jetzt muss ich also weiter suchen, ob es eine Lösung gibt. cgi.fix pathinfo = 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 ...
Wie man im 3M Security Glass Ad sieht (reales Geld in einer realen Installation), meint 3M es wohl sehr ernst mit der Sicherheit seines Sicherheitsglases. Nette Werbe-Idee - ich frage mich, wie viele Leute wohl schon versucht haben das Glas kaputt zu kriegen
Sony steigt komplett aus dem PDA-Geschäft aus - und das obwohl sie mit dem Clie PEG TH-55 so ziemlich das ultimative Palm OS Gerät haben ...
... und zurück. Odyssee der Webbrowser.
Nachdem ich jetzt einige Tage mit Firefox gearbeitet habe, war ich wieder zurück zu Camino gewechselt. Warum? Nunja, unter OS X ist FireFox dann doch suboptimal. Zum Einen habe ich den Eindruck das Fonts irgendwie grundsätzlich kleiner dargestellt werden als in Camino oder anderen echten Mac Programmen. Mag Einbildung sein. Keine Einbildung hingegen ist, das FireFox unter OS X die Services nicht unterstützt. Und das ist nervig - was bringts, wenn haufenweise Programme sich in das Services-Menü einklinken und nützliche Dienste zur Verfügung stellen die auf markierten Texten in anderen Programmen aufbauen, wenn die Hauptapplikation in der ich meine Zeit am Rechner vertüddel genau nicht unterstützt wird?
Genauso nervig war, das ausgerechnet Tab-X unter OS X nicht unterstützt wird. Diese Erweiterung packt ein Close-Icon an jeden Tab dran. Keine Ahnung was den UI-Designer vom Firefox geritten hat, aber ich betrachte weder das zwingende Aktivieren eines Tabs und anschliessend das Klicken auf ein winziges X am rechten Rand der Toolbar als ergonomisch noch das Schliessen eines Tabs über das Context-Menü. Ok, daran kann man sich zur Not gewöhnen.
Desweiteren hat mich ständig gestört, das FireFox seinen eigenen Passwortverwalter hat und nicht die KeyChain benutzt. Ich finds einfach praktisch das alle möglichen Programme sich an einer zentralen Stelle eintragen und ich genau dort meine Passwörter löschen kann, wenn ich das mal brauche. Ausserdem hilft das dabei nicht ständig die Passwörter neu eingeben zu müssen, nur weil man eine Seite mal mit einem anderen Browser besucht.
Leider verliere ich damit alles so nette Sachen wie es über die Erweiterungen von FireFox verfügbar ist - zum Beispiel die Web Developer Toolbar. Nur das die sowieso auf meinem Mac nicht funktioniert, weiss der Geier warum - von daher hab ich die sowieso immer nur unter Linux gehabt, und da benutze ich ja weiter FireFox. Das Plugin für den Google PageRank Status und das Plugin für mozcc werde ich hingegen schon vermissen - beides war durchaus praktisch. Irgendwie blöd, das ich nicht beides haben kann - einen FireFox mit vernünftiger Integration in OS X, das wärs schon ...
Aufgrund der ziemlich broken 0.8.2 von Camino habe ich mir aber die 0.8.1 wieder runtergeladen und installiert. Die hat wenigstens funktionierende Tabs und crashed nicht dauernd. Keine Ahnung was die mit der 0.8.2 gemacht haben, aber es war definitiv nicht zum Vorteil von Camino.
Und natürlich war gleich nach dem ich das hier geschrieben habe der Camino angefangen rumzuzicken. Ich fasse es nicht. Die 0.8.1 hat vorher einwandfrei funktioniert. Trotzdem gabs jetzt die gleichen Problem wie mit der 0.8.2 - also vermutlich ausgelöst durch irgendwelche Seiten mit denen ich jetzt im Gegensatz zu früher häufiger arbeite? Ich hab keinen blassen Schimmer - spezielle Tools habe ich nicht extra installiert unter OS X, im Gegenteil, ich hab eins deinstalliert.
Also andere Browser wieder mal ausprobieren. Safari 1.0 unter OS X 10.2.8 ist deutlich zurück in den Features - zur Not würde der mir aber noch als Alternative bleiben, er crashed aber immer mal wieder auf Seiten. OmniWeb ist im Prinzip ein aufgemotzter Safari, crashed aber noch häufiger. Und Opera kommt mit dem CSS vom WordPress-Admin überhaupt nicht klar - das ist wild durcheinandergewürfelt. Ausserdem fragt der immer mehrfach nach Passwörtern und Keychain-Zugriff wenn ich auf manche geschützten Seiten zugreife. Und diese Macke hat er schon seit Monaten - nicht sehr vertrauenserweckend.
Der IE für den Mac ist nicht mal eine Verzweifelungsoption. Netscape? Nee, sorry, aber das muss nicht. Mozilla auch nicht - dann schon lieber FireFox, denn der Mozilla bindet sich nicht nur nicht gut ins System ein, er sieht auch noch völlig anders aus als OS X Anwendungen ...
Der einzige wirklich brauchbare alternative Browser unter OS X 10.2 ist - trotz seiner Probleme - der OmniWeb. Notfalls der Safari, aber der OmniWeb ist bei manchen Seiten fortgeschrittener im Rendering. Unterstützt aber trotzdem nicht so Sachen wie z.B. Klicken auf das Label einer Checkbox zum Toggeln derselben - wird im WordPress Admin gerne benutzt und vermeidet alberne Zielübungen. Ausser bei OmniWeb oder Safari. Ok, das die QuickTag-Bar im OmniWeb und Safari fehlt ist Absicht bei WordPress - das JavaScript ist wohl nicht ganz kompatibel.
Also wieder retour das ganze und doch wieder den FireFox benutzen und sich über die fehlenden Services ärgern (die übrigens auch bei Carbon-Applikationen funktionieren können - wenn der Programmierer das berücksichtigt hat in seinem Programm)? Oder doch erstmal mit OmniWeb spielen und gucken ob man über die Probleme nicht wegkommt?
Und was lernen wir daraus? All Browsers suck. Even the good ones.
Riesiger Eissee auf dem Mars entdeckt - wow. Bisher gabs ja nur Spuren, aber direkt so Wasser im festen Zustand rumliegend hat ja keiner auf dem Mars bisher gefunden. Und dann gleich ein Tümpel von der Grösse der Nordsee ...
