Technik

Gestern Nacht hatte ich wieder "Programmier-Wut". Dabei ist etwas entstanden, was ich gerne als "fork" bezeichne, allerdings wäre "offener Ideenklau" hier sicherlich angebrachter, denn von 335 Zeilen Programmcode sind nur noch ca. 10 Zeilen aus dem ursprünglichen Programm - und die haben nichtmals wirklich was mit dem eigentlichen Abluaf zu tun

Herausgekommen ist dabei (wie schon in der Überschrift vermerkt) ein transparenter SOCKS5-Proxy, der komplett im Userspace läuft und bequem via IP-Tables konfigurierbar ist. Anders als sein Vorgänger verzichtet meine Implementation auf eine externe SOCKS-Library und den fork() pro eingehender Verbindung, im Gegenzug setze ich zum ersten mal libevent zur Verwaltung der Ereignisse auf den Sockets ein.

Da die ursprüngliche Version keinerlei Lizenz-Informationen beinhaltet, warte ich noch auf Rückmeldung vom Original-Author. Wenn der sein gründes Licht gibt, wird das ganze OpenSource. Bis dahin bereite ich den Einsatz auf unserer Seite als Erweiterung eines bestehenden Produkts vor

Es klingt irgendwo schon ein wenig skuril: Ein Kunde will gerne seine Webseitenzugriffe in Echtzeit auf einem eigenen System auswerten und fragte und daher nach einer Möglichkeit die Access-Logs für ihn an seine Server zu "pushen".

Es gibt hier sicherlich viele Wege so etwas zu realisieren, so war neben einer einfachen TCP-Verbindung über die die Daten in Text-Form geschickt werden auch eine direkte Anbindung an seine MySQL-Datenbank im Gespräch. Letzten Endes haben wir uns dann aber doch vorerst für einen Transport über Jabber/XMPP entschieden.

Um den Datenverkehr zu gering wie möglich zu halten, soll unser Logging-Backend direkt auf einem Jabber-Server beim Kunden einloggen und die Verbindung wird zusätzlich komprimiert. Die Daten werden dann ein einem eigenen Namespace umschlossen von eimem <message>-Block ihr Zuhause finden.

Momentan wird das Projekt noch geplant, aber ich bin jetzt schon ganz wild und gespannt was daraus wird.

Wenn ich von einem Integer spreche, spreche ich in der Regel von einem ganzzahligen Datentyp, der in 4 Bytes bzw. 32 Bit dargestellt wird. Als Zweierkomplement mit Vorzeichenbit lassen sich dort also Zahlen im Bereich von [-2.147.483.648; 2.147.483.647] darstellen. Das soweit vorweg.

Nun war es so, dass in den letzten 2 Wochen regelmäßig Lastschriften mit dem Verweis "Kontonummer falsch" zu uns zurückkamen, wo die in der Datenbank hinterlegten Daten sich jedoch nach Rücksprache mit dem Kunden immer als richtig erwiesen. Ein wenig Kopfzerbrechen bereitete mir die Geschichte schon und ich war kurz davor bei unserer Bank anzurufen um dort mal nach der Fehlerursache zu suchen.

Ich habe mir dann aber doch nochmal die Dateien angeschaut, die wir zuvor mit den Lastschriften übermittelt haben, und für die Irrläufer jeweils immer die selbe Kontonummer gefunden: 2147483647

Ohne, dass es mir da schon bewusst gewesen wäre, diese Zahl kam mir so verdammt bekannt vor!

Natürlich: 2147483647 ist die maximal darstellbare Zahl eines 32-Bit Integer. Und so war alles eigentlich mein Fehler, denn aus irgendeiner Gründlichkeit heraus habe ich die Kontonummer vor dem Export nochmal aus einer Zeichenkette heraus in besagten Integer konvertiert.

Schade nur, dass dieser Fehler bares Geld gekostet hat - das ist wohl der Preis dafür, wenn man alles selbst macht

... zumindest theoretisch.

Ich habe gestern Nacht mit der Revision 1245 wohl etwas richtig schönes in unser Produktiv-System geworfen: Wir unterstützen ab sofort SNI.

SNI steht für "Server Name Indication" und ist eine TLS-Erweiterung, die es unseren Webservern erlaubt schon vor dem eigentlichen "HTTP-Gequatsche" herauszufinden, um welche Domain es in der Anfrage gehen wird und dem Client die entsprechenden Zertifikate auszuhändigen. Damit entfällt diese alt eingesessene Bariere des "Ein Zertifikat pro SSL-Port" und macht es somit fast gänzlich überflüssig für Kunden noch dedizierte IPs oder Ports schalten zu müssen - zumal letzteres ohnehin sehr gruselig war.

Natürlich bringt diese schöne neue Technik nichts, wenn der anfragende Client sie nicht beherrscht. Allerdings unterstützen Firefox, Opera und der Internet Explorer (letzterer ab Version 7) SNI bereits von Haus aus. Für Konqueror ist SNI-Support geplant und dementsprechend wird Safari bestimmt auch bald folgen.

Ich bin gespannt, wie sich SNI in den nächsten Monaten oder Jahren durchsetzen wird - oder auch nicht. Allerdings dürften mit dem IE, Firefox und Opera bereits ein sehr sehr großer Teil der Internet-Community kompatibel sein. Fehlt eigentlich nur noch die Server- bzw. Hoster-Landschaft.

Neulich bei Jabber:

Man darf gespannt sein!

Ich habe wohl schon mehrfach hier im Blog erwähnt, dass OpenVPN über UDP-Sockets gelegentlich wesentlich performanter als über TCP-Sockets ist - der Umstand, dass beides seine Vor- und Nachteile hat, man sich aber für den Produktiv-Betrieb auf eine Variante festlegen muss, war mir schon immer ein Dorn im Auge.

Eigentlich hatte ich mich dann gestern Nacht dran gesetzt und wollte OpenVPN an sich patchen und einen neuen TCPv4/UDP-Server-Modus einführen, aber irgendwie war das der falsche Ansatz und ich habe in den letzten 2 Stunden einen anderen Verfolgt:

Ein Proxy, der sich zwischen TCP-Client und UDP-Server schaltet und die Kommunikation "übersetzt" - denn abgesehen von 2 Byte pro Paket unterscheidet sich die Kommunikation auf Socket-Ebene überhaupt nicht.
Heraus gekommen ist ein kleines PHP-Programm, was noch ein wenig schwerfällig daherkommt, aber durchaus einen guten Dienst tut.

WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1544', remote='link-mtu 1542'
WARNING: 'proto' is used inconsistently, local='proto TCPv4_SERVER', remote='proto UDPv4'

... beim Verbindungsaufbau beschwert OpenVPN sich zwar lautstark, arbeitet dann aber ganz normal wie auf einer normalen Verbindung.

Ich werde das Programm sicherlich noch ein Weilchen testen und umbauen, bevor es irgendwie in die Nähe etwas produktivem kommt, wer es selbst brauchen kann, findet es wie immer hier.

Lang ists her, dass ich an meinem mod_dvb geschraubt habe - doch mittlerweile ists wieder aktuell und immer wenn ich etwas abwechslung vom Alltag brauche und gerade allein bin schraube ich wieder dran.

Den Server, auf dem das Projekt ursprünglich gehostet war, gibt es schon lange nicht mehr, dafür aber eine recht alte SVN-Repository hier - eigentlich wollte ich das Projekt nur DVB-S-tauglich machen und ein wenig aufräumen, aber ist das irgendwie aus dem Ruder gelaufen:

So schreibe ich gerade den ersten MPEG-Remultiplexer meines Lebens und das auch noch in C, einer Sprache die nicht so wirklich zu meinem täglichen Handwerk gehören will, sodass mod_dvb in Zukunft wohl nicht mehr den bloßen MPEG2-Transportstream weiterleiten wird (und ggf. die PIDs neu schreibt) sondern nur noch einen MPEG-PS-Datenstrom (wie z.B. DVDs) ausliefert und dabei hoffentlich seine Kompatibilität mit gängigen Playern wie z.B. VLC steigert.

Letzterer hat immer nach Programmtabellen-Einträgen im TS-Stream gesucht und natürlich keine gefunden.

Der DVB-S-Support ist in diesem Zusammenhang wohl nur noch das kleinere übel, aber genau für diesen suche ich ein wenig Hilfe:

1. Hat jemand ggf. eine channels.conf, die mit scan aus den linux-dvb-utils erstellt wurde?
2. Verfügt hier jemand über eine kleine Maschine mit DVB-S-Adapater sowie Apache-Webserver und ist willig irgendwann mal entsprechend mitzutesten?

Garvin schickte mir heute morgen per Jabber einen Link, mit dem er mich auf ein Gewinnspiel aufmerksam machen wollte, das es momentan bei Serendipity (mit freundlicher Untersützung von Open Source Press) gibt.

Konkret geht es dabei um 5 Exemplare seines jüngst erschienen Serendipity-Handbuch "Serendipity: individuelle Weblogs für Einsteiger und Profis". Nicht, dass ich es gewinnen wollte, aber man kann ja immer mal ein wenig Werbung dafür machen.

Ungeachtet seiner Heimat Köln gönne ich ihm die Millionen Euro Gewinn

Es hätte ein guter Aprilscherz werden können: Unser VPN Gateway hat seit dem 1. April keinen Traffic-Verbrauch mehr protokolliert.

So ein kribbeln im Bauch hatte ich diesbezüglich schon in den ersten April-Wochen, auch haben eine Hand voll Kunden darauf hingewiesen, dass das Kundeninterface für den VPN Gateway keinen verbrauchten Traffic ausgibt. Obwohl Traffic für uns noch recht schnell zu einem nicht zu vernachlässigen Kostenfaktor werden kann, war ich die Ruhe in Person (zumindest was dieses Thema angeht) und habe mich erst heute abschließend darum gekümmert - wohlwissend, dass der Gateway in diesem Zeitraum die Kunden - abgesehen von der Grundgebühr - für Lau surfen lässt.

Hintergrund der Störung war ein kleiner programmiertechnischer Defekt, der sich bei der Vorbereitung auf ein neues Datenbank-Setup (das btw. schon erfolgreich eingeführt wurde) eingeschlichen hat und den Traffic-Protokollierer ins Jehnseits beförderte, sobald der Traffic in die Datenbank geschrieben werden wollte.

Bleibt noch anzumerken, dass diese Art von Störung zu denen gehört, wo wohl nur wie als Dienstleister den Schaden tragen - sofern das der Fall ist, gönn ich mir besagte Gelassenheit schon mal. Ansonsten natürlich nicht. VPN Gateway-Kunden, die trotzdem ihren Verbrauch erfahren wollen, können das im Nachhinein noch vom Support erledigen lassen.

Ich habe schon mit Virtuallisierung gespielt, da war ich noch gar nicht so alt. Man könnte meinen, ich hätte gerade mit dem Windeln tragen aufgehört und mich anschließend mit dem Thema befasst. In Wirklichkeit hatte ich gerade meine erste Wohnung und habe mich mit meinem Abitur beschäftigt - tiggersWelt.net gab es darmals noch gar nicht, wenngleich es abzusehen war.

Irgendwann muss das Thema von der Bildfläche verschwunden sein, zumindest habe ich eine halbe Ewigkeit nichts mehr in dieser Richtung getan.

Letzten Freitag war ich dann zu Besuch bei Bechtle im Systemhaus Solingen - einem Gebäude wo ich übrigends schon als kleiner Junge oft herum turnte, die Fax-Regel lernte und der heutige Geschäftsführer mein Namensgeber ist - um ein Update in Sachen Virtualisierung zu bekommen, genauer ging es um VMWares "Infrastructure 3"-Lösungen.

Ich muss zugeben, dass ich in dieser Richtung wohl etwas konservativ geworden bin, zumindest wäre ich nicht von mir aus auf die Idee gekommen eine kleinere Server-Farm zu virtualisieren - allerdings war die Präsentation, gerade auch im Hinblick auf die Energie-Effizienz, sehr überzeugend. Es wird bei uns zwar keine virtualisierten Webserver geben, aber ich werde das Thema wohl im Auge behalten und immer mal etwas herum experimentieren.

Mittlerweile habe ich hier in Stuttgart 4 "virtuelle Maschinen" laufen - mit denen scheint es sich genau so zu verhalten wir unser Gastgeber am Freitag verlauten lies:

Virtuelle Maschinen sind wie Kaninchen - auf einmal hast Du 10 mehr.

Ich konnte meinen Augen kaum trauen, wie ich diesen Bug-Report auf php.net las. Eigentlich hatte ich ja nach etwas komplett anderem im Internet gesucht, aber das musste ich dann doch gleich mal ausprobieren.

Da wir schon lange kein mod_php mehr einsetzen musste ich mir am Wochenende erst einmal einen solchen Webserver auf einer virtualiseren Maschine (dazu ggf. auch bald mehr) installieren - ich nahm hierzu den Standard-Apache von openSuSE 10.3, der mit mod_php 5.2.4 kommt, und schrieb ein dem Bug-Report entsprechendes Programm in C, das ich lokal statisch kompilierte und "wie ein normaler Webhosting-Kunde" per FTP hochlud.

Und tatsächlich: Sobald ich das Programm mittels system() über einen PHP-Skript aufrief, dauerte es keine ganze Sekunde bevor sich das Programm des Port 80 bemächtigt hatte und fortan selbst dort Anfragen beantwortete. Apache lief parallel weiter, tat aber gar nichts mehr und lies sich auch nur noch schwer beenden, wobei ein Neustart ohne Beenden meines kleinen C-Programmes natürlich gar nicht möglich war.

Mich würde gerade mal interessieren, ob unsere Marktbegleiter sich dieses Problemes bewusst sind bzw. wie sie damit umgehen. Selbst ausprobieren kommt natürlich nicht in Frage, da das schon ein recht massiver Eingriff in den Betrieb ist. Ein wenig schade finde ich ja auch, wie das Problem als "nicht-PHP-Problem" im Bug-Report abgetan wird - meines erachtens nach ist und bleibt es ein PHP-Problem und sollte dementsprechend auch behandelt werden.

Abgesehen davon, dass wir PHP via FastCGI ausführen, erlauben wir auch kein system() o.ä., da man damit recht leicht solch Begrenzugn wie PHP's open_basedir umgehen kann. Ich finde ja das sollte jeder so machen

Spam ist in den letzten Monaten ein Thema geworden, was mir mitunter schon mal richtig Kopfschmerzen bereitet hat. So gibt es in letzter Zeit immer mal wieder Kunden, bei denen das Spam-Aufkommen auf schier unendliche Dimensionen ansteigt, wobei dann ca. 6000 - 12000 E-Mails pro Tag und entsprechendem Kunden dann keine seltenheit sind.

Bevor ich hier weiterschreibe, möchte ich mich noch kurz für die zurückliegende Offenheit und Kooperationsbereitschaft der betroffenen Kunden bedanken! Ich hatte immer ein relativ schlechtes gewissen in solch einem Fall auf die Kunden zuzugehen, zumal die in den meisten Fällen ja recht wenig dafür können.

Mich persönlich stellt das immer vor eine sehr schwere Aufgabe, da sich dieser E-Mail-Ansturm selten gleichmäßig über den ganzen Tag verteilt, sondern meistens in zwei oder drei großen Paketen bei uns ankommt. Das hat schon mal zur Folge, dass der Spam-Filter zu viel zu tun hat und es zu zum Teil imensen Verzögerungen bei der Auslieferung "normaler" E-Mails kommt. Überhaupt stellen wir hier immer nur fest, wenn die Warteschlange sehr sehr lange wird und selbst dann sind - natürlich hauptsächlich wegen des Datenschutzes (den ich hier aber in keinster Weise als negativ darstellen mag) - sind unsere Möglichkeiten stark begrenzt.

In solch einem Fall mache ich dann immer eine Art Analyse des E-Mail-Queues, wobei nur die drei stärksten E-Mail-Nutzer samt prozentualer Nutzung aufgeführt werden. Bei oben beschriebenem Fall sind die Zahlen für den Moment schon mal leicht zwischen 85 - 99% und in dem Falle spreche ich dann gerne von "Beeinträchtigung des normalen Betriebes" und schalte für den Moment ab.

Abschalten heißt in diesem Moment, dass die Mails des Kunden aus dem Queue gezogen werden und über den Rest des Tages in kleinen Portionen (deren Größe nach Verkehrszeit variiert) erneut zugestellt werden, allerdings immer nur so viel, dass andere Kunden nicht drunter leiden müssen.

Seit neustem ist es ebenfalls möglich, den Spam-Filter für bestimmte E-Mail-Adressen oder auch ganze Domains einfach zu umgehen - eine Neuerung, die für mich als letzte Rettung fungiert, aber gleichzeitig auch ein paar Kundenwünschen nachkommt. Ich werde die Neuerung wohl auf lange Sicht in unser Kundeinterface einbauen müssen, ebenso wie das fallweise Abschalten des Greylistings

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.