Kostenlose Zeitreise

Inhaltsverzeichnis

Das Jahr-2000-Problem wird in den Medien stark und vor allem ängsteschürend diskutiert. Dabei werden die real existierenden Gefahren oft überzeichnet und verzerrt - was macht es schon, wenn der Videorecorder am 1. 1. 2000 eine Fernsehsendung nicht aufzeichnet. Oft haben die Mahner und Warner auch gleich die umfassende Lösung in Form von Tools oder Beratungsleistung zur Hand. Assoziationen an die Werbekampagnen der Waschmittelindustrie, die zu jedem Fleckenproblem das passende Waschmittel anpreist, drängen sich geradezu auf. Dagegen haben die im folgenden dargestellten Tests den Vorteil, daß die eingesetzten Tools Bestandteil des Betriebssystems Unix und somit ohne Zusatzkosten verfügbar sind.

Zunächst wurde die beschriebene Vorgehensweise auf einer kleinen Workstation, einem System RM200 der Firma SNI (jetzt wieder Siemens), entwickelt und getestet, danach auf die Abteilungsserver RM300/RM400 und die Enterprise-Server RM600/RM1000 übertragen. Der Hersteller deklariert sein Reliant Unix 5.43 C20 als ‘Ready for year 2000’. Wenn aber unternehmenskritische Anwendungen auf solch einem System betrieben werden, gilt wie immer: Vertrauen ist gut, Überprüfen ist besser. Darüber hinaus macht man beim Y2K-Test des Betriebssystems viele Erfahrungen, die einem später bei der Überprüfung der Anwendungen nützlich sind.

Schichtenmodell: Aufbau eines Y2K-Tests

Auch beim Jahr-2000-Test kommt das in der Informatik so beliebte Schichtenmodell zum Tragen. Hardware, Firmware und Betriebssystem bilden die unterste, Middleware (Datenbanken, Transaktionsmonitore) die zweite und Anwendungen die dritte Schicht. Wenn die unterste Schicht im Prinzip Jahr-2000-fest ist, lohnt ein Blick auf die Middleware. Und erst dann geht es um das Testen der Software, mit dem ein Unternehmen das Geld verdient, nämlich der Anwendungen. Dieses schichtweise Vorgehen erleichtert die Fehlersuche ungemein und spart Ressourcen, da die Fachabteilungen sich wirklich auf die Überprüfung ihrer Applikationen konzentrieren können.

Wichtig ist in jedem Fall eine Testumgebung. Diese sollte zum einen weitestgehend dem operativen System entsprechen, zum anderen einem vom Hersteller als Jahr-2000-fest versprochenen Stand. Selbst wenn man eine abschließende Prüfung auf dem operativen System ohnehin plant, ist ein ‘Spielsystem’ notwendig, um die Abläufe zu entwickeln und auszuprobieren. Darüber hinaus sind überprüfte Verfahren zur Datensicherung und -restaurierung zwingend - denn der gefährlichste Moment im Leben einer Jahr-2000-Zeitreise ist die Rückkehr in die Gegenwart. Wie reagieren Betriebssystem und Anwendungen auf Dateien, die in der Zukunft angelegt wurden? Werden diese von der Backup-Software gesichert? Und so fort.

Sicherheit mit kleinen Fußangeln

Diese Rückkehr in die Gegenwart ist zwar für den tatsächlichen Jahrtausendwechsel unproblematisch, für die Testphase aber existentiell. Darum ist ein Ausprobieren auf operativen Systemen sträflicher Leichtsinn.

Eine spezielle Problematik von Zeitreisen betrifft vor allem die verantwortungsbewußten Systemadministratoren. Die haben die Security-Parameter nämlich so eingestellt, daß Paßwörter nach einer bestimmten Anzahl von Tagen verfallen beziehungsweise Accounts nach einer bestimmten Zeit der Nichtbenutzung automatisch gesperrt werden. Wer diese Politik auch für die Kennung ‘root’ anwendet und mit dem Datum 31. 12. 1999 seinen Rechner bootet, steht anschließend vor einem mittelgroßen Problem - er hat sich selbst aus dem System ausgesperrt.

Darum: die Paßwortalterung für ‘root’ ausschalten, unter System V mit passwd -x -1 root.

Sind die folgenden Schritte realisiert, nämlich

• Aufbau einer Testumgebung mit einem vom Hersteller als Y2K-ready deklarierten Stand,
• Festlegung und Test von Backup- und Restore-Prozeduren und
• Anpassung der Security,

kann man sich der Definition der Testziele für die unterste Schicht zuwenden. Eine Überprüfung sämtlicher Funktionen des Betriebssystems ist für den normalen Anwender deutlich zu aufwendig. Wichtig ist, daß das Betriebssystem in den Teilen Jahr-2000-fest ist, die für die eingesetzte Middleware und die Anwendungen relevant sind. Außerdem sollte natürlich der Rechner selbst die Zeitreise stabil überleben.

Funktionen, die von mir untersucht wurden, sind

• zeitbezogene wie cron, at und date,
• mit dem Dateisystem operierende, also mkdir, ls und so weiter und
• Datensicherungsbefehle, beispielsweise cpio und tar.

Ergebnis der Tests sollte der Nachweis sein, daß das System als ‘nackter’ Rechner, nur mit dem Betriebssystem, auch im Jahr 2000 stabil läuft. Die Datensicherungsprozeduren zum Zurückspielen der Daten nach einer Zeitreise müssen sich bewährt haben.

Zeitreise im Detail

Die Zeitreise streift eine Reihe von kritischen Stationen. Neben dem eigentlichen Übergang auf das Jahr 2000 und dem 29. 2. 2000 sind dies die bekannten ‘Schnapszahlfallen’, die man früher gern als Abbruchbedingung einsetzte, zum Beispiel der 9. 9. 99, der 12. 12. 99 oder auch der 99. Tag im Jahre 1999. Diese Daten dürften zwar eher für die Anwendungen kritisch sein, wurden aber auch bei dem Betriebssystemtest mit untersucht. Es dürfte nach dem oben Gesagten klar sein, daß jede Zeitreise mit einer kompletten Datensicherung beginnt. Anschließend erfolgt die Anpassung der Security.

Für jede Station der Zeitreise gilt der gleiche Ablauf:

• Setzen des Datums für die erste Station der Zeitreise und Auslösen eines Reboot;
• Aufrufen von Testprozeduren vor dem Datumswechsel;
• Aufrufen von Testprozeduren nach dem Datumswechsel;
• Setzen des Datums für die nächste Station der Zeitreise und Auslösen eines Reboot.

at als Signalgeber

Der Ablauf läßt sich mit einfachen Bordmitteln automatisieren, nämlich via at. Dieser Unix-Befehl dient dazu, eine Aufgabe zu einem definierten Zeitpunkt in der Zukunft ausführen zu lassen, etwa am 29. 2. 2000 um 00:16 Uhr. Die Art der Aufgabe ist dabei weitgehend beliebig, sogar ein Reboot des Systems ist so steuerbar. Zudem ist at ‘reboot-fest’ und nutzt zum Zeitmanagement die Routinen des Betriebssystems. (Wenn eine Prozedur nicht wie angegeben am 29. 2. 2000 startet, liegt offensichtlich ein größeres Problem vor.)

Damit läßt sich die Zeitreise als Folge von durch at gestarteten Prozeduren realisieren, die in einem Shell-Script zusammengefaßt sind. at -l zeigt an, zu welchen Terminen Befehle eingestellt sind, at -r löscht einzelne Befehle. Die automatische Zeitreise startet, indem der Systemverwalter das Datum etwa zehn Minuten vor deren Beginn stellt und den Rechner bootet. Zur Überprüfung der Ergebnisse dient eine möglichst umfangreiche Protokollierung durch das Zeitreise-Script.

cron dient als Alternativtimer

Im in Listing 1 dargestellten Beispiel liest at die Kommandos aus einer Datei (Parameter -f), der untere Teil zeigt die entsprechende Ausgabe von at -l.

Im einzelnen heißt dies: at startet am 1. 1. 2000 um 00:30 Uhr die Prozedur reboot.022823302000. Diese stellt das Systemdatum auf den 28. 2. 2000, 23:30 Uhr, vor und bootet anschließend den Rechner. jtw_tail öffnet ein xterm-Fenster auf dem PC des Autors und zeigt den Fortgang der Tests durch tail -f ‘Protokolldatei’ an. Es folgen Scripts, die die verschiedenen Testfälle starten. Neben den über at eingestellten Prozeduren lassen sich auch durch cron zu einem definierten Zeitpunkt Aufgaben ausführen, ein Beispiel zeigt Listing 2. Im Klartext: Um 00:09 Uhr am 29. 2. jeden Jahres soll cron-shell.29.2 laufen, ein einfaches Script, das die cron-Funktion selbst testet.

at und cron sind also die Tools der Wahl zur Automatisierung der Zeitreise. Je nach Notwendigkeit kann der Ablauf durch Einfügen weiterer Prozeduren ergänzt werden. Funktionen, die wir bei unserem Test eingebunden hatten, waren zum Beispiel das Sichern und Rückgewinnen von Dateien und Verzeichnissen sowohl mit den Standardtools cpio und tar als auch über IBMs ADSM, die Übergabe von Fehlermeldungen an Tivoli, das Tracen eines X.25-Verbindungsaufbaus, Übertragen von Dateien mit FTP et cetera. Die Ausgaben all dieser Verfahren sind in der Protokolldatei nachvollziehbar, inklusive des durch pkginfo -l und showconf ermittelten Hard- und Softwarestandes.

Aus Vorsicht, vielleicht aber auch aus Feigheit, ließ ich übrigens die Prozeduren nicht unter der Kennung ‘root’ ablaufen, sondern richtete einen eigenen Account ‘jtw’ für die Tests ein. Ein dem Shareware-Programm ‘sudo’ ähnlicher Mechanismus berechtigt ‘jtw’, das Datum zu verändern und den Reboot durchzuführen.

Jedes System durchlief die Zeitreise mindestens zwei Mal. Bei der ersten war der Rechner zwischen den Reboots ausgeschaltet, beim zweiten und den folgenden Durchläufen erfolgte ein Warmstart über init 6.

Größere Probleme traten nicht auf, Reliant Unix 5.43 C20 erwies sich als Jahr-2000-fest. Interessant waren einige Erfahrungen über das Zusammenspiel von at, cron und den Zeitzonen. So führt cron einen Auftrag nicht aus, falls die Benutzerkennung zum entsprechenden Zeitpunkt gesperrt ist. Wenn eine Prozedur also etwa am 29. 2. 2000 nicht automatisch gestartet wird, kann es daran liegen, daß die entsprechende Kennung abgelaufen ist - Datei /var/cron/log kontrollieren.

Die Basis scheint fehlerfrei

Ein Account, der am 1. 1. 2000 gesperrt werden soll, etwa weil der Vertrag eines externen Mitarbeiters dann ausläuft, verfällt tatsächlich erst zum 1. Januar 2000 nach GMT - bis 0:59 MET hat der vermeintlich Gesperrte noch Systemzugang.

Immerhin entlarvten die Tests noch einige, wenn auch kleine Fehler. Der Befehl usermod -e 1/1/2000 ‘userid’ soll laut Manual den entsprechenden Zugang am 1. 1. 2000 sperren, zog die Kennung aber erst im Jahr 2020 aus dem Verkehr. Dieses ‘gravierende Problem’ wurde natürlich sofort dem Hersteller gemeldet, und es soll mit der Version 5.43D00 im ersten Quartal 1999 bereinigt sein. Kleiner Workaround bis dahin: usermod -e 1/1/00 ‘userid’.

Eine kleine Unsauberkeit: Mit dem Befehl passwd -s ‘userid’ kann man sich anzeigen lassen, wann das Paßwort zuletzt geändert wurde. Die Anzeige des Jahres ist auch für 2000 zweistellig, der interne Wert in /etc/shadow jedoch korrekt. Nach Abschluß dieser Basistests sind wir jedenfalls davon überzeugt, eine stabile Plattform zu haben, die die Überprüfungen von Middleware und Anwendungen optimal unterstützen kann.

WINFRIED SCHWOLGIN

ist bei der Dresdner Bank zuständig für hochverfügbare Server, auf denen Anwendungen der Kundenselbstbedienung (Steuerungen für Geldautomaten und Kontoauszugsdrucker) betrieben werden.

Online-Hilfen
Die im Artikel angesprochenen Test-Scripts sind in der Variante für Linux online verfügbar.
Via WWW bieten wir außerdem eine Sammlung wichtiger URLs zum Thema und ein Forum zum Erfahrungsaustausch an.
Download: Scripts für Linux

Mehr Infos

iX-TRACT

• Die Simulation des Wechsels in das Jahr 2000 sollte nicht auf operativen Systemen ausprobiert werden, weil vor allem das Rückstellen des Datums zu zahlreichen Problemen führen kann.
• Vor dem Test der Jahr-2000-Festigkeit sind geprüfte Backup- und Restore-Prozeduren zwingend.
• Ein Jahr-2000-Test sollte Schicht für Schicht durchgeführt werden: erst Hardware und Betriebssystem, dann Middleware, zuletzt Anwendungssoftware.

Mehr Infos

Y2K-Splitter

After-Date-Support: die Software AG bietet Unterstützung für Anwender, die nach dem 1. 1. 2000 auf bis dahin unerkannte Y2K-Probleme stoßen. Für die Zeiträume vom 24. 12. 1999 bis zum 20. 1. 2000 und vom 28. 2. bis zum 10. 3. 2000 bereiten die Darmstädter deswegen einen 24-Stunden-Service mit ihren Jahr-2000-Spezialisten vor. Die Zahl der möglichen Kunden ist auf 100 begrenzt, Anmeldungen unter Tel.: 061 51/92-30 06 und 061 51/92-12 66.

Silvester-Hilfe: Computer Associates (Tel.: 061 51/949-0) will seinen Kunden mit Wartungsvertrag vom 30. 12. 1999 bis zum 4. 1. 2000 mit Rat und Tat zur Seite stehen und bietet für die CA-Produkte, die Y2K-ready sein sollen, einen Vor-Ort-Support zum Spesensatz seiner eingesetzten Mitarbeiter.

Vernetzte PCs testen: ON Technology zeigt zur CeBIT (H1/8a2) Version 4 seines PC-Managementsystems ON Command CCM, die eine Funktion namens Y2K JumpStart enthält, um zentral gesteuert PCs im Netz auf Jahrtausendfestigkeit zu testen. Tel.: 081 51/369-0.

Alterung simulieren: Cyrano (Tel.: 061 96/40 08 27) hat mit der Software MillenniumTest ein Werkzeug im Portfolio, das unter OpenVMS, Unix und HP3000ME eine Alterung von Geschäftsdaten simuliert und die entsprechenden Folgen aufzeichnet.

Doppelprüfung: Sowohl auf Jahr-2000- als auch auf Euro-Festigkeit soll LiveQuality von Segue Software (Tel.: 089/36 34 33) komplexe Anwendungen im E-Business-Umfeld testen, vom Browser über Web-, Applikations- und Datenbankserver bis zu Legacy-Systemen.