Gesammeltes von A bis XYZ

Mein Bildschirm ist kaputt, der geht nicht mehr …

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

Subversiver Kollege

• Ein Linux-Entwicklungsserver mit diversen Toolchains.
• Ein schöner Donnerstagnachmittag.
• Eine panische Meldung: Der Server spinnt, ich kann nichts mehr machen, alles geht in Zeitlupe.
• Ein kritischer Blick auf die Kiste: Load über 50.
• Ein kritischer Blick auf die Prozessliste: Tausende von Bash-Instanzen.

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    $* 

Elektro-Installation

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 …

Wozu sich Feinde machen, wenn es Kollegen gibt?

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.

Ein Blick ins Manual erspart viel Gezeter

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

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

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

Fehldiagnostik

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 …

Power-Down-Boy

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.

Kein Danke für diesen "Guten Morgen"

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.

WOL ist gefährlich

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

Admin ruft Bergrettung – und die hilft prompt

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 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, ein Tippfehler, und die Geschichte geht irgendwo von vorne los …

Jeder heißt jeder

In unserer Behörde muss die Finanzsoftware um zwei Orcale-Versionen upgedated werden. Die gesamte sehr komplexe Installation besteht aus einer Mischung von programmspezifischen Teilen unter Windows, einer Progress-Schnittstelle und SQL-Scripten unter Oracle.

Die Einführung des Systems obliegt einer externen Supporterin (im Nachfolgenden Sup(port)ertante genannt), die für die Einführung sogar zwei Jahre fest eingestellt ist.

Das Allerwichtigste bei diesen Updates – und explizite Vorschrift des Herstellers – ist, dass auf keinen Fall irgendein User während des Updates auf Programm und/oder Datenbank eingeloggt ist. Deshalb wird die Supertante aktiv. Sie weist alle User am Tag X an, sich vom System fernzuhalten und sperrt allen anderen den Zugriff.

Also legen die Admins los, die sowieso schon wegen der Komplexität schwitzen, da sie die SQL-Skripte für die Oracle vor dem eigentlichen Programm-Update von Hand eingeben und die Commits prüfen müssen. Sie werkeln zu dritt. Alles läuft wie am Schnürchen, bis zum Programm-Update – kryptische Fehlermeldung.

Also noch mal von vorn, da haben wir wohl Mist gebaut. Vorher verständige ich noch die Supertante, dass es wohl doch länger dauert. Supertante: "Mmmh, jaaa …"

Also legen die Admins los, die sowieso schon wegen der Komplexität schwitzen, da sie die SQL-Skripte für die Oracle vor dem eigentlichen Programm-Update von Hand eingeben und die Commits prüfen müssen. Sie werkeln zu dritt. Alles läuft wie am Schnürchen, bis zum Programm-Update – kryptische Fehlermeldung. Immerhin ist es dieselbe wie beim vorigen Mal.

Das gibts doch nicht. Also rufen wir den Softwarehersteller an, schalten einen Hotliner auf und scannen mit ihm die Logs. Auch er kann sich den Fehler oder die Ursache nicht erklären und empfiehlt, es noch mal zu versuchen.

Auf dem Flur trippeln 60 User, die auf die Freigabe des Finanzsystems warten.

Vor dem nächsten Versuch verständige ich noch die Supertante, dass es wohl länger dauert. Supertante: "Soso, Die Aufgabe ist wohl zu komplex für euch Admins."

Also legen die Admins los, die sowieso  …

Moment – da stellt dann doch einer die Frage: "Könnte der Abbruch nicht daher kommen, dass nun doch noch einer aufgeschaltet ist?"

"Nee nee, die Supertante hat doch alle ausgesperrt, oder nicht?"

Ein Blick in "Domänen-Verwaltung–> Freigaben–> Dateizugriffe: "Heh, rat mal, wer da voll im Programm drin ist!"

Der IT-Leiter greift mühsam beherrscht zum Telefon, um die Supertante anzurufen. *säusel*: "Könnte es sein, dass Sie im Programm und auf die Datenbank aufgeschaltet sind?"

Supertante entrüstet: "Aber ja, ich will doch schließlich wissen, was Sie da treiben!"

Moral: Vertrauen ist gut, Kontrolle muss nicht immer besser sein.

Oh, Scheiße!

Ein hippes junges Unternehmen in den 90ern residierte in einem Glasfassaden-Gebäude im Dachgeschoss. Man hatte einen herrlichen Ausblick auf Frankfurt, auf die A5 (so wussten manche Mitarbeiter schon vor dem Losfahren, wie lange sie im Stau stehen würden). Es gab auch eine mehr oder weniger geduldete Dachterrasse. Alles in allem recht annehmlich. Ein signifikanter Nachteil der Location trat immer wieder in Sommer zu Tage. Die Räumlichkeiten heizten sich brachial auf.

Der Server-Raum war eine entkernte Küche, aber leider ohne Klima-Anlage. Es kam, wie es kommen musste: Die Temperatur stieg in der Server-Küche auf weit über 40 Grad. Die ersten Warnmeldungen der Server liefen ein. Die Anschaffung der Klimaanlage (Chef-Büro und Server-Raum) wurde beschlossen. Dummerweise hat so ein Gerät im Hochsommer einige Tage mehr an Lieferzeit.

Die Server jammerten immer lauter. Die Türen zu den Büros zu öffnen, war wegen der Lärmbelastung nicht möglich. Da es draußen trotz der sommerlichen Temperaturen deutlich kühler war, schien es, als könne man mit offenen Fenstern am Tage und offenen Türen in der Nacht die Zeit bis zur Lieferung der Klimaanlage überbrücken.

Ein weiterer heißer Tag lief an, Kaffee diente mittlerweile schon als Kaltgetränk. Ich lief an der Server-Küche vorbei. Neben dem latenten Soundgebaren stieg mir ein undefinierbarer Geruch in die Nase – leicht ätzend.

Doch darum musste ich mich später kümmern, denn es gab einen Notfall. Eine Kollegin hatte gerufen, weil der Internetzugang klemmte. Okay, wie erwartet konnten alle lokalen Ressourcen erreicht werden, bis auf den Router … Moment, der Router steht in der Server-Küche – der unangenehme Geruch!

Tür auf, Geruch wird beißender, leicht verbrannt mit einer Note von verschmortem Elko. Unser Router wies auf der Oberseite an einigen Kühlschlitzen eine deutliche Verfärbung auf: schmierig weiß und grau-grün. Dann hörte ich schräg hinter und über mir für einen Server-Raum seltsame Geräusche: Rascheln und Gurren. Auf unserem Rack saß – eine Taube. Warum sie durch das offene Fenster in diese Sauna geflogen ist, wird immer ein Rätsel bleiben. Aber Fakt bleibt: Sie hat unseren Router ausgeschissen.

Moral: Wer beizeiten für sinnvolle Kühlung sorgt, muss sich nicht mit verderblichem Geflügel herumschlagen.