Wohnzimmerhostblogger

Die Mitarbeiterin eines Kunden bat mich gestern darum, ihre E-Mail-Adresse heute abzuschalten bzw. auf die allgemeine info@-Adresse umzuleiten. Ich schrieb ihr, dass sie sich dann nicht wundern sollte, wenn es heute still wird. Ihre Antwort folgte prompt:

Ich werde nicht weinen

Vielleicht ein bisschen, wenn es zu still wird!

Sie sind - wie immer - mein ganz persönlicher Held! Ganz vielen lieben Dank!

Als ich ihr heute ihre vorerst letzte E-Mail (zumindest an diese Adresse) schrieb um sie vor der Umleitung zu "warnen" konnte ich mich bzgl. der Stille nicht ganz zurück halten:

Bei Ihnen bin ich recht zuversichtlich, dass in absehbarer Zeit "zu still" nicht zu den ernst zu nehmenden Problemen zählen wird. Aber das ist mitunter ja ein recht erfreulicher und wünschenswerter Zustand. Mitunter... Vielleicht nicht komplett...

Ich knipse Ihre E-Mail-Adresse nun ab und wünsche Ihnen schon mal alles Gute für die Zukunft! Bis in 3 Jahren dann.

Für die, die es noch nicht geahnt haben: Sie geht in den Mutterschaftsschutz. Und ich merke dabei, dass ich wohl mittlerweile so langsam in das Alter komme, wo man sich fast schon voller Neid für sie freut und sich dabei denkt "Wann bin ich denn endlich mal dran?".

Ach ja: An dieser Stelle auch nochmal ein "Herzlichen Glückwunsch!" an den Rackblogger. (Hat aber nichts mit dem oben erwähnten Fall zu tun, außer dass es gerade wohl "In" ist)

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.

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

Heute ist wohl schon wieder der "System Administrator Appreciation Day" - und ich hätte es schon wieder fast verpasst, wäre da nicht ein aufmerksamer Kunde gewesen, der sich schon zu Beginn unseres Arbeitstages gemeldet hat:

Heute ist der System Administrator Appreciation Day,
daher wollte ich mich mal für das gut funktionierende Hosting bedanken.

Vielen Dank, Hermann!

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