Technik

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

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.

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.

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

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.