Technik

Ich bereite momentan das entfernen von mod_php5 aus dem Webserver - eigentlich eine ganz simple Sache: "LoadModule modules/libphp5.so" auskommentieren und neu starten.

Denkste!

Das sind Maschinen auf denen Kunden ihre Sachen hinknallen dürfen in der Hoffnung, dass dabei nichts explodiert. In weiser Vorraussicht (ohne, dass ich es auch nur ahnte) habe ich vor Monaten mein eigenes System schon dahingehend erweitert, dass es mit "<IfModule>"-Direktiven arbeitet. Aber das tut längst nicht jeder Und selbst wenn doch wäre es eine Schande, wenn auf einmal die Mühevoll gesetzten PHP-Werte weg wären - drum wird es bald einen (nahezu) kompletten php.ini-Editor geben. Vorerst nur dem Support vorbehalten, aber eine Integration ins Kundeninterface ist geplant.

Für diesen Zweck sammel ich momentan die ganzen php_values und php_flags meiner Kunden zusammen, packe sie in die Datenbank und setze die "<IfModule>"-Direktiven.

Wann mod_php jetzt komplett verschwindet vermag ich noch nicht abzuschätzen Aber spätestens in 2 Wochen.

Im Zuge der Einführung des Bloghosting-Angebotes habe ich in den letzten Wochen immermal wieder an Serendipity rumgeschrieben. Das "Problem" hierbei war, dass wir das ganze Hosting als eine Art "managed Hosting" verkaufen, die bloggenden Kunden sich also nicht um Installation, Updates etc. kümmern müssen.

Es erschien mir etwas dumm jedem Blogger ein eigenes Webroot zuzuordnen und auch die in der README angepriesene "Shared Installation" kam für mich nicht in Frage - einfach aus dem Grund, weil ich damit bisher nur negative Erfahrungen gemacht habe.
Überhaupt reagierte Serendipity bisher immer recht allergisch, wenn ich es versuchte anzufassen, weshalb die jetzige Lösung etwas mehr Hand und Fuss haben sollte. Ausserdem sollen die Benutzer auch nicht wichtige Systemeinstellungen wie etwa die Verbindung zur Datenbank oder die Systempfade ändern können.

Herausgekommen ist eine Lösung mit der zumindest ich sehr zufrieden bin: Ein Serendipity das mit einer Installation eine unbegrenzte Anzahl an virtuellen Nutzern verwalten kann, dabei den Zugriff auf bestimmte Einstellungen verwehrt und sich einfach mit einem kleinen Bash-Skript installieren lässt. Wunderbar

Vielleicht sollte ich zumindest ersteres der Serendipity-Forschung zur Verfügung stellen... :hmm:

Seinerzeit bin ich diesen Weg gegangen, weil mir da das Tor einfach zu offen stand (in Sachen Sicherheit fang ich schon beim kleinsten Windzug an zu bibbern), habe mir aber in der Zwischenzeit Alternativen ausgedacht, denn ein Dauerzustand sollte dies nicht werden und für mein Gefühl musste ich in letzter Zeit einfach zu vielen Kunden absagen, weil sie Perl (etc) haben wollten.

Heute bin ich der Lösung des Problemes ein wenig näher gekommen: Ich sperre meine Kunden ein!

In baldiger Zukunft werden die Skripte der Kunden wohl (ein wenig aufwändiger) in einem chroot-jail laufen und somit ist die Gefahr, dass sie auf irgendwelche Systemdateien (man weiß ja nie) oder Daten anderer Kunden Zugriff bekommen wesentlich geringer. In Kombination mit der neuen FastCGI-Schnittstelle, die ich momentan auf meine Server migriere, ein echter Vorteil.

Einen kleinen Vorgeschmack gibts mit einem kleinen Explorer-Skript

Manchmal wünsche ich mir hier an meinem Arbeitsplatz einen großen roten Knopf (auch Buzzer genannt) auf dem in Großbuchstaben P-A-U-S-E steht. Bei Betätigen eben dieses Buzzers würde die ganze Welt "einfrieren" und für einen Augenblick lang würde die Zeit stehen bleiben - für den Rest der Welt, aber nicht für mich, ich würde fröhlich weiter arbeiten.

... eigentlich genau wie bei diesem einen Mädel aus "Mein Vater ist ein Ausserirdischer" dessen Name mir gerade nicht einfällt. Ich glaube Yvie...

Hätte ich die Macht dies zu tun, wäre einiges sicherlich einfacher. So könnte man zum Beispiel während der Rushhour Änderungen am Webserver vornehmen, völlig frei und ohne Angst haben zu müssen, dass etwas passiert. Ich hab sie aber nicht und darum muss ich dies alles zu Zeiten wie diesen machen...

Wo stand noch die Kaffee-Maschine? :hmm:

Gestern Abend hatte ich richtigen Heißhunger auf Spam und was passierte in dem Moment: Nichts! Es ist schon ärgerlich, will man Spam nicht haben, bekommt man ihn, will man ihn jedoch haben, erlebt man eine lange Durststrecke. Danke, Murphy!

Heute morgen hab ich dann noch ein paar alte gelöschte Spams gefunden (46 an der Zahl) - auf meinem PDA. Die hab ich natürlich gleich hergenommen und in einen neuen experimentellen Ordner meiner Mailbox verschoen.

Das tolle an diesem Ordner: Es ist kein richtiger Ordner. Es ist ein Interface für sa-learn - das lustige Tool den Spam-Filter zu trainerien.

Ich verwende zur Authentifizierung beim Zugriff auf Webseiten sehr gerne PHP und HTTP Auth (auch noch in Verbindung mit HTTPS )

Aus diversen (z.T. Sicherheits-)technischen Gründen bereiten wir momentan die Umstellung der Webserver weg von mod_php5 hin zur FastCGI-Version von PHP 5 vor. Heute war ich schon drauf und dran die Migration zu kippen, denn mein heiß geliebtes Feature funktioniert per Default nicht mehr.
Abgesehen von der Tatsache, dass es von mir so geliebt ist, tue ich mich immer recht schwer damit Dinge zu entfernen, die mal funktioniert haben - denn irgendein Kunde könnte sie ja derweil benutzen.

Doch die Lösung war so einfach: Einfach den FastCGI-Wrapper mod_fcgid patchen! Abgesehen davon, dass es mit PHP nun tut, tut es rein theoretisch auch mit jeder anderen FastCGI-Anwendung...

Einen Auszug aus meinem Patch gibt es im Anhang, die orginale Datei gerne per Mail