Wohnzimmerhostblogger

Ich hatte das Thema schon in einem recht langen Blog-Post ausformuliert, allerdings habe ich das Fenster ohne zu speichern einfach so geschlossen. Insgesamt ist es auch ein für mich persönlich recht schwieriges Thema, aber ich finde das es im Rahmen einer "kompletten Berichterstattung" auch in diesen Blog gehört - immerhin berichte ich hier das eine oder andere Mal über unseren "tollen und super-schnellen" Support, doch auch hier arbeiten nur Menschen und nicht immer läuft alles rund. Um es für mich schmerzlos zu halten, formuliere ich es recht knapp.

Eines Nachts vor ca. einem Monat  hatte ich mit einem Interessenten per Jabber/XMPP ein paar Sonderkonditionen ausgehandelt. Zur Bearbeitung am nächsten Tag hatte ich die entsprechende E-Mail in meinen Ordner sortiert und dort vergessen. Wer die Verantwortung hierfür trägt ist klar: Ich. Und die einzige Möglichkeit die ich bei sowas habe ist "die Flucht nach vorne": Sofort eine E-Mail schreiben und um Entschuldigung bitten und hoffen, dass dem stattgegeben wird.

Ob man mir in diesem Falle verziehen hat? Ich glaube nicht so recht dran, denn den Kunden haben wir nicht bekommen. Wobei ich in so einem Falle eigentlich auch nicht mehr davon ausgehe - denn je nachdem wie lange wir nicht von uns hören lassen, ist es schon ein arg schlechtes Bild, dass wir von unserem Support präsentieren - aber man kann es ja versuchen und eine Entschuldigung ist das mindeste, was man von einem Dienstleister erwarten kann.

Auch mit dem Wissen mir zum Schluss Mühe gegeben zu haben, ist das ein schwarzer Tag für mich und es wird einiges an Schokolade und positivem Zuspruch brauchen bis ich das verdaut habe. Irgendwo gehört zum Verdauen auch, es hier erwähnt zu haben, denn auch bei uns gibt es offensichtlich nicht nur Sonnenschein. Wehe es dreht mir da jemand einen Strick draus!

Seit heute betreiben wir (wie schon einmal angedroht) auf unserem Jabber/XMPP-Server eine c2s-Komponente, die alle bei uns gehosteten Domains bedient und auf den wohlbekannten Standard-Ports 5222 und 5223 (klassisches SSL) horcht.

Für ganz restriktive Umgebungen haben wir noch die Ports 80 (HTTP) und 443 (HTTPS) hinzugefügt. Damit sollte der Dienst wohl für alle Nutzer von überall erreichbar sein. Auf den von vorne herein verschlüsselten Ports liefern wir unser SSL-Zertifikat für ssl.tiggerswelt.net aus - das ist nicht direkt schön, aber offiziell signiert. Für die modernere StartTLS-Variante funktionieren die jeweiligen Kunden-/Domain-spezifischen SSL-Zertifikate bzw. wieder unser SSL-Zertifikat als Fall-Back.

Einziger Nachteil bei dieser Variante: Änderungen auf Kundendomains spielen wir maximal alle 2 Stunden ein. Das bedeutet zum einen, dass Änderungen an der XMPP-Konfiguration wie z.B. verwendetes Zertifikat, Passwort-Änderungen oder Benutzer-Registrierung werden nur stark verzögert übernommen. Zudem kann es dann entsprechend im "worst case" zu einem Disconnect aller Nutzer auf dieser Komponente kommen.

Ich bin mal gespannt, wie viele die neue Variante nutzen werden und wie oft da tatsächlich neu gestartet wird.

Ich musste mal wieder das Rad neu erfinden... Für interne Zwecke wollte ich einen Content-Filter installieren, der bestimmte E-Mails, die bei unserem Postfix ankommen, verarbeitet.

Ich wette es gibt mindestens eine Hand voll Lösungen da draußen, die genau das tun was ich brauche - aber ich habe sie wie üblich nicht einmal gesucht, sondern sofort eine eigene Implementierung zusammen geschrieben. In knapp 40 Minuten habe ich in 350 Zeilen Quellcode insgesamt 9095 Zeichen zusammengetippt, wobei knapp 2/3 davon Kommentare und Dokumentation sind. Wenn man mal bei Seite lässt, dass ein paar Validierungen fehlen ist das Ding sogar komplett Konform zu RFC 5321.

Wenn man bedenkt, dass sich selbst produzierter Code meistens besser in unsere Umgebung integriert als jeder andere Fremdkörper, bin ich mal gespannt oder würde gerne wissen, was in Sachen Maintinance mehr Arbeit bereitet. Da das Ding aber wesentlich mehr Dokumentation im Quelltext besitzt als die meisten OpenSource-Applikationen die mir bekannt sind, sich ohnehin nach unseren internen Programmier-Richtlinien richtet und bei uns wohlbekannte Schnittstellen verwendet bin ich aber recht zuversichtlich, dass die Rechnung zu meinen Gunsten aufgeht

Es gibt doch nichts schöneres als mit einem geknackten osCommerce in den Tag zu starten.

Auf ein neues also das Superman-Kostüm anziehen und die bösen Jungs jagen!

Nachdem wir im Test-Betrieb nun ein paar tausend E-Mails mit S/MIME und GnuPG testweise verschlüsselt haben, habe ich heute die entsprechende Komponente heute für den Produktiv-Betrieb freigegeben.

Das heißt aber erst einmal rein gar nichts bzw. bieten wir das Feature noch nicht von der Stange ab an, sondern schlagen jetzt erst diesen Weg ein und automatisieren den Vorgang. Pünktlich zu Weihnachten darf dann aber bestimmt jeder Kunde seine E-Mails in einem kryptographischen Geschenkpapier einpacken - wenn er denn will.

Analog dazu arbeiten wir auch schon an einer weiteren Komponente, die das selbe auf der Postausgangsseite realisiert. Entweder automatisch verschlüsseln oder - wenn der Kunde unbedingt will und soviel Vertrauen aufbringt - signieren. Die Postausgangsseite wird wohl auch noch mit anderen Features, die speziell auf Geschäftskunden abziehlt, etwas mächtiger werden. Dazu bewahre ich aber erst einmal stillschweigen, zumal hier auch noch nichts in trockenen Tüchern ist.

Der erlehmann hat beim diesjährigen Google Summer of Code mitgemacht und ein Plugin für Wordpress entwickelt, mit dem sich recht einfach Lizenz-Informationen für im Blog verwendete Bilder verwalten lassen.

Eigentlich ein Muss für jeden, der 1.) Wordpress verwendet und 2.) ab und zu fremde Bilder in seinem Blog verwendet. 

Ich habe heute für einen Geschäftskunden auf knapp 6 Seiten zusammengefasst, was es alles bei einer Migration seines E-Mailservers zu uns zu bedenken gibt. Gerade bei Geschäftskunden gehören E-Mails ja mittlerweile zu einem durchaus geschäftskritischen Bereich, von daher kann ich auch jedes Zögern eine bestehende Konfiguration anzufassen vollkommen nachvollziehen, da leg ich mich dann auch gerne dementsprechend ins Zeug und schreibe solche Zweifel aus der Welt.

Fast anderthalb Seiten in diesem Dokument gingen um die Anforderungen, die der Kunde eigentlich an so ein E-Mail-System haben sollte. Ich habe versucht* den Anforderungskatalog Anbieter-neutral zu halten und habe erst im Nachhinein einen kritischen Blick auf die Liste geworfen, was wir davon eigentlich erfüllen und/oder leicht erfüllen könnten. Selbstredend waren darunter viele Punkte aufgeführt, die der aktuelle E-Mail-Provider des Kunden nicht bietet - sonst würde der Umzug wohl auch wenig Sinn machen, wenn man von der Zufriedenheit des Kunden mal absieht. Zu meiner großen Freude aber musste ich nur bei einem einzigen Punkt klein bei geben, alles andere können wir nahezu von der Stange anbieten.

Eine Antwort auf mein Schreiben habe ich natürlich noch nicht erhalten. Für den Moment bin ich aber doch schon sehr zufrieden und fühle mich gut mit unserem E-Mail-System. Wie ich mich kenne wird das aber nur eine Momentaufnahme sein, denn dieser eine Punkt wird mich fuchsen, zudem habe ich noch einen Haufen anderer Ideen

* Versucht in dem Sinne als das ich selbst als Anbieter niemals ganz neutral agieren werden kann, so sehr ich das auch wollen mag.

Ich habe gestern nun endlich aktiv damit begonnen, unseren Jabber/XMPP-Server um eine MUC-Komponente zu erweitern.

Ein wenig überrascht war ich schon, denn bevor ich zur eigentlichen Arbeit gekommen bin, hagelte es erst einmal ein paar Patches für meine Event-Bibliothek, meine XMPP-Komponente und natürlich auch die recht generische MUC-Implementation von mir.

Am Ende des Tages war ich dann aber doch recht zufrieden und fast schon wieder im Arbeitsrausch. Die Sache mit dem Klappe halten hat bei einem kurzen Test auf unserem Produktiv-Server recht gut funktioniert, wenngleich mich die 700 KB an Traffic überrascht haben, die bei einem einfach Start der Komponente mit Authentifizierung und dem Bekanntmachen mit anderen Komponenten auf dem Server (presence und Service-Discovery) verbraten wurden.

Was jetzt noch fehlt ist das dynamische Hinzufügen und Entfernen von MUC-Domains und alles, was so zu einem Chat-Raum dazu gehört - wobei beides wohl weniger ist, als es klingt - und natürlich jede Menge Ideen, die das Ding einzigartig machen

Wer schon eine Jabber/XMPP-Instanz bei uns hat und an einer Public-Beta interessiert ist, darf mich gerne mal anschreiben.

Vor einiger Zeit schon musste ich ein recht komischen Zettel auf meiner Tastatur finden...

Interview für Essen

Da so ein Fernsehbeitrag ja durchaus ein Stück Eigenwerbung ist, die Sache um die es primär ging es definitiv wert war und überhaupt der Tag zwar recht anstrengend, aber doch wunderschön war, empfand ich es etwas fehl am Platze auch noch Geld dafür anzunehmen. Anscheinend dichtet man mir nun an, ich würde getreu dem Motto "Will code for food", Interviews gegen Essen geben.

... mach ich doch gerne, wenn man a) mir überhaupt zuhören will und b) das Thema stimmt!

Wir betreiben ja bekanntlich einen Jabber/XMPP-Server mit einigen Domains unserer Kunden.

Vergangene Woche kam hierzu die Frage auf, ob es eigentlich möglich ist, hier eine Komponente anzuschließen, die nicht bei jeder Domain (in der Service-Discovery) als verfügbarer Dienst angezeigt wird. Gerade wenn es darum geht personalisierte Dienste auf den Domains der Kunden oder speziell gebuchte Dienste für einen speziellen Kunden anzubieten.

Die Antwort hierauf ist recht einfach: Ja, es geht!

Ganz egal, ob die Komponenten mittels XEP-0114 oder mit dem nativen Component-Protocol des Jabberd2 (bzw. hier sobald eine Domain gebunden wird) an den Server "angeschlossen" werden, der Router sendet immer einen <presence>-Tag an alle anderen Komponenten, darunter auch die Session-Manager für die Kundendomains. Diese veranlassen daraufhin eine Service-Discovery, deren Ergebnis sie zwischenspeichern und bei eingehenden Anfragen einfach weiterreichen. Wenn wir also nicht wollen, dass ein Dienst unterhalb einer bestimmten Kundendomain angezeigt wird, unterlassen wir einfach Service-Discovery-Antworten an diese Domain.

Schade nur, dass ich selbst auf die Idee kommen musste und mir eigentlich keine Komponente auf dem freien Markt bekannt ist, die so eine Funktionalität von Haus aus anbieten würde. Egal, ich muss das Rad ja sowieso immer neu erfinden

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