zurück zum Artikel

Ihre neuen, wahrhaftig-unglaublichen Andekdoten aus dem Admin-Alltag

Admin-Horrorladen, Teil 2

Wissen | Reportage

Der erste Geburtstag von heise Netze und der Kundenzuspruch im ersten Admin-Horrorladen sind Anlässe genug, sein Angebot um weitere originelle oder abstruse Begebenheiten aus der Welt der Netzwerkexperten zu erweitern.

Hand hält aufgespleißtes Elektrokabel

Im Juli öffnete [1] der Admin-Horrorladen erstmals seine Pforten und das Echo war überwältigend. Nicht nur Lob und Kritik zu den veröffentlichten Geschichten erreichte uns, sondern auch eine ganze Reihe neuer Horrorgeschichten. Den ersten Geburtstag von heise Netze nehmen wir zum Anlass, Ihnen originellsten und abstrusesten Begebenheiten aus der Welt der Netzwerkexperten zurückzuschenken.

From: 1a@bc.de

Eines Tages bekomme ich für eine äußerst großzügig bemessene Mailbox eine Warnung, dass diese fast voll ist. Verwundert schaue ich mir den Inhalt der Mailbox an und erkenne, dass schlagartig ein Zustrom von tausenden E-Mails eingesetzt hat, die alle an einen mittelgroßen Industriekonzern gerichtet sind.

Ich rufe bei dem Konzern an, werde aber nicht ernstgenommen.

Also mache ich mich daran, die E-Mails zu filtern. Und tatsächlich finde ich eine Telefonliste, gerichtet an den Systemadministrator: Allerdings handelt es sich nicht um ein Telefonverzeichnis der Firma, für die die E-Mails bestimmt sind, sondern um eine Nummernliste der Bergrettung. Da der Administrator zugleich Mitglied der Bergrettung ist, komme ich auf diesem Weg an seine private Handy-Nummer.

Mein Anruf klingelt ihn aus einer Tagung im Ausland, er ist kurz ungläubig, lässt sich aber durch ein paar Firmeninterna schnell überzeugen, und es fällt beim sofort der Groschen: Ein Mitarbeiter hat ihn gefragt, wie er eine Weiterleitung für E-Mails einrichten kann. Bei der Anleitung hat der Administrator aber auf meine Adresse verwiesen, statt – wie in RFC 2606 [2] empfohlen – eine Adresse wie " test@example.com" zu verwenden. Zugegebenermaßen bietet sich meine Domain gut an für solche Beispiele. Dass der Mitarbeiter die vom Administrator genannte Beispiel-Adresse eins zu eins übernommen hat, erklärt auch, warum gleich den gesamte Mail-Verkehr und nicht nur der an eine einzelne Adresse zu mir weitergeleitet wurde.

Risiken und Nebenwirkungen: Um die Identität des einreichenden Admin zu schützen und um sein Postfach vor erneuter Flutung zu bewahren, haben wir seine E-Mail-Adresse geändert. Doch ähnelt 1a@bc.de derjenigen Adresse, mit der diese Geschichte tatsächlich passiert ist. Schreiben Sie dennoch bitte nicht an 1a@bc.de [3], ein Tippfehler, und die Geschichte geht irgendwo von vorne los …

Es war einmal, vor gar nicht allzu langer Zeit, eine Firma, die in einem Altbau residierte (dieses Detail ist nachher noch von Bedeutung). Diese Firma beschaffte "mal eben" rund 2000 neue Rechner, die unter anderem per Wake-on-LAN (WOL [4]) startfähig sein sollten. Bis hierhin keine Katastrophe in Sicht.

Als die Rechner endlich alle standen, wollte der Admin auch mal sehen, bei welchen Rechnern es mit dem WOL womöglich klemmt. Also ein Script getippt, das alle Rechner einschaltet, anpingt und bei Erfolg dann ausschaltet. Der Test mit rund 10 Rechnern ging 1a und überraschend fix (auch das "fix" ist nachher noch wichtig …)

Am nächsten Morgen beginnt das Grauen: Da war der Admin schon schätzungsweise gegen 05.00 Uhr, auf jeden Fall so früh, dass es draußen noch dunkel und das Gebäude leer war, an seinem Rechner, um oben genanntes Script zu starten. Was nun folgte, war in Echtzeit in etwa folgendes:

Script-Start, Stromausfall im ganzen Haus!!!

Was war passiert?

Das Script hat es geschafft, die Magic-Packets so schnell 'rauszuhauen – schon der Test am Vortag ging ja recht fix –, dass die Rechner nahezu gleichzeitig eingeschaltet wurden: Also wollten 2000 CPUs, 2000 (Röhren-)Monitore, 2000 Festplatten, 2000 Boards alle gleichzeitig Saft haben, woraufhin nahezu sämtliche Sicherungen inklusive die Hausverteilung kollektiv in Streik getreten sind – was bei einem Altbau mit alter Elektrik nicht wirklich verwunderlich ist.

Als ich noch als Azubi im Außendienst gearbeitet habe, war ich die personifizierte Ursache für Stromausfälle – jedenfalls sahen das einige Kunden so.

Einmal kam ich in ein Büro und sollte den PC warten. Also kroch ich unter den Tisch, wo der PC stand. Dabei stieß ich – mitten im Sommer – an einen wirklich antik aussehenden Heizlüfter. Dieser sprang plötzlich an und brannte postwendend durch, was zu einem Stromausfall im Büro führte. Die Personen im Büro hatten mich natürlich nur unter dem Tisch verschwinden sehen, dann gab es einen Knall, eine Rauchwolke und dann war alles aus. Klar, dass ich Schuld seinen musste. Als ich den Heizlüfter hervorzog, konnte sich niemand an diesen erinnern. Der musste dort schon seit Jahr und Tag eingeschaltet herumgestanden und irgendwann seinen Dienst eingestellt haben, bevor er durch mich noch einmal für kurze Zeit ins Leben zurückgerufen wurde.

Bei einem anderen Kunden stand ich mit einem fröhlichen "Guten Morgen" in der Bürotür und stellte meinen Service-Koffer neben mir auf den Boden. Genau auf einen Schalter, welcher alle Macs im Raum ausschaltete. Es gab also kein "Guten Morgen" zurück, sondern nur böse Blicke. Ich traute mich dann nicht mehr zu fragen, warum auf dem Fußboden, direkt neben der Tür ein Aufputzschalter geschraubt war. Später habe ich mir zusammengereimt, dass das Büro in einem denkmalgeschützten Gebäude war. Die Verkabelung war unter dem eingezogenen Holzfußboden verlegt und aus versicherungstechnischen Gründen (Brandgefahr) mussten wohl alle Geräte nach Feierabend zentral ausgeschaltet werden.

Ein paar Wochen später, beim gleichen Kunden, sollte der Server aufgerüstet werden. Ich wurde in den Raum mit dem 19-Zoll-Schrank geführt. Die gute Frau, die mich dorthin begleitet hatte, drehte sich um, ich öffnete den Schrank und – zack – war der Strom weg und zwar im ganzen Haus. Alle kamen angelaufen, weil sie wussten, dass ich im Haus war. Es dauerte eine Weile, bis wir herausfanden, dass die ganze Straße ohne Strom war. Einige blicken mich immer noch böse an, weil sie wohl tatsächlich glaubten, dass ich die ganze Straße lahmgelegt hätte. Tatsächlich hatte irgendwo ein Bagger eine Leitung gekappt.

Wir nahmen gerade neue Server in Betrieb. Bei einem Gerät zeigte die integrierte Diagnose-Software einen Fehler im RAM an. Kein Problem angesichts der dreijährigen Vor-Ort-Garantie: die zuständige Serviceorganisation wurde aufgeboten.

Techniker da, Diagnose nochmals gestartet, Fehler immer noch da, das RAM wurde getauscht. Als Abschlusstest wurde die Diagnose nochmals laufen gelassen und siehe da, der Fehler war immer noch da.

Der Techniker kam ins Grübeln . Schließlich entschloss er sich, dass es an den Prozessoren liegen müsse. Diese wurden bestellt, und am nächsten Tag stand er wieder auf der Matte. Prozessoren getauscht, Diagnose gestartet, und: Fehler immer noch vorhanden.

Klar, dann liegt es wohl am Mainboard: Mainboard bestellt, am nächsten Tag war der Techniker wieder da und tauschte auch dieses Teil unter großem Aufwand. Alles zusammengebaut, Diagnose gestartet – und: Fehler immer noch vorhanden.

Der Techniker kam wiederum ins Grübeln, telefonierte mit Irland, schaute in seinem Notebook nach – und was fand er dort, in der herstellerinternen, nicht öffentlichen technischen Datenbank? Die Diagnosesoftware selbst hatte in der angewandten Version einen Fehler, der für die Reihe von Fehldiagnosen verantwortlich war. Nachdem das Patch für das Diagnosetool eingespielt war, war auch beim betroffenen Rechner alles wieder paletti …

Eines schönen Tages mußte ich als geübter Linux-Engineer während der Bereitschaft unserem Alpha Oracle Cluster helfen. Um einen Prozess zu beenden, habe ich dann killall <prozessnamen> eingegeben.

Nun ja … killall tut unter Tru64 nichts anderes, als alle Prozesse zu beenden – einen Parameter kennt das Kommando leider nicht ;-)

Lessons Learned: Rufe [i]immer die man page auf, wenn du das System nicht kennst.[/i]

Während meiner Ausbildungszeit (1997 – 2000) haben wir bei vielen unserer Kunden GroupWare und damit verbundene Virenscanner eingeführt. Viele dieser Systeme liefen bei den Kunden auf Novell Netware mit GroupWise. Damit verbunden hatten die Kunden selbstverständlich auch den Novell Client installiert. Eines Tages (irgendwann im Sommer) rief ein Kunde völlig aufgelöst an: "Jetzt haben wir eine ganze Stange Geld ausgegeben und bekommen trotzdem Viren auf unsere Computer!!! Hier steht irgendwas von Novell: Auf ihrem PC ist ein Virus aufgetreten. Bitte drücken Sie Strg + Alt + Entf. Wenn ich das mache, geht der PC aus!"

Ok, den zweiten Teil konnte ich dem Kunden sehr schnell erklären, weil man unter Windows 98 mittels Strg + Alt + Entf. den PC neu starten konnte. Aber der erste Teil wunderte mich doch sehr. Ich bat den Kunden einen Ausdruck von der Meldung zu machen, die sich nach jedem Neustart wiederholte. Als ich in meinen Faxeingang schaute, wurde einiges klar. Der Kollege gegenüber dem Anrufer hatte die Funktion "Nachricht versenden" im Novell Client entdeckt.

Moral: Bei solchen Nachbarn braucht man keine Feinde mehr.

Bei uns wurde eine neue LAN-Verkabelung verlegt, welche dann wie allgemein üblich im Technikraum auf einem Patchpanel aufgelegt werden sollte. Ein Kollege des Netzwerkteams wollte sich zwischendurch über den Fortschritt der Arbeit des Elektrikers erkundigen und kam laut lachend aus dem Technikraum zurück.

Was war passiert???

Der Elektriker hat die Inhouse-Verkabelung nicht auf das Patchpanel aufgelegt, sondern jedes Kabel mit einem RJ45-Stecker versehen, gecrimpt und von vorne in das Patchfeld gesteckt. Patchen wäre demnach möglich gewesen, aber verdammt zeitaufwendig. (Diese Vorstellung hat doch ihren Reiz, oder? "Ich geh dann mal patchen – gibst du mir mal das LSA-Auflegewerkzeug?") Leider besitze ich von der Installation kein Foto mehr …

Es stellt sich raus, der Kollege wollte sich die Arbeit mit Subversion etwas erleichtern, also hat er sich ein script gebestelt, das er "svn" genannt hat, und das so abgelegt war, dass für ihn dieses Script im Pfad vor dem eigentlichen svn lag. Und das Script sah ungefähr so aus:

#!/bin/bash svn <irgendwelche parameter> $* 

 …ok, in den meisten Fällen ist die Stromzufuhr unterbrochen, gelockert, die Putzfrau oder sonstiges daran Schuld. Also habe ich vor den Augen der Anwenderin den Kaltgerätestecker aus dem Bildschirm gezogen, drei Mal daraufgepustet und dann wieder in den Bildschirmanschluss eingesteckt: Natürlich lief der Bildschirm dann wieder, es war ja nur der Stecker losgerappelt. Ungefähr ein Jahr später kam unser Elektriker zu uns und rollte sich ab, während er erzählte: "Da gibt es doch ein paar User, die ziehen den Kaltgerätestecker und pusten darauf, auf dass der Bildschirm wieder funktioniert."

Moral 1: Sofortmaßnahmen müssen nicht schlüssig nachvollziehbar sein, je mysteriöser sie sind, desto dankbarer werden sie angenommen.

Moral 2: Ihre Verbreitung als Geheimtipp ist sicher.

Moral 3: Sie machen noch nach etlichen Monaten Spaß.


URL dieses Artikels:
http://www.heise.de/-221766

Links in diesem Artikel:
[1] https://www.heise.de/ct/artikel/Admin-Horrorladen-Ihre-Geschichten-221744.html
[2] http://www.heise.de/netze/rfc/rfcs/rfc2606.shtml
[3] donotmailto:1a@bc.de
[4] https://www.heise.de/ct/artikel/Wake-on-WAN-221718.html