Aus dem Rechenzentrum

Wir setzen zur Handhabung des Supports gerne den Request Tracker ein. Der benötigt in der neuesten Version HTML::Mason >= 1.36. Da wir auf den fraglichen Systemen üblicherweise die yum-Repositories von RPMforge eingebunden haben, nutzen wir „yum install perl-HTML-Mason“, was uns aber nur Version 1.32 verschaffte. Da die zu alt ist, haben wir kurzerhand die aktuellste Version 1.40 mittels cpan2rpm von Hand installiert. Die böse Überraschung erfolgte nach einem späteren „yum upgrade“: Aus dem RPMforge-Repository wurde die 1.32 drübergebügelt, und der RT lief nicht mehr.

Mit Blick auf die im Repository enthaltenen Mason-Pakete konnte ich dann feststellen, dass zu einer unseligen Zeit das fragliche RPM mit der Versionsnummer „1.3200“ bereitgestellt wurde. Und, Überraschung: Bei RPMforge gibt es durchaus auch die 1.40 – und auch schon die 1.39, die 1.38, … und eben die 1.3200. Die betrachtet das Versionsmanagement nun aber dummerweise als neueste Version – nicht ganz zu Unrecht, denn mathematisch gesehen ist 3200 nun mal größer als 40.

Also erstmal die 1.40 von Hand installiert und eine Ausnahme in die /etc/yum.conf eingetragen; gleichzeitig Info an Dag Wieers (RPMforge) mit der Bitte um einen Bugfix.

Nach der Arbeit kommt es oft genug vor, dass die Energie einfach nicht mehr zum Kochen reicht. Gut, dass Joeys in der Nähe ist. Ich habe dort schon rund zwei Dutzend Mal bestellt. (Dass im Regelfall immer etwas fehlte, die Lieferung deutlich länger als telefonisch angekündigt dauerte oder sonstwas war, sei mal dahingestellt.)

Das heutige Telefonat verlief dann in etwa so:

Er: „Joeys Pizza-Service, was kann ich für Sie tun?“

Ich: „Pasche, guten Abend. Ich würde gerne etwas zum Liefern bestellen.“

Er: „Pasche … ah, Albert-Schweitzer-Str. 2d? Moment, ich muss kurz schauen, ob Sie noch zum Liefergebiet gehören.“

Ich: – – –

Er: „Herr Pasche? Es tut mir leid, Sie gehören nicht mehr zu unserem Liefergebiet.“

Ich: „Aber ich habe schon zwei Dutzend mal bei Ihnen bestellt.“

Er: „Ja, aber unser Liefergebiet wurde ab dem 2.3.2009 geändert.“

Ich: „Aber ich habe auch schon nach dem 2.3.2009 Pizza bei Ihnen bestellt und auch geliefert bekommen.“

Er: „Hmja. Aber Sie gehören nicht mehr zum Liefergebiet.“

Ich: „Also gibt es jetzt eine Joeys-Filiale, die mehr in meiner Nähe liegt und jetzt zuständig ist?“

Er: „Äh … nein.“

Ich: – – –

Er: – – –

Ich: „Welche Joeys-Filiale kann uns denn dann jetzt noch Pizza liefern?“

Er: „Keine. Sie können natürlich etwas bestellen und dann bei uns abholen.“

Ich: „Ich dachte, Joeys sei ein Lieferservice.“

Er: „Es war nur ein Vorschlag. Möchten Sie jetzt etwas bestellen?“

Ich: „Ach, wissen Sie, wenn Sie sich so einen schicken Plan ausdenken, wie man Stammkunden zu Ex-Kunden macht, dann will ich dem nicht Weg stehen.“

Das neue Liefergebiet liest sich übrigens so: „Altstadt, Neustadt, Uni-Klinikum“. Gi-gan-tisch. Unnötig zu sagen, dass ein großer Teil der Neustadt wesentlich weiter weg von der Joeys-Filiale liegt als die Albert-Schweitzer-Straße. D’Oh.

Tja, dann wird sich Luigi eben künftig öfter wieder über Besuch freuen.

ClickandBuy? Mal von gehört. Ich hab nix mit denen zu tun. Aber ich weiß von einem Kunden, dass man sich dort mit seinem Bankkonto anmelden muss und dann eine Überweisung in Höhe von 0,01 EUR erhält, die im Verwendungszweck einen Freischaltcode enthält, den man im Web eingeben muss, um das Konto zu „aktivieren“.
Nun finde ich plötzlich einen solchen Cent mit Freischaltcode auf meinem geschäftlichen Konto vor. Und denke mir, och naja, kannst ja ClickandBuy einfach mal Bescheid sagen, dass da wohl jemand die falschen Kontodaten angegeben hat.
Ich bekomme zur Antwort:

Wir haben Ihren Verdacht, dass es sich bei der vorliegenden Registrierung um einen Betrugsfall handeln könnte, zur Kenntnis genommen. […] Bitte stornieren Sie gleichzeitig bei Ihrer Bank die Abbuchungen unseres Unternehmens.

Wir werden die Weiterleitung an die Rechtsabteilung unverzüglich vornehmen, sobald Sie uns erneut per eMail bestätigen, dass Sie sich nicht für ClickandBuy registriert und dass Sie die folgenden Verbindungen nicht ausgelöst haben:

Kauf   26.03.2009 / 20:06:30   75103821   PStars   50,00 EUR

Also schreibe ich zurück, alles klar, ich war das nicht, ich weiß auch nicht, was „PStars“ sind, und überhaupt: Sie können ja gar nichts bei mir abbuchen, denn ich habe ja den Freischaltcode nicht eingegeben. Wo auch, ich wüsste ja nicht mal, dass ich dort einen Account habe.

Eine Woche später werden 50 Euro abgebucht.

Tolle Wurst. Ich denke mir, super, dann lass ich das eben stornieren, wenn die das so wollen – kostet die dann halt Geld, aber sie hätten die Abbuchung ja auch bleiben lassen können.

Ich storniere also die Abbuchung und schreibe interessehalber nochmal an ClickandBuy:

Soweit ich weiß, verifiziert Ihr Unternehmen die Korrektheit der Bankverbindung, in dem Sie eine Überweisung in Höhe von 1 Cent tätigen und im Verwendungszweck einen Freischaltcode angeben, den der Kontoinhaber nach Erhalt wiederum auf Ihrer Website eingeben muss.

Diesen Code habe ich einige Tage zuvor erhalten, was ja der Grund für meine Anfrage war. Ich habe ihn aber nirgendwo eingegeben, da ich keinen Vertrag mit ClickandBuy habe – und eine dritte Person, die meine Kontodaten unberechtigterweise verwendet hat, kann ja eigentlich keine Kenntnis über den Freischaltcode erlangt haben.

Können Sie mir mitteilen, wieso es dann trotzdem zur Abbuchung einer Leistung gekommen ist, obwohl jener Dritte sich offenkundig nicht mit dem Freischaltcode hatte ausweisen können?

Diesen Code habe ich einige Tage zuvor erhalten, was ja der Grund für meine Anfrage war. Ich habe ihn aber nirgendwo eingegeben, da ich keinen Vertrag mit ClickandBuy habe – und

Nun habe ich heute Antwort erhalten. Schon der Header ist spannend:

From: ClickandBuy Service <service@de.clickandbuy.com>
To: Jonas Pasche <mail@jonaspasche.com>
Cc: cash0344@web.de

WTF?! Und es ist nicht nur ein dummes Versehen im Header, sondern die Mail beginnt auch mit einem standardisierten Kopf:

Ihr Benutzername lautet: cash0344@web.de
Ihre ClickandBuy Kundennummer lautet: 77746812

ClickandBuy hat mir also nun die Kundennummer, die E-Mail-Adresse und die Buchung (Datum, Uhrzeit, Produktname, Bestell-ID, Preis) mitgeteilt. Der Datenschutz lebe hoch! Vor allem machen es diese Angaben der Polizei sicher sehr viel einfacher, den Verursacher zu ermitteln.

Schließlich beweist ClickandBuy Humor:

Sehr geehrte(r) Herr Paschke,

vielen Dank für Ihre eMail und Ihr Interesse an ClickandBuy.

ClickandBuy ist das einfache, schnelle und sichere Tarifierungs- und Abrechnungssystem für das Internet.

Nun, äh, „sicher“ ja offensichtlich nicht. Naja, vielleicht für die Kunden. Nur die Nichtkunden, die müssen sich wohl in Acht nehmen.

Und dann schießen sie den Vogel ab:

Gerne möchten wir Ihnen Ihre Anfrage persönlich beantworten, wir möchten Sie daher bitten, unser Serviceteam unter der u.g. Telefonnummer anzurufen. Unser Service-Team steht Ihnen täglich 24 Stunden zur Verfügung.

+49 1805-333 450 (0,14 EUR / Min.).

Es ist ja nicht nur die Dreistigkeit, von mir zu verlangen, eine kostenpflichtige Telefonnummer anzurufen. Wenn sich jemand die Mühe macht, mir schriftlich mitzuteilen, dass ich die Auskunft nur telefonisch erhalten werde, dann weiß ich schon, wie das endet, wenn man sie dann auf eine entsprechende Auskunft festnageln will: „Daran können wir uns nicht erinnern“, „Das haben wir SO nie gesagt“, „Das müssen Sie falsch verstanden haben“.

Sorry, aber wer sich um eine schriftliche Auskunft drückt, der will mauscheln – 100%.

Nachher wird dann mal Anzeige bei der Polizei erstattet.

Für einen Kunden wollte ich ein SSL-Zertifikat verlängern. Bei Thawte. Ich war es gewohnt, dass zumindest bei einem Renewal nach einem Jahr noch nicht die Unterlagen (HR-Auszug etc.) neu eingereicht werden müssen und war von daher einigermaßen überrascht, als mir die Statusseite des Zertifikats anzeigte: „all renewals need to be re-authenticated and will no longer be issued automatically“. Aber nun gut. Also wollte ich die mir ja noch vorliegende Dokumentation nochmal losschicken. Dazu steht auf der Statusseite: „Your documentation is being processed by our Customer Services team. You can contact the Representative working on your order directly.“

Schade, schade, schade: Die mit dem Wort „Representative“ verlinkte Adresse b_eu_general_entry@thawte.com existiert überhaupt nicht. Das Logfile meines Mailservers notiert:

starting delivery 686131: msg 1673822 to remote b_eu_general_entry@thawte.com
delivery 686131: failure: 64.18.5.10_does_not_like_recipient.
Remote_host_said:_550_No_such_user_-_psmtp/Giving_up_on_64.18.5.10.

Also dachte ich mir, hm, wäre doch eine gute Idee, den Thawte-Support darauf hinzuweisen. Ich öffne ein „Live Chat“-Fenster, berichte, wo genau die fehlerhafte Adresse verlinkt ist und sende die Fehlermeldung des Mailservers mit. Jeremy E, mit dem ich chatte, teilt mir freundlicherweise mit, dass das ja nicht schlimm sei und mein Zertifikat ja schon praktisch auf dem Weg sei:

Jeremy E: This certificate will be issued soon, and an email willb e sent to thawte@jonaspasche.com, it should be issued within the next hour or so, I am not sure where that email address will come into play

Er sei sich nicht sicher, wo diese Mailadresse überhaupt „into play“ komme? Ich erläutere, dass da doch steht, dass man nun auch bei jedem Renewal die Doku erneut einschicken solle und es von daher doch eine gute Idee wäre, für das Einsenden auch eine funktionierende Adresse anzugeben.

Jeremy E ist nicht beeindruckt. Er meint weiterhin, es ginge hier um speziell das eine Zertifikat, das ich gerade verlängern lassen will, und betont, ich brauche die Adresse doch gar nicht, das Zertifikat sei doch schon unterwegs.

Jeremy E: Yes, but your one will be issued, as it is only awaiting issuance.

Jaaa, ich weiß. Hast du mir schon gesagt, Jeremy. Ich weise darauf hin, dass es doch zumindest für andere Kunden relevant sei, eine funktionierende Adresse bereitgestellt zu bekommen:

Jonas Pasche: Fine!
Jonas Pasche: However, the e-mail address published on the status page should be fixed IMHO …

Jeremy E hat mittlerweile schon vergessen, um welche Adresse es geht und fragt:

Jeremy E: Which email address do you have there?

Oh bitte, das habe ich doch bereits oben geschrieben. Zusammen mit einem Logfile-Auszug. Aber gut:

Jonas Pasche: The word „Representative“ on the status page is linked to: b_eu_general_entry@thawte.com

Jetzt könnte es doch mal in der Sache vorangehen. Nicht so bei Schnellmerker Jeremy:

Jeremy E: I dont think you should worry about that honestly Jonas, your certificate is already pending issuance, so you will receive an email at thawte@jonaspasche.com when it has been issued, then you can simply install that to your server.

Meine Kollegen schauen schon etwas merkwürdig, als ich mit dem Kopf auf die Tischplatte schlage.

Jonas Pasche: Yes, I understood that. Thank you. However, OTHER users might worry about a non-functional e-mail address on your status page.

Ich werde dann bei der nächsten Verlängerung mal schauen, ob sich was bei der Adresse getan hat …

Oftmals stand ich vor dem Problem, eine Reihe von Datensätzen mittels DBI „auf einmal“ abzufragen und das Ergebnis praktikabel vorliegen zu haben. „Praktikabel“ heißt für mich, jeder Datensatz als Hashref. Nun benötige ich aber oftmals keine speziellen Index pro Datensatz, wie ihn selectall_hashref aber verlangt. Manchmal gibt es auch schlicht keinen passablen Index. Dafür möchte ich die Ergebnisse vielleicht sortiert beziehen. Bisher habe ich mir mit einer Krücke beholfen, die aus dem Hashref, dessen Values die gewünschten Hashrefs der einzelnen Datensätze sind, ein (sortiertes) Array aus den Datensatz-Hashrefs produzierte. Hat geklappt. War aber nicht elegant.

Elegant ist jetzt aber, dass selectall_arrayref nicht nur die Ergebnisliste so wie mittels ORDER BY angegeben zurückliefert, sondern auch dazu noch die Datensätze nicht zwingend ebenfalls als Arrayref liefern muss, sondern diese auch als Hashref liefern kann. Und so sieht das aus:

my $arrayref =
  $dbh->selectall_arrayref( $statement, { Slice => {} }, @bind );

Data::Dumper zeigt, wie die Struktur dann ausschaut:

$VAR1 = [
          {
            'key1' => 'value1',
            ...
          },
          {
            'key2' => 'value2',
            ...
          },
          ...
        ];

Neat! :-)

… scheint für die Auslieferer des Paketdienstes DHL eine besondere Bedeutung zu haben; jedenfalls nimmt man dort den ihr zu Ehren eingeführten Feiertag am 4. Dezember ziemlich ernst. Wir warten allerdings dringend auf eine Festplattenlieferung, die seit gestern im Depot der Zustellbasis herumgammelt, Verzeihung: sorgfältig aufbewahrt wird. Der Paketstatus im Onlinetracking verrät:

Oder sollte es sich hier ernsthaft um Betriebsferien handeln, bei denen alle Zusteller gleichzeitig ihren Jahresurlaub auf Haiti verbringen?! Mann, mann, mann.

manchmal glaubt man nicht wo ein Problem überall liegen kann. So geschah es das ich mal wieder eins von diesen Tickets in der Form „Ich habe nichts gemacht und auf einmal geht es nicht mehr“. Es ging in diesem Fall um einen DynDNS Account der immer wieder eine falsche IP bekam ohne das der Benutzer ein Update vorgenommen habe. Nach Recherchen im Logfile stellte ich fest, dass die IP Updates sehr wohl richtig vorgenommen wurden. Bzw. das dies mit den richtigen Zugangsdaten übermittelt wurden. Das eigenartige war nur, dass die vermeintlich richtigen Updates von einer Update-software kamen und die falschen Updates ca. 1 Stunde später von einer Fritzbox. Nach genauen überprüfen der übertragen IP Adressen stellte sich heraus das diese zu unterschiedlichen Internetanbietern gehörten. Das Fragezeichen über meinem Kopf wurde immer größer. In meiner Mail an den Kunden beschrieb ich diesen Umstand mit der Vermutung, dass ein dritter seine Zugangsdaten benutzten würde um seinerseits ein Update vorzunehmen. Als ich aber die Antwort des Kunden auf meine Vermutung las, könnte ich mich kaum auf dem Stuhl halten: „Ich hatte mal eine Fritzbox die ich gegen eine neue Ausgetauscht habe. Diese Box lag dann wochenlang rum und ist jetzt vorübergehend bei einem Bekannten gelandet … in dieser sind wohl meine DynDns Zugangsdaten noch vorhanden“. Man sieht also mal wieder wie sinnvoll es ist verschenkte Hardware auf Firmeneinstellung zurück zu setzten.

Zugegeben: In unserem von Kundenaufträgen bestimmten Arbeitsalltag spielt das Thema Datenschutz keine besondere Rolle. Mein Interesse daran ist eher privater Natur. Nichtsdestoweniger verfolge ich aktuelle Diskussionen mit Interesse und prüfe auch, inwieweit ich als Provider zu einem verbesserten Datenschutz beitragen kann oder gar Kunden das Thema schmackhafter machen kann.

Durch einen Bekannten wurde ich schon vor einiger Zeit auf die Aktion Wir speichern nicht aufmerksam gemacht. Vereinfacht gesagt geht es darum, die IP-Adressen von Website-Besuchern aus den Logfiles zu verbannen. Was mir selbst zunächst nicht klar war: §15 des Telemediengesetzes verbietet es sogar explizit, derartige Nutzungsdaten zu speichern, wenn diese nicht für Abrechnungszwecke, für die Ermöglichung des Zugangs oder zur Verhinderung von Missbrauch benötigt werden. Für alle drei Aspekte lassen sich im Website-Betrieb kaum stichhaltige Argumente finden.

Auf der Aktions-Website finden sich diverse Anleitungen für die Abschaltung von IP-Protokollierungen. Gegenüber Triviallösungen wie einem Script, das als Pipe fürs Logging funktioniert und dort IP-Adressen entfernt, haben Lösungen wie mod_removeip (dessen offizielle Website immer mal verschwindet) den Vorteil, dass diese nicht erst auf Logging-Ebene eingreifen, sondern schon vorher in den einer Applikation zur Verfügung stehenden Servervariablen die IP durch 127.0.0.1 ersetzen und somit jeglichen Zugriff anonymisieren. Auf diese Weise wird wirksam verhindert, dass auf Applikationsebene IP-Adressen geloggt werden könnten, selbst wenn das im access_log verhindert wird.

Drei Aspekte allerdings bereiten mir noch Kopfzerbrechen:

• Einige Mechanismen wie z.B. Session-Handling benutzen die IP-Adresse, um den Diebstahl einer Session (Übertragung auf einen anderen Rechner) dadurch zu verhindern, dass die Session an die IP gebunden wird. Dieser ohne Frage sinnvolle Mechanismus greift nicht mehr, wenn sowieso alle Zugriffe von 127.0.0.1 kommen.
• Logfile-Auswertungen, z.B. mit Webalizer, werden oftmals Zugriffe geografisch aus, und bei allem Wunsch nach Anonymität kann ich verstehen, dass insbesondere für international auftretende Unternehmen diese Informationen relevant und erhaltenswert sind.
• Schließlich dürfte eine „knallharte“ Durchsetzung von mod_removeip in Virtual-Hosting-Umgebungen wenig praktikabel sein. Schließlich hat nicht jeder Website-Betreiber die gleichen Datenschutzanforderungen; möglicherweise erfüllt der eine oder andere auch eins der Kriterien, unter denen eine Speicherung zulässig und erwünscht ist.

Aus diesem Grund habe ich mir einige Anforderungen überlegt, die ich persönlich an eine No-IP-Retention-Lösung hätte:

• Die Funktionalität soll pro virtuellem Host ein- oder ausstellbar sein, um die unterschiedlichen Anforderungen verschiedener Website-Betreiber abbilden zu können.
• Statt einer vollständigen Ersetzung der IP durch 127.0.0.1 könnte eine Kürzung der IP zum Einsatz kommen, bei der z.B. nur die letzte oder die letzten beiden Stellen der IP durch 0 ersetzt werden: Aus 1.2.3.4 würde zum Beispiel 1.2.0.0. Auf diese Weise wäre bereits Anonymität weitestgehend erreicht; die Ermittlung von Personendaten auf IP-Basis würde so bereits 256 bzw. 256^256 Ermittlungsverfahren bedingen. Gleichzeitig bliebe die Zugehörigkeit zum Class-C- oder Class-B-Netz erhalten, so dass zumindest eine grobe geografische Auswertung weiterhin möglich wäre. Last but not least würden Sicherheitsmechanismen wie IP-gebundene Sessions nicht mehr völlig wirkungslos sein: Ein Angreifer müsste nicht nur eine Session stehlen können, sondern noch dazu aus dem gleichen Netzbereich angreifen.
• Parallel dazu könnte die Top-Level-Domain des zugreifenden Hosts bestehen bleiben, in dem nur der Hostname selbst verschleiert wird, die TLD aber erhalten bliebe. Aus „dsl47110815.provider.se“ könnte so beispielsweise „anonymous.se“ werden, womit immer noch das Herkunftsland (Schweden) des Zugriffs dokumentiert wäre, ohne konkrete personenbezogene Daten vorzuhalten.

Ich höre mich derzeit nach weiterem Feedback zu dieser Fragestellung um und suche nach entsprechenden Möglichkeiten der Umsetzung. Da wir selbst hausintern keine Erfahrung mit der Erstellung von Apache-Modulen haben, würden wir ein entsprechendes Modul auch per Sponsoring (mit)finanzieren, solange das Ergebnis unter einer freien Lizenz veröffentlicht wird. Interessenten..?

Für einen Kunden habe ich erstmalig im größeren Stil mit einer an sich netten kleinen JavaScript-Bibliothek gearbeitet: mktree. Überhaupt sind die meisten der Bibliotheken von Matt Kruses JavaScript Toolbox sehr brauchbar: Sauber programmiert, leicht einsetzbar, kein Bloat.

Im konkreten Fall ging es um die baumartige Darstellung von Kategoriestrukturen. Bei den Tests lief alles wirklich prima, aber kaum war die Funktion freigeschaltet, meldete sich eine Anwenderin: Bei ihr bräuchte die überarbeitete Liste nun zwei Minuten zur Anzeige.

Einige Messungen später hatte sich herausgestellt: Der Server war schon nach zwei Sekunden fertig, aber der Browser, besser gesagt: JavaScript, hatte dann doch einiges zu tun: Mit dem Rendering von 1.600 Kategorien (jawohl!).

Es blieb für’s erste nichts anderes übrig, als derart große Kategoriesammlungen als starre, nicht auf- und zuklappbare Baumstruktur darzustellen. Funktioniert ja genauso gut, sieht nur nicht ganz so elegant aus. Dennoch schade, wo ich doch gerade erst mitgeteilt bekam, dass JavaScript so sauschnell sei … ;-)

Aus dem Zustellungsversuch einer Mail an einen Server:

Remote host said: 550 5.7.1 <abgelehnteadresse@nowhere>: Recipient address rejected: Mail appeared to be SPAM or forged. Ask YOUR Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs

Da frage ich mich doch: Was reitet einen Mailserverbetreiber, der doch schließlich einen spezifischen Grund hat, eine Mail abzulehnen, in der Ablehnungsmeldung nur mehrere unspezifische Möglichkeiten anzugeben? Auf diese Weise macht Debugging keinen Spaß.