RackBlogger

Nachdem das (angebliche? weil bisher noch nicht näher benannte) Spamurteil des Landgerichts Lüneburg durch die Blogosphäre geistert will ich auch noch ein Wort dazu sagen: alles kein Problem.

Unsere Kunden können individuell ihren Spamfilter konfigurieren und dabei (derzeit noch über den Support, in Kürze aber auch über’s Web-Frontend) nicht nur Greylisting und Content-Filter, sondern sogar Blacklists individuell aktivieren oder deaktivieren. Somit bleibt es dem Kunden selbst überlassen, ob er Spam empfangen “will”.

Auch ohne dieses Urteil hätte ich als Provider ein Problem damit, dem Kunden (auf welche technische Art auch immer) irgendwelche E-Mails vorzuenthalten, wenn er/sie explizit keine Filterung wünscht (und Ja - wir haben solche Kunden…)

Die Spam-Statistik des Mailservers spricht mal wieder für sich:

Blau sind die gesamten Zustellversuche, grün die tatsächlich akzeptierten Mails.
Aktuell wird nur noch etwa jede hunderste Mail durchgelassen.

Gelobt seien Blacklists und Greylisting.

Nach einer seeehr kurzen Nacht (3x 1,5 Std. Schlaf - jeweils zäh von Nagios unterbrochen) bin ich in meiner wohlverdienten “Mittagspause” bei YouTube auf dieses extrem geniale Video gestoßen: Virales Marketing im Todesstern Stuttgart. Ich liebe diesen Dialekt!

So wie Dirk sich über Marktbegleiter mit eigenem Rechenzentrum aufregt, frage ich mich bei so manchem Marktbegleiter, was das mit dem “Hosting für Dummys” soll, bei dem gezielt unerfahrene/technikunwillige Kunden geworben werden. Der Leitspruch ist dann “Sie müssen gar nichts machen [ oder können ] - mit einem Knopfdruck ist Ihre Anwendung installiert!”.

Das mit der Installation mag zwar schon einfach sein - aber wer aktualisiert dann brav die ganzen Anwendungen? Egal ob WordPress, PostNuke, Mambo oder was-auch-immer - wenn der “unerfahrene Anwender” das nicht mal anhand der jeweiligen Anleitungen selber installieren kann, wie soll er es dann up-to-date halten?

Ich verstehe unter “Application Hosting” doch etwas mehr als “Application Installation“.

Nichts für ungut…

Heute kommt irgendwie alles zusammen:

• Bestellung neuer dedizierter Server (Telefonate mit Lieferanten wg. Verfügbarkeit, Vorbereitung Rack, …)
• die SWITCH hat einen Kunden direkt bezüglich der Verlängerung seiner .ch/.li-Domains angeschrieben, obwohl sowas doch über uns laufen soll (Grund: die Domainverlängerung hat sich mit einer 30-Tages-Frist bis zum Domainablauf überschnitten… zukünftig werden wir .ch/.li-Domains also 35 Tage vor Ablauf verlängern…)
• Fax von der Polizei - Anschlussinhaberfeststellung aufgrund einer Strafanzeige (viel Papierkram - Kundendaten heraussuchen, IP-Adressen heraussuchen, usw…)
• Erweiterung unseres DynDNS-Dienstes (der Router eines Kunden hat sich “nicht ganz” an das DynDNS-Protokoll gehalten, also haben wir das auf unserer Seite etwas flexibler gestaltet)
• ein paar VoIP-Bandbreiten-Tests (das QoS der Fritzboxen macht einen feinen Eindruck…)
• und noch viel, viel mehr…

Außerdem steht in den nächsten Tagen wieder ein großes Meeting mit dem Steuerberater an, weshalb sich hier langsam die Ordner stapeln…

SWsoft, Hersteller von Verwaltungs- und Virtualisierungssoftware (u.a. Plesk, Confixx, Virtuozzo), war letzte Woche offenbar auf großer Einkaufstour. Am 11.09. wurde das Konkurrenzprodukt ENSIM pro aufgekauft, drei Tage später der Konkurrent Positive Software (ein Tochterunternehmen von Comodo) mit Produkten wie H-Sphere, NOC Monkey oder FreeVPS.

Der Markt konsolidiert sich also zunehmend in Richtung SWsoft (die nun übrigens auch ihr altes Logo ersetzt haben).

Nur gut daß wir unsere Server alle selber verwalten können.

Unsere Verwaltungssoftware hat nun ein weiteres kleines, aber feines Feature: die Unterstützung von Zeitzonen. Um ausländischen Kunden die Anzeige zu erleichtern, werden intern alle Uhrzeiten in GMT/UTC abgespeichert und während der Anzeige an die jeweilige Zeitzone des Kunden angepasst.

Die ursprüngliche Idee war, im Kundenprofil jeweils nur die entsprechenden GMT-Offset-Stunden zu speichern (z.B. “2″ für GMT+2). Wenn da nicht so Länder wie Nepal wären, die als GMT-Offset 5:45 Stunden haben… In diesem Fall speichern wir das also in Minuten (es gibt auch sekundengenaue Zonenwechsel im Rahmen der jeweiligen Angleichung an GMT, aber uns interessieren eh erst Zeiten ab dem Computer-Urknall am 01.01.1970).
Das nächste Problem sind die Sommerzeiten. Dafür gibt es keine feste Regelung; die einen Länder schaffen die Sommerzeit gerade spontan ab, andere orientieren sich am Ramadan, andere haben wiederum gesetzlich festgelegt daß der Sommer mindestens 150 Tage lang sein muß, und so weiter… Wir könnten nun zusätzliche Eingabemasken definieren, mit denen die Kunden das selber pflegen können, aber zum einen wird das auf Dauer lästig (und Fehleranfällig), zum anderen möchten wir auch in zehn Jahren noch wissen wann dieses Jahr die Sommerzeit angefangen hat (die Daten müssten also historisch gespeichert werden, was das Ganze auch nochmal komplexer macht).

Also wurde das Ganze gleich ganz ordentlich gemacht: mit der frei verfügbaren Zeitzonen-Datenbank, die u.a. auch Basis für die GNU glibc ist. In einigen großen Textdateien sind (fast?) alle Zeitzonen sowie deren Regeln definiert.

Ein kompaktes Perl-Script (immerhin auch 300 Zeilen) parst diese Dateien, filtert nur Regeln ab dem 01.01.1970 heraus, und schreibt das in SQL-Befehle um, mit denen wiederum die Backend-Datenbank gefüttert wird.

Daraus wird dann beim Laden des Benutzerprofils (z.B. beim Login) die gewünschte Zeitzone und alle relevanten Regeln in eine spezielle Datenstruktur im Speicher geladen (sind nur wenige Byte). Die Datums-Klasse (C++) konvertiert dann mit einem Befehl eine GMT-Zeitangabe in die gewünschte Zeitzone um und stellt daneben auch das jeweils gültige Zeitzonen-Kürzel (z.B. “CEST”) bereit. Der Overhead ist somit absolut minimal.

Und so schaut’s dann aus, wenn ich meine Zeit auf Nepal einstelle…