Login
Login-Name Passwort


 
Newsletter
Werbung

Mi, 15. Januar 2003, 00:00

Der Memoiren 2. Teil oder: Der Weg zum Sysadmin

X-Snow wurde ein paarmal gestartet und Linux ein paarmal installiert und so nebenher wurde UNIX erlernt, sozusagen. Nach dem Einstieg in die Linux-Welt erfolgte 1994 der Einstieg in die UNIX-Welt, indem ich mich selbständig machte und im Auftrag von anderen Firmen Rechner betreute. Dies sollte mir Geld bringen, um mein Studium, welches nichts mit Rechnern zu tun hatte, zu finanzieren.

Hauptsächlich tätig war ich für die Firmen "Compdata" und "Der Technikladen". "Der Technikladen" ist leider seit einigen Jahren geschlossen. Es war der beste Computerladen in ganz Bayreuth. Im übrigen hat die Schließung nichts mit mir zu tun ;-)

Für die Firma "Compdata" installierte ich Telefonanlagen, Router unter Linux, und betreute auch eine Rechenanlage unter SCO OpenServer und Solaris x86. Mit beidem habe ich so meine speziellen Erfahrungen gemacht Aber die wichtigste vorweg: Es gibt nichts, was ein "GNU Tar" ersetzen könnte.

SCO

Nun, diese Anlage verfügte über einige Clients, in diesem Falle zunächst serielle Terminals, einige, ebenfalls seriell angeschlossene, Drucker, einen Barcode-Scanner, eine Kassenschublade und einige Rechner, die über Terminalemulation auf den SCO-Server zugriffen.

Alles lief, aber irgendwann fing ab und zu mal die Systemplatte an zu spinnen. Nun eigentlich kein Problem, einfach austauschen. Denkste!

Nun, einfach rüberkopieren ging nicht. Warum, weiß ich nicht mehr, aber es ging eben nicht. Darum sollte mittels Rescue-Disketten das System gebootet werden und dann die Bänder einfach eingespielt werden. Die Sache hatte nur einen Haken. Das Programm, welches die Boot- und Root-Disketten erzeugt, war wegen irgendwelcher Fehler nicht in der Lage, die Bootdisketten zu erstellen, nur die Root war in Ordnung.

Also wandte ich mich an den Support, der mir zwei Disketten zuschickte. Unglücklicherweise verhält (oder verhielt...) es sich unter SCO so, daß Treiber in den Kernel "eingelinkt" werden. Wir hatten einen QIC-Streamer (Quarter Inch Cartridge, nicht zu verwechseln mit den Minidingern von vor 15 Jahren...), aber der Support hatte einen DAT-Streamer in den Kernel gelinkt. Also erneuter Anruf. Diesmal hatte der Support zwar den richtigen Treiber eingelinkt, nicht aber die richtige SCSI-ID, denn, ja, auch die SCSI-ID wird in den Kernel mit hineingelinkt.

Nun, eigentlich wäre das recht einfach, wenn nicht zufällig die Platte bei uns an dieser ID gehangen wäre.

Und noch ein Problem existierte: Der verwendete Treiber von uns kam nur mit der alten verwendeten Firmware auf dem Adaptec-SCSI-Controller klar, und der vom Support verwendete Treiber nur mit der neuen Firmware des Controllers.

Das ganze Spielchen verhielt sich also folgendermaßen: Einbauen der neuen Platte, IDs wechseln, von verschiedenen Disketten/Platten booten, einlesen, Controller wechseln, Spielchen von vorne... und so weiter und so weiter, bis zu guter Letzt die Daten alle auf der neuen Platte waren, mit dem alten Kernel und dem alten Controller natürlich.

Und was hat das mit Linux zu tun?

Nun, während der ganzen drei Tage Umbaumaßnahmen lief neben dem Server ein Linuxrechner, der früher mal nach einem Problem mit der SCO-Kiste aufgestellt worden war. Auf diesem Rechner lief eine SuSE 5.3 und auf dem System das "iBCS2"-Kernelmodul. Damit lief die Anwendung, die in Cobol geschrieben war und eine eigene Datenbank benutzte, einwandfrei weiter, einzig das Ausdrucken von Rechnungen und so ging nicht, da die Ausgabe das Programms irgendwie so komisch gestaltet war, daß alles kleiner auf dem Drucker ankam als unter SCO.

Solaris x86

Um es gleich vorweg zu nehmen, a) auch hier half "GNU Tar", das Leben zu vereinfachen und b) hier kommt leider kein Linux drin vor.

Was predigen einem immer die Eltern? Messer, Gabel, Schere, Licht, sind für kleine Kinder nichts. Einen ähnlichen Spruch sollte es auch für PS/2 geben. Zumindest für den PS/2-Mausanschluß, denn obwohl sehr gefährlich, hat es sich bis jetzt immer noch nicht herumgesprochen, daß jemand, der eine PS/2-Maus im laufenden Betrieb absteckt, mit Stockschlägen nicht unter 5 Stück auf die Fußsohlen bestraft wird.

Der Fall betraf den zweitgrößten XXXXXXXXXX-Hersteller Europas. Dort betreute ich eine Solaris-Anlage, auf der eine CAD-Applikation lief. Dort lief einmal ein folgender Dialog ab (mangels persönlichen Dabeiseins kann ich dies nur aus zweiter Hand wiedergeben):

Einer: He, was host denn du für a Mausschdegger, ich hab den hier
Anderer: Ne, ich hob hier so anen
Pflopf PS/2-Mausstecker wird gezeigt.
Pfropf PS/2-Mausstecker wird wieder eingesetzt
Anderer: Hee, warum geht ma Dasdadur net meer?
Einer: Boot hoalt amol.

Bleibt zu erwähnen, daß weder Tastatur noch Maus an diesem Board jemals wieder liefen, denn das Keyboard-BIOS war zerschossen. Wer jetzt glaubt, daß dieses eine Ausnahme ist, dem sei gesagt, daß dies konstruktionsbedingt bei PS/2-Mäusen vorkommen kann. PS/2 ist so designed!!!

Nun, wir kauften das direkte Nachfolge-Board des defekten Motherboards und bauten es ein. Es sollte verhindert werden, daß die Applikation neu installiert werden muß oder irgendetwas installiert werden muß, da sonst erst wieder ein Schlüssel für die CAD-Software aus England angefordert werden muß und vom Service-Techniker einige Dinge installiert werden müßten.

Es blieb uns nach einem Marathon und zig Telefonaten mit SunSoft trotzdem nicht erspart. Mit SunSoft zusammen versuchten wir die verschiedensten Dinge, wie "boot -r", irgendwelche Neuinstallationen auf eine andere Platte und Austauschen diverser Directorys. Nichts half.

Letztendlich installierte ich auf eine andere Platte neu und linkte die diversen Verzeichnisse von der alten Platte neu ein. So brauchten wir nur einen neuen Schlüssel und nicht noch den Servicetechniker.

Trenne nie PS/2, denn es geht entzwei.

Der Mensch von SunSoft meinte übrigens nach diesen drei Tagen und dem Geld, das wir dafür bezahlen mußten, daß das Booten des Systems auch nicht gegangen wäre, wenn wir ein identisches Board zum Austausch gehabt hätten. Aber erstmal drei Tage zahlen lassen...

Tja, dies waren zwei herausragende Ergebnisse, die sich so getan haben... inzwischen hatte ich aber ein ganz anderes Problem bekommen. Das Studium ließ mir nicht genug Zeit, soviel zu arbeiten, wie ich bräuchte, um genug Geld zu verdienen, um mein Studium fortzusetzen. Andererseits ließ mir die Arbeit nicht genug Zeit, um soviel für mein Studium zu tun, um die Prüfungen zu bestehen und um überhaupt zum Abschluß zu kommen.

Wie das Problem gelöst wurde, steht im letzten Teil.

  • Dieses Werk wurde unter der GNU Free Documentation License veröffentlicht. Das Kopieren, Verbreiten und/oder Modifizieren ist erlaubt unter den Bedingungen der GNU Free Documentation License, Version 1.2 oder einer späteren Version, veröffentlicht von der Free Software Foundation.

    - Weitere Informationen
Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung