RackBlogger

… wenn man täglich 12 Stunden im Büro und 12 Stunden zu Hause ist. Oder?

(zur Beruhigung: ich war erst kürzlich für ein paar Tage im Urlaub )

Damit wir uns nicht immer den Mund fusselig reden müssen, gibt’s nun auch ein Video von LiveConfig

Ich bin ja ein zutiefst überzeugter Facebook-Ignorant. Trotzdem gibt’s für unser Hosting Control Panel nun auch eine eigene Facebook-Fanpage.

Zur CeBIT werden wir (oder vielmehr meine Kollegen ) dort täglich vom Messestand aus berichten. Bis dahin gibt’s ein paar Einblicke in die Vorbereitungen.

Wer möchte, kann also gerne unser Fan werden. Facebook-Buttons kann man trotzdem vorerst vergeblich auf der LiveConfig-Website suchen - die 2-Klick-Lösung gefällt mir noch nicht so ganz, und ein direktes Einbetten des “Like-Buttons” kommt eigentlich nicht in Frage.

Ich weiß nicht was mich gerade mehr schockiert. Die Tatsache, dass einfache PDFs ziemlich “gefährlich” sein können…

… oder die Tatsache, dass ich diese E-Mail quasi “routinemäßig” geöffnet habe (weil ich solche Mails nunmal praktisch gewohnt bin). Und das obwohl auf den zweiten Blick sowohl die Empfängeradresse als auch die Widersprüche im Text hätten auffallen müssen:

Außerdem muss ich gleich mal schauen, warum diese Mail überhaupt durch unseren Mailserver durchgelassen wurde - der doch eigentlich auch auf Viren prüft.

Manchmal ist es schon echt zum verzweifeln, wie hart einen Bugs in fremden Produkten treffen können.

Unser Hosting Control Panel unterstützt ja auch MySQL als Backend zur Speicherung der “eigenen” Daten. Der Zugriff auf MySQL erfolgt aus Performancegründen ausschließlich mittels Prepared Statements. Nun hat uns kürzlich ein LiveConfig-Kunde auf ein merkwürdiges Problem aufmerksam gemacht: regelmäßig erschien nach der Durchführung eines MySQL-Backups (via mysqldump) in LiveConfig die Fehlermeldung “Prepared statement needs to be re-prepared”.

Die Suche hiernach führte zum MySQL-Bug #41119. Als Workaround haben wir daher nun eine explizite Fehlerbehandlung nach mysql_stmt_execute() eingeführt, welche mit mysql_stmt_errno() die jeweilige Fehlernummer ausliest und in unserem Fall (Fehlercode 1615) das betroffene Statement explizit neu erzeugt.

Nur leider funktionierte dieser Workaround nicht. Also überhaupt nicht.

Ein ausführliches Debugging und Tracing aller Datenbankzugriffe hat dann ergeben, dass unsere Fehlerbehandlung gar nicht aufgerufen wird. Zusätzliche Debug-Ausgaben bestätigten dann tatsächlich, dass mysql_stmt_errno() immer “0″ zurückliefert! WTF!?!?

Diesmal hat MySQL-Bug #53311 zugeschlagen. Beseitigt ist dieser Fehler seit knapp einem Jahr ab MySQL Connector/C 6.0.3. Dummerweise ist diese Version aber nach wie vor nicht freigegeben (”aktuell” verfügbar ist nur Version 6.0.2).

Letztendlich haben wir hier nun den über 650 MB großen bazaar-Branch von libmysql ausgeckeckt, und müssen uns nun zwangsweise die 6.0.3-Release selbst erzeugen…

Nachtrag:

Finger weg vom MySQL-Connector/C 6.0.3! Ich glaube zu verstehen, warum diese Version noch nicht freigegeben wurde - da funktioniert die Hälfte nicht mehr… vor allem bei Prepared Statements scheint diese Version besonders merkwürdige Fehler zu haben - so funktioniert selbst ein einfaches UPDATE mit drei bestimmten Parametern (String/Int/String) reproduzierbar nicht mehr; ändert man die Reihenfolge der Parameter (zB. String/String/Int oder Int/String/String) so klappt’s plötzlich wieder. Und der Bug liegt definitiv nicht bei uns - selbst ein eigenes Testprogramm (basierend auf dem Beispiel von MySQL) führt bei einer bestimmten Variablenfolge zu einem “Incorrect arguments to mysqld_stmt_execute”. Ob das mit MySQL-Bug #61225 zu tun hat weiß ich nicht, aber auch dessen Fehlerbeschreibung lässt einen fast erschaudern.

Der Trick zu einem stabilen und aktuellen MySQL-Client führt über die GA-Pakete des Community-Servers. Einfach dort die entsprechenden Bibliotheken und Developer-Pakete zusammensuchen, oder aus dem “Generic”-Paket (.tar.gz) die Verzeichnisse “/lib” und “/include” nehmen. Der Client aus MySQL 5.5.20 spricht ebenfalls Protokollversion 10 (wie auch Client 6.0.x), dürfte daher soweit kompatibel sein. Man muss seinen eigenen Code allerdings neu gegen diese Bibliotheken linken, da es ein paar kleinere ABI-Unterschiede gibt.

Vorhin habe ich einen 15-seitigen Vertrag unterschrieben und an eine Kollegin weitergegeben, um diesen zur Gegenzeichnung an Google zu senden. Ein anderer Kollege wurde gleich hellhörig und fragte, ob das der Übernahmevertrag von Google ist.

Leider (noch) nicht - es handelt sich “nur” um einen Vertrag zur Auftragsdatenverarbeitung für Google Analytics…

Für uns “Tekkies” ist das kein Thema, aber viele “normale” Benutzer verwechseln gerne mal HTTP und HTTPS bei der Eingabe einer URL. Zum Glück kann OpenSSL erkennen, ob statt eines erwarteten SSL-Handshakes etwas eintrifft was eher nach einem “HTTP GET” ausschaut. Ist das der Fall, gibt OpenSSL die Fehlermeldung SSL_R_HTTP_REQUEST zurück.

So fängt LiveConfig in der nächsten Version (1.3) auch solche falschen Zugriffe ab und bietet dem Benutzer die “richtige” URL an. Ein kleines, aber praktisches Feature.

Eventuell werden wir bei Gelegenheit auch einen Test einbauen, ob bei HTTP-Verbindungen ein SSL-Handshake eintrifft, um dann ebenfalls eine entsprechende Fehlermeldung zu erzeugen.

Ich weiß das man sich da auf ganz dünnem Eis bewegt, aber ich kann es mir einfach nicht verbeißen: aufgrund der Forderung nach einer gesetzlichen Frauenquote bin ich dafür, auch in naturwissenschaftlichen Studiengängen eine Frauenquote einzuführen (wahlweise durch Zwangsstudium für Frauen, oder durch entsprechende Limitierung der Studienplätze für männliche Studenten).

Gleichzeitig sollte in überwiegend weiblich besetzten Berufen eine Männerquote gesetzlich vorgeschrieben werden. Grundschulen mit weniger als 30% männlicher Lehrer gehören umgehend durch allseits beliebte Finanzstrafen sanktioniert.

Und nicht zuletzt sollte endlich gesetzlich geregelt werden, dass es an Weihnachten immer zu schneien hat!

Gut, dass es offenbar derzeit keine anderen Probleme gibt.