Technik

Nachdem wir vor knapp 2 Wochen vom Rechenzentrums-Betreiber hier in Stuttgart ein IPv6-Netzwerk zu testzwecken überlassen bekommen haben, habe ich mich mal auf gemacht und die IPv6-Sandbox auf ein Produktiv-System übernommen, vorerst aber nur das vHost-Backend und die angepassten "allgemeinen" Funktionen (a la "Welche IP-Adressen sind für diese Maschine konfiguriert").

Unsere Haus-eigene Auto-Konfiguration (nicht zu verwechseln mit der von IPv6 oder DHCP) gilt es noch anzupassen - die mittlerweile recht eingestaubte Bash-Skript-Sammlung weiß noch rein gar nichts über die Existenz von IPv6, sodass jedes System, das bisher auf IPv6 hört, manuell konfiguriert wurde und nach einem Reboot alles vergisst. Für einen Produktiv-Betrieb mit dem Label "Wir können nun IPv6" natürlich überhaupt nicht ausreichend.

Alles in allem bin ich recht zuversichtlich. So hat sich z.B. auch herausgestellt war, dass es gar nicht falsch war schon im Jahr 2006 unser System vollkommen mit der Fähigkeit zum Multihoming auszustatten. Klingt vielleicht ein wenig abwegig, aber dadurch haben wir bei einem Dualstack-Betrieb, also IPv4 und IPv6 gleichzeitig, überhaupt keine Probleme mit der Konfiguration - das handhabt unser Backend vollkommen automatisch.

Eine spannende Frage ist dann noch, wie wir mit dieser Fülle von IP(v6)-Adressen in Zukunft dann umzugehen haben. Es gab schon Anmerkungen, dass man ja "in Zukunft" (vielmehr in einer goldenen Zukunft) genug IP-Adressen hätte um jedem Kunden (oder jeder Domain) eine eigene zu geben. Aber irgendwie schrecke ich vor sowas noch zurück.

Mein Helferlein #1 hat dazu gestern schon den Kopf geschüttelt:

Um das SCP-Protokoll besser zu verstehen, habe ich gestern einfach mal einen SCP-Server in PHP geschrieben. Zu meiner großen Überraschung hat das Ding auch auf Anhieb wie erwartet funktioniert.

Produktiv wird es den aber natürlich niemals geben. Es war wie bereits erwähnt nur ein kleines Projekt um mal einen Blick hinter die Kulissen zu werfen. Wer sich für den Code interessiert, kann btw. hier einen Blick drauf werfen - finde ich allemal besser zu lesen als die scp.c aus dem OpenSSH-Projekt

Für meine nächste Zugfahrt habe ich schon einen weiteren Kandidaten: S F T P!

Ich bin heute morgen recht früh aufgewacht und schaffte es nicht weiterzuschlafen. Aus etwas Verzweifelung heraus bin ich dann also aufgestanden und habe erst einmal alles fürs Frühstück vorbereitet. Da ich dann aber immernoch ca. anderthalb Stunden bis zur Sendung mit der Maus hatte, habe ich mich an XEP-0045 heran gemacht.

Das besagte XEP beschreibt den "Multi-User-Chat" für XMPP/Jabber, also die Möglichkeit auf einem XMPP-Server einen Chatraum aufzumachen und eine Konversation mit mehr als zwei Teilnehmern zu führen. Das XEP zu lesen steht schon seit gefühlten 2 Jahren auf meiner ToDo, aber irgendwie erschien es beim ersten Blick immer so aufgebläht und riesig. Doch falsch gedacht! Auch dieses XEP ist nur mit Wasser gekocht und in den meisten Stellen recht trivial.

Ich habe es mir nicht nehmen lassen während des Lesens einfach mal eine Test-Implementation auf Basis meiner bereits vorhandenen XMPP-Bibliothek zu schreiben. Hat super funktioniert und ist mit minimalem Funktionsumfang (ohne Administration oder Moderation) absolut lauffähig. Das bringt uns dem Thema auch Chaträume auf unserem XMPP-Server anzubieten etwas näher, wobei sich dann die Frage stellt, ob man eine bestehende Lösung nimmt oder gleich auf den Eigenbau setzt.

Schlussendlich habe ich ca. 30 KB Code (und größtenteils Kommentare und Leerzeichen) in knapp 2 Stunden generiert. Wenn ich bei dem Tempo bleibe, überhole ich noch die Ergebnisse der Google Summer of Code Meinen Code gibt es btw. wie so oft als CC BY-SA hier - sollte es irgendwen interessieren.

Wir sind gerade mal 10 Monate in unserem neuen Rechenzentrum und schon hege ich den Plan einfach mal alles nach und nach abzuschalten.

Grund hierfür ist weder ein ausgeprägtes BOfH-Syndrom noch eine Geschäftsaufgabe (Gott, behüte!). Vielmehr sind wir stets bemüht in Sachen Energie-Effizienz recht weit vorne mitzumischen. So verbrauchen unsere Energie-Hungrigsten Prozessoren momentan max. 32,5 Watt pro Kern und wir achten beim Anschaffen neuer Hardware stets auf ihre Energie-Effizienz (um genau zu sein ist das Kriterium #1) oder lassen die CPUs gerne mal mit dem "ondemand"-Governor laufen.

Okay, ich verrenne mich etwas. (Wobei im ausgeschalteten Zustand natürlich die Energieeffizienz natürlich atemberaubend wäre)

Grund des geplanten Abschaltens ist ein Positionswechsel innerhalb des Rechenzentrums. Wir verlassen unseren angestammten Cage und wechseln in einen neuen Raum - ausgestattet mir Warm- und Kaltgängen. Ich freu mich schon drauf! Gerade im Sommer ist es schön im kalten Gang zu stehen, wohingegen ich im Winter wohl den anderen vorziehen werde.

Momentan bereiten wir noch die "Rahmenbedingungen" für den Umzug vor, d.h. schalten Patches zwischen den Racks, stellen neue Switches auf und planen den Umzug in der Theorie durch. Wir werden den Umzug natürlich Stück für Stück durchführen um die Ausfallzeiten so gering wie möglich zu halten. Darüber hinaus werden wir die meisten Webserver (die mittlerweile in einem virtuellen Container laufen) während des Umzugs auf einen Fallback-Host im neuen Rack umstellen.

Ich habe soeben die relativ neuen PHP-Versionen 5.2.14 und 5.3.3 fürs Webhosting freigegeben.

Bei Bedarf oder auf speziellen Wunsch hin werden wir diese Versionen also auf unseren Webservern ausrollen.

(Im Falle von 5.3 werden wir aber weiterhin auch 5.3.2 im Produktiv-Betrieb anbieten, da 5.3.3 eine nicht rückwärts-kompatibele Änderung in Sachen Namespace-Hanling beinhaltet)

Bevor ich mit dem eigentlich Artikel beginne: Wir haben uns darauf geeinigt folglich immer von XMPP/Jabber zu sprechen. Früher hieß es Jabber, für das Protokoll an sich ist mittlerweile XMPP eigentlich richtig. Mit XMPP/Jabber ist wie ich finde ein guter Mittelweg gefunden worden, der zum einen den Wiedererkennungswert von Jabber hat und die korrekte Bezeichnung XMPP beinhaltet. Zudem finde ich, dass es einfach geekig klingt und folglich toll ist

Wir haben vergangene Woche unser Backend für unseren XMPP/Jabber-Dienst auf eine komplett neue Software umgestellt. Das System haben wir von Grund auf neu geschrieben und keine Altlast aus dem Vorgänger übernommen. Im Gegenzug sind ein paar allgemeine Verbesserungen aus unserem Framework integriert worden, was die Konfiguration insgesamt etwas eleganter und effektiver gestaltet. Bis auf weiteres läuft es jetzt schon runder als vorher.

Im selben Atemzug haben wir den entsprechenden Bereich im Kundeninterface überarbeitet und den Server ausgewechselt. Schon im alten System war es möglich neben virtuellen Jabber-Benutzern auch "ganz normale" Benutzeraccounts zu verwenden. Dieses Feature haben wir noch ein stück weit ausgebaut, sodass man nun u.a. den lästigen Prefix wegkürzen kann. Wo früher nur kunde_name@domain.de funktionierte, tut es mittlerweile (auf Wunsch) zusätzlich name@domain.de

Richtig kurios finde ich auch die neue Benutzer-Verwaltung: Die haben wir komplett an unser E-Mail-Backend angelehnt - Authorisation, Registrieren und Löschen von Benutzerkonten funktioniert nun über die von Postfix gewohnten Mechanismen und ist dementsprechend auf Performance ausgelegt (wenngleich nicht notwendigerweise) hinzu kommt der Vorteil eine Schnittstelle weniger Pflegen zu müssen.

Alles in allem war das wieder mal nur der Startschuss für weitere Veränderungen - meine Liste hierzu ist noch elendig lang. Als nächstes werden wir alle Domains über die Standard-Ports 5222 und 5223 (SSL) verfügbar machen. Und als kleines Schmakerl noch 80 (HTTP) und 443 (HTTPS) oben drauf legen. Und ja: Die Transports sollen auch zurück kommen.

Ich musste schon recht lange blättern bis ich schlussendlich den gesuchten Blog-Post gefunden habe:

Vor 3 Jahren schrieb ich von der Idee E-Mails bei ihrem Eintreffen bei uns mittels einem öffentlichen Schlüssel (den der Kunde uns überlasst) zu verschlüsseln und somit nur verschlüsselte E-Mails abzuspeichern.

Seitdem sind viele, viele E-Mails verschickt und empfangen worden und nicht viel ist passiert. Es gab mal eine Art Proof-of-Concept-Skript, der als rudimentärer Filter für Procmail funktionierte. Wenn man bedenkt, dass dort ca. eine Stunde arbeit drin steckte liegt auf der Hand, dass er natürlich nicht fehlerfrei funktionieren konnte.

Nachdem ich mir aber nicht zuletzt wegen unserer Vertreter-Funktion oder auch dem Support-Filter (der Erweitert Kunden-E-Mails um deren Leistungsdaten bei uns) eine Programm-Bibliothek gewünscht (und bekommen) habe, mit der sich E-Mail leicht "manipulieren" lassen, hat das Projekt wieder etwas Leben bekommen:

E-Mails an den Support werden bei ihrem Eintreffen nun kopiert und zu Testzwecken S/MIME- und GnuPG-verschlüsselt in einem speziellen Verzeichnis abgelegt. Der Test läuft bereits seit einiger Zeit sehr erfolgreich - wenn man denn von ein paar Ecken und Kanten absehen mag. Eigentlich ist es nur noch reine Formalität das Ding mal produktiv zu schalten, aber wirklich trauen tue ich mich noch nicht

Ich habe gerade eben die erste erfolgreiche Anfrage an unseren experimentellen WSGI-Server für Python gestellt.

Der Weg hier hin war recht steinig und ging über Verständnis-Probleme bzgl. des WSGI PEP über Stolperfallen in der Python-API bis hin zu den üblichen Speicherzugriffsfehlern in C. Ganz fertig ist der WSGI-Server aber noch lange nicht - so stürzte der Server prompt bei der zweiten Anfrage ab, aber das wird wohl nur eine Sache von Minuten sein...

Die Freude war erst einmal so groß, dass ich diesen Zwischenschritt erst einmal bloggen musste

Nachtrag: Wer Py_Finalize() anstelle von PyEval_ReleaseThread() aufruft ist selbst schuld

Ich habe den Eindruck, dass unser System unter der Haube immer mehr einem Gentoo ähnelt. Zwar setzen wir im Rumpf unserer Server eine ganz andere Linux-Distribution ein, aber ich sag schon immer scherzhaft, dass wir die eigentlich nur wegen dem Compiler brauchen.

Um eine einheitliche Hosting-Landschaft zu gewährleisten kommt der meiste große Rest aus unserem Haus-Internen Software-Management und integriert sich nahtlos in die Hosting-Umgebung. Und auch wenn mal ein Server zwischen den Rechenzentren bewegt wird, taumelt er nicht orientierungslos durch die Gegend, sondern versucht sich die Frage nach dem "Wo bin ich?" einfach selbst zu beantworten (ohne DHCP ).

Neben dem Compiler gab es aber auch immer noch ein paar Tools, die das Host-System noch vorhalten musste: make, patch, tar und autoconf. Letzteres primär um beim Compilieren von PHP ein paar PECL-Erweiterungen einzubinden.

Nachdem ich vergangene Woche aber das neue OpenSuSE 11.3 zu Testzwecken in einer Sandbox installiert hatte, bin ich jedoch schier verrückt geworden, denn besagte PECL-Erweiterungen wollten sich partout nicht installieren lassen sondern störten den kompletten Build-Prozess von PHP. Irgendwann fand ich im aktuellen Entwicklungs-Zweig von autoconf den Hinweis, dass ein Makro in der aktuellsten Version 2.66 defekt sei - und genau daran störte sich auch PHP.

Ich habe kurzerhand autoconf in der Version 2.63 (mit neueren Versionen scheint es nicht zu funktionieren) in unser Software-Management mit aufgenommen. Und so ist die Liste der Anforderungen an ein Host-System erneut geschrumpft. In ein oder zwei Jahren haben wir somit bestimmt unsere eigene Linux-Distribution - ohne dass es jemand wirklich wollte

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!

Wir haben vor einiger Zeit heimlich, still und leise in der PHP-Bibliothek die hinter unserem Kundeninterface sitzt i18n- bzw. genauer gettext-Unterstützung eingebaut und setzen folglich die entsprechenden Locales in der Programmumgebung wie LC_MESSAGES oder LC_ALL. Dabei ist es dann recht schnell zu Problemen mit einen wie auch Softwaremodulen von Drittherstellern gekommen.

Konkreter Hintergrund: Immer wenn ein float-Wert (also eine Dezimalzahl mit Komma) als String ausgegeben werden sollte, wurden auch hier die entsprechenden Locales angewendet. Natürlich weiß ich, wie man das umgehen kann, aber u.U. ist das durchaus gewollt - außer man will z.B. ein Excel-Worksheet per PHP-Software generieren. Da macht ein float-Wert, der mit einem Komma "getrennt" ist wahnsinnig schnell Probleme.

Wir haben daher die interne Richtlinie ausgegeben für "Zahlen, die nicht direkt von Menschen gelesen werden sollen sondern für die Interaktion mit Software-Schnittstellen gedacht sind" stets die PHP-Funktion number_format() zu verwenden ist. Mich würde freuen, wenn andere Entwickler das auch so handhaben, bei den Bibliotheken die wir gepatched haben, sind die Änderungen auch schon weitergegeben worden.