Technik

Etwas, das mir des öfteren böse aufstößt,ist der Umstand, dass wir neben PHP keine weiteren Skripting-Sprachen im Webhosting anbieten. Zwar nicht oft, aber ab und zu wird halt danach gefragt und dann mit "Nein" zu antworten halte ich fast schon für Interessenten-Abschreckung

Es gibt so einige Gründe, warum wir z.B. Python bisher nicht angeboten haben. Zwei davon wären: Skriptsprachen dürfen bei uns nicht innerhalb des Webservers laufen, sondern explizit mit den Rechten des jeweiligen Kunden. CGI scheidet aber aus Performance-Gründen aus, FastCGI ist Pflicht.
Nun mag man behaupten, dass Python ja FastCGI könne, doch ich verneine dies gerne, denn Python kann FastCGI nur dann, wenn das ausgeführte Skript es explizit kann. Hält man PHP nun dagegen, so ist dem Skript vollkommen egal, ob es nun eine Apache- oder IIS-SAPI, CLI, CGI- oder FastCGI-Schnittstelle ist, es funktioniert transparent. Diesen Zustand würde ich als "Python kann FastCGI" gelten lassen. Et voila:

In unserer Sandbox ist nun ein bisher voll funktionsfähiger (unentdeckte Fehler nicht mit eingeschlossen) Python-nach-FastCGI-Wrapper. Im Wesentlichen ist es ja nur ein FastCGI-Verbindung annehmen, Python-Interpreter vorbereiten, Ein- und Ausgabe umleiten und Skript ausführen. Dennoch: Es hat lange bis hier hin gedauert.

Und jeder der sich jetzt schon freut: Es wird auch noch ein bisschen dauern. Erst müssen wir noch weiter testen und fehlende Funktionalität, wie z.B. PHP's openbase_dir, nachrüsten.

"Hat mal jemand eine gute Dokumentation des MyISAM-Format" fragte ich mich heute morge, als ein Kunde mit dem Problem ankam ein paar hunderttausend Datensätze in seiner MySQL-Datenbank gelöscht ohne ein Backup zu haben.

Laut MySQL AB ist es nicht möglich Datensätze aus einer Datenbank zu retten, wenn diese irrtümlich gelöscht wurden. Für mich eigentlich vollkommen nachvollziehbar, würde ich nicht das Erwachsenen-Puzzeln so sehr mögen. Drum habe ich kurzum angefangen, mal das Datensegment einer solchen MyISAM-Datenbank auseinander zu nehmen.

Auf den ersten Blick kein Voodoo oder größere Wissenschaft. Beim Löschen werden wohl die ersten 16 Byte eines Datensatzes zerstört, zumindest konnte ich nie die ersten vier INT-Felder mit korrekten Werten wiederherstellen, ansonsten scheint der Datensatz intakt zu bleiben. Eine Schwierigkeit kam mir dann doch irgendwann unter, als die Datensätze dann ab und zu und irgendwie das eine oder andere Byte nach hinten geschoben wurden. Merkwürdig!

So wirklich verstanden habe ich es nicht, da ich aber keine Dokumentation oder Quellcodes wälzen wollte, habe ich kurzerhand eine Suchfunktion für VARCHAR-Felder im nächsten Datensatz geschrieben (das Layout der Tabelle lies das glücklicherweise hier zu) und schon war alles wieder super.

Die wichtigsten Daten konnte ich dem Kunden also wiederherstellen. Einen Tadel gab es trotzdem. Hat Spaß gemacht!

Vor ziemlich genau 3 Monaten hatten wir unser neues SVN-Backend eingeführt, was es ja nun auch erlaubte eine "SVN Working Copy" auf einem Webserver abzulegen und automatisch updaten zu lassen.

Anfang der Woche hat sich gezeigt, dass dieses Feature auch für ganz andere Dinge hilfreich sein kann:

Ein Kunde hat seinen Online-Shop in einer SVN-Repository verwaltet. Nach einer Sicherheitslücke war der Shop des Kunden kompromittiert worden. Da aber nun sämtliche Dateien auf dem Webspace versioniert waren, konnten wir bis ins letzte Detail rekonstruieren, was der Angreifer so alles verbrochen hat.

Genial!

Die Analyse läuft wohlgemerkt noch und ich bin gespannt wie ein kleines Kind, was so alles im Abschlussbericht auftauchen wird.

Ein Kunde, der auf seiner Domain bei uns auch noch ein paar externe Dienste betreibt, wollte gegen 2 Uhr nachts eine in der Domain hinterlegte IP-Adresse ändern. Man kann natürlich den ganzen Abend lang Kaffee trinken und so lange aufbleiben, muss man aber nicht - so war zumindest mein Gedanke, drum habe ich mich kurzerhand hingesetzt und fix eine Erweiterung bei uns im Kundeninterface eingebaut:

Zeitgesteuerter DNS-Datensatz

Dort kann man nun eine "Gültigkeit" für jeden DNS-Datensatz spezifizieren. Sei es ein fixes Datum ab wann der Datensatz gilt, ein Datum bis wann der Datensatz gilt oder einfach beides zusammen. Eigentlich perfekt wenn irgendein Dienst zu einem bestimmten Zeitpunkt (automatisch) umgestellt werden soll und die Domain nicht automatisch auf den neusten Stand gebracht werden kann.

Ganz nebenbei habe ich noch ein wenig umstrukturiert und ein paar Korrekturen eines anderen Kunden eingepflegt. Das war zwar wieder so eine Sache wo man vielleicht nach der Wirtschaftlichkeit fragt, aber ich bin sehr zufrieden damit. Der Kunde hat es uns gedankt und ich habe das Gefühl unterm Strich wieder etwas besser geworden zu sein. Vielleicht ist es auch einfach nur ein nettes Alleinstellungsmerkmal

Wir haben heute zwei neue Features für die SVN-Repositories bei uns eingeführt, die mich irgendwie an den "großen Bruder" erinnern.

Zum einen darf der große Bruder nun spionieren und kann bei Updates (bzw. "commits") auf der Repository per E-Mail informiert werden. Entgegen hier evtl. aufkeimenden Feature-Wünschen lässt sich hier ganz UNIX-like nur eine E-Mail-Adresse angeben. Die Adresse kann dann aber natürlich auf mehrere Ziele verweisen. Irgendwie empfand ich es als fehl am Platze in dieser Applikation noch einen "Verwaltung für mehrere E-Mail-Adressen" einzuführen, das kann unser E-Mail-Backend viel besser.

Eine Peitsche haben wir dem großen Bruder auch noch an die Hand gegeben: Optional kann nun auch das Verwenden eines Kommentars bei jedem Commit erzwungen werden. Ist die Option aktiviert und der Kommentar fehlt, wird der Commit einfach mit Fehlermeldung abgebrochen.

Und gut!