Wohnzimmerhostblogger

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

... schlug heute bei uns eine Kundenreaktion auf. Als außergewöhnlich würde ich diesen Umstand eigentlich nicht bezeichnen, es kommt schon mal vor, dass etwas mit der Rechnung nicht stimmt, wir etwas vergessen haben oder ein ausländischer Kunde nur seine Umsatzsteueridentnummer nachtragen lassen will (ebenfalls heute geschehen).

Aber mit dieser Reaktion habe ich echt nicht gerechnet:

Gerne. Mach ich heute abend fertig. Du bist und bleibst der beste Webhoster den ich kenne

... aber war natürlich mehr als hoch erfreut!

Eine der Aufgaben aus dem Support, die eigentlich recht unbeliebt war, war es "Abwesenheitsnotizen" für unsere Kunden einzutragen und wieder zu entfernen. Eigentlich ein Standard-Feature und der Aufwand der wir hier betrieben haben stand eigentlich nicht in Relation zu dem Ergebnis.

Seit heute ist das nun anders - quasi passend zum Ferienbeginn in Baden-Württemberg:

Bei uns im Kundeninterface findet sich ab sofort ein Widget zum Bearbeiten von Abwesenheitsnotizen. Wobei es sich hierbei nicht nur um die einfache automatisierte Nachricht "Ich bin dann mal weg!" handelt, vielmehr kann der geneigte Kunde auch gleich den Zeitraum festlegen, in dem die Nachricht verschickt werden soll. Das spart Stress vor der Abreise und funktioniert trotzdem auf den Punkt genau.

Viel cooler als diese kleine Standardfunktion finde ich unsere damit verbundene "Vertreter-Regelung" - die richtet sich wohl eher primär an unsere Geschäftskunden (bzw. dort wo man einen Vertreter stellen kann und es auch nötig ist). Die Funktion tut eigentlich genau das, was ihr Name auch andeutet: Neben der Abwesenheitsnotiz (oder ohne diese) kann man einen Vertreter festlegen, der für die Dauer der Abwesenheit die E-Mails mit einem entsprechenden Vermerk (z.B. auch mit Hinweis wann die Regelung endet) weiterleitet.

Bevor sich jemand wundert: Der entsprechende Bereich im Kundeninterface wird in Kürze noch einmal umgestaltet, weil wir im Hintergrund noch mehr Funktionalität hinzufügen.

Kommentator Björn hatte in meinem Posting zu unserem neuen SVN-Backend angemerkt, dass es doch eventuell nett wäre HTML-formatierte Diffs in der E-Mail zu einem SVN-Commit zu erhalten.

Da wir bis dato keinerlei Diffs an die E-Mail angehangen haben, sondern nur den Kommentar des Commits sowie die betroffenen Dateien aufgelistet haben, war das ein recht schöner Einwurf, den wir auch recht gerne umgesetzt haben. Seit gestern nun kann man also auswählen, ob man die Unterschiede eines Commits nun im "rohen Format", als HTML-Formatierte Datei, beides oder eben gar nicht haben möchte.

Endlich eine Option mehr im Subversion-Menü!

Fast schon heimlich, still und leise haben wir im Webhosting in den vergangenen zwei Wochen zwei neue Features implementiert:

Zertifikat-Verwaltung

Kunden, die mindestens "SSL via SNI"-Unterstützung in ihrem Webhosting-Paket haben, können nun vollkommen selbstständig eigene Zertifikate hoch (und runter) laden und in den Einstellungen des jeweiligen Webservers auswählen und aktivieren.

Auf spezielle Anfrage war ich gestern nacht noch so flink hier einen PKCS#12-Export hinzuzufügen, da einem Kunden das wohl massig viel Arbeit beim Import der entsprechenden Zertifikate im IIS erspart. (Hintergrund: Wir nutzen das Kundeninterface auch um Zertifikate auszutauschen, die nicht direkt für den Einsatz bei uns gekauft wurden)

Keine IP-Adressen mehr für CGI-Skripte und Protokolle

Die Zugriffsprotokolle kann man bei uns ja schon seit ein paar Jahren anonymisieren bzw. komplette Felder herausstreichen. Nicht betroffen vom Filter waren bisher das Fehlerprotokoll und die CGI-/PHP-Skripte unserer Kunden. Nicht ohne Grund prangert auf unserer Datenschutz-Seite der Hinweis:

Wichtiger Hinweis: Die Filterung und Anonymisierung dieser Daten bezieht sich ausschließlich auf die Protokollerstellung auf Providerseite, dem Kunden stehen zur Dauer der Anfrage weiterhin die kompletten Daten zur Verfügung und könnten durch den Kunden noch anders weitergenutzt werden.

... und irgendwie war mir das immer ein gewisser Dorn im Auge, denn es bricht das Konzept der Seite.

Seit Mai letzten Jahres rollen wir in unseren Webservern "mod_removeip" mit aus, d.h. wer es wusste hätte es nutzen können. Seit vergangener Woche haben wir nun auch einen einfach zu bedienenden Schalter im Kundeninterface unter "Webserver" » "Datenschutz", mit dem sich diese Einstellung bequem pro Domain regeln lässt.

Zu meiner großen Freude erfüllen wir damit z.B. die Anforderungen von "Wir speichern nicht". Wobei ich hier noch auf Antwort über die Nutzungsbedingungen des Siegels warte. Sobald die da ist, werden wir auch die oben genannte Datenschutz-Seite überarbeiten.

Viel mehr Änderungen gab es bisher nicht, aber noch viel mehr sind geplant. Um sie mal der vermutlichen Chronologie nach aufzulisten: Python/WSGI, Jabber/XMPP, Ruby/embeded Ruby, SCP/SFTP und und und...