Krisenmanagement bei 1&1

In der Krise zeigt sich, was der Provider wirklich drauf hat. Krise bei 1&1 war gestern. Und das Krisenmanagement hat sich mit der Internetleitung einen Wettstreit darum geliefert, wer von beiden der größere Totalausfall ist.

Los ging es um kurz vor drei. Fünf von fünf Servern nicht erreichbar. Ein kurzer Check über die serielle Konsole ergab aber, dass es nicht an den Servern lag. Der Twitter-Account @1und1 brauchte dann geschlagene 20 Minuten, um das auch zu bemerken. Die, man sollte annehmen eigentlich genau für einen solchen Fall gedachte, Statusseite status.1und1.de hingegen verkündet auch heute morgen noch, dass alle Systeme funktionieren würden und dies seit dem 4. August so sei.

Ziemlich genau zwei Stunden später waren dann alle Server wieder erreichbar bis kurz vor 20 Uhr. Und hier kommt der Teil, der mich an dieser Geschichte wirklich aufregt. Fehler können immer mal auftreten, da kann man sich noch so gut absichern. Und ich gestehe jedem eine angemessene Zeit zu, dass er diese beheben kann. Wenn man aber um kurz nach fünf mit großen Halali auf Twitter verkündet, dass jetzt wieder alles gut sei, dann sollte man alles daran setzen, dass nicht genau der gleiche Fehler kurz darauf wieder auftritt:


Die Ursache ist bekannt. In anderen Worten:

Scheiße, genau das gleiche wie vorhin. Warum haben wir das nicht einfach vernünftig gefixt?

Und obwohl 1&1 weiß, woran es liegt, brauchen sie erneut über zwei Stunden, um das Problem aus der Welt zu schaffen!
Krisenmanagement und vor allem auch Krisenkommunikation sieht anders aus. Die angesprochene Statusseite hat sich auch beim zweiten Ausfall nicht aktualisiert und der Twitter-Account war eigentlich immer so viel zu spät dran, dass man sich auch den hätte sparen können.

Konfigurierbare Produkte mit individuellen Preisen

Bei manchen Funktionalitäten, die in Magento eingebaut sind, fragt man sicht schon, ob man bei Varien mit dem, was man sich da zusammenklöppelt, auch einen Praxisbezug sieht oder ob man einfach irgendwas programmiert, egal ob es in der Praxis brauchbar ist oder nicht. Die Preisvergabe bei konfigurierbaren Produkten ist so ein Fall. Magento sieht von Haus aus vor, dass man einer Variante, etwa einer anderen Größe, einen festen oder prozentualen Aufpreis geben kann. Oder anders gesagt, die untenstehende Preismatrix funktioniert mit diesem System schon nicht mehr:

  11cm 15cm
natur 28,40 31,80
Goldrand 31,20 34,90
lasiert 34,60 40,70

Denn bei natur kostet die 15cm-Variante 3,40 Euro mehr, bei Goldrand aber schon 3,70 Euro und bei lasiert gar 6,10 Euro. Das lässt sich weder durch einen Fixpreis noch durch einen prozentualen Aufschlag abdecken und wenn man dann noch bedenkt, dass man das auch noch für die Ausführung (natur, Goldrand, lasiert) machen muss bricht das ganze System in sich zusammen.

Zum Glück gibt es eine Lösung, die eigentlich so naheliegend ist, dass man sich fragt, warum Magento das nicht einfach von Haus aus kann: Simple Configurable Products. Die Erweiterung sorgt dafür, dass einfach der direkt beim Produkt hinterlegte Preis benutzt wird. Und nicht irgendwelche komischen Berechnungen durchgeführt werden, die am Ende doch nicht zum gewünschten Ergebnis führen.

Einen kleinen Bug hat die Erweiterung aber: Zeigt man die gewählte Option im Warenkorb an, dann wird immer das Admin-Label für das Attribut verwendet, welches nicht mehrsprachig ist. Aber dafür gibt es Abhilfe. Die Datei, um die es geht, ist Checkout/Block/Cart/Item/Renderer.php. Dort findet sich in Zeile 81:

'label' => $attribute->getFrontendLabel(),

Das muss lediglich durch

'label' => $attribute->getStoreLabel(),

ersetzt werden und schon sind die Label auch in der jeweiligen Store-Sprache.

Umlaute im URL key von Magento

Umlaute ist ja eines meiner Lieblingsthemen. Und Magento stellt sich da direkt hinter Afterbuy in die ‘Können wir nicht’-Schlange. Naja, fast. So heißt es in meinem Lieblingsbuch auf Seite 162:

Die URL-Bezeichnung ist wichtig, wenn Sie als Shop-Besitzer die Anzeige in der Adressleiste eines Browsers beeinflussen möchten. Sollten Sie das Feld leer lassen, generiert Magento automatisch aus dem Produktnamen die URL-Bezeichnung. Da das System aus dem USA stammt, werden die Umlaute dabei nicht berücksichtigt, sondern falsch dargestellt: ä als a, ö als o etc.

Soweit richtig. Magento berücksichtigt in der URL-Bezeichnung (URL key) keine Umlaute. Warum man im Buch aber nicht direkt auf die Lösung verweist erschließt sich mir nicht. Denn wer mag schon bei vierstelligen Produktzahlen jeden URL key in Handarbeit erstellen?

Allerdings muss die im Magento-Wiki befindliche Lösung noch etwas erweitert werden, denn die Einträge in app/etc/local.xml, die im Wiki genannt werden, berücksichtigen weder ß noch die Großbuchstaben Ä, Ö und Ü (die Ersetzung erfolgt offensichtlich bevor der String in Kleinbuchstaben gewandelt wird).

Der fertige Block, der direkt vor </config> eingesetzt wird, muss also lauten:

<default>
  <url>
    <convert>
      <char0228><from>ä</from><to>ae</to></char0228>
      <char0246><from>ö</from><to>oe</to></char0246>
      <char0252><from>ü</from><to>ue</to></char0252>
      <char0223><from>ß</from><to>ss</to></char0223>
      <char0196><from>Ä</from><to>ae</to></char0196>
      <char0214><from>Ö</from><to>oe</to></char0214>
      <char0220><from>Ü</from><to>ue</to></char0220>
    </convert>
  </url>
</default>

Damit werden Umlaute im Produktnamen im URL key korrekt umgeschrieben. Die Einstellung greift nicht für Kategorien. Wer dafür eine Lösung hat, immer her damit, aber Kategorien legt man ja auch nicht so oft neu an wie Produkte bzw. nicht in der selben Anzahl.

Steht zu euren Fehlern, Sage!

Wir benutzen für unsere Buchhaltung den GS Buchhalter von Sage. Den kann man mit diversen Datenbanksystem betreiben, unter anderem auch mit MySQL 5, was wir dankend angenommen haben, da bei uns der Betrieb mit SageDB nicht möglich war.

Jedes Jahr gibt es für den GS Buchhalter ein Update, so auch beim Jahreswechsel von 2010 nach 2011. Dieses einzuspielen wird vom Sage-Support nicht nur empfohlen, sondern regelrecht gefordert. Während das die Jahre zuvor problemlos funktioniert hat war das dieses Mal nicht so. Diverse Vorgänge liegen in einen Fehler, die Buchhaltung konnte schlicht und ergreifend nicht arbeiten. Der Anruf beim Sage-Support brachte nur die Erkenntnis, dass das ein Fehler in unserem Server für verantwortlich sein müsste, das Update selbst wäre fehlerfrei (guter Witz am Rande, aber mir war zu dem Zeitpunkt nicht nach Lachen).

Nachdem ich von der Buchhaltung eine SQL-Fehlermeldung bekommen habe war mir schnell klar, wo das Problem ist und es war auch genauso schnell klar, dass es durch das Update ausgelöst wurde:

Illegal mix of collations (latin1_german1_ci,IMPLICIT) and (latin1_swedish_ci,IMPLICIT) for operation ‘=’.

Da die komplette Datenbank und alle darin enthaltenen Tabellen vom Sage-Installer (bzw. vom Updater) angelegt wurden geht die falsche Kollation ganz klar zu Lasten von Sage.
Denn die Tabelle mand hat als Kollation latin1_swedish_ci, während alle darin enthaltenen Tabellen die Kollation latin1_german1_ci haben. Naja, nicht ganz alle. Nach dem Update existierten drei Tabellen, die auch latin1_swedish_ci als Kollation nutzten: sage_auf_ratenzahlung, sage_fib_buchungstexte_termine und sage_fib_buch_split. Offensichtlich hat der Updater die Kollation dieses Mal nicht explizit angegeben und daher wird die Kollation der Datenbank benutzt. Joins, die sowohl alte Tabellen als auch diese drei mit abweichender Kollation umfassen, laufen zwangsläufig in einen Fehler.

Man kann das Problem lösen, indem man die Kollation der Tabellen händisch auf latin1_german1_ci ändert, auch die Datenbank selbst sollte man ändern, denn der nächste Sage-Updater hat eventuell genau den gleichen Bug und legt wieder Tabellen ohne explizite Kollationsangabe an.

Und was schreibt der Sage-Support, explizit auf die Punkte angesprochen?

Bei dem von Ihnen benannten Sachverhalt handelt es sich nicht um einen Programmfehler.

Nein, natürlich nicht. Und die Erde ist eine Scheibe!

Reichelt weiß, wie’s geht

Ich bestelle ja gern bei Reichelt. Nicht, weil der Shop sonderlich hübsch oder besonders gut benutzbar ist, eher das Gegenteil ist der Fall, sondern weil die Preise gut sind und die Ware schnell ausgeliefert wird.

Beim Aufräumen fiel mir jetzt ein alter Gutschein über 10 Euro in die Hände. Passend, da ich eh bestellen wollte. Geht um Strom sparen und so, mehr dazu in Kürze auf blogpotato.de. Da sich im ganzen Checkout-Prozess kein Feld findet, in das man die Gutscheinnummer eintragen könnte habe ich kurzerhand ins Kommentarfeld geschrieben, man möchte mir doch bitte den Gutschein mit der Nummer #123456 mit dieser Bestellung verrechnen.

Heute morgen finde ich dann in meinem Postfach eine E-Mail mit dem vielsagenden Betreff ‘Reichelt Mail-Service’. Und darin heißt es wörtlich:

Gutscheine benötigen wir im Original! Schicken Sie uns
diese bitte per Post (Reichelt Elektronik, Elektronikring 1,
26452 Sande) zu

Bitte beachten Sie außerdem folgendes:
– Die Ware wird erst NACH Eingang Ihrer Antwort an Sie versendet.
– Sie bekommen auf Ihre Antwort von uns KEINE Bestätigungmail.
– Wenn Sie sich auf unsere Anfrage nicht melden, wird Ihre Bestellung
nach 1 Woche automatisch aus unserem System entfernt.

Entschuldigung? Da hab ich mich wohl verhört, oder? Jedes popelige Open-Source-Shopsystem ist in der Lage, Gutscheincodes direkt im Bestellprozess entgegenzunehmen und zu validieren. Jeder Wohnzimmerversender kann folglich ein funktionierendes und für den Kunden leicht benutzbares Gutscheinsystem implementieren, nur Reichelt schafft das nicht?
Mir schon klar, warum das so ist, wenn ich mir die Gutscheinnummer so anschaue. Die ist wohl einfach fortlaufend. Aber die Lösung kann ja wohl nicht sein, dass ich mir ein Kuvert (1,99€ und neun Stück, für die ich keine Verwendung habe) und dazu eine Briefmarke (0,55€, gibt’s zum Glück einzeln) kaufen muss. Da gehen ja schon allein 25% des Gutscheinwertes für unnötige Ausgaben drauf! Darüber hinaus will das ganze eingetütet und zur Post gebracht werden. Und dann darf ich auch noch auf meine Bestellung warten, bis der Gutschein bei Reichelt eingetroffen ist und verbucht wurde!

So kann man natürlich auch die Kundschaft effektiv davon abhalten, Gutscheine einzulösen. Das Geld hat man ja schon kassiert. Ein Schelm, der böses dabei denkt.

So geht Support, 1&1!

Geht eigentlich gar nicht um 1&1, sondern um Spreadshirt. Aber vielleicht mag man sich in Montbaur mal ein paar Sachen dort abgucken, nachdem das letzte Erlebnis mit dem 1&1-Support wieder unterirdisch schlecht war.

Ich mach mir ja ab und zu selber T-Shirts. In meiner Gewichtsklasse gibt es nicht immer unbedingt alles, also muss man hin und wieder selber ran. Das mache ich gerne bei Spreadshirt, die sind zwar in Sachen Übergrößen nicht unbedingt die billigsten, aber es geht schnell und einfach und die Qualität ist auch gut.
Spreadshirt hat jetzt auf ein neues, umweltschonenderes Druckverfahren umgestellt. Als direkte Folge davon riechen die Shirts leicht nach Essig, daher soll man sie vor dem ersten Tragen waschen. Ich kann bestätigen, dass dadurch der Geruch rausgeht. Der Druck, zumindest in meinem Fall, aber auch. Vom eigentlichen Logo waren nach dem ersten Waschen nur noch ein paar wenige Fragmente zu sehen, das T-Shirt war also nahezu weiß.

Ich habe also an den Support geschrieben und hatte direkt am nächsten Tag eine Antwort, der man sofort anmerkte, dass sie nicht aus der Textbausteinsammlung zusammengeklickt wurde. So wurde unter anderem auf das Problem eingegangen, dass man das Motiv nicht mehr nachdrucken könne, weil es bereits wieder gelöscht worden sei.
Ja, ich hatte da ein vorhandenes Logo leicht verfremdet und das Legal-Department von Spreadshirt hat das gemerkt und das Motiv gelöscht. In der Folge entwickelte sich eine unterhaltsame E-Mail-Konversation, immer mit dem selben Supportmitarbeiter, wobei es mir primär darum ging, das Motiv noch einmal hochzuladen, ohne dass die Sheriffs vom Legal-Department gleich wieder losreiten würden. Klappte natürlich nicht, trotzdem wurden meine Anfragen immer freundlich, schnell und vor allem individuell beantwortet.


Wir halten fest: Auch wenn ich mich nicht in allen Punkten durchsetzen konnte, hatte ich doch im gesamten Verlauf den Eindruck, wie ein Kunde behandelt zu werden. Und nicht wie ein Bittsteller, wie das bei 1&1 der Fall ist.

Support geht anders, 1&1!

Wegen den Problemen mit dem 1&1-Zertifikat, das neuerdings ein, oder genauer gesagt zwei, Zwischenzertifikat(e) erfordert, habe ich mich an den 1&1-Support gewandt. Schließlich bietet man sich ja nachgerade an:

Für Rückfragen zu diesem Vorgang stehen wir Ihnen gerne zur Verfügung.

Ich habe natürlich die Anleitung von Geotrust vorher nicht durchgelesen, schließlich gab es von 1&1 keinerlei Hinweise darauf, dass sich am Zertifikat irgendwas geändert hätte. Trotzdem habe ich direkt in der ersten Mail darauf hingewiesen, dass ich die Leistung gerne so hätte wie die vergangenen Jahre (also ohne Zwischenzertifikat), die Fehlermeldung war sehr eindeutig in diese Richtung gehend:

Dieses Zertifikat wurde von einer unbekannten Instanz signiert.

Das ganze als Anhang an die Mail gepackt und ab damit.

Erste Antwort vom Support nach zwei Tagen, es wäre kein Anhang an meiner Mail dran. Also schicke ich den Screenshot erneut. Zweite Antwort, anderer Supportmitarbeiter: Den Screenshot hätte ich doch bereits bei meiner ersten Mail geschickt. Aber vielleicht könnte ich grade mal erzählen, was ich mache. Klar, kann ich:

Nun, wie gehe ich vor? Ich gehe so vor wie die letzten 4 Jahre: Ich rufe Plesk 8.0.1 auf, klicke auf Server, klicke auf Zertifikate, wähle den Eintrag für zertifikat.domain.de, lade das Zertifikat als Text im Feld ‘Zertifikat’ hoch – und sehe mich seit diesem Jahr mit einen Zertifikatsfehler konfrontiert.

Was kommt als Antwort vom mittlerweile dritten Supportmitarbeiter? Ich solle doch bitte beschreiben, wie man den Fehler nachvollziehen könne. Leicht in Rage kopiere ich noch einmal obige Schritt-für-Schritt-Anleitung und frage höflich nach, welchen Teil man davon bei 1&1 nicht verstanden hätte. Die Antwort lässt nicht lange auf sich warten (nur drei Tage): Problem nicht nachvollziehbar, da ich ja auf der Domain wieder das alte Zertifikat aktiviert hätte. Case closed.


Wir halten also fest:

  • 1&1 hat sieben Tage gebraucht, um den Supportcall ohne Lösung zu schließen
  • Auf die Tatsache, dass ein Zwischenzertifikat erforderlich ist, ist niemand eingegangen
  • Vier verschiedene Supportler haben mir geantwortet – bei insgesamt vier E-Mails seitens 1&1
  • 1&1 erwartet anscheinend allen Ernstes, dass ich im Weihnachtsgeschäft in einer Live-Umgebung ein ungültiges Zertifikat benutze, damit der Support den Fall nachvollziehen kann

Fazit: Setzen, sechs. So in etwa ist auch das Feedback auf die „Waren sie zufrieden”-Mail ausgefallen, die interessanterweise kam, bevor der Fall von 1&1 eigenmächtig als erledigt abgehakt wurde. Ich glaube aber nicht, dass das jemand dort liest. Auch nicht Marcel D’Avis.

Zwischenzertifikat für’s Zwischenzertifikat

Auf die hier angesprochenen Probleme mit dem 1&1 SSL-Zertifikat, die sich durch die nicht angekündigte Umstellung auf eine Lösung mit Zwischenzertifikat ergeben, ist man mittlerweile auch bei Geotrust aufmerksam geworden.

Und man löst das ganze über eine weiteres Zwischenzertifikat. Das heißt, man hat jetzt zum gleichen Preis wie vorher kein Rootzertifikat mehr und auch kein Zertifikat, dessen Stammzertifikat ein Root-Zertifikat ist (was sich mit dem ‘falschen’ Zwischenzertifikat von Geotrust ja mit einem gewissen Bastelaufwand bewerkstelligen ließ), sondern einen bis in die vierte Ebene verschachtelten Zertifikatsbaum.

Als die Welt noch in Ordnung war: Zertifikat ohne Zwischenzertifikat


Funktionierende Selbstbaulösung mit einem Zwischenzertifikat


Das neueste aus dem Hause Geotrust: Zwei Zwischenzertifikate

Nur damit wir uns nicht falsch verstehen: Dadurch wird nichts unsicherer. Und zumindest als 1&1-Kunde hat man bislang für das Zertifikat ja auch nichts bezahlt, aber es bleibt trotzdem ein fader Beigeschmack bei dem Ganzen.

Der schleichende Niedergang…

…des 1&1-SSL-Zertifikats.

1&1 bietet seit Jahren zu seinen Server-Produkten ein SSL-Zertifikat kostenlos mit an.

Dabei handelte es sich die letzten Jahre, und ich habe seit mindestens fünf ein solches im Einsatz, um ein vollwertiges Zertifikat, d.h., es war als Rootzertifikat ausgestellt und ist somit ohne irgendwelche Zwischenzertifikate nutzbar. Da ist es dann auch nicht weiter wild, dass man es jedes Jahr erneuern muss. Das Zertifikat wird über Plesk verwaltet, bislang reichte es einfach aus, das neue per Copy&Paste in der Zertifikatsverwaltung einzupflegen und den Apache neu zu starten.

Seit diesem Jahr geht das nicht mehr. Denn seit diesem Jahr stellt Geotrust, die der eigentliche Leistungserbringer sind, das Zertifikat mit Zwischenzertifikat aus und als Nutzer erfährt man davon erst, wenn man das Zertifikat eingefügt hat und die Seite aufruft, um zu prüfen, ob alles in Ordnung ist. Denn dann wird man von einem hübschen Zertifikatsfehler begrüßt, der je nach Browser mehr oder weniger furchteinflößend daherkommt.

Eine kurze Information seitens 1&1, dass sich am Zertifikat und seiner Installation etwas geändert hat, wäre als wirklich nicht zu viel verlangt. Denn die Installation ist, anders als es die Anleitung bei Geotrust vermuten lässt, nicht ganz so einfach. Geht man nämlich gemäß Anleitung vor und lädt die Zertifikate getrennt hoch quittiert Plesk das mit einer Meldung, dass das Zwischenzertifikat nicht zum eigentlichen Zertifikat passen würde. Abhilfe schaffte im konkreten Fall bei Plesk 8, beide Zertifikate in der eigentlich nur für das Zertifikat vorgesehenen Box gleichzeitig hochzuladen – BEGIN/END-Zeilen dabei nicht vergessen. Ob es sich dabei um einen Fehler in der Anleitung von Geotrust handelt oder es an der zugegebenermaßen antiquierten Plesk-8-Version liegt, darüber kann man nur spekulieren.

Der 1&1-Support konnte im Übrigen nicht wirklich weiterhelfen. Aber das ist eine andere Geschichte…

Page 2 of 212