Artikel mit ‘support’ getagged

Dunning-Kruger lässt grüßen

Montag, 03. Mai 2010

[Der] Dunning-Kruger-Effekt (DKE) ist eine Form der kognitiven Verzerrung und beschreibt die Tendenz inkompetenter Menschen, das eigene Können zu überschätzen und die Leistungen kompetenterer Personen zu unterschätzen.

Es kommt nur selten vor, dass mich Anfragen im technischen Support erreichen, die dazu führen, dass meine Gedanken den ganzen Tag über um nichts anderes kreisen und mich letztlich fast verrückt machen.

Vorweg: Ich finde es überhaupt nicht schlimm, wenn man von Technik keine Ahnung hat. Wirklich nicht. Ich sehe auch nicht auf solche Menschen herab. Es gibt genug Bereiche, in denen ich selbst völlig unbewandert bin.

Die Kombination aus Unwissenheit und Ignoranz ist aber dann schon eine Stufe härter. Sowas regt mich dann vielleicht kurz innerlich auf, aber dann hat sich’s auch wieder.

Wenn jedoch Unwissenheit, Ignoranz und dazu noch Besserwisserei zusammenkommen, fällt es mir schwer noch an mich zu halten.

Der Auslöser für diesen Blog-Beitrag war ein einfacher Satz (kurz zuvor hatte ich dem Kunden mitgeteilt, dass ich ihm nicht dabei helfen kann, wie er seinen lokalen Proxy-Server am vernünftigsten konfigurieren solle):

Da Sie mir keine Sicherheitsberatung bieten können, möchte ich Ihnen mal zeigen wie „Sicher“ ihre Server sind.

Gepaart mit einem Link zur Diagnoseseite von Googles Safe Browsing (die sagte, dass mit der Seite alles Bestens sei) und einem Link zu RadaBG.com, der aussagt, dass 0,06% der Seiten im Netz unseres Upstream-Providers (bei dem wir ja nur einer von vielen Kunden sind) vermutlich „malicious“ seien. In absoluten Zahlen: 3 Websites. Festgestellt 2005. Aha. Was das über die Sicherheit unserer Server aussagen soll, erschließt sich mir nicht.

Aber ein wenig zur Vorgeschichte. Im Zuge einer Supportanfrage des betreffenden Kunden fiel mir auf, dass ich beim Aufruf seiner Website ein 410 Gone bekomme, zusammen mit einer detaillierten Hinweissseite, dass ich gesperrt worden sei (beim ersten Aufruf seiner Seite!), weil ich gegen eine der Benutzungsregeln seiner Website verstoßen hätte. Diese Bedingungen („auf Grund meiner schlechten Erfahrungen notwendig“) umfassen diese strikt zu befolgende Anweisungen:

– es darf kein Proxy von mir erkannt werden
– ein wildes herumklicken ohne die Seite durch zu lesen ist nicht gestattet
– es muß von Ihrem Browser ein Referrer gesendet werden
– der Hostname zu Ihrer ip-Adresse muß aufgelöst werden können
– die *.css-Datei muß mit geladen werden
– die Ansicht meiner robots.txt ist nicht gestattet
– automatische Anfragen an meinen Server werden geblockt
– Anfragen in der URL mit http/https werden geblockt
– das scannen nach Schwachstellen mit einer Software sollte auch verhindert werden
– Anfragen außer POST, GET werden von mir abgewiesen
– Besuche ohne Browserkennung sind nicht möglich
– ohne aktivierte Cookies ist die Ansicht von Informationen nicht möglich

Ich blieb beim ersten Lesen nur kurz an „es muß von Ihrem Browser ein Referrer gesendet werden“ hängen. Mein Gefühl sagte mir: Naja, so kann das ja wohl schlecht gemeint sein, dann kann man ja seine Website nur über Links aufrufen – nicht aus einer Mail heraus, nicht von Hand eingegeben, und vor allem auch nicht aus einem Lesezeichen im Browser heraus.

Doch genauso ist es.

Minuten später trifft eine Mail bei mir ein, die mir allen Ernstes eine Anleitung gibt, wie ich seine Seite aufzurufen habe:

ich sehe gerade Sie besuchen meine Seite, und vielleicht auch noch einer Ihrer Kollegen. Damit Sie nicht noch weitere ip-Adressen verschießen besuchen Sie folgenden Link:

http://www.google.de/search?hl=de&q=das+hab+ich+mal+lieber+entfernt

Dort bin ich der 4. Link von oben. Da vielleicht Ihre Kollegen meine Seite direckt aufrufen wird natürlich am Anfang kein Reffer übertragen.

Ab 00:00Uhr setzt sich meine Openbsd Firewall in gang (PF) dort werden alle IP-Adressen die mein Webserver gesammelt hat gesperrt.

Ich war für einen Moment sprachlos. Ein ausgeprägtes Sicherheitsbedürfnis ist ja schön und gut. Bei diesem Mann scheint mir die Grenze zur Paranoia aber schon vor langer Zeit überschritten worden zu sein.

Inhaltlich beschäftigt sich seine Website mit Suchmaschinen-Optimierung (d’oh!). Und was ich da alles gelesen habe, das zog mir wirklich die Schuhe aus angesichts des riesigen Haufen Unsinns, aus richtigen Beobachtungen falsch gezogener Schlüsse, technisch grundfalscher Informationen und nicht zuletzt einer Rechtschreibung, die mir die Tränen in die Augen trieb. Ein andere Kunde von uns, der sich wirklich mit Suchmaschinen-Optimierung auskennt (normalerweise würde ich hier verlinken, aber ich möchte vermeiden, dass sein bissiges Zitat auf ihn zurückfällt), berichtete mir im Chat nach kurzer Lektüre der fraglichen Website von einem Vortrag, den er kürzlich besuchte:

ja, der SEO Papst Mario Fischer sagt dazu: 90% aller SEOs sind Dumpfbacken.

Kein Zweifel, dass ich hier nicht gerade mit jemandem zu tun habe, der sich zu den 10% zählen darf. Oder etwa doch? Immer wenn man ganz besonders laut „au Backe“ rufen möchte, tut es ganz gut, sich zu versichern, ob andere die eigene Einschätzung teilen – schon, um nicht selbst ein Opfer des DKE zu werden. Aber das Urteil der anderen fiel beruhigenderweise ebenso vernichtend aus. Eine kleine Auswahl:

Was für ein Irrer. Und das ist ein Kunde von dir?

Prost an den Herrn, er kann nur im Dauerkoma leben – anders ist das nicht erklärbar.

meinst du, er hat keine ahnung, was er da tut oder glaubst du, er weiß es sehr wohl?

ferndiagnostisch ne schizotype persönlichkeitsstörung :p

wow. der ist unfassbar dumm.

ich würde ihm wirklich das „sind sie blöd formular“ schicken

welcher total hirn ampotierte speert leute die auf seine seite gehen – da müsste ich doch eins an der latte haben

meine Güte, es gibt schon Spezialisten, oder?

Meine ganz persönliche Einschätzung ist: Der hatte noch nie mit jemandem mit technischem Sachverstand zu tun, der ihn mal an die Seite genommen hat und ihm sagte: Pass auf, mein Junge, das ist Mist, was du da schreibst. Ich erklär dir das mal. Und nun sieht er den Umstand, dass jeder mit einfachsten technischen Grundkenntnissen vor ihm sofort die Flucht ergreift, als Bestätigung dafür an, dass nur er der einzig wahre Experte ist.

Was also tun? Ihn in dem Glauben lassen, er sei der Größte auf Erden? Klar, irgendjemand muss ihm mal die Augen öffnen, aber muss unbedingt ich das sein? Höchstwahrscheinlich würde er ohnehin nur beleidigt sein, und noch viel schlimmer: Er würde sich darin bestätigt fühlen, dass auch wir wieder nur einer der vielen inkompetenten Provider sind wie die, mit denen er seiner Aussage nach bisher zu tun hatte. Umgekehrt wäre es natürlich auch fies, jemandem deutlich zu schreiben, dass er keine Ahnung hat, wenn man dann nicht auch bereit wäre, ihn darüber aufzuklären, wie die Dinge in Wirklichkeit funktionieren – aber Hand aufs Herz, soviel Zeit habe ich nicht. Soviel Zeit hat keiner von uns.

Wenn eine Antwort also aller Voraussicht nach sowieso nichts bringt als noch viel längere, fast körperlich qualvolle Diskussionen, dann richtet sie doch vielleicht eher noch Schaden und Verletzung an. Deshalb meine Antwort dazu nicht an ihn persönlich, sondern anonymisiert an dieser Stelle, aus der beliebten Kategorie „Mails, die meinen Postausgang letztendlich doch nicht verlassen haben“:

Hallo Herr $NAME,

ähnlich wie Sie offensichtlich die Sicherheit unserer Server in Zweifel ziehen, ziehen nicht nur ich, sondern auch meine Kollegen die sinnvolle Konfiguration Ihres Servers und auch die Stichhaltigkeit der von Ihnen genannten Punkte in Zweifel.

Ich würde mir normalerweise kein Urteil oder Kritik anmaßen und mit meiner persönlichen Meinung hinter dem Berg halten. Wenn Sie uns aber Nachhilfe darin erteilen möchten, wie „sicher“ unsere Server sind und dazu ausgerechnet eine Website heranziehen, die lediglich eine Aussage über die Anzahl möglicherweise unsicherer Website im Netz unseres Upstream-Providers trifft, dann möchte ich hiermit dann doch gerne ganz schnell einen Schlussstrich unter die Diskussion ziehen:

Selbst wenn ich einmal annehme, dass Sie im SEO-Bereich ein Experte wären (worüber ich mir kein Urteil anmaße, weil ich mich damit nicht auskenne), so zeigt doch nahezu jede Unterseite Ihrer Website grundlegende Verständnisprobleme und gravierende Fehleinschätzungen einfachster technischer Zusammenhänge auf. Dass Sie mit Ihren „Tatsachen“-Schilderungen von Kunden ausgelacht wurden, kann ich von daher – so leid es mir tut, das zu sagen – nur sehr gut nachvollziehen. Meine ganz persönliche Befürchtung ist, dass Sie keine Vorstellung davon haben, wie sehr Sie sich in ihrem eigenen „Wissen“ über angebliche Zusammenhänge verstrickt haben, und wie weit das von der Realität entfernt ist.

Insbesondere da Sie ja ohnehin keine Hosting-Leistungen von uns beziehen, dürfte eine Auseinandersetzung über Sicherheitsthemen so oder so entsprechend fruchtlos verlaufen. Ich bitte daher um Verständnis darum, dass wir diese nicht mit Ihnen zu führen bereit sind.

Freundliche Grüße,
Jonas Pasche

Wenn Sie das hier lesen sollten und sich angesprochen fühlen – dann sind möglicherweise auch Sie gemeint.

So, jetzt geht’s mir besser.

PS: Einen Kreativitätspunkt für „ein wildes herumklicken ohne die Seite durch zu lesen ist nicht gestattet“ gibt es natürlich schon noch. Auf die Idee muss man erstmal kommen..!

Undokumentierte natürliche Konstante

Montag, 12. April 2010

Aus der Mail eines Kunden über einen seiner Kunden, nachdem wir ein von ihm gemeldetes Problem bearbeitet hatten, das sich bei genauerer Betrachtung als bei weitem nicht so massiv darstellte, wie der Kundeskunde behauptete:

Das liegt wohl am $KUNDESKUNDE-Faktor, der beträgt bei Übertreibungen ca. 3, und bei Untertreibungen ca. 0,3. Ist so ähnlich wie Pi oder e eine bisher undokumentierte natürliche Konstante ;-)

Das ist fein beobachtet!

What exactly did you do?

Dienstag, 23. März 2010

Immer wieder habe ich Anlass, nach diesem Zitat zu suchen, und weil ich mir regelmäßig einen Wolf suche, packe ich es jetzt mal ins Blog. Es geht darum, wie man gute Supportanfragen stellt. Dazu kann man natürlich das informative How To Ask Questions The Smart Way bemühen. Man kann aber auch die Bernstein’sche Kurzform nehmen, die alles Wichtige auf diesen Schnipsel reduziert:

Your message should give complete answers to the following three questions:

  1. What exactly did you do?
  2. What exactly did the computer do?
  3. What exactly did you expect the computer to do?

Es ist kaum vorstellbar, wieviele Supportanfragen sich auf (um mal ein griffiges Thema exemplarisch herauszugreifen) „Ich kann keine Mails versenden – warum nicht?“ reduzieren. Schon die Frage danach, welche Fehlermeldung man denn erhält, provoziert häufig nur große Augen, wenn nicht gleich überraschende Antworten wie „die war auf Englisch, hab ich nicht verstanden“. Ebenfalls nicht ohne Grund bitten wir immer wieder darum, uns Fehlermeldungen nicht am Telefon vorzulesen, sondern uns im Originalwortlaut weiterzuleiten. Nicht selten hören wir am Telefon Dinge wie „Da steht, den Empfänger gibt’s nicht“ – die tatsächliche Meldung hingegen lautete „User over quota“, was nun eben mal etwas völlig anderes ist.

Selbstverständlich bemühen wir uns, Supportanfragen soweit wie möglich zu qualifizieren. Wir bewegen uns ja hier nicht im Bereich von Community-Support, sondern im Bereich bezahlter Unterstützung – dass wir da Kunden nicht „maßregeln“ oder „erziehen“, versteht sich schon von selbst. Aber manchmal ist das Maß der uns vor die Füße geworfenen Informationen wirklich so gering, dass wir da beim besten Willen nichts extrahieren können, was zur Beantwortung einer Anfrage vonnöten wäre. Teamintern ist dann schon mal die Rede davon, dass wir unsere Glaskugel leider schon für ihren Einsatz an Ostern bemalt haben. Nach außen hin fragen wir natürlich einfach nur freundlich nach weiteren Daten. :-)

Aber bitte: So schwer ist das mit den drei Fragen nun wirklich nicht. Und sie helfen uns enorm dabei, Supportanfragen zügig und korrekt zu beantworten, ohne uns mit langwierigen Zwischenfragen aufzuhalten oder aufgrund der allzu sparsamen Informationen in eine ganz falsche Richtung zu denken und dann auch zu antworten. Von daher: Herzlichen Dank im Voraus, wenn Sie mit dazu beitragen, damit alles zügig in Ihrem Sinne funktioniert.

Angeschossen? Abgeknallt!

Samstag, 14. November 2009

Für einen Kunden adminstrieren wir einen Server, den er sich selbst bei Anbieter S gemietet hat. S ist einer der Großen der Branche; einer von denen, die in die c’t immer bunte Prospekte einlegen lassen, also nicht gerade ein Wald-und-Wiesen-Provider.

Da der fragliche Server mit einem Software-RAID1 bereitgestellt wird, fragen wir per Nagios regelmäßig den mdadm-Status ab, um rechtzeitig bei Plattenproblemen informiert zu werden. Vor wenigen Tagen war es dann leider auch tatsächlich soweit: Das RAID1 ist degraded, eine Platte fehlt. Da wir auf die Hardware keinen Zugriff haben, vereinbarten wir mit dem Kunden, dass wir uns direkt mit S in Verbindung setzen, um die defekte Festplatte auswechseln zu lassen – im Rahmen unserer Wartungsverträge mit Kunden, die bei externen Providern hosten, ist das für uns selbstverständlich.

Der Anruf bei der Hotline von S verlief jedoch gänzlich anders als erwartet. Ich versuche es mal aus dem Gedächtnis wiederzugeben und bitte für leichte Anpassung in der Dramaturgie um Verständnis – inhaltlich hat das Telefonat wirklich so stattgefunden.

Hotline: „Anbieter S, Kundenservice, guten Tag!“

Ich so: „Guten Tag! Bei einem Server, den wir für einen Ihrer Kunden warten, ist eine Festplatte ausgefallen. Das Gerät läuft aber noch, da es ein RAID1 hat. Wie schnell können Sie denn da die Festplatte tauschen? Geht das per Hot-Swap im laufenden Betrieb, oder muss da eine kurze Downtime erfolgen?“

Er so: „Nein, die Festplatte wechseln wir nicht aus. Wir stellen Ihnen einen neuen Server bereit.“

Ich so: „Ääääh … aber es ist doch nur eine der beiden Festplatten kaputt. Der Server an sich läuft ja noch …“

Er so: „Das ist egal. Wenn es Hardwareprobleme gibt, bekommen Sie einen neuen Server.“

Ich so: „Wieso tauschen Sie denn nicht einfach die defekte Platte aus und dann ist alles wieder gut?“

Er so: „Nein, sowas machen wir grundsätzlich nicht. Sowas macht überhaupt kein Internetprovider. Höchstens ein kleines Systemhaus.“

Ich so: „Entschuldigung, aber da muss ich Ihnen widersprechen. Wir betreuen im Kundenauftrag auch noch Server bei H1, H2 und bei P, und bei allen gab es im Lauf der Jahre auch schon mal Festplattenschäden. Ich kann Ihnen versichern: Jeder dieser Anbieter [nebenbei allesamt in der Liga von S] hat anstandslos die defekte Festplatte ausgetauscht, und dann lief das RAID1 wieder.“

Er so: „Das kann ich mir nicht vorstellen. Vielleicht früher mal. Versuchen Sie das heute mal. Das wird Ihnen keiner machen.“

Ich so: „Selbst wenn Sie Recht hätten: Ist denn der Umstand, dass andere Anbieter schlechten Service bieten, für Sie Entschuldigung genug, um auch selbst schlechten Service zu bieten?“

Er so: „Ich verstehe Sie nicht. Sie bekommen doch einen ganz neuen Server. Das ist doch gut für Sie!“

Ich so: „Nehmen wir das mal so hin. Wie wäre denn dann der Ablauf; wie gehen wir strategisch am Besten vor?“

Er so: „Sie versetzen Ihren bisherigen Server in den Neuinstallationsmodus und geben uns dann Bescheid. Wir stellen Ihnen dann den neuen Server bereit.“

Ich so: „Und was ist mit den Daten des Servers?“

Er so: „Ich verstehe die Frage nicht.“ [Kein Scherz! Das hat er wirklich gesagt!]

Ich so: „Naja, wenn Sie einen neuen Server bereitstellen, dann ist der ja erstmal nur mit dem nackten Betriebssystem installiert. Wie kommen denn die Daten von dem alten Server auf den neuen? Oder kopieren Sie die gleich mit rüber?“

Er so: „Welche Daten? Wenn Sie den alten Server in den Neuinstallationsmodus versetzen, dann werden alle Daten von der Festeplatte gelöscht. Insofern sind da ja keine Daten mehr zum Übertragen auf den neuen Server.“

Ich so: „Ach so, dann stellen Sie uns den neuen Server doch einfach vorab bereit, wir kopieren die Daten rüber, und wenn alles drüben ist, können Sie den alten Server abschalten.“

Er so: „Nein, das geht nicht.“

Ich so: „Bitte? Wieso das denn nicht?“

Er so: „Der neue Server bekommt ja die gleiche IP-Adresse. Wissen Sie, es kann grundsätzlich nicht zwei Server mit der gleichen IP-Adresse geben, das geht einfach technisch nicht.“

Ich so: „Stellen Sie sich vor: Das weiß ich. Aber Sie können ihm ja einfach vorübergehend eine andere, temporäre IP geben, damit wir die Daten übertragen können, und danach wird jene IP wieder freigegeben.“

Er so: „Nein, das können wir nicht machen.“

Ich so: „Dann verraten Sie mir doch bitte mal, wie ich die Daten vom alten auf den neuen Server bekommen soll, wenn der neue Server noch nicht da ist, während der alte noch läuft, und wenn der alte dann weg ist, sobald der neue Server läuft!“

Er so: „Sie können ja den bereitgestellten Backup-Speicherplatz benutzen, der bleibt ja bestehen.“

Ich so: „Ich muss also ein paar Dutzend Gigabyte per FTP auf einen anderen Server kopieren, was Stunden dauern wird, dann muss ich Ihnen Bescheid geben, dass Sie einen neuen Server bereitstellen, was Stunden dauern wird, dann darf ich das Betriebssystem von Hand wieder zurechtfrickeln, was Stunden dauern wird, weil das System, das damals installiert wurde, heute gar nicht mehr zur Installation angeboten wird, und dann darf ich die gleichen paar Dutzend Gigabyte wiederum per FTP zurückkopieren, was nochmals Stunden dauern wird?“

Er so: „Ja, das ist das normale Vorgehen in diesem Fall. Dieses Vorgehen ist das Ergebnis unserer internen Prozessoptimierung und Qualitätssicherung.“ [sic!]

Ich so (erregt): „Haben Sie eine Vorstellung davon, wieviele Stunden an Downtime das bedeuten wird, um ein Problem zu beheben, das jeder Ihrer Konkurrenten innerhalb einer Downtime von höchstens zehn Minuten lösen könnte? Wie kann das denn bitte ein Ergebnis von Prozessoptimierung sein?“

Er so: „Beim Austausch von einzelnen defekten Festplatten gibt es einfach zuviele Probleme.“

Ich so: „Im Moment machen eher Sie mir Probleme und nicht die defekte Festplatte. Können Sie mir denn dann bitte sagen, wofür Sie überhaupt ein RAID1 in diesen Server bauen, wenn Sie dann bei dem Problem, für das ein RAID1 einen Workaround bietet, nämlich den Ausfall einer Festplatte zu kompensieren, dann gleich dem ganzen Gerät den Gnadenschuss verpassen? Dann hätten wir uns das RAID1 ja auch gleich sparen können.“

Er so: „Nein, denn dann wäre der Server sofort ausgefallen und Sie hätten unter sofortigem Handlungsdruck gestanden. So können Sie sich den Zeitpunkt frei aussuchen, wann Sie die Neueinrichtung machen wollen, also eben dann, wenn es Ihnen gelegen kommt.“

Ich so: „Das RAID1 ist nur dazu da, dass ich mir den Zeitpunkt der stundenlangen Downtime selbst aussuchen kann, wann immer es mir, ich zitiere: „gelegen“ kommt? Ist das ihr Ernst?“

Er so: „Ja, genau.“

Ich so: „Ihnen ist aber doch klar, dass das Internet 24 Stunden täglich geöffnet hat und eine mehrstündige Downtime immer ungelegen kommt? Auf dem Server läuft ein Onlinespiel, das rund um die Uhr aktiv genutzt wird!“

Er so: „Also, die meisten unserer Kunden finden es gut, einen ganz neuen Server zu bekommen.“

Ich so: „Ja und? Offensichtlich haben die meisten Kunden keine wirklich wichtigen Sachen auf den Servern bei Ihnen. Dass ein einzelner Server keine hochverfügbare Lösung ist, ist natürlich klar, aber wir haben uns absichtlich einen Server mit RAID1 ausgesucht, um der wahrscheinlichsten Ausfallursache eines Servers, nämlich einer defekten Festplatte, entgegentreten zu können. Und nun machen Sie dies völlig zunichte, in dem Sie ohne Not eine stundenlange Downtime provozieren, die für uns mit jeder Menge Arbeit verbunden ist, nicht zuletzt für den darauf folgenden zu erwartenden Support. Gibt es da wirklich keine andere Möglichkeit?“

Er so: „Nein, die gibt es nicht.“

Es hat unsererseits gar keiner Empfehlung für diesen Schritt bedurft – unser Kunde kündigt den bei S betriebenen Server  von sich aus. Und für uns bleibt es unterm Strich ein lehrreiches Beispiel dafür, wie wir uns von Providern abgrenzen, für die „Prozessoptimierung“ wichtiger ist, als die für den Kunden optimale Lösung zu finden – und dafür dann eben auch mal einen Finger mehr krummzumachen. In diesem Sinne sind wir stolz darauf, in den Augen von S „höchstens ein kleines Systemhaus“ zu sein.

Einfach mal umgebaut

Montag, 07. September 2009

Es ist sicherlich nicht die feine Art, über Mitbewerber zu lästern, und es soll auch eine Ausnahme bleiben. Aber was einem unserer Kunden vor wenigen Tagen bei einem anderen Hoster – nennen wir ihn „N“ – passiert ist, ließ mir wirklich die Kinnlade herunterfallen.

Wir haben kein Problem damit, wenn Kunden von uns Server bei anderen Anbietern betreiben und dann nur den Support von uns beziehen. Sicherlich ist das nicht optimal, wenn wir bei echten Problemen keine Möglichkeit haben, z.B. Hardware zu reparieren und auch sonst auf die Debugging-Möglichkeiten des anderen Anbieters angewiesen sind, wenn der Kunde Hilfe braucht, aber wir kommunzieren im Vorhinein klar, was geht und was nicht, so dass es hier eigentlich nie zu Irritationen kommt.

Der Server, den unser Kunde neben einigen anderen bei N hat, machte Probleme. Die genaue Vorgeschichte kennen wir nicht; aus telefonischen Schilderungen konnten wir Unspezifisches entnehmen wie „das Gerät reagiert nur langsam“ (obwohl der Load bei 0 liegt), „Pings gehen mal durch und mal nicht“ … kurz, Symptome, die vieles bedeuten können.

Den Logfiles konnten wir entnehmen, dass der fragliche Server in den letzten Tagen etwa 40 Mal rebootet worden ist – au weia. Wenn ein Reboot ein Problem nicht löst, tut’s ein zweiter in der Regel auch nicht. Aber sei’s drum.

Wir wurden zu Hilfe gerufen, als die Situation die war, dass N dem Kunden mitteilte, den Server rebootet zu haben, der Kunde den Server aber dennoch nicht erreichen konnte. N hat für diese Fälle ein einfaches Schema: Der Server wird in den Rescue-Modus versetzt und dem Kunden das Rescue-Passwort mitgeteilt, damit er sich die Sache selber ansehen kann.

Ich will anmerken, dass ich diese Vorgehensweise – gelinde gesagt – bereits eine Unverschämtheit finde. Der Server ist nämlich ein Mietgerät, das mit von N vorinstallierter Software ausgeliefert wird und ein Webinterface mit sich bringt. Der Kunde hat zu keinem Zeitpunkt am Kernel, an den Netzwerkeinstellungen oder an sonst irgendetwas herumgebastelt, sondern einfach nur Websites über das bereitgestellte Webinterface eingerichtet. Wenn so grundlegende Funktionalität wie die schlichte Erreichbarkeit übers Netzwerk fehlt, ist das aus meiner Sicht daher immer Sache des Anbieters, dies vertragsgemäß bereitzustellen. (Anders sieht der Fall natürlich aus, wenn der Kunde selber ein Betriebssystem installiert oder am bereitgestellten System herumbastelt, zum Beispiel einen anderen Kernel installiert, der nicht funktioniert. Anbieter, die eine solche Freiheit ermöglichen, bieten dann aber typischerweise dafür auch eine Rescue-Konsole. Bei N heißt „Rescue-Modus“, dass man anrufen muss und ein Techniker eine CD einlegt. Von daher muss man auch nochmal anrufen, wenn die CD wieder entfernt werden muss, damit das Gerät normal booten kann. An Rescue außerhalb der Geschäftszeiten ist von daher nicht zu denken.)

Wir hatten nun also Zugang zum Rescue-System des Servers, der nicht mehr per Netzwerk erreichbar war. Die letzte Auskunft des Supports von N lautete: Wir hatten Tastatur und Monitor angeschlossen und konnten verifizieren, dass der Server hochgefahren ist und nun am Login-Prompt steht. Als der Kunde daraufhin anmerkte, dass der Server aber nicht mal per Ping erreichbar wäre, folgte kurzerhand der Rescue-Modus, „damit Sie das wieder in Ordnung bringen können“.

Mein Kollege Matthias brachte mich auf den entscheidenden Punkt: Ich solle mir doch mal die Ausgabe von lspci anschauen; da würde was von einer Intel-Netzwerkkarte stehen. Er meine, sich erinnern zu können, dass da eine RealTek-Karte drin gewesen sei.

Einige Checks in den dmesg-Logfiles später war klar:

Erstens, N hat die Netzwerkkarte ausgetauscht.

Zweitens, N hat dem Kunden aber nicht gesagt, dass sie die Netzwerkkarte ausgetauscht haben.

Drittens, in dem – von N! – installierten Kernel ist überhaupt kein Treiber für die neue Netzwerkkarte vorhanden. Das Gerät kann also überhaupt nicht übers Netzwerk erreichbar sein.

N hat folglich überhaupt nicht geprüft, ob die neue Netzwerkkarte funktioniert. Sie haben es nicht mal geprüft als der Kunde sich explizit darüber beschwerte, dass der Server nicht per Netzwerk erreichbar ist. Stattdessen hat man einfach den Rescue-Modus aktiviert und dem Kunden die Fehlersuche überlassen – wie gesagt, ohne ihm mitzuteilen, dass da jetzt eine ganz andere Netzwerkkarte drinsteckt.

Letztlich konnten wir an dem Problem nicht viel machen, denn der installierte Kernel ist, vorsichtig gesagt, antik. Kurz, für aktuelle Intel-Netzwerkkarten ist da mit einem Treiber nicht viel zu wollen. Unser Support für den Kunden beschränkte sich also eher darauf, ihn darin zu unterstützen, dass N das Problem korrekt löst – und sich vielleicht dann doch auch bitte mal zum Thema „stillschweigend getauschte Netzwerkkarte“ äußern möge.

Das hat N dann schließlich auch getan: Die einzige Möglichkeit sei, einen neuen Kernel zu kompilieren oder die Daten zu sichern und den Server neu aufzusetzen. Offensichtlich war es N aber zu mühselig, einen neuen Kernel zu kompilieren, denn die finale Aufforderung lautete schließlich:

Daher bitten wir Sie, die wichtigen Daten zu sichern, sodass wir den Server neu aufsetzen können. Dies können Sie im Rescuemodus mit dem Programm „WinSCP“ machen, welches so ähnlich funktioniert wie ein ftp-Programm.

Verständlicherweise ist dem Kunden da dann ziemlich der Kragen geplatzt. Immerhin ist bei einem Mietserver die korrekte Funktion der Hardware strikt die Sache des Anbieters, und genauso auch das korrekte Zusammenspiel mit dem ausgelieferten System – sprich, wird die Hardware durch den Anbieter (zumal ohne Rücksprache) verändert, sehe ich es auch als Sache des Anbieters, das installierte Betriebssystem entsprechend anzupassen.

Unnötig zu sagen, dass „die wichtigsten Daten sichern“ nicht einfach ein scp-Befehl gewesen wäre. Immerhin geht es um unterschiedliche Systemuser, deren Daten, Konfigurationsdateien, und schließlich auch noch die Daten der Konfiguration der Web-Administration, von der niemand genau weiß, wo sie liegen und wie man sie so sichern kann, dass man sie woanders wieder einspielen kann. Aber offensichtlich meint N, das manuelle Anlegen von, sagen wir mal, 100 Websites und 1000 E-Mail-Adressen und anschließendes Wiedereinspielen von Backups sei keine Arbeit, das kannman ja mal in der Kaffeepause erledigen.

Nachdem wir den Kunden mit entsprechender Argumentation ausgestattet hatten, war es eine Sache von einer Stunde, bis der Anbieter eine Netzwerkkarte eingebaut hatte, die vom bestehenden Kernel unterstützt wird. Das Gerät läuft seitdem wieder ohne Schwierigkeiten.

Wie bitte?

Donnerstag, 03. April 2008

Aus dem Support:

guten mrgen willi,meine telefonie ist gestern vollkommen abgestürzt,jetzt
wird die vollkommen neu aufgebaut und wenn die fertig ist,komme ich wieder
rein,würdest du bitte mal von der technik den weg zu mir überprüfen
lassen,denn das relais schliesst nicht wenn ich telefoniert habe ,wählt
während des telefonats irgendwo nochmal jemand und der von der telekom meint
das kommt von wo anders und das betrifft auch nur die leitung mit der ich
über den chat telef.aber das habe ich nicht gesagt,die anderen leitungen
sind in ordnung

Hat jemand eine Idee, was der oder die Fragende will? Irgendjemand? Hallo..?

Denial-of-Service mit Gästebuch

Samstag, 29. März 2008

Auf dem Server eines Kunden gab es seit längerem höchst merkwürdige Phänomene: Obwohl die Maschine an sich nur minimal ausgelastet war, hat sie – mit steigender Frequenz – plötzlich Lastspitzen, die die Maschine geradezu unbenutzbar werden ließen. Schnell war ein extrem hoher iowait-Wert identifiziert. Mittels iostat war auch schnell festgestellt, dass der iowait nicht auf eine defekte Festplatte o.ä. zurückzuführen war, sondern zu den Zeiten der Lastspitzen wirklich astronomisch viele Daten auf die Platte geschrieben wurden.

Nun gibt es unter Linux ja einen ganzen Haufen Tools, mit denen man Systemressourcen wie CPU-Zeit oder RAM-Nutzung einschränken oder wenigstens protokollieren lassen kann (Stichworte psacct). Wieviel HDD-Last eine Anwendung erzeugt, kann hingegen meines Wissens nach nicht ausgewertet werden. Sowas könnte ja auch ganz andere Gründe haben, z.B. wenn eine Anwendung unkontrolliert soviel RAM verbraucht, dass die Maschine in den Swap geht. Soll heißen: Die Diagnose eines solchen Problems ist zu einem gewissen Grad einfach Glückssache.

Einigermaßen schnell war geklärt, dass das Problem „irgendwie mit dem Webserver zusammenhängen“ müsse, denn immer, wenn der gestoppt war (was angesichts der Art von Sites und dem mit jenen verbundenen Servicelevel durchaus für einige Minuten tolerierbar war), trat das Problem nicht mehr auf.

Mit Hilfe des server-status-Handlers des Apache schrieb ich einen kleinen Job, der alle paar Sekunden die derzeit abgearbeiteten HTTP-Aufrufe protokollierte. Ziel war, dieses Logfile mit dem Logfile der Lastspitzen abzugleichen, um mit etwas Glück einen Zusammenhang zu einer aufgerufenen Site oder gar einer bestimmten URL herzustellen, um zumindest mal einen Anfang für eine konkretere Analyse zu finden.

Ich gebe gerne zu: Den Aufruf einer Gästebuch-URL habe ich beim Durchsehen des Logfiles unterschwellig ausgeblendet. Ein Gästebuch kann’s ja nun irgendwie nicht sein.

War es aber doch.

Das Gästebuchscript, das sich einer der Kunden installiert (oder vermutlich sogar selbst geschrieben) hatte, speicherte alle Einträge in einer Textdatei, aus der dann schließlich statische HTML-Seiten generiert wurden, durch die man seitenweise blättern konnte. Pferdefuß Nummer 1: Immer wenn vorne ein neuer Eintrag dazu kam, musste hinten der letzte der entsprechenden Seite auf die jeweils folgende Seite rutschen. Das heißt konkret, dass alle HTML-Seiten neu geschrieben werden müssen. Das Problem konkretisiert sich langsam vor dem inneren Auge.

Bisher erschien lediglich die Programmierung ein wenig, ähem, ineffizient. Aber der endgültige Kollaps wurde von der Datenmenge selbst verursacht: Das Gästebuch fasste inzwischen über 16.000 Einträge. Bei 10 Einträgen pro HTML-Seite ergibt das 1600 HTML-Dateien, die im Falle eines neuen Eintrags neu geschrieben werden müssen. Und wenn das noch nicht spannend genug klingt: Die 10 Einträge ergeben mit HTML-Overhead immerhin rund 30 KB. Nun kommen aber, noch ein Pferdefuß, auf jede Seite Links zu den anderen Seiten. Nicht zur davor- und dahinterliegenden, sondern zu allen 1599 anderen Seiten. Mit HTML-Overhead werden daraus rund 120 KB nur für die Links – also rund 150 KB pro HTML-Seite. Multipliziert mit 1600 ergibt das ein Datenvolumen von rund 250 MB, und immer, wenn jemand einen Eintrag hinzufügt, werden diese 250 MB – um einen Eintrag erweitert – auf die Festplatte geknallt.

Das Problem sind nicht die Besucher der Website. Das Problem sind die Spammer. Die bespammen das Gästebuch nämlich durchschnittlich rund 200 Mal pro Tag, mit steigender Tendenz. Das ergibt rund 50 GB Schreibzugriffe pro Tag. Und wir wundern uns über Peaks …

Übrigens: Klickt man auf der betreffenden Website den Link „Gästebuch“ an, kommt man auf eine hübsche Seite, die verkündet: „Das Gästebuch wurde wegen zuviel Spam abgeschaltet“ – die Spammer kannten aber auch ohne Verlinkung von der Website selbst immer noch den ursprünglichen Link, denn vorhanden war das Script nun mal immer noch. Ein besseres Beispiel für den Begriff „Altlast“ habe ich bisher nicht finden können.

Und nochmal übrigens: Solche Analysen gehören bei uns zum üblichen Support, solange sie sich noch „irgendwie im Rahmen“ halten. Der Kunde hat von uns keine Rechnung dafür bekommen.

SCRIPT_NAME unter PHP+FastCGI

Mittwoch, 26. März 2008

Auf mehreren Kundenservern setzen wir aus Sicherheitsgründen PHP unter FastCGI in Kombination mit suEXEC ein, in Anlehnung an diese Doku. Das läuft auch weitestgehend unproblematisch, allerdings stehen SCRIPT_NAME und SCRIPT_FILENAME in diesem Fall nicht auf dem Namen des PHP-Scripts, sondern auf dem des PHP-Interpreters, was einige PHP-Scripts etwas durcheinanderbringt.

Für diejenigen, die das für Bug #19656 halten: Nö. Viel simpler ist es mit dem Aktivieren von cgi.fix_pathinfo in der php.ini gemacht.

vorher:

_SERVER["SCRIPT_FILENAME"] = /var/www/virtual/site174/fcgi-bin/php4-fcgi-starter
_SERVER["SCRIPT_NAME"] = /fcgi-bin/php4-fcgi-starter

nachher:

_SERVER["SCRIPT_FILENAME"] = /var/www/virtual/site174/html/shop/info.php
_SERVER["SCRIPT_NAME"] = /shop/info.php

simscan mit ClamAV > 0.90

Dienstag, 25. März 2008

Das für den Einsatz mit qmail entwickelte Scannerpaket simscan, das diverse Scan-Enginges (darunter SpamAssassin und ClamAV) einbinden kann, hat eine Komponente namens simscanmk, die unter anderem die Versionsstände der eingesetzten Tools zusammenstellt. Diese liegen dann vorgefertigt in einer .cdb-Datei, damit simscan diese Daten simpel in einen Mailheader packen kann, ohne die Infos jedes Mal aufwendig zusammenstellen zu müssen. Seit einiger Zeit meldet ein entsprechender Cronjob aber:

# /etc/cron.daily/simscanmk:
LibClamAV Error: cl_cvdhead: Can't open file /var/clamav/daily.cvd

Hintergrund ist, dass ClamAV in neueren Versionen keine daily.cvd mehr führt, sondern inkrementelle Updates im Verzeichnis daily.inc ablegt. Davon weiß simscan allerdings nichts und findet folglich die Versionsinfo nicht mehr. Das ist eher kosmetisch, weil es deshalb trotzdem immer noch korrekt scannen kann, aber kosmetisch ist das natürlich inakzeptabel.

Bis das in der Distribution gefixt ist, kann man sich mit diesem Patch von John M. Simpson behelfen, der nebenbei für den irrsinnig praktischen validrcptto.cdb-Patch verantwortlich zeichnet. Dankeschön!

Warum kann ich keinen CNAME für eine ganze Domain definieren?

Dienstag, 25. März 2008

Gerade bei selfHOST immer mal wieder eine gern gehörte Frage. Mein liebste Antwort ist die von Dan J. Bernstein:

Remember the wise words of Inigo Montoya: „You keep using CNAME records. I do not think they mean what you think they mean.“ (Quelle)

Leider reagieren die meisten Leute etwas … ähem, verärgert, wenn man sich in seiner Antwort auf dieses Zitat beschränkt. :-)

Nun gibt es eine ganze Reihe von Gründen, warum man CNAMEs am Besten gar nicht einsetzen sollte (zum Beispiel, dass sie weder von NS- noch von MX-Records referenziert werden dürfen, was aber allzu leicht passiert). Was bei selfHOST relativ häufig vorkommt, ist: Ein Kunde hat komplexe DNS-Einstellungen auf domain1.tld und möchte nun, dass unter domain2.tld das komplette Set an DNS-Einträgen genauso abgebildet wird. Er möchte von daher per CNAME sagen: domain2.tld soll einfach alle Einträge von domain1.tld erben. (Böse Zungen behaupten, dass dahinter vor allem der Wunsch steht, den DynDNS-Account einer Domain einfach noch auf einer zweiten mitbenutzen zu können, ohne dafür auch einen zweiten DynDNS-Account zu bezahlen.) Hier nun also der offizielle FAQ-Eintrag:

Frage: Warum kann ich keinen CNAME für eine ganze Domain definieren?

Antwort: Weil es gegen RFC 1912 verstößt. Hier steht’s:

2.4 CNAME recordsA CNAME record is not allowed to coexist with any other data.  In
other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
can't also have an MX record for suzy.podunk.edu, or an A record, or
even a TXT record.  Especially do not try to combine CNAMEs and NS
records like this!:

podunk.xx.      IN      NS      ns1
IN      NS      ns2
IN      CNAME   mary
mary            IN      A       1.2.3.4

This is often attempted by inexperienced administrators as an obvious
way to allow your domain name to also be a host.  However, DNS
servers like BIND will see the CNAME and refuse to add any other
resources for that name.  Since no other records are allowed to
coexist with a CNAME, the NS entries are ignored.  Therefore all the
hosts in the podunk.xx domain are ignored as well!

So!


Impressum