Elektronikschrott

Am aktuellen Seagate-Desaster und dessen langsam bekanntwerdenden Hintergründen läßt sich wunderschön demonstrieren, daß viele Anwender (und vermutlich unter ihnen auch viele Administratoren) beim panischen Einspielen irgendwelcher vielleicht, vielleicht aber auch nicht so ganz passenden Beta-Firmware-Updates die zwei goldenen Regeln der Systemadministration nicht beachten:

Erstens:

Keine Panik.

Und zweitens:

Erst denken. Dann handeln.

Eigentlich sind diese beiden Merksätze nur Konkretisierungen ein und desselben Hintergrundes: Panik blockiert das rationale Denken und damit die Folgenabschätzung. Und Handeln ohne Folgenabschätzung mag die akuten Symptome eines Problems beseitigen können - wenn man Glück hat. Aber die Folgefehler solch unüberlegten Handelns können viel schwerwiegender und schwieriger zu beseitigen sein, als es das ursprüngliche Problem jemals war. Vor allem dann, wenn objektiv betrachtet noch gar kein (akutes) Problem vorlag, sondern nur die (mehr oder weniger vage) Möglichkeit, daß eins vorliegen könnte.

Von daher gilt für einen guten Admin: Wenn die Informationslage zu einem möglichen Problem unklar und verworren ist, ist der beste Lösungsansatz, erst einmal die Informationslage zu verbessern. Mitunter geht das nur, indem man einfach erst einmal abwartet - auch Hersteller können nicht zaubern und haben endliche Ressourcen. Solange die Informationslage nicht zufriedenstellend ist, solange ich nicht weiß, mit was ich es zu tun habe, solange wird an einer laufenden Systemkonfiguration erst einmal nichts geändert. "Never touch a running system" ist als Merksatz zwar auch schon etwas älter, hat deshalb aber trotzdem nichts an seiner Richtigkeit verloren. Sobald die Informationslage sicher genug ist, daß ich zuverlässige Entscheidungsgrundlagen habe, kann ich eine Entscheidung treffen - keine Sekunde vorher.

Und ja, ich weiß, daß das leichter gesagt als getan ist, wenn man panische Kunden, ein hysterisches Marketing oder ähnlich unangenehme Dinge abzuwehren hat. Leute, die einem im Nacken sitzen und einen anbrüllen, daß dieses PROBLEM! der Untergang der westlichen Zivilisation ist und SOFORT!, AM BESTEN GESTERN!!! gelöst werden muß. Dagegen hilft nur, sich ein dickes Fell zuzulegen und freundlich darauf hinzuweisen, daß man an dem Problem arbeitet. Und in Härtefällen der folgende Satz:

Wenn ich jetzt keine Zeit habe, überlegt und geplant zu handeln - woher soll ich dann die Zeit nehmen, die Folgen einer unüberlegten Fehlhandlung wieder auszubügeln?

Die IBM-Großrechnerwelt ist für mich bislang terra incognita. Ich habe seinerzeit an der Uni verpennt, mir einen MVS-Account zuzulegen (was für meinen Jahrgang gerade noch möglich gewesen wäre), und so blieb nur die Erinnerung an die großen IBM 3270-Terminals an den Abholfächern für die Druckausgabe und an die IBM-typischen Deckblätter der Ausdrucke vom Endlospapier-Laser.

Aber heutzutage gibt es ja die Möglichkeit, alles auf PC-hardware zu emulieren. Der Emulator für IBM-Mainframes heißt "Hercules" und ist für Linux, Mac OS X und Windows erhältlich. Und es gibt ein fertiges CD-Image für ein "Turnkey System". Runterladen, installieren, und dann bekommt man so etwas:



Jetzt muß ich nur noch das alte MVS-Handbuch wiederfinden...

Da ich gerade dabei bin, meinen Domainregistrar und meinen Hoster zu wechseln, könnte die Erreichbarkeit der Domain "datentrampelpfad.de" und damit auch dieses Blogs über das Wochenende und/oder am Anfang der nächsten Woche ein wenig wackelig sein. Dafür wird das Blog dann aber auch auf wesentlich neuerer und leistungsstärkerer Hardware liegen, wenn die Umzugswehen einmal überstanden sind.

Man beachte auch den Warnhinweis für unerfahrene Benutzer:

Wer ab und an mal serielle Dinge mit seinem Rechner tun muß, kennt das Problem: Man muß ein Terminalprogramm auf dem System installiert haben. Man kann dafür cu(1) benutzen - wenn man UUCP auf dem System installiert hat, was häufig nicht der Fall ist. Oder minicom(1), ein klassisches Terminalprogramm. Aber was macht man, wenn man auch das gerade nicht zur Hand hat?

[0] toje@sparrow:~$ grep "inserting leap second" /var/log/messages
Jan  1 00:59:59 sparrow kernel: Clock: inserting leap second 23:59:60 UTC
Jan  1 00:59:59 finch kernel: Clock: inserting leap second 23:59:60 UTC

Ich hoffe, daß eure Rechner auch so gut ins neue Jahr gekommen sind.

Wie ich vor einiger Zeit schon geschrieben hatte, ist mir eine SPARCstation IPC zugelaufen. Leider war sie mit den Jahren etwas flügellahm geworden - die integrierte Batterie des IDPROM-Chips war mittlerweile leer, so daß der Rechner nach jedem Einschalten erst einmal seine Identität beigebracht bekommen mußte. Auch die Originalplatte, eine Maxtor LXT213SY mit sagenhaften 213 MB Kapazität im praktischen Ziegelsteinformat, mochte nicht mehr anlaufen. Trotzdem war es mir mit dem Diskless NetBSD-HOWTO gelungen, auf der Maschine ein NetBSD zu booten. Leider wurde eine qfe-FastEthernet-Karte nicht erkannt, aber es war ein erster Erfolg.

Wer schon immer einmal wissen wollte, welche Hardware sich eigentlich genau in einem NTA der Deutschen Bahn (auch "Touchscreen-Automat" oder "Fernverkehrs-Automat" genannt, die offizielle Bezeichnung ist "Neuer Ticket-Automat") verbirgt, der wird hier fündig:

Seit Herbst letzten Jahres steht bei mir eine SPARCstation IPC im Regal, die mir Hanno freundlicherweise überlassen hatte. Erste Wiederbelebungsversuche waren seinerzeit daran gescheitert, daß die Framebuffer von Sun "composite sync" (nicht, wie immer wieder behauptet wird, "sync on green"!) verwenden, was mein VGA-Monitor nicht versteht. Zudem sind die seriellen Schnittstellen als Mini-DIN8 ausgeführt, und ich hatte kein passendes Kabel.

Das Kabel gab es nun beim üblichen Verdächtigen für kleines Geld, und somit wurde am Wochenende ein erneuter Versuch gestartet. Gleich beim ersten Booten zeigte sich dann auch, warum auf dem Ethernet-Port vorher keine Aktivität zu verzeichnen war: Das NVRAM (manchmal auch IDPROM genannt) hatte seine Inhalte vergessen, da die integrierte Batterie mittlerweile den Geist aufgegeben hatte. Gottseidank gibt es im Web FAQs zu diesem Problem, und nach etwas Tipparbeit bootete die Sun wieder. Der Nachmittag ging dann mit dem Aufsetzen diverser Dienste (RARP, Bootparm, TFTP) und dem Auspacken eines älteren NetBSD-Releases herum (NetBSD läuft ja bekanntlich auf allem, vom Großrechner bis zum Toaster), und gegen Abend dann das Erfolgserlebnis: Die IPC bootete den NetBSD-Kernel vom Netz.

Jetzt muß ich erstmal einen widerspenstigen DHCP-Server in meinem LAN zähmen, und dann folgt Teil 2: Booten des Gesamtsystems. Leider scheint die integrierte Platte tot zu sein, mal sehen, ob ich noch irgendwo eine kleine SCSI-Platte auftreiben kann. Bis dahin muß phoenix halt erstmal vom Netz booten. Ein neuer IDPROM-Chip ist wahrscheinlich auch fällig. Irgendwann einmal soll die Kiste mit einer Quad-Ethernetkarte Router für das Wohnungs-LAN spielen, aber bis dahin ist noch ein weiter Weg.

(Zum Namen: "Phoenix" ist der Sun-interne Codename für die IPC gewesen. Eigentlich vergebe ich ja keine Rechnernamen doppelt, und phoenix war mal ein DSL-Router aus einem ausgemusterten 486er, aber das ursprünglich vorgesehene "crow" habe ich dann doch nicht übers Herz gebracht.)