Wohnzimmerhostblogger

Aus einem Gespräch mit einem möglichen Lieferanten heute morgen (schlechtes Gedächtnisprotokoll):

Ich muss Sie vorab schon einmal enttäuschen, solche Reaktionszeiten wie Sie bekommen wir nicht hin.

Sollten Sie mir einmal eine E-Mail schreiben kann es schon mal ein oder zwei Tage dauern bis Sie mit einer Antwort rechnen können.

Kein Problem damit! Auch nicht mit solch versteckten Komplimenten

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 hatte heute morgen einen (mir eher unangenehmen) Kontakt mit den Geschäftsführern eines unserer Kunden. Es ging um die Frage, warum die Bitte zum Anlegen von SVN-Benutzern noch nicht ausgeführt worden sei - schließlich würde die entsprechende E-Mail ja schon einige Zeit bei mir liegen.

Wie sich im Gespräch dann herausstellte, war die Mail deutlich jünger als 24 Stunden, lag also noch keinen Tag in meiner (persönlichen) Mailbox und auch auf Seiten des Kunden war woein Eindruck von Dringlichkeit entstanden, der wohl weder vom Verfasser der ursprünlgichen Bitte (ein Mitarbeiter des Kunden) beabsichtigt noch mit mir kommuniziert worden war.

Schlussendlich schrieb mir der Geschäftsführer:

Das kling ja eher wie:

"Sie waren ja sonst immer sofort aktiv, jetzt hat es einige Minutengedauert."

Das ist doch eine sehr hohe Service-Qualität.

Welch erfreuliches Ende! Eigentlich ist das auch nicht ganz unüblich, es gab sogar schon mal den Fall wo ein Kunde nach knapp 3 Stunden fragte, ob seine Mail überhaupt angekommen sei und kommentierte dies mit "wir wären ja sonst nicht so langsam". Aber den Weg bis rauf in die Geschäftsführung hat solch ein Umstand heute zum ersten Mal genommen, aber super wenn wir nun auch dort einen Stein im Brett haben

In letzter Zeit erwische ich mich immer wieder dabei, dass ich bei einigen Kunden vor Ort die Strompreise raussuchen lasse, wenn es darum geht, dass wir für diese Hardware anschaffen und vor Ort bereitstellen.

Mit dieser Information sowie einer Messung des Verbrauches von evtl. schon vorhandener Hardware, kann ich dem Kunden dann oft zeigen, dass Energie-Effizienz nicht nur was für "Ökos" (sofern es die so überhaupt noch gibt) ist, sondern sich über die Zeit hinweg durchaus auch auszahlen kann und es manchmal sogar wirtschaftlich ist auch dann neu anzuschaffen, wenn auf den ersten Blick gar kein Bedarf dazu besteht.

Das ist zwar etwas mehr Arbeit für mich, macht aber durchaus Spaß und zeigt vielen Kunden, dass es uns eigentlich niemals nur um den nackten Umsatz geht.

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