Technik

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.

Es ist nun schon fast genau einen Monat her, seitdem ich das letzte Mal etwas an meiner OSCAR-Implementation gedreht habe. Bisher war ja alles recht dürftig - das Programm konnte sich gerade mal beim Netzwerk anmelden und gab Debug-Informationen sobald jemand seinen Status änderte.

Viel geändert hat sich an diesem Zustand nicht, allerdings war ich gestern Abend mal so frei das Handling der Klassen (besonders dem FLAP-Handler) ein wenig zu verbessern und so etwas unsinniges wie Suspend/Resume-Funktionalität einzubauen.

Das wichtigste ist wohl die Fähigkeit jetzt auch Textnachrichten empfangen, zu verarbeiten und selbst welche schicken zu können.

Bei der Gelegenheit bin ich einfach mal in unser Kundeninterface gegangen und habe für OSCAR ein nettes SVN angelegt. Auschecken darf jeder via

svn co http://oss.tiggerswelt.net/oscar/

Mal schauen, wann ich mehr Zeit und Lust finde

Ich habe hier gerade so ein feines altes Maschinchen der IBM eServer-Reihe herumstehen - genauer ein xSeries 330 mit 2 Prozessorkernen (je 1,4 GHz), 2 GB RAM und einem netten SCSI-RAID.

Was sich im Rechenzentrum schon mal als großer Vorteil erwiesen hat, kann im kleineren Umfeld allerdings ein großer Nachteil sein: Die Maschinen haben keine herkömmlichen Ausgänge für Monitor, Tastatur und Maus, sondern einen sog. C2T-Stecker über den sich mehrere Server miteinander verbinden lassen und man sich so den KVM-Switch sparen kann.

Dumm nur, wenn das einzige Breakout-Kabel (eben zum Anschluss von Tastatur etc.) seinen Geist aufgegeben hat, man aber unbedingt etwas spielen will.

Wie gut, dass man sich auch anders behelfen kann! (Nein, sowas mache ich nur zu Hause und im privaten Umfeld!)

Schon am Donnerstag Abend hatte ich es irgendwo auf meine ToDo gekritzelt, aber spätestens nach dem gestrigen Tag kam ich dann nicht mehr herum: Wir müssen diese "Cross Site Request Forgery" loswerden!

Ich bin mir zwar relativ sicher, dass es auf uns momentan noch niemand absehen würde, dennoch würde es mich doch sehr schmerzen diese Lücke als offen im Hinterkopf zu haben. Ich habe mich heute mal dran gesetzt und den Login um einen kleinen Referer-Check ergänzt.

Zwar muss der Referer nicht zwangsläufig übertragen werden, sollte aber doch bestimmt 90% der möglichen Fälle abdecken (meinte zumindest Christian bei manuel). Verstärkend kommt dann noch hinzu, dass die meisten Formulare bei uns sowieso per POST übertragen werden müssen

Bleibt noch eine ToDo vom Donnerstag auf meiner Liste - dazu vielleicht aber später mehr.

Linux sagt man ja immer nach, dass es den schlechteren Hardware-Support hat - zumindest kommt es gerne mal vor, dass man Hardware anschafft, bei der man vorher vergessen hat nachzuschauen, ob es überhaupt einen geeigneten Treiber dafür gibt und damit dann prompt auf die Nase fällt.

Wenn die Hardware dann aber einmal läuft, dann läuft sie - zumindest fühlt es sich so an - viel besser

Mit meinem Rechner hier an meinem Arbeitsplatz habe ich die Tage allerdings etwas eher gegenteiliges erlebt: Um mich bei der Arbeit bei Laune zu halten steckt dort ein schon etwas älterer (aber immernoch sehr guter) Soundblaster Live 5.1 aus dem Hause Creative drin. Die Treiber-CD dazu habe ich nicht mehr - braucht man für Linux ja auch nicht

Nun kam es allerdings, dass ich mir auf der Maschine ein Windows installierte - z.B. für so Spielereien wie Elster. Mal abgesehen davon, dass Windows prompt die falschen Grafikkarten für sein primäres Display missbrauchte, läuft der gute Soundblaster bis heute nicht - nicht weil Windows ihn nicht erkennen würde, nein, die Treiber von Creative, die ich schon in zig Varianten herunterlud, wollen auf Teufel komm raus nicht mit der Karte arbeiten...

Muss ich solange halt was anderes machen - zum Glück benutz ich ja gar nicht so oft Windows

Ich frage mich oftmals, was zuerst da war - das Huhn oder das Ei?

Just in diesem Moment habe ich es wieder getan. Zur Verwaltung unserer Server setzen wir ein selbst entwickeltes Framework ein, das für gewöhnlich auf einem SVN-Server verweilt. Wenn ich früher einen neuen Server eingerichtet habe, habe ich dort immer erst einen SVN-Client installiert und die aktuellste Version ausgechecked - der Rest geht dann (wenn man es schon mal gemacht hat) wie von selbst.

Vor einiger Zeit aber habe ich das SVN so umgestellt, dass es nur über unser internes Verwaltungsnetz zu erreichen ist. Um sich aber mit dem verbinden zu können sind ein paar Funktionen aus unserer Verwaltungssoftware zwangsweise notwendig. :hmm:

So ein Mist! Bequemes auschecken war gestern. Jetzt muss erstmal eine Kopie auf dem System installiert und die Verbindung zum Verwaltungsnetz hergestellt werden. Der Aufwand ist nicht zwangsläufig größer, dennoch kam es mir früher leichter vor

Nachdem AOL wohl wieder mal irgendwas am ICQ-Protokoll gedreht hatte und der ICQ-Transport unserer Jabber-Server ausgefallen war, hatte ich über die Feiertage irgendwie die Schnauze voll.

Ich bin ja der Meinung, dass man jedes Problem viel besser angehen kann, wenn man sich im Vorfeld richtig intensiv mit der darunter liegenden Technik auseinandersetzt und habe das spontan mal in die Wirklichkeit umgesetzt:

Nach ein wenig googlen und tcpdumpen, habe ich dann mal angefangen meine eigene Implementation zu schreiben - in PHP, was auf dem ICQ-Markt sicherlich auch ein ziemliches Novum ist

Viel kann mein OSCAR zwar noch nicht, aber wer schon mal spicken mag, kann das gerne tun!

Aus irgendwie unerklärlichen Gründen hat das Mediawiki eines Kunden bei jedem Aufruf der Seite die Tabelle "objectcache" zerstört - zumindest deren Index.

Irgendwie war ich es heute Abend leid weiter nach dem Fehler zu suchen und den Kunden mit einem kaputten Wiki zurückzulassen, drum habe ich erst einmal eine Kopie erstellt und die Speicherengine für die besagte Tabelle auf "Blackhole" umgestellt - und siehe da: Es funktioniert

Natürlich weiß ich nicht, ob das die beste Methode ist - aber sie lag irgendwo nah, da ich so nicht an die Dateien des Kunden muss und ausschließlich auf der Datenbank arbeite

Dem aufmerksamen Blogleser wird es nicht entgangen sein: Es ist sehr ruhig um diesen Blog geworden...

Eigentlich bedauere ich das ein wenig und es ist auch nicht so, als hätte ich nichts, das es zu bloggen gäbe. Allerdings stecke ich meine Energie gerade in ein anderes Projekt.

Intern überarbeiten wir mal wieder das System, das bei uns die Webserver verwaltet. Überarbeiten heißt meistens primär neue Funktionen hinzufügen, ganz selten auch mal was altes austauschen. Neu hinzu kommen wird im wesentlichen alles das, was man beim Apachen in <Location>- oder <Directory>-Direktiven packen kann.

Allen voran natürlich WebDAV und SVN, ersteres erwähne ich heute wohl zum ersten Mal hier im Blog, was allerdings kein Wunder ist, da das Projekt primär von meinem Helferlein geplant und durchgeführt wurde. Ich darf nun nur die "generische Implementierung" vornehmen. Fürs SVN gibt es seit heute morgen nun mehr die dritte Implementierung, die so wie es scheint auch die finale sein wird... (die muss jetzt nur noch mal ausprobiert werden )

Wer also mal mittesten mag, einfach melden!

Es waren nur ein paar Sekunden, die ich heute morgen meinen Laptop alleine gelassen habe, doch als ich wieder zurück kam, hörte ich merkwürdige Geräusche...

Kratz, kratz, kratz...

Geräusche, die mir in einer gewissen und sehr unliebsamen Weise bekannt vorkamen... :eek:

Als das System bei meinen ersten Analyse-Versuchen einzufrieren drohte, habe ich erstmal den Stecker gezogen und den Laptop ausgeschaltet und ein paar Minuten ruhen lassen... Danach habe ich ihn per USB-Stick gebootet und ein komplettes Image der Festplatte gezogen.

Merkwürdig: Seitdem wollte es nicht mehr kratzen und auch die Festplatte lässt sich ohne weiteres komplett auslesen... Der aufgezwungene Schwabe in mir würde nun sicherlich sagen, dass es so doch alles gut ist. Ich schau mich aber trotzdem vorsichtshalber nach einer neuen Festplatte um - auch wenn auf dem Laptop ohnehin kaum wichtige Daten liegen...

Ich hatte letzte Woche mal testweise eine MySQL-Tabelle auf die sehr oft lesend wie auch schreibend zugegriffen wird von MyISAM auf HEAP umgestellt. Ging auch gleich alles viel schneller, jedoch war der Speicherplatz-Bedarf der Tabelle nun 10 Mal mehr wie vorher...

Auf den kleinen Geschwindigkeitsvorteil haben wir dann doch lieber verzichtet, denn das waren die 500 MB Arbeitsspeicher mir dann doch nicht wert - zumal besagte Anwendung "nur" im Backend läuft.

Seit jeher setzen wir auf unsere eigene Verwaltungssoftware und ich kann es nur immer wieder sagen: Das hat Vor- und Nachteile, für uns überwiegen jedoch die Vorteile

Nachteil ist natürlich, dass nicht immer alles für den Kunden direkt verfügbar ist, sprich er muss gelegentlich bis oft den "Umweg" über uns im Support machen. Ein anderer Nachteil ist, dass das System sich ständig weiterentwickelt - es ist noch nicht ausgewachsen und bringt oftmals nur die Leistung, die es in einem bestimmten Punkt bringen muss, oder ein wenig mehr. Viel mehr dann aber auch nicht und das ist schlecht, wenn man bedenkt, dass wir noch recht jung am Markt sind und ständig wachsen.

Letzterem ist schon vor längerer Zeit ein Programm zum Opfer gefallen, dass wir intern "vHost-Deamon" nennen - ein Programm, das die Konfiguration für den Webserver überprüft, bearbeitet und aktiviert. Das lief bis dato in seiner zweiten Generation und ist auch ganz wunderbar - bis auf die Last, die es auf den gewachsenen Systemen hervorruft. Die Anforderungen an die System-Ressourcen hatten uns dazu veranlasst das Programm nicht automatisch ablaufen zu lassen, sondern immer von Hand anzustoßen, was natürlich den Grad der automatisierung rapide absenkt.

Nun war das aber kein Zustand auf dem man sich ausruhen könnte, sodass ich in den letzten Monaten immer mal wieder an der 3. Generation gearbeitet habe. Gestern Nacht war ich dann mal so mutig und habe die Beta ins erste Produktiv-System genommen.

Funktioniert perfekt!

Ich gebe es nur ungern zu, aber es stimmt: Wird ein Marktbegleiter angegriffen, dann freut man sich schon mal ein wenig - wenn auch nur inoffiziell. Jeder weiß ja, was des einen Freud ist, ist gleichsam des anderen Leid.

Anders verhällt es sich, wenn der Marktbegleiter, der dort angegriffen wird, zufällig auch der ist, bei dem man selbst seine Maschinen unterstellt. Dann hat man gar keine Zeit sich irgendwie zu freuen. Denn die Erreichbarkeit der eigenen Systeme knickt je nach Härte des Angriffs im Handumdrehen ein und man hat erstmal Stress herauszufinden, woher die Ursache dafür kommt.

So geschehen heute zwischen 11:40 und 11:54.

Ein wenig zitterig ist mir immernoch zu mute, aber es ist gut zu wissen, dass sich an der entscheidenden Stelle schnell und zuverlässig gekümmert wurde - das lindert doch ein wenig den Schmerz

Ich habe eben einen Prozess angestossen, der schon längst überfällig war: Ich erstelle für mich selbst ein neues Kontakt-Handle.

Das hat den Hintergrund, dass im "alten" Handle noch unsere alten Telefonnummern vermerkt waren (die nach wie vor funktionieren, aber halt nicht mehr aktuell sind). Die DeNIC mag es dabei irgendwie nicht, wenn Firmennamen oder Telefonnummern in bestehenden Kontakt-Handles geändert werden, weswegen die Handles dann komplett neu angelegt werden müssen.

Wir hatten den Fall "glücklicherweise" schon mal bei einem Kunden, wo es nur um ca. 8 Domains ging. Genug Zeit um uns für die Zukunft vorzubereiten. So musste ich eben nur eine einzige Funktion ausführen um den Vorgang anzustoßen.

Trotzdem bleibt es ein mulmiges Gefühl im Bauch wenn man nahezu alle Domains im Hause modifizieren lässt. :hmm: