Technik

Vor zwei Jahren hatte ich es schon einmal hier im Blog:

Jabber-Präsenz API

Und es hat doch tatsächlich so lange gedauert bis ich mich dazu hab überreden lassen, es für alle Jabber/XMPP-Nutzer bei uns zugänglich zu machen.

Auslöser war wie so häufig das einfache Nachfragen eines Kunden, ob es sowas bei uns gibt und dann das herausfordernde "Geb mir kurz mal 10 Minuten" - und es hat tatsächlich nur 10 Minuten gedauert. Wesentlich anstrengender war es dann das ganze noch ins Wiki zu schreiben. 

Ich habe niemals ein Geheimnis daraus gemacht, dass viele unserer Vorgänge verbesserungswürdig sind. Es wäre auch langweilig und vermutlich auch geschäftsschädigend wenn es nicht so wäre oder ich den Eindruck hätte wir wären schon "Perfekt" - schade wäre es dann auch, denn was sollte man den lieben langen Tag tun, wenn man nicht optimieren oder verbessern könnte? Für Däumchen drehen möchte ich nicht bezahlt werden.

"Bezahlt werden" ist ein gutes Thema! Wir haben bei uns keinen festen Rechnungslauf, sondern stellen Rechnungen so wie es gerade passt. Ich habe schon mehrfach darüber nachgedacht, diesen auf ein festes Datum zu legen, z.B. den 1. oder 14. eines jeden Monats, aber irgendwie missfällt mir das - es war ja immer schon ganz anders.

Die Rechnungsstellung an sich hat so oder so ziemlich viele Faktoren, die sich tweaken lassen. Vor ein paar Jahren konnte war es z.B. möglich, dass Domains sofort in Rechnung gestellt wurden, nachdem sie registriert bzw. in der Buchhaltung vermerkt wurden.  War ein bisschen blöd, wenn in relativ kurzen Abständen weitere Domains geordert wurden. Das generiert im ersten Schritt nur unnötig viele Rechnungen, im Nachgang aber auch unnötig viel Arbeit und Kosten. Deshalb schafften wir irgendwann die Möglichkeit Leistungen zu "priorisieren" bzw. so zu flaggen, dass sie nur abgerechnet werden, wenn eine "größere" Leistung wie z.B. Webhosting abgerechnet wurde.

... das funktionierte eigentlich recht gut, nur bildete sich so auch ein "Rückstau" an Leistungen die noch nicht abgerechnet wurden, der im mittleren vierstelligen Bereich lag. Für den Kunden natürlich toll, für uns eher unschön.

Zwischen den Jahren hatten wir daher noch einmal unsere Buchhaltungssoftware verbessert bzw. nachgebessert. So haben wir eine kundenspezifische "untere Grenze" eingeführt, ab der auch solch "nieder Priorisierte" Leistungen abgerechnet werden und z.B. auch das auslaufen des Fiskaljahres berücksichtigt wird und evtl. eine Rechnung erzwungen wird.

Funktionierte super und der Rückstau baute sich kontinuierlich ab (mittlerweile im oberen dreistelligen Bereich)! Bis vor kurzem...

Vor kurzem musste uns dann auffallen, dass ein Kunde in einem recht kurzen Zeitraum relativ viele Rechnungen von uns erhielt. Für das aktuelle Abrechnungsmodell war das absolut in Ordnung, denn der Kunde hatte in kurzen Abständen größere Mengen an Domains bestellt. Ich fand das aber nicht so lustig, den Kunden so häppchenweise mit Rechnungen zu stören, weswegen wir eine Art "Look ahead (and back)"  eingeführt haben:

Unsere Buchhaltungssoftware berücksichtigt nun bei der Rechnungsstellung auch, ob in nächster Zeit weitere Leistungen abzurechnen wäre und verhält sich dementsprechend "ruhiger". Auch wenn dadurch kurzzeitig der Cashflow einbrach fühlt sich diese neue Ruhe doch toll an - ich hoffe selbiges gilt für unsere Kunden bzw. besonders diesen einen

Nachdem ein Kunde gestern ein paar Probleme mit seinem zugesicherten Arbeitsspeicher bemängelt hatte, habe ich intern ein paar Nachforschungen angeregt um die Ursachen dafür zu finden und auch für die Zukunft ein paar mehr Daten zu haben.

Heraus gekommen ist dabei u.a. ein kleiner Benchmark, der die PHP-Optimizer APC, eAccelerator und XCache nicht auf die Geschwindigkeit in der Skripte ausgeführt werden sondern auf die Nutzung von Arbeitsspeicher hin untersucht. Unsere Ergebnisse teile ich gerne mit dem Rest der Welt.

Legt man die Daten nun neben einen der vielen Benchmarks bezüglich der Geschwindigkeit ergibt sich ein recht schlüssiges Bild. Mich persönlich alarmiert es insgesamt etwas, denn bisher rollen wir eAccelerator als voreingestellten Optimizer aus, der in Geschwindigkeitstest immer zufriedenstellend abschneidet, in unserem Memory-Test aber total versagt. APC hatten wir vor ein paar Jahren aus dem Standard weg degradiert, da der immer mal wieder Probleme mit unserem FastCGI-Setup zu haben schien.

So stehen nun wohl alle Zeichen für XCache als eventuellen neuen Standard. Da haben wir aber (im Vergleich zu eAccelerator) weniger Erfahrungen gesammelt und haben nur wenige Seiten (aber auch recht große) die mit diesem Optimizer laufen. Ich werde in den nächsten Wochen wohl forcieren, dass wir hier Erfahrungen sammeln aber auch APC werden wir uns noch einmal anschauen. Am Schluss wird mit großer Sicherheit ein neuer Standard-Optimizer stehen. Bleibt die Frage, was wir mit dem gesparten Arbeitsspeicher tun - anteilig werden wir den bestimmt an unsere Kunden weitergeben.

Wir haben irgendwann dieses Jahr angefangen unsere Dokumente wie Angebote und Verträge im PDF/A1-Format zu generieren, abzuspeichern und zu versenden.

Gerade eben rief mich unsere Ansprechpartnerin bei einem unserer Distributoren an und meinte sie hätte Probleme den Lieferschein für eine Bestellung eines unserer Kunden zu öffnen. Auch die Logistik hätte es nicht geschafft das Dokument zu öffnen.

Ich habe daraufhin das Dokument noch einmal als "normale" PDF generiert, rübergemailt und schon hat es funktioniert. Merkwürdig, ganz naiv gesagt hätte ich es eher anders herum erwartet, da PDF/A ja auf den ganzen "fancy stuff" verzichtet...

Wir haben PHP heute morgen ein kleines Update spendiert und bieten ab sofort die Versionen 5.2.16 und 5.3.4 zusätzlich an.

Neukunden bekommen ab sofort die Version 5.2.16 auf ihr Webhosting geschaltet, Bestandskunden bleiben vorerst unangetastet können aber jederzeit ein Update per E-Mail erfragen.

Okay, das ging schneller als erwartet:

Unser Mailserver kennt nun das Sender Rewriting Scheme (SRS). Theoretisch gilt das für beide Richtungen, also das Umschreiben des Absenders wenn eine E-Mail weitergeleitet wird und das Umschreiben des Empfängers, wenn eine E-Mail an unsere SRS-Domain empfangen wird. Produktiv verfügbar ist aber vorerst nur zweiterer Dienst - der war einfach leichter zu testen und fällt auch eigentlich gar nicht auf, wenn wir den einfach dazu schalten.

Unsinnig eigentlich, denn ohne das shared secret aus unserem E-Mail-System ist es vermutlich niemandem möglich selbst E-Mail-Adressen zu bauen, die von unserem System akzeptiert werden. Vielleicht wollte da jemand einfach nur ein Kreuzchen auf der ToDo-Liste machen.

Dabei ist die andere Richtung viel interessanter und spannender. Wie ich letzte Woche bereits schrieb haben wir für die SRS-Einführung eigenes einen Patch für das von uns eingesetzte Postfix entwickelt. Wie schon dort angedeutet fehlten dementsprechend eigentlich nur noch zwei Dictionaries (bzw. Lookup-Tables). Eigentlich recht trivial, im Zweifel hätte es gereicht zwei Pipes in Richtung libsrs2 zu legen (wenn wir es denn einsetzen würden), aber das wäre nicht sehr "intelligent".

Der bereits erwähnte "Weg zurück", also das Umschreiben des Empfängers einer E-Mail an unsere SRS-Domain, funktioniert genau so. Darf man machen, da der erste Check hier ein Check der Domain ist und die ausschließlich für SRS verwendet wird. Der vorhergehende Schritt, das Umschreiben des Absenders gestalten wir jedoch etwas differenzierter:

1. Es werden keine Absender umgeschrieben, die von Domains kommen die ohnehin über unseren Mailserver laufen
2. Es werden nur Absender umgeschrieben, die von Domains mit aktivem SPF-Schutz kommen

Kleine persönliche Anmerkung: SRS hat erst einmal nichts mit OpenSRS am Hut. Das sind zwei unterschiedliche Dinge, letztere höre ich mir morgen vermutlich auf den WorldHostingDays im Europa-Park in Rust an

Das Sender Policy Framework (SPF) ist nun schon fast altes Zeug. Immer mehr Domains verfügen über einen solchen "Schutz" und dementsprechend öfter fallen nun E-Mails auf, die "klassisch" weitergeleitet werden sollten - sei es eine E-Mail die von GMX kommt, ursprünglich an eine bei uns gehostete Domain ging und wieder zurück an GMX geleitet wird - und es nicht funktioniert. Die Problematik ist zwar nahezu überall dokumentiert, aber mitunter doch recht schwer zu kommunizieren.

Das Problem ist bei uns eigentlich auch schon ewig bekannt: Seit 2006 setzen wir auf nahezu allen Domains SPF ein und auch der Lösungsansatz des "Sender Rewriting Scheme" (SRS) war uns ein Begriff. Nur mangelt es bis heute irgendwie an einer passenden Lösung für Postfix (so wie es bei uns zum Einsatz kommt).

Zwar gibt es hier und da ein paar Ansätze oder auch Aussagen a la "Wir haben es geschafft", aber konkrete Angaben bzw. Dokumentation oder etwas öffentlich verfügbares für den Produktiv-Einsatz fehlt gänzlich. In ein paar Foren findet man auch oft die Aussage SRS wäre ein Fall für einen Content-Filter. Letzteres ist sicherlich auch ein einfacher und schneller Weg das "Problem" anzugehen, doch scheint mir der Overhead hier recht enorm zu sein. Etwas schlankeres wäre mir doch lieber.

Grund genug sich einmal den smtp-Client von Postfix anzuschauen und mal herauszufinden, was das Ding in die Richtung alles kann. Grundsätzlich bin ich bei Postfix gewöhnt alles irgendwie über Dictionaries umzuschreiben und so Daten nahezu endlos umzubiegen. Ein gutes Beispiel wäre hier sicherlich die Struktur unserer Relay-Funktionalität, die sich auch auf einzelne E-Mail-Adressen beschränken lässt und sich Domains so im gemischten Betrieb verwalten lassen. Oder natürlich auch die Anbindung von Zarafa-Mailboxen im Multi-Tenancy- sowie gemischten Betrieb mit normalen POP3/IMAP-Mailboxen - aber ich schweife ab.

Der SMTP-Client von Postfix kennt mit den smtp_generic_maps tatsächlich auch ein Dictionary um den Absender einer E-Mail umzuschreiben, also eigentlich wäre hier genau der richtige Punkt um mit einer SRS-Implementation anzusetzen. Ein einziges Problem gibt es dann allerdings:
Die smtp_generic_maps kommen sowohl für den Absender wie auch den Empfänger zum Einsatz und man kann technisch bedingt nicht unterscheiden, wonach genau gerade gesucht wird.

Die Lösung des Problems ist daher ganz einfach: Die smtp_generic_maps auseinander friemeln. Genau das tut ein Postfix-Patch (für 2.8 Patchlevel 1) von uns, den ich just in unser Build-System geschickt habe: Neben den smtp_generic_maps führt der Patch die smtp_sender_maps ein, die nur für MAIL FROM:-Einträge konsultiert werden.

Fehlt eigentlich nur noch das passende Dictionary, dass die Verarbeitung bzw. Konvertierung der Absender-Adressen vornimmt. Für den Moment behalte ich näheres dazu aber für mich bzw. überlasse das gerne der Community, zumal wir da noch nichts produktives haben - unsere SRS-Bibliothek hat noch Probleme mit SRS1 nach SRS1. Mal davon abgesehen, dass der Weg zurück noch gar nicht gebaut ist

Wir haben in der letzten Tagen eine Zarafa-Instanz bei uns aufgesetzt. Nun haben wir ja unsere eigene Hosting-Plattform und die richtet sich nicht gerade nach den offiziell von Zarafa unterstützten Betriebssystemen - nun ist die Frage, geht man den von Zarafa vorgeschriebenen Weg oder verbiegt man der Giraffe ein wenig den Hals?

Ich hatte mich in dieser Sache für den zweiten Weg entschieden. Auf Dauer schien es mir der bessere Weg zu sein, zumindest verkleinert es die Zahl der "Fremdkörper" die sich bei uns auf den Servern befinden. Aus dieser Entscheidung resultierten jedoch 3 wesentliche Probleme:

1. Zarafa ist auf eine Webserver-Umgebung mit mod_php ausgelegt
2. Die Webaccess-Oberfläche benötigt die Zarafa-eigene MAPI-Erweiterung für PHP
3. Z-Push ebenfalls auf mod_php ausgelegt

Um das Feld von hinten aufzuräumen: Die einzige Sache, die Z-Push an mod_php bindet, ist ein Aufruf der Funktion apache_request_headers(). Das Problem ist schon im Jahr 2007 im Z-Push-Forum diskutiert worden, hat es aber wohl nie in die offizielle Distribution geschafft - warum auch immer. Neben dem Patch, der in besagtem Forum zu finden ist, haben wir auch einen eigenen Patch geschrieben.

Punkt #1 ist im Vergleich zu #2 auch weniger kritisch. Es scheitert hier im wesentlichen daran, dass die .htaccess-Datei in /usr/share/zarafa-webaccess einfach so php_flag-Direktiven verwendet, die den Apachen dazu veranlassen einen 500er zu werden, wenn mod_php nicht vorhanden ist. Ich finde ja, dass es grundsätzlich guter Stil ist <IfModule>-Direktiven zu verwenden, auch oder gerade wenn man ein bestimmtes Modul voraussetzt.
Die Einstellungen, die man in der php.ini anpassen sollte sind:

register_globals = Off

magic_quotes_gpc = Off
magic_quotes_runtime = Off

post_max_size = 32M
upload_max_filesize = 30M

short_open_tag = On

log_errors = On
error_log = error.log

... das meiste war bei uns ohnehin so voreingestellt. Weiter sollte das Verzeichnis /var/lib/zarafa-webaccess/tmp auch noch für den Benutzer unter dem der FastCGI-Prozess ausgeführt wird schreibbar sein.

Wir bieten seit heute morgen eine gewisse Unterstützung für die Autokonfiguration von Mozilla Thunderbird.

So ganz glücklich bin ich mit dem Status Quo nicht, er mutet an zwei Stellen etwas dreckig an, ist aber definitiv schöner als der Zustand vorher. Zum einen haben wir uns auf den E-Mail-Domains die Subdomain "autoconfig.%DOMAIN" genommen bzw. nehmen müssen.
Eine Delegation der Einstellungen über DNS wäre da wesentlich schöner gewesen und das Thunderbird-Projekt hat da auch schon was in der Mache - funktionieren tut es nur noch nicht

Ein weiterer Nachteil ist, dass sich bei uns der Benutzername von der E-Mail-Adresse unterscheidet oder - anders gesagt - ein Benutzer mehrere E-Mail-Adressen haben kann, die er über die selbe Mailbox abholt. Thunderbird ist sich dieses Umstand bewusst hat aber noch keine Lösung parat, die "stable" wäre. Schlussendlich müssen wir da wohl noch etwas warten - bis dahin schlagen wir als Benutzernamen "BEARBEITEN" vor - mit einem schönen "Bearbeiten"-Button daneben. Ich hoffe mal jeder ist so weise den auch zu klicken

Ein wenig naiv war ich gestern in meinem logischen Denken irgendwie schon. Aber was war überhaupt passiert?

Ich hatte mit PHP ein Objekt über ein Array gelegt und das Interface "Iterator" implementiert um mit einer foreach()-Schleife direkt an die Inhalte des Arrays ranzukommen. Später dann wunderte ich mich, dass ich in einer Schleife immer nur das erste Element aus dem Array geliefert bekam und die anderen stillschweigend verschwanden.

Eigentlich lag die Lösung immer schon direkt vor meiner Nase, denn schon vorher hatte ich mich gewundert, dass wenn ich während der Schleife das aktuelle Element aus dem Array entferne, das nächste übersprungen wird. Eigentlich ganz einfach: Der Zeiger der foreach()-Schleife bleibt an der gleichen Position, nur die Elemente rutschen beim Löschen von hinten nach. Dementsprechend sollte man ihn nach dem Löschen mittels prev() zurück bewegen, bevor die foreach()-Schleife ein next() triggert. Dementsprechend ahnte ich schon, dass es nicht so ganz einfach ist mit meinem Objekt das exakt selbe Verhalten eines klassischen Arrays nachzustellen.

Aber warum lieferte mir die genannte Schleife nur noch ein Element aus einem Array mit mehreren Elementen?
Recht einfach: Mein Array-Objekt hat genau einen Zeiger auf die aktuelle Position im Array. Verschachtelt man nun ein paar foreach()-Schleifen, so entsteht hier ein heilloses Chaos und das Ergebnis wird niemals das erwartete sein.

Die ernüchternde Lösung meines Problems war dann schlichtweg ein IteratorAggregate und somit das Kopieren des Arrays für jede foreach()-Schleife. Ich kann mir gerade Szenarien vorstellen, wo auch das vermutlich schief gehen würde, allerdings sind die mir noch gar nicht untergekommen und ich wüsste ehrlich gesagt auch gar nicht, wie sich da ein normales Array verhält.

Hauptsache es tut für den Moment

Eigentlich ist es ja schon recht lange her, das ich über ein paar Fortschritte bei unserer Python-Implementierung geschrieben habe. Das Projekt war auch zugegebenermaßen auch etwas ins Stocken geraten, da ein paar Aufgaben anstanden, die aus wirtschaftlicher Sicht interessanter waren.

Das ging soweit, dass ich zwischenzeitlich gar nicht mehr wusste, dass die Schnittstelle gar kein CGI mehr spricht, sondern auf WSGI umgestellt wurde. Auch war mir gar nicht mehr bewusst, dass wir schon erste Geh-Versuche mit Ruby als weitere Skripting-Sprache gemacht hatten. Irgendwie ist nun abder doch wieder leben in die Sache gekommen.

Letzte Woche habe ich aus beiden Projekten den FastCGI-Code herausgeschnitten und eine abstrahierte Schicht zwischen Webserver und Skripting-Sprache geschaffen, die insgesamt leichter zu warten und etwas performanter als ihr Vorgänger scheint. Sehr schön
Das Problem, dass Kunden nicht beliebige Programme auf den Servern ausführen sollen, und ihnen auch der Blick in manche Verzeichnisse von vorne herein aus Prinzip verwehrt sein soll (vgl. PHP's open_basedir) ist auch schon angegangen worden - in Form einer lustigen kleinen Bibliothek, die einfach die (f)open's und exec's überlädt und entsprechend beschneidet.

Sowohl beim Überladen wie aber auch beim Abgreifen der Ausgabe eines Skriptes sei gesagt: Python arbeitet gerne mit fopen, d.h. man kann auch die Standard-Ausgabe jederzeit mit Cookies umleiten. Ruby hingegen greift auf das näher am Kernel liegende open zurück und holt sich von jedem FILE-Handle die entsprechende Deskriptor-Nummer. Wer hier eingreifen will muss tricksen - tut auch die abstrakte FastCGI-Schicht.

In beiden Fällen stehen eigentlich nur noch ein paar Tests bzgl. Performance und Ausfallsicherheit an. Viel schwieriger sind da aber dann andere Fragen, zum Beispiel werden Python-Skripte meistens per SSH installiert oder brauchen eine Shell - sowas bieten wir ja erst einmal konsequent nicht an. :-/

Seit gestern haben wir einen sog. Push-Dienst bei uns in der Sandbox, genauer genommen ist es etwas, was eine gewissen Kompatibilität mit Exchange und ActiveSync herstellt.

Irgendwie schon ein wenig gruselig, wenn ich aber auf meinem Handy meine Mailbox auf den Typ "Exchange" ändere funktioniert das oberflächlich ganz gut. Unter der Haube sieht es aber für meinen Geschmack recht grauenhaft aus: Es fängt bei der Definition "Push-Dienst" an. So wie ich die Technik verstanden habe ist das mehr ein Pull- als ein Push-Dienst. Selbiges meint auch das Zugriffsprotokoll des Servers auf dem wir den Dienst bereitgestellt haben - eine Anfrage reiht sich dort an die andere und bettelt den Server förmlich an, dass doch bitte irgendwas passiert sein soll. Da es "nur" ein Add-On für unseren IMAP-Server ist, sieht das Log dort entsprechend aus, denn jede Anfrage an den Push-Pull-Dienst generiert ein Login auf dem Mailserver.

"Technologien" (ich schreibe es in Anführungszeichen, weil der Begriff dafür echt zu groß ist) wie IMAP IDLE finde ich viel schöner: Der Client macht genau eine Verbindung auf, hält diese offen und bittet den Server "Sag mir kurz bescheid, wenn eine neue E-Mail da ist oder sich irgendwas tut". Auf mobilen Endgeräten mag es schon mal zu Verbindungsabbrüchen kommen, aber dann kann man die Verbindung ja wieder aufbauen. Der Exchange-ähnliche Dienst tut das ja auch, mutet da aber eher wie ein BOSH-Client mit weniger Funktion an. Zugegeben: Die BOSH-Entwickler behaupten mit ihrem Protokoll in wiedrigen Umgebungen besser Verbindungsabbrüche abfedern zu können als jeder andere, aber das geht gerade entschieden zu weit und tut hier nix zur Sache.

Meine ersten Erfahrungen waren nun also irgendwie negativ und sehr langsam - wenngleich auch irgendwie stabil. Dennoch bin ich irgendwie abgeneigt den Dienst als offizielles Feature zu erwähnen - hat denn irgendwer Interesse an einer ActiveSync-Schnittstelle zu seiner Mailbox (ohne Kontakte und Kalender)?

In der Diskussionsrunde nach meinem Vortrag am Donnerstag wurde unter anderem nochmal der Wunsch nach einem serverseitigen Gesprächsverlauf um nicht bei einem Wechsel des Clients oder Gerätes zerschnittene Protokolle zu haben.

Nun gibt es bereits XMPP-Dienste, die sowas über eine eigene Oberfläche ermöglichen, es stellt sich aber immer die Frage, ob man will dass die Betreiber der selbigen (offiziell? ) die eigenen Konversationen mitloggen. Der interessierte Geek wird sowieso lieber selber loggen wollen bevor er irgendwem anderes die Macht über seine Daten gibt.

Mir ist das Thema im Kopf geblieben und ich als Geek wollte in dem Fall einfach nur mal spielen.

Heraus gekommen ist dabei eine Jabberd2-Komponente, die sich als "logging sink" am Server anmeldet und Konversationen ganz stupide auf die Festplatte schreibt - natürlich nur sofern dies auch gewünscht wird. Andernfalls wird alles bedingungslos verworfen.

"Gewünscht werden" ist in diesem Fall recht simpel: Der Dienst stellt fest, wem eine Nachricht gehört ("owner") und wer sein Gegenüber ist ("opponent") und schaut nach ob ein Verzeichnis "history/owner/" existiert - wenn dem so ist, wird gelogged.

Die viel spannendere Frage ist dann aber eher, wie man an die Mitschnitte seiner Gespräche kommt. Zwar existiert mit dem XEP-0136 bereits ein Entwurf zum Archivieren von Nachrichten, allerdings ist es wie erwähnt im Monent lediglich ein Entwurf, kaum ein Client unterstützt die Erweiterung und es wird explizit darauf hingewiesen, dass dieser Ansatz noch zu überarbeiten ist. Schade!

Ich habe mich folglich für einen Mix aus Service Discovery (XEP-0030), Ad-Hoc Commands (XEP-0050) und Delayed Delivery (XEP-0203) entschieden und auch über In-Band Registration (XEP-0077) nachgedacht. In der Summe ist es nicht wirklich schön geworden, aber es funktioniert.

Gerade wenn man sich den Teil bestehend aus Service Discovery und Ad-Hoc Commands anschaut und das "Replay" von Gesprächen mal außen vor lässt ist es eigentlich noch schön anzugucken:

Der Dienst erscheint als Service unterhalb der eigenen Domain. Sofern bereits Gesprächspartner existieren, werden diese nach Jabber-ID sortiert direkt als Knoten unterhalb des Dienstes angezeigt. Unterhalb dieses Knotens findet man dann die Gespräche nach Datum sortiert.

Mit den Ad-Hoc Commands kann man die Protokolle dann nochmal lesen oder direkt vom Server löschen lassen. Wobei ersteres irgendwie noch Ekelhaft ist:

Der Dienst (in diesem Fall "logger") schickt Chat-Nachrichten an den Eigentümer der Konversation und stellt die jeweilige Jabber-ID des ursprünglichen Absenders voran. Delayed Delivery hilft dabei den ursprünglichen Absender und Zeitstempel mit zu übertragen - letzteres wird aber längst nicht von jedem unterstützt und hat gerade beim "ursprünglichen Absender" immer irgendwo ein Geschmäckle.

Der Dienst ist keine propietäre Erweiterung, die ich bei mir in der Schublade verschwinden lassen würde. Im Gegenteil:
Er befindet sich in den Code-Beispielen meiner XMPP-Library, da es eigentlich nur ein Interface für die Logging-Sink-Variante der Jabberd2-Komponente ist - somit Open-Source und für jedermann nutzbar. Wenn man denn will.

Anders herum weiß ich gar nicht, ob ich so eine Komponente im produktiven Einsatz haben möchte. Wenn man sich ein Webinterface dazu denkt, eigentlich ne super Sache, aber son bisschen Geschmack nach Stasi & Co. hab ich dann schon im Mund.
Vielleicht wartet man hier einfach besser bis das Message Archiving (XEP-0136) als Standard abgesegnet wird, da wird dann ja auch geregelt wie der Nutzer über eine etwaige Protokollierung seiner Unterhaltungen zu informieren ist. Bis dahin sei sowieso jedem GnuPG oder OTR ans Herz gelegt.

Wer heute Abend noch nichts vor hat und zufällig in der Region Stuttgart ist, ist herzlich eingeladen in die Stadtbücherei zu kommen und der Vortragsreihe des Chaos Computer Club Stuttgart (CCCS) beizuwohnen.

Thema heute:

IRC trifft Jabber - Wie XMPP ein weiteres Protokoll konsolidiert

Der Referent bin zufälligerweise ich selbst und ich traue mich das, weil wir ja gerade selbst kräftig an einer MUC-Komponente bauen.

Als ob ich nicht schon Panik genug vor dem Publikum dort hätte, würde ich mich natürlich freuen den einen oder anderen Blogleser und/oder Kunden im Publikum wiederzufinden. Für alle die nicht dabei sein können gibt es im Anschluss einen Audio-Mitschnitt und natürlich meine Vortragsfolien.

... die ich noch übelst kürzen muss. Ich soll mich kurz fassen hat Myriam gesagt und ich soll langsam und deutlich sprechen hab ich mir gesagt.

In letzter Zeit schüttel ich irgendwie regelmäßig den Kopf wenn ich mit OpenVPN zu tun habe, bzw. frage ich mich wie die Standardeinstellungen ohne Probleme funktionieren sollen.

Das TUN/TAP-Device für den VPN-Tunnel wird per default mit einer MTU von 1500 Byte konfiguriert, womit für die VPN-Verbindung die bei OpenVPN typischerweise auf UDP basiert eine maximale Nutzdaten-Größe von eben diesen 1500 Bytes entsteht. Addiert man hierauf nun den Overhead von UDP, IP und Ethernet oder PPP, landet man typischerweise weit über der MTU der eigentlichen Internet-Verbindung und Datenpakete werden verworfen.

Eine Abhilfe würde die Verwendung von einer TCP-basierten Verbindung schaffen - mit unserem VPN Gateway ist immerhin beides möglich. Hier würden die Nutzdaten fragmentiert und entsprechend der maximalen MTU auf dem Weg zum VPN-Server übertragen. Allerdings ist TCP im Vergleich zu UDP nicht optimal für VPN-Verbindungen geeignet - um es zu veranschaulichen: Eine VPN-Verbindung ist eine Art "virtuelles Kabel", das dementsprechend auch die Eigenschaften wie ein reales Kabel haben sollte. Dazu gehört auch die Eigenschaft Pakete zu verlieren. UDP schickt die Daten einfach so raus und achte nicht auf Reihenfolge oder ob diese auch ihr Ziel erreichen, TCP hingegen sorgt dafür, dass die Nutzdaten immer in Reihenfolge und auch komplett ihr Ziel erreichen - das ist auch gut, solange das "Kabel" nicht ohnehin schon dafür sorgt. Ohne nun noch weiter in die Tiefe zu gehen: Eine VPN-Verbindung über TCP zu tunneln ist Mist und eigentlich nur für den Notfall bzw. wenn es nicht anders geht eine Option.

Man kann nun nicht behaupten, OpenVPN hätte hier nicht vorgesorgt, im Gegenteil: OpenVPN kennt die Konfigurations-Parameter "tun-mtu" und "link-mtu". Beide definieren einen MTU-Wert, der sich auf das TUN/TAP-Device auswirkt. tun-mtu tust das für das TUN/TAP-Device direkt, wohingegen link-mtu den Paket-Overhead für den Transport über das Netzwerk abzieht und die MTU des TUN/TAP-Device entsprechend setzt.

Nun wird OpenVPN mit "tun-mtu" voreingestellt auf 1500 ausgeliefert, was zu dem eingangs erwähnten Problem führt. Sinnvoller wäre es eigentlich "link-mtu" mit diesem Wert zu versehen. Wenn man dann aber noch die weite Verbreitung von DSL-Zugängen auf Basis von PPPoE berücksichtigt, sollte dieser Wert noch kleiner ausfallen, mindestens 8 Byte.

Nun hocke ich aber nicht immer in Stuttgart im Büro, sondern fahre oft auch durchs Land, sodass ich schon so einige fremde Netzwerke, Hotspots oder UMTS-Verbindungen gesehen habe. In Konsequenz haben wir uns nun dazu entschlossen unseren VPN Gateway mit einer link-mtu von 1400 zu betreiben. Zwar sorgen die 100 Byte weniger, dass mehr Frames generiert werden müssen, doch habe ich persönlich die Erfahrung gemacht, dass es so weitaus seltener zu Verbindungsproblemen kommt - besonders bei SSL-Handshakes.

Zu Migrationsproblemen kommt es hierbei nicht, da ja nur die Menge der zu senden Daten herab gesenkt wird. Solange die dann ihr Ziel erreichen, werden sie dort auch akzeptiert - an einem MRU-Schalter wird in der Regel nicht gedreht.