Achtung: Die Inhalte hier werden nicht mehr gepflegt und sind u.U. veraltet.

Tricks und Kniffe: Kopflos im Rechenzentrum

Dr. Wetter IT-Consulting

Wir schreiben das Jahr 5 nach 2000. Alle Server im Rechenzentrumsland sind über ihre serielle Konsole für Notfälle und normalere Gelegenheiten via Out-of-Band-Administration zugänglich. Alle? Nein. Eine kleine Herrschar unbeugsamer Systemadministratoren hört nicht auf, dieser Maßnahme Widerstand zu leisten. Diese fröhlichen und rauflustigen Gesellen warten eigentlich nur drauf, dass Ihnen der Himmel auf den Kopf fällt.

Zugegeben, serielle Konsolen sind nicht mehr der letzte Schrei. An immer mehr im Rechenzentrum befindlichen Servern ist dies auch immer weniger nötig, da viele einen eigenen Managementprozessor mitbringen, der übers Ethernet auch bei heruntergefahrener Maschine sich der Hardware annehmen kann. Bei einigen Linux-Farmen ist es in manchen Fällen auch gar nicht erforderlich oder zu teuer, jeden einzelnen Knoten seriell anzustöpseln, da ein einzelner Ausfall die Farm nicht als Ganzes in Ihrer Funktion beeinträchtigt. Übrig bleiben immer noch eine ganze Reihe Szenarien, in denen serielle Konsolen sinnvoll sind.

Auf die Schnelle

Wenn es einen mehr oder weniger kalt erwischt im Rechenzentrum und keine Konsole griffbereit ist für die ach-so-wichtige Maschine, gibt es mehrere Möglichkeiten, sich zu behelfen. Nach Geek-Manier ganz simpel kann man seinen dicken Server mit einem PDA starten, sofern dieser über einen seriellen Anschluss verfügt. Beim alten Palm geht das mit einem seriellen Kabel und dem Programm ptelnet. Wer es etwas komfortabler mag, sucht sich ein Nullmodem- (also ein „gekreuztes”) Kabel und einen zweiten benachbarten Computer nebst Terminalsoftware, entweder minicom (Linux/BSD), HyperTerminal (Windows) oder unter Solaris tip. Ab Werk mögen eigentlich alle seriellen Geräte die Einstellungen 9600,8N1 (9600 bps, 8 Datenbits, keine Parität, 1 Stoppbit) und kein Software- und am besten auch erstmal kein Hardware-Handshake. Dies sollten im Zweifelsfall die Starteinstellungen sein. Eine weitere Binsenweisheit: Man sollte sicher stellen, dass man auch die richtige serielle Schnittstelle auserkürt, was manchmal nicht eindeutig ist, da nun mal das Betriebssystem oder das BIOS nicht die Bezeichnung übernimmt, die auf dem Gehäuse hinten drauf steht (stty -F /dev/ttyS0 liefert zumindest einen Hinweis, ob die erste serielle Schnittstelle unter Linux richtig erkannt wird).

Die Richtige finden

Viel Zeit kann ins Land gehen bei der Suche nach dem richtigen Kabel. Während es bei den Klassikern DB 9 oder DB 25 vorkonfektionierte Nullmodemkabel zu kaufen gibt, existiert für die Pinbelegungen der seriellen RJ45-Buchsen keine Standardbelegung. Wer demnach mit einem CAT 5-Ethernetkabel seine Sun-Netra oder seinen Cisco-Switch an seinen Konsolenserver oder an einen Rechner mit der Terminalsoftware anstöpseln möchte, sollte, falls dies nicht auf Anhieb klappt, einen Blick ins Handbuch oder ins Paket der Konsolenserver bzw. des Switches wagen: Meistens liegen Kabel oder Adapter bei oder sollten am besten gleich mit auf der nächsten Bestellliste stehen. Zumindest haben die meisten Hersteller die Belegung dokumentiert. Wem der Sinn eher nach der Trial-and-Error-Methode steht: Manche Konsolenserver haben zudem das nützliche Feature, dass Ihnen der Status der einzelnen seriellen Adern zu entlocken ist. Anderenfalls leisten ein einschleifbarer RS-232-Analysator oder eine RS-232-Steckbrücke („Break-Out-Box”) gute Dienste, die beim freundlichen Elektronikversandhandel für wenige Brüssel-Taler zu erstehen ist.

Von Anfang an

Nachdem nun die Kabelverbindung und die Clientseite funktionieren, geht es dran, den Server auf seinen seriellen Einsatz vorzubereiten. Eine Sparc unter Solaris ist in dieser Hinsicht sehr Admin-freundlich, sie stellt selbstständig beim Einschalten ohne Tastatur fest, dass sie ab Open Boot Prompt (OBP) alle ab nun folgenden Ein- und Ausgaben über die erste serielle Schnittstelle abwickeln soll. Weder das BIOS Ihres Server-PCs noch das Betriebsystem sind bisher so intelligent. Daher als Nachhilfeaktion für Ihren „kopflosen” PC unter Linux die einzelnen Schritte, gegliedert in mehrere Abschnitte:

Die serielle BIOS-Umlenkung,
Konfiguration des Boot-Laders,
des Linux-Kernels
und schließlich des seriellen TTYs.

Bei allen muss man – Achtung: manchmal missachtete Binsenwahrheit – natürlich die gleichen seriellen Kommunikationsparameter einstellen. Bei der seriellen BIOS-Umleitung sind nicht immer alle hohen Geschwindigkeiten verfügbar. Dieses Einengen der Schnittmenge sollte zum Anlass dienen, zuerst ins BIOS wegen der Wahl der Geschwindigkeit zu schauen. Falls im BIOS eine serielle Umleitung vorgesehen ist, sollten Sie diese ruhig aktivieren, wenn Sie die Selbsttests mitverfolgen, Hardware-Events-Logs, Spannung, Lüfterdrehzahl und alles andere einsehen und ggf. Einstellungen im BIOS ändern wollen. Nicht zu verschmähen ist der damit gleichzeitig ermöglichte Zugriff auf das BIOS etwaiger Zusatzkarten. Als Terminalemulation funktioniert vt100 in der Regel, Falls die Taste DEL Sie nicht wie angegeben ins Setup BIOS-Setup führt, sollte Backspace funktionieren. Generell sollte die eingestellte Terminalemulation mit der des Terminalfensters identisch sein oder zumindest abwärtskompatibel.

Geburt mit Lilo / Grub

An den Boot-Ladern muss an zwei Stellen geschraubt werden: Der globale Teil, damit die Ausgabe von Grub oder Lilo auch auf der seriellen Schnittstelle zu sehen ist. Dann bei den einzelnen Kerneln, damit diese beim Start wissen, wo ihre Systemkonsole ist. Im globalen Teil der Boot-Lader-Konfigurationen lilo.conf bzw. in der entsprechenden Grub-Konfigurationsdatei menu.lst/grub.conf befindet sich üblicherweise grafischer Schnickschnack, den es zu entfernen oder auszukommentieren gilt. Dazu zählen Splash-Screens, gfxmenu-Meldungen, Zeilen mit menu-schemeoder grafische message-Zeilen. Bei Verwendung von Grub müssen folgende Zeilen in den ersten globalen Teil von menu.lst/grub.conf hinzugefügt werden ("BBBB" steht für die Übertragungsgeschwindigkeit, X für die Nummer der seriellen Schnittstelle, also meistens 0 oder 1):

serial -unit=X -speed=BBBB -word=8 -parity=no -stop=1 
terminal --timeout=1 serial console
timeout=5

In der mit terminal beginnenden Zeile wird Grub klargemacht, dass es zwei Konsolen gibt: serial und console. Die Angabe von timeout ist an dieser Stelle nötig, da Grub sonst bis zum Sankt Nimmerleinstag auf einen Tastendruck wartet. Erst dann – nicht der besagte Tag ist gemeint, sondern der Tastendruck – erscheint nämlich das Grub-Menü. Der timeout-Wert gibt an, wie lange auf einen Tastendruck gewartet werden soll.
Im Gegensatz dazu spezifiziert wie gehabt der alleinstehende timeout die Zeitspanne bis der Default Kernel (default) geladen wird. Etwas verwirrend meines Erachtens. Die Info-Seite besagt zudem, dass bei Angabe von zwei Konsolen wie im obigen Beispiel, diejenige gewinnt, bei der der erste Tastendruck registriert wird. Dies stimmt nicht. Man kann trotz erstem seriellen Tastendruck munter Ein- und Ausgabe der normalen Konsole weiterbenutzen.

Bei Lilo funktioniert es etwas anderes, es braucht im globalen Abschnitt in lilo.conf:

serial=X,BBBBn8

Doch Vorsicht: Bei manchen Servern, etwa einigen von Dell, kollidiert die serielle BIOS-Ausgabe mit der Boot-Lader-Umlenkung im globalen Abschnitt: Es geht immer nur eins von beiden. Die Kernel, die über die serielle Konsole erreichbar sein sollen, benötigen bei Lilo den Zusatz

append="console=tty0 console=ttySX,BBBBn8"

im Grub hinter der mit Kernel beginnenden Zeile

console=tty0 console=ttySX,BBBBn8

In beiden Beispielen ist zusätzlich als Erstes noch die Standard- Konsole tty0 angegeben, auf der auch dann die Kernel-Meldungen beim Start zu sehen sind. Die letzte angegebene Konsole wird für Ein- und Ausgabe benutzt. Unter Umständen mag es sinnvoll sein, einen Kernel für Tastatur und Monitor vorzuhalten.

Update: Bei der Verwendung von Xen gehören die o.a. Angaben der Konsole(n) entsprechend in die module-Zeile mit dem Kernel (vmlinuz-xen). Dies reicht jedoch nicht, auch hier läuft ohne den Hypervisor – normalerweise xen.gz – gar nichts. Ein Beispiel:

title XEN
    root (hd0,1)
    kernel /xen.gz com1=38400,8n1 
    module /vmlinuz-xen root=/dev/sda5 resume=/dev/sda1 console=ttyS0,38400
    module /initrd-xen

Die Angabe com1=38400,8n1 sync_console besagt, dass die erste serielle Schnittstelle mit 38400 bps, 8 Daten-, 1 Stoppbit und keine Parität konfiguriert werden soll. Der Zusatz sync_console stellt sicher, dass Ausgaben des Xen-Hypervisors synchron ausgegeben werden. Unter Umständen kann sonst die Konsole bei der asynchronen Ausgabe einfrieren.

Eine weitere Binsenwahrheit: Starten Sie ein anderes Betriebssytem via chainloader, können Sie lediglich das Ziel, worauf der Kettenlader zeigt, mit einer seriellen Konsolenumleitung konfigurieren – falls letzteres denn überhaupt möglich ist.

Grundsätzlich empfiehlt es sich, die Boot-Lader an der seriellen Konsole durch Passwörter zu sichern, um Eindringlingen nicht den Systemstart via init=/bin/bash zu ermöglichen. Mehr dazu siehe man lilo.conf(5) beziehungsweise info grub. Grub ist grundsätzlich dabei der Vorzug zu geben, da der Altvater Lilo nur Klartextpasswörter unterstützt.

Am lebenden Objekt

Da der Kernel beim Start nun weiß, wo seine serielle Konsole ist, muss man sich nur noch des seriellen Login-Prompts annehmen. Dies übernimmt ein getty. Je nach Distribution ist dies agetty oder mgetty, sodass /etc/inittab um Folgendes zu ergänzen ist:

S0:12345:respawn:/sbin/agetty -L BBBB ttySX xterm

alternativ:

S0:12345:respawn:/sbin/mgetty -r -s BBBB ttySX

Bei der Gelegenheit spätestens sollte man auch noch das obsolet gewordene grafische Login an der Konsole ausknipsen durch Anpassung des Init-Levels. Nach der Änderung der inittab ist ein init q zum Neueinlesen der Datei erforderlich. Stein des Anstoßes ist häufig die Datei /etc/ioctl.save, in denen init für den Single-User-Modus seine Terminaleinstellungen speichert. Bei bei Änderungen der Kommunikationsparameter sollte diese entfernt werden. Merke: In diesem Modus sind lediglich die weiter oben eingestellten Kernelparameter relevant. Falls Root sich im Normalbetrieb über die serielle Konsole anmelden können soll, muss in /etc/securetty zusätzlich das serielle TTY stehen (ttyS0 oder ttyS1). Soweit zur Pflichtübung der serverseitigen Konfiguration unter Linux. Ausführlicher geht das Remote Serial Console HOWTO auf diese Punkte ein.

Kür

Ist der serielle Zugang hinreichend sicher (siehe unten), kann es nicht schaden, beim Linux-Server „Magic SysRq” scharf zu schalten, denn es erlaubt das Senden von Kommandos zum (dahinsiechenden) Kernel: In /etc/sysctl.conf durch kernel.sysrq=1 oder zur Laufzeit mit sysctl --w kernel.sysrq=1. Durch die drei Tastenfolgen SysRq-[S,U,B] lässt sich der Linux-Kernel meistens noch zum sync, unmount der Dateisysteme und einem Reboot bewegen, SysRq-H gibt eine Hilfestellung, was sonst noch möglich ist. Im Gegensatz zur physikalischen Konsole (ALT-PrtSc) muss man ein anderes (Escape-)Zeichen voranstellen. Dies ist der Dokumentation des Konsolenservers oder des Terminalprogramms zu entnehmen. Wer den Kernel in so einem Fall seriell weiter untersuchen möchte, sei auf SGI's Kernel-Debugger verwiesen, der seit einiger Zeit auch nicht mehr mit dem verhängnisvollen CTRL-A, sondern mit <ESC>-KDB aufgerufen wird. Bourne-Shell-affine Admins gucken nun also nicht mehr verdutzt drein, wenn Sie auf den KDB-Prompt blicken, wo Sie doch vermeintlich den Cursor zum Zeilenanfang bewegt haben.

Syslog sei Dank

Das Erscheinen wichtiger Syslog-Meldungen auf der Konsole wie standardmäßig unter Solaris, sollte man ruhig unter Linux auch anknipsen. Dies dient nicht nur der Information, sondern ist hilfreich auch für manche Konsolenserver, die derlei Ausgaben auf Zeichenketten hin untersuchen und gegebenenfalls per SNMP-Trap und anderer Mechanismen alarmieren. Es empfiehlt sich Kernel-Warnungen und alle Fehler auszugeben, beim herkömmlichen Syslog also:

kern.warning;*.err;authpriv.none		/dev/ttyS0

Allerdings bitte schön mit Tabulatoren vor /dev (wieder einer dieser Binsenwahrheiten). Für Syslog-ng entsprechend. Dies sollte vorher genügend getestet werden, da unter Umständen der Admin die Konsole bei der Eingabe sonst seinen Wald vor lauter Bäumen nicht sieht: Beispielsweise würde die Suse-Firewall in der Standard-Installation mit Log-Level 4 (iptables -L -n | grep level), also warning (siehe syslog(2)), kräftig ihre Logs auf die Konsole pinseln. Abhelfen kann man dem mit einer numerischen (!) Erhöhung des log-level in /sbin/SuSEfirewall2 oder der Filterung dieser Meldungen beim Einsatz von Syslog-ng (was eh seit Suse 9.3 der Standard-Syslog-Dienst ist).

Vom Terminal aus installieren

Auch bei der seriellen Linux-Installation wird es dem Admin nicht ganz so kinderleicht gemacht wie unter Solaris/Sparc, die Maßnahmen sind allerdings nur etwas höher, nämlich auf Krabbelniveau: Zieht man die Rechner via PXE-Boot groß, klappt dies mittels hinzufügen einer APPEND-Option in die Konfigurationsdatei für die IP-Adresse: console=ttySX,BBBBn8. Ähnlich bei linuxrc und einer nicht-automatischen Installationen.

Abschließende Worte zur Sicherheit

So hilfreich serielle Konsolen – gleich für welche Geräte – sind: Sie setzen bei unsachgemäßer Handhabung die Sicherheit herab. Stand das Stückchen Hardware vorher im Rechenzentrum mit hoffentlich physikalischer Zugangskontrolle, ist dies nun durch ein serielles Kabel, einem Rechner mit Ethernetanschluss und einer vielleicht nicht vertrauenswürdigen Route zum Admin-Rechner ersetzt worden. Die Sicherheit angefangen vom seriellen Kabel bis zum Admin-Rechner sollte daher nicht auf dem Rücksitz Platz nehmen. Folgende Punkte gilt es daher zu beherzigen:

Wenn möglich sollte für Out-Of-Band generell ein eigenes (physikalisches) Admin-LAN her, dessen Zugang eher restriktiv gehandhabt werden soll.
Besonders für alle Fälle, in denen dies nicht möglich ist – aber gerne auch sonst – sollten Klartextprotokolle (HTTP, Telnet) zugunsten von HTTPS oder SSH vermieden werden. Für Konsolenserver-Applets, bei denen man die Wahl zwischen einer verschlüsselten und einer unverschlüsselten Verbindung hat, gilt Entsprechendes.
Der Rechner mit Ethernetanschluss sollte sicherheitstechnisch auf dem Laufenden gehalten werden. Dies gilt auch für Konsolenservern, da diese zuweilen recht haarsträubende Sicherheitsprobleme haben.
Vorsichtig wegen Session-Hijacking am Konsolenserver! Entsteht, wenn z.B. die Sitzung vom Arbeitsplatz bis zum Konsolenserver per Escape- plus Disconnect-Zeichen beendet wurde, die Admin-Sitzung vom Konsolenserver zum Knoten jedoch noch offen ist. Gegenmaßnahmen:
- keine unauthentifizerten Sitzungen am Konsolenserver erlauben
- Idle-Logout am Server oder Konsolenserver
Serverseitig gibt je nach Vertrauenswürdigkeit der Betriebsumgebung folgende Sicherheitsschalter, die man auf „on” stellen kann:
- Der Boot-Lader sollte ein Passwort verpasst bekommen wie im Text schon angesprochen (in jedem Fall eigentlich zu empfehlen).
- Abwägen, ob alles so sicher ist, dass man den DoS-Fall mittels Magic-SysRq auschließen kann.
- Wenn man's sicherer möchte, evtl. keinen direkten seriellen Zugang für Root (/etc/securetty) erlauben. Gilt nur für Runlevel ungleich Single-User-Mode.
Last but not least, hilft gerade für die jüngeren Admins eine vernünftige Policy mit Do's and Don'ts, sodass Frischlinge nicht auf die kirre Idee kommen, das Admin-LAN mit Konsolenservern und anderen Gerätschaften etwa über ein schlecht oder gar nicht verschlüsseltes WLAN von zu Hause oder gar vom Internet-Café aus zu benutzen. Aber das ist ja selbstverständlich, oder?

Copyleft 2005-2008 Dr. Wetter IT-Consulting