Aus dem Rechenzentrum

Unsere Serverhardware bestellen wir inzwischen fast ausschließlich bei der Thomas-Krenn.AG. Nicht zuletzt, seit wir Ende letzten Jahres dort eine Betriebsführung mitmachen konnten, haben wir noch mehr Argumente dafür: Es geht einfach sauschnell, und das ist nicht zuletzt den hervorragend integrierten Prozessen bei Krenn geschuldet, die den Webshop, das Warenwirtschaftssystem und das RMA-System „aus einem Guss“ realisieren, mit hausintern entwickelter Software. Kurz gesagt: Was im Shop bestellt wird (und dort als „sofort lieferbar“ gekennzeichnet ist), kann typischerweise nach zwei Stunden per Paketdienst das Haus verlassen – also schon am nächsten Tag geliefert sein.

Ehrlich gesagt fehlt mir seitdem zunehmend das Verständnis dafür, wieso wesentlich größere Unternehmen wie Dell, die ebenfalls auf „Build-to-Order“ getrimmt sind, so elend langsam arbeiten.

Letzten Mittwoch hab ich dort was bestellt. Nichts Kompliziertes, zwei Vostro-Desktops ohne Extras. Bezahlt per Kreditkarte. Dann passierte erstmal zwei Tage lang nichts.

Am Freitag bekam ich eine handgeschriebene Mail in eher gebrochenem Deutsch („Hiermit bestätigen wir die Erhaltung ihrer Bestellung“, als ob „Erhalt“ und „Erhaltung“ synonym wären, aber es ist natürlich auch beruhigend, dass meine Bestellung vor dem Verfall bewahrt wird): Meine Kreditkarte konnte nicht belastet werden. Und ich Dummerchen dachte, sowas würde während einer Bestellung live geprüft – aber wohl nicht. Man bat mich um Mitteilung einer alternativen Zahlungsmethode. Hab ich dann auch am gleichen Tag gemacht und für diese Bestellung Bankeinzug genehmigt. Nebenbei kann sich auch meine Bank nicht erklären, was es für ein Problem mit meiner Kreditkarte geben sollte, denn das Limit böte eigentlich ausreichend Spielraum, und ich hatte in den letzten Wochen auch nichts anderes über die Karte gebucht. Sei’s drum.

Dann war natürlich erstmal Wochenende. Heute, am Montag, bekomme ich schließlich die Mitteilung, dass der Auftrag nun gebucht sei und man den Zahlungseingang abwarten würde. Herrje. Per Kreditkarte würde der Betrag vorab nur reserviert und erst nach Auslieferung der Bestellung auch gebucht. Nun will Dell das Geld aber gleich, und ein angehängtes PDF verrät mir den prognostizierten Liefertermin: 28.01.2010. In siebzehn Tagen! Oder ausgehend vom Bestelldatum: Satte drei Wochen, bis das Gerät hier ist.

Für ein Kind der Internet-Generation, das von Amazon & Co schon so „versaut“ ist, dass es eigentlich immer von „heute bestellt, morgen geliefert“ ausgeht, ist das harter Tobak – insbesondere, wenn andere Anbieter wie Krenn kurzfristige Lieferungen scheinbar spielend hinbekommen.

Aus der guten alten Zeit haben wir noch einige wenige Domains bei einem Domainregistrar, von dem wir uns schrittweise trennen, in dem wir die letzten Domains sukzessive kurz vor Ablauf zu InternetX transferieren. Das ist insofern eine ziemliche Arbeit, als dass es mit jenem Domainregistrar keinen Rahmenvertrag gibt, der uns davon befreite, für jeden Vorgang unterschriebene Faxe einzureichen. Als muss es hier Papierkram sein.

Nun sind wir praktischerweise für die restlichen Domains auch immer als admin-c eingetragen, denn bei einem der Domaininhaber handelt es sich um einen Verein mit relativ hoher Vorstands-Fluktuation, dem es lieber ist, wenn wir als „Konstante“ uns um seine Angelegenheiten kümmern; ein anderer Domaininhaber lebt im Ausland und benötigt so oder so einen deutschen Ansprechpartner als admin-c. Dass ich administrativer Kontakt der Domains bin, steht insofern auf rechtlich sicheren Füßen, da ich ausdrücklich dazu bevollmächtigt wurde.

Seit Monaten ziehe ich auf dieser Basis die Domains zu unserem neuen Registrar um und unterschreibe dazu auch die einzureichenden Freigabeerklärungen, wozu ich als admin-c laut DENIC-Richtlinien auch berechtigt bin.

Nun schlägt plötzlich ein Transfer fehl, mit der überraschenden Begründung, die Freigabeerklärung sei nicht vom Domaininhaber unterschrieben. Ich antwortete, das sei zwar richtig; sie sei aber vom admin-c unterschrieben, und der sei schließlich befugt, über den Verbleib der Domain zu entscheiden. Daraufhin passierte nichts. Ich insistierte daher einen Tag später noch einmal und streute bei der Gelegenheit noch ein, dass man ja dem letzten Dutzend Transfers auch schon zugestimmt habe, obwohl die Schreiben nicht vom Domaininhaber, sondern „nur“ vom admin-c unterschrieben worden wären.

Heute wurde dem Transfer dann plötzlich zugestimmt, und ich bekam eine überraschende Erklärung per Mail:

Herr Pasche,

wir wissen die Richtlinien von DeNic, aber Sie kennen nicht die Richtlinien in der $FIRMA. Wir als Registrar muessen sicher sein dass der Transfer in Ordnung ist.
Wir verstehen dass der AdminC normaler Weise dass Recht hat fuer die Transfers zu zustimmen. Aber wir muessen auch sicher sein dass zwischen den AdminC und den Domaininhaber keine Probleme gibt, kein Streit oder so. Darum haben wir diese Sicherheits Methode dass wenn ein Antrag nicht vom Domaininhaber stimmt schicken Wir dem Provider eine Mail, durch welch‘ wir auch die Zustimmung vom Domaininhaber verlangen.
Der Transfer wurde jetzt zugestimmt.
Hoffentlich haben Sie Verstaendniss fuer diese Sicherheits Methode aus unserem System.

Wer mich kennt, weiß, dass ich es nur schwer stehenlassen kann, wenn Leute Unsinn reden. Ich habe mich daher freundlich für die Zustimmung zum Transfer bedankt, aber es ging einfach nicht ohne diese Ergänzung:

Verständnis für diese „Methode“ habe ich allerdings nicht. Denn erstens wenden Sie sie offensichtlich nicht in jedem Fall an (zum Beispiel nicht bei meinen vorherigen 12 Transfers), und zweitens haben Sie den Transfer von $DOMAIN erst abgelehnt und dann aber doch zugestimmt, ohne dass sich an der Sachlage irgendetwas geändert oder sich der Domaininhaber dazu geäußert hätte. Ich habe Sie lediglich mit Nachdruck noch einmal zur Zustimmung aufgefordert, mehr nicht.

Die Sicherheitsmethode hängt also offensichtlich erstens vom Zufall und zweitens von Willkür ab. Damit ist es also weder eine Methode, noch dient es faktisch einer weitergehenden Sicherheit. Es ist nur eine ärgerliche und zeitraubende Verzögerung. Dafür fehlt mir in der Tat das Verständnis.

Jeder weiß, dass „mehr Sicherheit“ in der Regel mit „mehr Arbeit“ einhergeht. Um so weniger habe ich Verständnis dafür, wenn mich jemand ohne Not mehr Arbeit machen lässt, ohne dass dies einem erkennbaren Plus an Sicherheit dient. (Wer sich  über meinen „harten“ Umgangston wundert: Der ist beileibe nicht repräsentativ für meinen Umgang mit Geschäftspartnern und Lieferanten; im Gegenteil. Beim konkreten Registrar reiht sich der aktuelle Vorfall aber in eine ganze Reihe von Vorfällen, die einfach nur von geradezu methodischer Willkür erscheinen – sprich, es gibt durchaus einen Grund, warum wir schon vor langer Zeit zu InternetX gewechselt sind.)

Soeben habe ich die erste Version des Perl-Moduls „InternetX“ hochgeladen, mit dem sich die API (Handle-Verwaltung, Domainregistrierung, etc.) über eine „perlige“ Schnittstelle steuern lässt, sowohl als .tar.gz als auch als .src.rpm.

Problematisch war zunächst, dass die InternetX-API bei Domainaufträgen nur eine Rückmeldung im Sinne von „Auftrag angenommen“ liefert und die endgültige Rückmeldung erst im Nachhinein per E-Mail kommt. Wir haben uns daher überlegt, dass es doch ganz praktisch wäre, eine Art Eventliste zu realisieren, um diese periodisch nach zu erledigenden Aufträgen auszuwerten – und dafür eine POP3-Mailbox zu benutzen. Eine Methode eventlist() liefert also den Inhalt einer definierten Mailbox zurück, wobei die Mails hierbei automatisch in ein Hashref geparst werden, das sich leicht weiterverarbeiten lässt. Eine event_delete($uidl)-Methode ermöglicht das „Abhaken“ von Events als erledigt, in dem die betreffende Mail aus der Mailbox entfernt wird – simpel, aber effektiv.

Ich möchte anmerken, dass wir dieses Modul derzeit noch nicht produktiv einsetzen – wenngleich wir das bald umsetzen werden. Sicherlich gibt es hier und da noch etwas zu schleifen, aber letztlich beinhaltet das Modul ohnehin nicht viel eigene Logik, sondern ist in erster Linie Übersetzer zwischen gängigen Perl-Datenstrukturen und den XML-Strukturen, die InternetX verarbeitet. Für Feedback sind wir gerne zu haben; perldoc InternetX liefert außerdem passende Dokumentation mit Beispielen.

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 …

… 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.