Technik

Seit gerade eben kann man bei uns die Zeichenkodierung für einzelne Webserver-Verzeichnisse bequem über unser Kundeinterface selbst einstellen.

Sicherlich nur eine Kleinigkeit, aber doch sehr hilfreich

Wie ich mittlerweile ( :eek: ) vorletzte Woche im Zug zu einem Kunden fuhr, hatte ich per E-Mail eine - wie ich doch fand - sehr produktive Diskussion über Datenschutz mit einem Kunden.

Zugegeben: Meine letzte Antwort steht noch aus, aber das heißt nicht, dass ich mich vor dem Thema drücken würde. Im Gegenteil: Ich halte es für sehr wichtig, dass man gerade über dieses Thema redet, und es wäre ja nicht so, dass auch diese Diskussion keine Früchte getragen hätte.

In dem Gespräch kam unter anderem zum Tragen, dass unsere Kunden die für sie generierten Zugriffs- und Fehlerprotokolle nicht selbst löschen können und das man keinerlei Möglichkeit hat, das Erstellen von Fehlerprotokollen zu unterbinden.

Beides sehr berechtigte Einwände!

... die es seit heute morgen nicht mehr gibt.

Nachdem ich gerade eben mit meinem Helferlein unsere IPv6-Pläne und -Vorbereitungen durchgegangen bin - nicht zuletzt weil heute die ersten 6 DNS-Root-Server offiziell IPv6-Adressen bekommen haben - ist uns aufgefallen, dass unser DDNS-Dienst noch gar nicht "IPv6-ready" ist.

Er wird sich demnächst um dieses Problem kümmern und ich bin mal gespannt, wie er es lösen wird, zumal IPv6 soweit ich weiß momentan keine Erwähnung im offiziellen Standard findet.

Ich konnte es mir heute Nacht irgendwie nicht nehmen lassen, mal meine zwei Spielerein aus dem IM-Bereich miteinander zu kreuzen.

Herausgekommen ist ein kleiner irgendwie richtig unfertiger XMPP-nach-ICQ-Transport. Eigentlich kann er nur Nachrichten zwischen zwei Benutzern (einer bei ICQ, der andere eben bei Jabber) hin und her schieben, keine Subscriptions oder Online-Informationen.

Aber für den Anfang ist das doch eine sehr passable Sache!

Ich habe das kleine Demo-Programm im SVN des XMPP-Skriptes eingechecked - für jeden der mal schauen will

Von allen Protokollen, mit denen wir so täglich umzugehen haben, empfinde ich XMPP (Jabber) irgendwo als das unhandlichste.

Zwar ist XMPP mit seinem XML-Format sehr leicht zu lesen, allerdings geben die Protokolle auf dem Server oftmals nicht sonderlich viel her, was zum debuggen nützlich wäre. Man könnte vielleicht drüber nachdenken, den Jabber-Server mal im Debug-Modus zu starten, allerdings muss man dafür die Software erst einmal herunter fahren. Man könnte auch überlegen sich den IP-Traffic anzuschauen, der während des Betriebes generiert wird, allerdings wird der großzahl unserer s2s-Verbindungen (Server-zu-Server) von Haus aus verschlüsselt und mit den c2s-Verbindungen (Client-zu-Server) gibt es eher selten Probleme - ganz nebenbei empfehlen wir auch hier eine Verschlüsselung der Verbindung.

So habe ich mir über die Jahre immer mal wieder ein paar Spielzeuge gebastelt, mit denen ich unabhängig vom laufenden Betrieb s2s-Verbindungen testen kann. Eines davon provoziert einen Server-Dialback nach XEP 220, so wie es im Normal-Betrieb mittlerweile üblich ist, um die authentizität eines Jabber-Servers zu ermitteln, und hat mir heute wieder einen guten Dienst erwiesen.

... dummerweise teilen nicht alle Jabber-Server mit woran der Dialback scheiterte, so blieb mir diesmal nichts anderes übrig, als mal bei den Serverbetreibern nachzufragen, woran es denn gescheitert sein könnte.