Konsolenserver: Know-How zum OOB und Vergleichstest von sieben Topmodellen
Dies ist die erweiterte Fassung eines in dem Fachmagazin iX (8/2005) veröffentlichen Konsolenserver-Vergleichstests. Beachten Sie bitte das Copyright; das Recht zur Wiederveröffentlichung, auch auszugsweise, nur mit Genehmigung der Rechteinhaber.Wir sind beratend als technischer Dienstleister u.a. im OOB-/Konsolenserver--Umfeld tätig. Falls Sie also wissen wollen, welches der richtige Konsolenserver für Sie ist oder mit welcher Lösung Sie am besten all Ihre Konsolenserver managen, gerne an. Ein paar weitergehende technische Infos finden Sie unter http://oob.drwetter.org.
Außer Rand und Band
Dr. Wetter IT-Consulting
Konsolenserver erfreuen sich vor allen Dingen in Rechenzentren hoher Beliebtheit, um eine hohe Verfügbarkeit und Administrierbarkeit elementarer Komponenten zu garantieren. Der Markt ist interessant wie heiß umkämpft. Als ob diese Spannung nicht schon reichen würde: Die Themen GPL und Sicherheit der Appliances fachen – wie dieser Artikel zeigt – zu Recht das Spannungsfeuer noch mehr an. Verfeinert ist das Ganze mit einer Prise Know-How rund ums Thema Out-Of-Band-Management.
|
| Abb. 1 (oben) und 2 (unten): Cyclades Alterpath ACS32 2PSU, Digi CM48 Dual AC, Avocent CCM 4850, MRV In-Reach LX-8040S-102AC, Raritan Dominion SX 32, Lantronix SLC 3222N, Logical SCS 480R (von oben nach unten) |
|
Wer kennt das nicht: Das hoffentlich vorhandene
Monitorprogramm oder schlimmer ein Benutzer meldet
die Nicht-Verfügbarkeit eines Dienstes auf einer
Unix-Maschine. Die Einwahl enthüllt, dass In-Band
– übers Ethernet – kein Lebenszeichen dem
ach-so-wichtigen Server mehr zu entlocken
ist. Dann gilt es, ins Rechenzentrum zu sputen,
sich ans angeschlossene Terminal zu setzen oder
schnell vorher ein solches zu
organisieren. Schlecht, wenn der Verantwortliche
gerade zuvor seinem Tiefschlaf in 10 km
Entfernung frönte. Wenn dann noch die Anreise
umsonst war, weil der dicke Server „lediglich” nach
einem Absturz gerade mit dem POST oder einem
fsck über ein Terabyte großes Dateisystem seine
Zeit vertrödelte, sollte der Aufschrei in
fruchtbare Bahnen gelenkt werden.
Out-Of-Band-Lösungen – darunter fallen alle aus
der Ferne zu bedienende Lösungen, die „am Ende”
nicht das In-Band-Ethernet benutzen – können in
diesem leider noch zu häufig anzutreffendem
Szenario für Abhilfe sorgen, so denn der Server
(wie SunFire-, Blade- oder große IA64-Server)
nicht von Haus aus einen Managementzugang via
Ethernet hat. Wie die in [1] vorgestellten
KVM-over-IP-Lösungen sind Konsolenserver die
ausführende Hand der Out-Of-Band-Systeme. Sie
ermöglichen die Bedienung verschiedener Geräte
über deren serielle Schnittstellen, was Sie
prädestiniert für Fernwartungen sowie allgemeine
Administrationsaufgaben aus der Ferne,
nötigenfalls von jedem Platz der Welt aus, sofern
der Verantwortliche über seinen hoffentlich
sicheren Zugang die Ethernetschnittstelle – oder
bei manchen Geräten das Modem des Konsolenservers
erreicht. In schwerwiegenden Fällen lässt sich mit
den in Mode gekommenen – Stichwort Remote
Powermanagement – per IP oder seriell
schaltbaren Steckdosenleisten (Powerstrips) der
Strom des Sorgenkinds einzeln ein- und
ausschalten.
Und nicht zuletzt: Durch überflüssige Terminals oder Monitore lässt sich in beengten Rechenzentren einiges an kostbarem Platz einsparen.
Anschluss gesucht
Prädestiniert für Konsolenserver ist alles mit einer seriellen Schnittstelle: Risc-/Intel-Server unter Unix, Netzwerkequipment wie Switches/Router, Loadbalancer/Firewalls, im Storage-Bereich SAN-Switches, RAID-Systeme sowie USVs, TK-Anlagen, Klimageräte und vieles mehr. Nicht vergessen werden sollte, die seriellen Konsolen von Konsolenserver selber anzuschließen. Bei der Redmond-Fraktion bietet erst Windows 2003 mit dem „Emergency Management Port” eine SAC „Special Administration Console”, andere Windows-Versionen sind mit KVM-over-IP-Lösungen besser bedient. Im Vergleich sind die Bandbreitenansprüche serieller Konsolen geringer und lassen sich sogar nötigenfalls via GPRS-Einwahl bedienen. Als Dreingabe bieten Konsolenserver vielfach zeichenkettenbasiertes Monitoring und Alarmierung, falls beispielsweise eine Sparc „ok” auf die Konsole pinselt oder sich dort beschwert, dass ein Dateisystem oder Swap voll ist. Missbraucht man nicht gerade einen Desktop-PC als Server, mag meistens sogar das BIOS seriell kommunizieren. Neben einer Session mit Lese-/Schreibzugriff ist das Mitlesen – also ein nur-Lesezugriff – Standard.Hart rangenommen
Die Testumgebung im Firmenlabor des Autors sollte einen Konsolenserver nicht vor unlösbare Aufgaben stellen: Als Hardware stand ein Cisco-Catalyst-Switch, ein Server-PC und ein Ultra-Sparcserver zur Verfügung, der die heutzutage übliche Break-Festigkeit („Solaris Ready”) verifizieren sollte. Zum Hintergrund: Bestimmte Sparcs (wie SGIs) missinterpretieren fatalerweise bei einem Stromausfall eines Konsolenservers die Signalkurve auf den 12V-Zweigen der RS 232 als Befehl, sich in den „ok”-Prompt zu begeben. Glücklicherweise passiert dies nicht mehr bei allen Sparcs bzw. bei neueren Solaris-Versionen kann ein Patch dem abhelfen. Im Test sollte bei Exemplaren mit zwei Netzteilen das Steckerziehen eines Stromzweiges einen Stromausfall simulieren und sich bemerkbar machen. Ein kompletter Stromausfall sollte den Kandidaten danach wieder sauber hochkommen lassen, was selbstverständlich erscheint: Es gibt zwar ein jffs (Journal-basiertes Flash-Dateisystem), dies oder andere Journal-basiertes Dateisysteme verwenden jedoch nicht alle. Der Stromausfall wurde mindestens 10mal simuliert. Außerdem harrten für Modelle mit PCMCIA-Slot drei PCMCIA-Karten (CF-Adapter, 3Com-Modem- und Linksys-Ethernetkarte) ihres Einsatzes.Softwareseitig stellte das Labor folgende Randbedingungen bereit: Feste und bei Bedarf dynamische IP-Adressen konnten via DHCP vergeben werden. Aufgrund der Rückverfolgung von Ereignissen sollte ein NTP-Server konfigurierbar sein und das Syslog des Konsolenservers zur weiteren Behandlung auf einen zentralen Server weitergeleitet werden. Ein lokaler Benutzer sollte Zugriff auf zwei Ports bekommen. Als Kür stand ein LDAPv3-Server inklusive normalem SSL und TLS-Upgrade-Option im Labor bereit, um weitere Testbenutzer zu authentifizieren. Die in meistens größeren Netzen vorhanden Authentifizierungsverfahren wie TACACS+ oder RADIUS blieben mangels Zeitmangel bei der Untersuchung außen vor. NIS wird zwar hie und da von Konsolenservern unterstützt, ist aber aufgrund schlechter Sicherheit – ypcat -d {NIS-Domain} passwd gibt die via schwachem DES verschlüsselten Passwörter Preis – für die Authentifizierung von Konsolenserverbenutzern ungeeignet.
Sicher lebt's sich am Besten
Remote-Powermanagement, KVM-Over-IP sowie der Konsolen-Service sollten in einer kontrollierten Umgebung – ein dediziertes physikalisches Admin-Netz – betrieben werden. Anderenfalls droht ein GAU, wenn ein Unbefugter durch vergessene Root- oder Admin-Sitzungen am seriellen Zweig des Konsolenservers Herr über einen Server, Router, einer USV oder gar einer schaltbaren Steckdosenleiste wird.Da diese Randbedingung wegen mangelnder Möglichkeit oder schlimmstenfalls aufgrund Nachlässigkeit nicht immer gegeben sind – wenn man weiß, wonach und wie man suchen soll, findet man gar Konsolenserver im Internet via Google – lag ein besonderes Augenmerk auf der Sicherheit der Konsolenserver. Erscheinen die Konsolen als offene Telnet-Ports oder gar drüberhinaus ohne Authentifizierung, gab es Punktabzug. Standard heutzutage ist ein authentifizierter wie verschlüsselter Zugang per SSH(v2). Aus ähnlichen Gründen sind nicht SSL-verschlüsselte Webserver beziehungsweise im Klartext kommunizierende Applets sowie Telnet-Admin-Zugänge zum Konsolenserver eine Sünde. Ist nur der Default schlecht, d.h. der Hersteller hat nur den falschen Kompromiss zwischen Sicherheit und bequemer Inbetriebnahme/Administration geschlossen – schwächte es das negative Urteil nicht entscheidend ab.
Verhängnisvoll sind ererbte Root-Sitzungen. Diese lassen sich in den Griff bekommen, indem grundsätzlich eine Port-Authentifizierung vorgegeben wird. Ein Idle-Logout des Ports am Konsolenserver oder beim angeschlossenen Endgerät kann zusätzlich helfen.
Weitere Labor-Versuche beschränkten sich auf Stichproben, darunter die Untersuchung von SNMP-Monitoring und SNMP-Traps.
Nacheinander aufgereiht
Die proprietären Betriebssysteme anfänglicher Generationen von Konsolenserver wie Xyplex Maxserver, Cisco 2511 und Lantronix SCS 3200 sind Linux-basierten Lösungen gewichen, verspricht dies doch vereinfachte Entwicklungsarbeiten aufgrund offener Quellen, besonders bei sonst nicht ganz trivialen Zusatzfeatures wie Firewall, PCMCIA oder Modems. Die Quellen für die Geschmacksrichtungen des auserkorenen „embedded Linux” müssen lediglich angepasst werden. Den Admin beglückts, dass die Funktionsweise des Gerätes auf der Kommandozeile – so denn vorhanden – transparenter und die Einarbeitung leichter ist. Sonderwünsche kann man selber mit (Cross-)Entwicklungsumgebungen für den Konsolenserver nachkommen.Ein brandheißes wie leider häufig vernachlässigtes Thema für Appliance-Hersteller mit Linux-Herz: Die Beachtung GNU-Copyrights. Die Erfahrungen des Autors sind dem Kasten Copyleft zu entnehmen.
Angefangen hat der Linux-Boom bei den Konsolenservern vor ein paar Jahren, als die Firma Cyclades ihre ersten Exemplare der TS-Serie ins Rennen schickte. Jedoch bläst diesen mittlerweile etwas der Wind ins Gesicht, da viele neue Geräte wie Hersteller auf der Bildfläche erschienen sind, die gerne ein Stück vom Linux-Konsolenserver-Kuchen abbeißen wollen. Sieben Linux-betriebene Topmodelle (siehe auch Tabelle) bilden das Testfeld. Kleinere Lösungen – es bieten einige Firmen 16, 8-, 4- oder gar 1-Port-Lösungen an – mussten draußen bleiben. Angetreten sind: Cyclades Alterpath ACS 32 2PSU, Digi CM 48 Dual AC, Logicals SCS 480R, Lantronix SLC 3222N, der MRV LX-8040S-102AC, Raritan Dominion SX 32 und der Avocent CCM 4850. Bis auf die letzten beiden Kandidaten hatten alle Testgeräte redundante Netzteile, einige erreichten die Redaktion gar mit zwei Ethernetschnittstellen und „doppelter” Konsole.
Thinklogical SCS 480R
Thinklogical firmiert nun als ausgegliederte Abteilung von Logical Solutions. Lantronix Aufkauf 2001 von Lightwave USA hatte zur Folge, dass ein Teil der Ex-Lightwave-Beschäftigten nach einigen Verwicklungen mit der neuen Mutter sich abnabelten und Logical in den USA gründeten. Das Gerät versteht sich nicht als Alleskönner wie die von Cyclades oder Digi. Thinklogical hat KVM-over-IP-Geräte im Portfolio, interessanterweise auch solche, die DVI-Signale über Glasfaser transferieren.Das Gerät offenbart sich als eine kleine Überraschung in vielfacher Hinsicht: Nur der SSH-Port ist offen nach Inbetriebnahme per vorgegebener fester IP oder per Konsole, ein Zugriff via Telnet ist nicht vorgesehen. Nach Quickstart-Anleitung dient netconfig als Shell-Kommandozeile von Root zur Konfiguration der Netzparameter, timeconfig zur Einstellung der Systemzeit und authconfig für Authentifizierungsparameter, was größtenteils problemlos funktionierte. Wer ein Déjà-vu vermutet, liegt richtig: Dies sind die alten Werkzeuge im Ncurses-Look von Red Hat. Tatsächlich läuft auch auf dem Konsolenserver ein altes Red Hat-Linux mit eigenen RPMs und solchen aus dem Fedora-Legacy-Projekt. Anders als all die anderen Testkandidaten hat der SCS kein echtes embedded Linux mit busybox als wesentlichen Teil. Sogar nmap befindet sich auf dem SCS, aus Sicherheitsgründen sollte dies allerdings dort nichts verloren haben. Als Herz dient eine kleine mit 66 Millionen Schlägen pro Sekunde tickende AMD-Elan-CPU ohne Lüfter. So simpel und schön das Konzept ist, so sehr werden wahrscheinlich eher unerfahrene Admins bei komplexeren Aufgaben mit der nackten Kommandozeile überfordert sein. Kurz vor Ende des Test kam seitens des Herstellers die Nachricht, dass linuxconf als Web-GUI verfügbar ist. In der ab sofort ausgelieferten Produktionsversion fände die Kommunikation ausschließlich per SSL statt. Red Hat-gemäß übernahm nach Anknipsen vom dhclient dieser die via DHCP-Optionen übergebenen NTP-Server, lediglich ein chkconfig ntpd on fehlte noch. Das Handbuch legt lobenswerterweise auch die Aktivierung von NTP nahe, nebst der Änderung des Root-Passwortes und der Empfehlung, Benutzerkonten anzulegen und via sshd_config das Anmelden von Root zu verhindern.
Bei der Portkonfiguration helfen unter dem erwachsenen Linux man 1 lsi oder man 8 lsi. Mit dem Portmonitor pm kann man Kommunikationsproblemen kabeltechnischer oder softwareseitiger Art auf die Schliche kommen. pm gibt gegebenfalls sogar Empfehlungen. Das Einrichten eines lokalen Benutzers in einem Rutsch samt Portzugriffsrechte geschah problemlos via adduser.
Ein wenig hakelte die LDAP-Unterstützung: Obwohl per authconfig befohlen und richtig eingetragen, mochte der SCS nur ohne ssl start_tls-Option oder ssl on in ldap.conf mit dem LDAP-Server sprechen, was bedeutet, dass zwischen diesem und dem als LDAP-Client funktionierenden Konsolenserver das Passwort im Klartext über die Leitung geht. Eine weitere nötige Korrektur: sshd_config musste der Tester durch Auskommentieren von UsePAM ändern zur Honorierung der PAM-Konfiguration des LDAP-Clients. Weitere Stolpersteine: /etc/pam.d/system-auth benötigte in einer account-Zeile des Moduls pam_ldap zusätzlich ein authinfo_unavail=ignore, sonst war kein „Reinkommen” mehr, wenn der LDAP-Server nicht erreichbar war. Für Fälle, wo gar nichts mehr geht, wäre eine Möglichkeit zur Werksrückstellungen erforderlich, was schlicht fehlt.
Zu LDAP gibt die Dokumentation nichts her, diese nimmt nur den NIS-geneigten Administrator an die Hand, unter anderem in puncto Zugriffsberechtigungen auf die Ports: Es erfordert (ähnlich wie beim SecureLinx-Server) beim NIS- Server eine YP-Map namens port_access, die auf dem Client via einem einzufügenden NSS (Name Service Switch) angesprochen wird. Für LDAP ist mit ein wenig Handarbeit sicherlich ähnliches mit LDAP-Gruppen und Schemadateien auf dem Server möglich, jedoch umhüllt den Hersteller da ein Schweigen.
Schade, dass das Handbuch – im PDF-Format auf der CD – knapp gehalten ist. Perlen wie LDAP-, Kerberos- oder gar RADIUS-Authentifizierung schlummern so total im Verborgenen, und die von Kernel- und Anwendungsseite unterstützte Linux-Firewall fristet ein Schattendasein. Ebenso die Dial-in-Unterstützung, obwohl das Handbuch gleichzeitig für die Sentinel-Reihe mit internem Modem gilt und sogar ein PPP-RPM installiert ist. Ein externes Modem müsste sich an dem getesteten Exemplar mit etwas Handarbeit betreiben lassen.
Das System-Logging ist vorbildlich: Nicht nur Standard-Unix-Ereignisse werden mitprotokolliert, ebenso Verbindungsauf- und -abbbau zu den Ports und gesendete Breaks. Ebenso gab der SCS sich vorbildlich bei Ziehen eines Netzsteckers: Das weitergeleitete Systemlog auf dem zentralen Logserver meldete brav „Left Power Supply Failed” und später „Left Power Supply Restore”. Als einziges Gerät im Testfeld sind die Netzteile sogar im Betrieb austauschbar.
Die Stärke des SCS 480R ist seine grundsolide wie in seiner Einfachheit schöne Hardware und die Linux-Basis. Das Preis-/Port-Verhältnis ist attraktiv. Der SCS zielt nicht auf Kunden, die auf eine Appliance mit einem durchdachten GUI oder einem alles konfigurierenden „Wizard” aus sind, sondern eher auf solche, die einen einfach gehaltenen, sicheren Server – so versteht die Firma Ihr Produkt – haben wollen und „für mehr” einen fähigen Linux-Admin auf der Gehaltsliste stehen haben.
Lantronix SLC 3222N
Das Exemplar der getestete SecureLinx-Serie ist erst seit einem Jahr am Markt. Ein Gerät der ActiveLinx-Baureihe, ebenfalls Linux-betrieben, stand nicht zum Test zur Verfügung. Den technischen Randdaten des Herstellers zu Folge scheinen die ActiveLinx-Geräte „etwas weniger zu können”: PCMCIA-Slots fehlen wie Kerberos- und TACACS+-Authentifizierung. Tatsächlich erinnern das Äußere, der Namenskürzel SCS und die technischen Eckdaten ein wenig an das Gerät von Logical.Der SLC hat ein gefälliges Äußeres und ist neben dem SCS 480R eins der beiden Geräte im Testfeld mit einem zweizeiligen LCD nebst Cursortasten zur Bedienung. Die grobe Inbetriebnahme kann in beiden Fällen sogar mit den Cursortasten erfolgen, falls keine serielle Konsole vorhanden ist. Im Labor bekam der SLC seine IP-Adresse via DHCP und seinen initialen Grobschliff nach dem erstmaligen Anmelden mit SSH, was automatisch ein ASCII-basiertes „Quick Setup” startete. Nach Einstellen der IP-Parameter und der Zeitzone bat der Schnellstarter erfreulicherweise um Änderung des voreingestellten Passwortes. Lobenswerterweise sind per Default nur sichere Protokolle erlaubt wie HTTPS und SSH. Obwohl im SLC ein Linux-Herz schlägt, gibt es keinen Weg, einen Linux-Shell-Zugang zu bekommen. Administratoren mit einem Fetisch für die Kommandozeile müssen so Vorlieb nehmen mit einem proprietären Kommandozeilen-UI, was trotzdem logisch zu bedienen ist und eine ganz passable Hilfe hat. Der Webserver kann ebenso mit einer Online-Hilfe glänzen.
Lantronix' SLC 3222N erkannte die Modem- und den CF-Card-Adapter, nicht die Linksys-PCMCIA-Karte. Laut Hersteller wären die On-Board-Ethernet-Karten genug des Guten.
Ein wenig Tadel: Der SLC mochte sich – via Web-Browser befohlen – nicht an den vorkonfigurierten NTP-Server wenden, da dessen Eintrag veraltet war. Mit einer händisch eingetragenen IP-Adresse funktionierte es. Eine Alarmierung bei Erkennung einer vorzugebenden Zeichenkette am angeschlossenen Konsolenport ist nur via E-Mail möglich.
Ein Minuspunkt ist beim Lantronix das System-Logging des Konsolenservers: Syslogs lassen sich nur interaktiv per E-Mail weiterleiten oder via Web-Browser oder auf der Lantronix-Kommandozeile anschauen. Eine Unix-gemäße Syslog-Weiterleitung an einen Server ist nicht vorgesehen. Das einzige, was in Echtzeit über Zustände informiert, sind SNMP-Traps, die aus dem Grund ruhig aktiviert werden sollten. Unverständlicherweise schlugen diese nicht Alarm beim simulierten Stromausfall eines Netzteils, wohl aber beim Anmelden eines Benutzers auf der Konsole oder einem Port des Konsolenservers.
Der Versuch zur Authentifizierung eines Benutzers über LDAP geriet zum Hürdenlauf: Der eingetragene LDAP-Server war angeblich nicht erreichbar, was sich mittels eines eingebauten Diagnoseprogramms falsifizieren ließ. Mithören im Netz enthüllte, dass der SLC 3222N trotz anderer Konfiguration darauf bestand, eine LDAP-Verbindung zu 108.100.97.112 aufzubauen, eine von der IANA reservierte IP-Adresse und kein „hidden back channel” wie in einer Schrecksekunde vermutet: Der Konsolenserver mag sich nur nicht-anonym an einen LDAP-Server binden, übermittelt daher bei jedem bind Authentifizierungen für zwei Benutzerkonten.
Erfreulicherweise ist der Port-Status im Konfigurationsmenü eines Ports einsehbar, was hilft, falschen Kabeln oder Adaptern auf die Schliche zu kommen, wobei wie üblich der Status der seriellen Leitungen RTS, CTS, DTR und DSR angezeigt wird.
Die Ports selber sind standardmäßig weder per SSH/Telnet direkt von außen erreichbar. Wird dies anders befohlen, steht nur ein unauthentifizierter Telnet/SSH-Zugang auf die Ports bereit. Ein Idle-Logout ist konfigurierbar, aber nicht standardmäßig scharfgeschaltet. Das Senden von Breaksignalen funktioniert leider nicht via direktem SSH/Telnet auf den Port, sondern nur nach interaktivem Anmelden mit nachfolgendem connect-Kommando.
Schade nur, dass auf das darunter liegende Linux nicht zugegriffen werden kann, was eventuell nötigen Feinschliff – beispielsweise beim Syslogging – der sonst relativ durchdachten Appliance verhindert. Ein dickes Sicherheitsloch offenbarte sich beim SLC: Aus dem Netz sind die privaten SSH-Hostkeys und Log-Dateien über den Webserver erhältlich, wodurch SSH ad absurdum geführt wird und Systemzustände nicht nur des Servers selber sondern auch u.U. angeschlossener Komponenten einsehbar sind. Schade außerdem, dass der Zugriff zum Linux verschlossen bleibt, was eventuell nötigen Feinschliff – beispielsweise beim Syslogging – der sonst durchdacht wirkenden Appliance verhindert.
MRV In-Reach LX-8040S
Obwohl 1988 gegründet, betrat MRV erst mit dem Aufkauf von iTouch, vormals nBase-Xyplex, vormals Xyplex, die Welt der Konsolenserver. Wer die alten Maxserver von Xyplex kennt, wird trotz der offensichtlichen Unterschiede hie und da Ähnlichkeiten zu den neueren In-Reach-Modellen entdecken. Kenner werden feststellen, dass das alte Systempasswort ab Werk noch dasgleiche ist.Beim Auspacken und erstmaligen Anschließen vertieft sich der Großvater-Sohn-Eindruck: Der MRV verzichtet auf Ein-/Ausschalter für die beiden Netzteile, eine Bohrung harrt des Resets durch eine Büroklammer, die dann gemäß einem POST ein bestimmtes Leuchtmuster in der Reihe der LEDs auslöst.
Erfreulicherweise ist eine Fülle elektronischer Dokumentation mitgeliefert: „Getting Started” hat ganze 73 und der Configuration Guide 369 Seiten. Die CD scheint mehr für „Acrobat-phile” erstellt worden zu sein (Acrobat Reader 4 ist dabei): Das Hauptmenü ist ein PDF-Dokument, baumartig weiterverzweigt geht's per PDF-Links. kpdf von KDE 3.4.x verschluckte sich ab und zu an den in den PDF-Dateien vorhandenen Querverweisen, acroread in der Version 7 hatte unter Linux keinen Schluckauf. Das Handicap: Aus den Dateinamen à la 4510324a.pdf lässt sich nicht ableiten, ob das Dokument in Kyrillisch oder Hanzi oder gar für ein anderes Produkt ist. Für zusätzliche, den Inhalt reflektierende Dateinamen, ist auf der CD noch reichlich Platz.
Die grundlegende Konfiguration der Netzparameter findet per ASCII-Menü über den eigenen Konsolenport statt, alternativ erfragt der MRV via BOOTP/DHCP oder RARP seine initialen Daten. Zum folgenden Feinschliff dient entweder die proprietäre Kommandozeile oder ein Java-Applet, was wahlweise verschlüsselt oder unverschlüsselt mit dem MRV kommuniziert. Beides ist recht komfortabel. Die Kommandozeile funktioniert bis auf die nicht erlaubten Kürzel wie bei Cisco's IOS. Den Benutzern, denen es gestattet ist, können das darunter liegende Linux durch das Kommando shell einen Root-Prompt auf den Bildschirm bekommen.
Das Applet gibt sich übersichtlich und kann im Vergleich zum ähnlich Feature-reichen Cyclades fast sämtliche Funktionen bedienen. Im Rahmen des Tests erforderte nur die Syslog-Konfiguration einen manuellen Eingriff per Linux-Prompt, was den LX 8040 dazu bewegte, den simulierten Ausfall eines Netzteils sowie sämtliche Systemereignisse auf dem Syslog-Server kundzutun. SNMP-Traps – mit dem Applet konfiguriert – beschwerten sich ebenfalls über den Stromzweigausfall.
Nach ein wenig Log-Dateien-Satz-Lesen beim LDAP-Server und nachfolgender Anpassung funktionierte die LDAP-Anbindung. Leider nur mittels LDAPv2 und ohne Verschlüsselung.
Der Zugriff auf die seriellen Ports erfolgt entweder per Applet oder von „Außen” via Telnet oder SSH. Das Applet kann auch intern ohne weitere Authentifizierung mit diesen Protokollen eine Verbindung zum gewünschten Port herstellen. Die zwei Wermutstropfen: Unsichere Protokolle wie Telnet für Admin-Konsole sowie Ports sind per Default neben SSH scharfgeschaltet. Anders als bei den Konkurrenten existiert kein einsehbarer Datenpuffer für die seriellen Ports.
Die Vorgabe eines NTP-Servers klappte problemlos, ebenso ließ sich ein lokaler Benutzer einrichten. Ein Bug: Gab der Autor einem Benutzer Zugriff via SSH-Keys, konnte dieser auch auf Ports, für die er nicht zugelassen war, zugreifen.
Eine zunächst nervige Eigenschaft des MRV war die Tatsache, dass die TCP-Verbindung zum Server unterbrochen wird, wenn der Carrier auf der seriellen Verbindung beispielsweise bei Neustart eines Knotens kurzfristig weg war: Per Default ist für jeden Port „AutoHangup” angeknipst. Vorbildlich ist die Port-Status-Dialogbox, mit deren Hilfe man Verbindungsproblemen auf den seriellen Leitungen einfach auf die Schliche kommt. Traps oder Nachrichten lassen sich bei Statusänderungen versenden. Die Konsole des Cisco-Switches mit RJ45-Buchse mochte weder mit dem mitgelieferten noch anderen Kabeln aus dem Labor ein Zeichen von sich geben. Beim Hersteller war dies mit einem anderen MRV-Gerät und Cisco-Switch nicht reproduzierbar.
Unterm Strich: Ein einfach bedienbarer Konsolenserver mit vielen Features, stimmig zusammengehalten mit einem durchdachten GUI und Kommandozeile. Getrübt war das Bild durch den de-facto fehlenden Datenpuffer, die Klartextprotokolle als Default und den SSH-Key-Bug.
Cyclades Alterpath ACS 32 2PSU
Der kleine Bruder des Alterpath – der ACS 16 – kam vor zwei Jahren in einem Einzeltest in der iX [2] unter die Testlupe.Beim Blick auf das Aufmacherfoto oben fällt im Vergleich zu den anderen Geräten auf, dass die Vorderfront keine Betriebs- und Zustandsleuchten hat. Die optische Musik des robust wirkenden Cyclades spielt nur auf der Rückseite.
Die initiale Installation geht einfach von der Administratorhand. Im Labor geschah dies über die eigene Konsole und Aufruf von wiz, was die Netzparameter einstellt.
Das Resultat des obligatorischen Portscans entfachte keine Begeisterungsstürme: Neben SSH und HTTPS sind unverschlüsselte Protokolle – Telnet, HTTP, sowie Telnet auf alle 32 Ports – per Default verfügbar. Schlimmer: Der Portzugriff erfolgt ab Werk ohne Authentifizierung und hat kein Idle-Logout, was den ACS prädestiniert für ererbte Root-Sitzungen. Es empfiehlt sich als Erstes, dies mit dem Browser gerade zuziehen (alternativ: all.authtype in /etc/portslave/pslave.conf von none in local ändern). Einer Anfrage des Autors beantwortete Cyclades mit einen deren Aussage zufolge in neueren Versionen der Firmware vorhandenen Sicherheitsschalter („secure/legacy/expert”) und einer Änderung des Quickstart-Guide mit Sicherheitshinweisen. Der Default stände jedoch bis zum Redaktionsschluss auf „legacy” mit den alten Vorgaben. Obwohl vorgesehen existiert kein /etc/shadow auf dem ACS. Die DES-verschlüsselten Passwörter sind in /etc/passwd von eingerichteten Ottonormalbenutzer, der problemlos einzurichten war, einsehbar.
Auf der Sonnenseite kann der ACS kann mit einer Vielzahl Features glänzen wie das auf FreeS/WAN basierende VPN (ohne X.509-Patch), dass neben iptables per Browser konfigurierbar ist. Wer die über „lokal” hinausgehende Authentifizierungsmechnismen, Verwendung von analogen oder ISDN-Modems, GSM-Karten-Konfiguration und anderen Schmankerl nicht mit dem GUI arbeiten will, kann hierfür und für andere Feinarbeiten die Linux-Kommandozeile benutzen. Dabei gut unter die Arme greifen kann der 300 Seiten dicke „Console Server Reference Guide” auf der beiliegenden CDROM.
Das GUI erlaubte im Test nur die Weiterleitung von lokalen Systemereignissen. Die Kommandozeile offenbarte erfreulicherweise die Verwendung von syslog-ng, was mit ein paar zusätzlichen Zeilen versehen dem ACS die Weiterleitung von allen Ereignissen beibrachte. Auf den simulierten Netzteilausfall eines Zweiges reagierte der ACS mit einem Eintrag ins Remote-Syslog und – als einziges Gerät – mit einem lauten akustischen Signal. Cyclades unterstützt syslog-ng dahingehend, Ereignisse via SNMP-Traps, E-Mail oder Pager weiterzuleiten. Eine händische Konfiguration der SNMP-Traps setzt die Eingabe von OIDs und Nachrichten voraus, vorgefertigte OIDs zur Anbindung ans Enterprise-Management existieren nicht. Ein SNMP-Agent läuft per Default, ihm muss jedoch per GUI auf die Sprünge geholfen werden. Ein Schmankerl: Der ACS scheint die von Windows 2003 EMS gesendeten XML-Tags via syslog-ng zu unterstützen. Eine Unterstützung für Cyclades serielle Steckdosenleisten (AlterPath PM) ist integriert.
Die Einrichtung des NTP-Servers gelang problemlos mit dem Browser. Nachhilfe benötigte die Einstellung der Zeitzone in /etc/TIMEZONE mit der Shell. Wer ob der im Referenzhandbuch erwähnten Notation verständlicherweise nicht gleich der richtige Wert aus den Fingern geglitten kommt, sei auf die hilfreiche FAQ von Cyclades verwiesen.
Cyclades GUI ließ Wünsche offen: Konquerors (KDE 3.4.x) Sitzung fand häufig ein unsanftes Ende, wenn der Tester vom Wizard- in den Expertenmodus wechseln wollte. Firefox und Mozilla gerieten außer Tritt, wenn die Klicks zu schnell kamen. Auch in puncto Geometrie hätte sich das Web-GUI etwas weiter aus dem kleinen Fenster lehnen können: Zieht man den Rahmen ab, bleibt der entscheidende Teil trotz großem Browser-Fenster in einer Luke mit 612x362 Punkten verborgen, was bei langen Menüs der Bedienbarkeit und Übersicht nicht zuträglich ist.
Der ACS unterstützt einen ganzen Zoo an PCMCIA-Karten. Alle drei Testkarten wurden korrekt erkannt, das FAT32-Dateisystem der CF-Karte sogar automatisch eingehängt.
Unterm Strich: Ein vielseitiger Konsolenserver mit Potenzial. Nachbesserungsbedarf besteht bei den Schwächen des Webservers und den zu laxen Sicherheitseinstellungen, die Klartextprotokolle und vergessene Root-Sitzungen ab Werk erlauben.
Digi CM 48 Dual AC
Die Inbetriebnahme des Digi geschieht exklusiv via Konsole, inoffiziell hatte der CM 48 eine IP-Adresse vorgegeben. configmenu harrt denn auf der Kommandozeile der Eingabe der Netzparameter. Die restliche Konfiguration des Digi kann entweder weiter damit oder wie im Test geschehen mit einem Web-GUI erfolgen.Wie beim Cyclades offenbarte sich ein Session-Problem mit Konqueror unter KDE 3.4: Der Webserver konfrontierte den Tester häufig mit „Connection to host [..] is broken”. Firefox/Mozilla taten es anstandslos, so beispielsweise bei der NTP-Serverkonfiguration. Trotz Vorgabe der Zeitzone CEST erwartete der Digi noch ein Offset zu UTC.
Wie beim Lantronix aus der SecureLinux-Serie ist beim CM48 die Systemprotokollierung verbesserungsbedürftig: Das Ziehen eines der beiden Netzstecker findet sich zwar als roter Balken auf der Webadmin-Oberfläche wieder, aber nicht im System-Log, ebenso wenig wie irgendwelche Systemereignisse vom Kernel oder Dämonen. Der verwendete Syslog-Dämon unterstützt keine /etc/syslog.conf. Mitgeschrieben werden beispielsweise Anmeldeversuche via Weboberfläche oder damit durchgeführte Änderungen der Konfiguration und erfolgte Verbindungen auf die Ports. Das Scharfschalten von SNMP-Traps verschaffte Linderung: Der Ausfall eines Netzteils wird signalisiert, Anmeldeversuche und den seriellen Port-Status kann man beim Digi ebenfalls etwas mit SNMP-Traps kompensieren: Sie informieren drüber, ob man ein Kabel korrekt angestöpselt oder gerade abgezogen hat. Ein- und Ausgaben der Konsolenports lassen sich in vollem Umfang an den Syslog-Server weiterleiten. Das Mitschreiben ist generell mit Vorsicht zu genießen: Bei Eingaben beispielsweise befinden sich hier drin Passwörter im Klartext, bei Ausgaben unter Umständen WEP-Schlüssel, die beim Start des Knotens ein iwconfig anzeigt.
Positiv im Handbuch zu vermerken ist die Beschreibung von Inbetriebnahme und Funktionen der SAC für Windows 2003. Das Web-GUI bietet sogar für kommandozeilenphobe Knöpfe für „ON / Reboot / Shutdown”, das serielle Menü eines hierzulande nicht erhältlichen Baytech-Powerstrips kann der CM 48 ebenso bedienen. Weitere Testfreuden: Firmware-Upgrade und Konfigurationsmanagement sind bequem via Web möglich, ähnlich beim Lantronix.
Das Anlegen eines lokalen Benutzers und dessen Authentifizierung klappten problemlos im Gegensatz zum LDAP-Testbenutzer. Obwohl richtig eingetragen – das Handbuch leistet keinen Beistand dabei – war auf dem Draht zwischen Konsolen- und LDAP-Server kein LDAP-Paket beim Anmelden des LDAP-Benutzers zu erschnüffeln. Selbst mit einem gerüttelt Maß an Systemerfahrung ist ohne UNIX-gemäßes Systemlogging die Fehlersuche auf der Clientseite eher ein Ratespiel.
Vorsicht ist angebracht bei den ab Werk verfügbaren Sicherheitseinstellungen des Digi: Die Klartextprotokolle Telnet und HTTP sind auch hier zum Administrieren verfügbar. Telnet auf die angeschlossenen Ports geht allerdings nicht ohne Login und Passwort. Ein SNMP-Agent lauscht, harrt aber wie beim Cyclades einer initialen Konfiguration und könnte deswegen von vornherein ebenso abgeschaltet sein.
Eine ganze Latte von PCMCIA-Karten unterstützt der Digi, insofern funktionierten die drei Testexemplare anstandslos. Selbst WLAN-Karten mit dem toten Verschlüsselungsstandard WEP lassen sich einsetzen. Eine Warnung im Handbuch, die vor dieser Fahrlässigkeit im Data Center warnt, wäre wünschenswert. Dies gilt auch für den ACS von Cyclades.
Hardwareseitig stellt das Pin-Layout der RJ45-Buchsen eine Besonderheit dar: Zum Cisco und zu einer Sun-Netra genügt ein CAT5-Patchkabel. Ein Lüfter, wenn auch leise, sorgt im Digi für die nötige Frischluftzufuhr. Wer deshalb skeptisch ob der Lebensdauer des CMs ist: Digi gewährt eine Garantie von 5 Jahren.
Fast ähnlich dem Cyclades bietet der Digi eine Menge Funktionen an. Das GUI ist übersichtlich strukturiert. Allerdings könnte die Sicherheit ab Werk sowie die Systemprotokollierung besser sein.
Avocent CCM 4850
Avocent ist eine relativ junge Firma, die aus der Symbiose von Apex und Cybex hervorgegangen ist. 2001 übernahm Avocent dann Equinox, die eher in den USA bekannt sind für ihre Konsolenserverlösungen, nicht zuletzt dank Unterstützung von IBM.Obwohl mit zwei relativ lauten Lüftern bestückt, entfleuchte dem Autor beim Auspacken und Inbetriebnahme ein kleines „Aha”: Laut Anleitung sollte der Avocent eine 10/100/1000-Ethernetkarte haben. Die für Konsolenserver ungewöhnliche 1000MBit/s-Anbindung tat er nach Einstecken in einen Gigabit-Switch durch eine orange Status-LED kund. Unglücklicherweise gab es bei der Inbetriebnahme ein paar Hürden: Wie sich nach ein wenig Wanzenjagd herausstellte, war der Avocent vorkonfiguriert mit IP-Adresse und Passwort, sodass der Avocent gar keine IP-Adresse mehr vom DHCP-Server erfragen wollte und das Anmelden via serieller Konsole misslang. Die Büroklammer (siehe unten) half.
Zur initialen IP-Adresskonfiguration dient BOOTP. Nach einem Reset verhielt sich der BOOTP-Client etwas widerspenstig: Obwohl er eine Adresse übergeben bekam, war die Konfiguration unvollständig: Netzmaske und Defaultroute waren nicht gesetzt. Eine Korrektur von Hand und ein always-reply-rfc1048 on in der /etc/dhcpd.conf vom ISC-DHCP-Server half dem CCM auf die Sprünge – im Handbuch steht nichts dazu. Über bootp vergebenen IP-Einstellungen überstehen das Ein- und Ausschalten ebenso wie ein server init config auf der Kommandozeile. Lediglich ein Reset via Büroklammer oder ein server init all bewegen den CCM dazu, sich eine neue BOOTP-Konfiguration vom DHCP-Server zu holen – und alles andere zu vergessen.
Zum weiteren Schliff existieren zwei Methoden: Eine (proprietäre) Kommandozeile oder AVWorks, eine Java-basierte Software. Avocent liefert bei Bedarf ein alte JRE-Version mit. Während des Tests fiel die Wahl auf die Kommandozeile, die den Wunsch nach einem Einfügemodus und mehr als 16 Zeilen History-Puffer offen ließ. Händisch sollte zunächst der leider per Default eingeschaltete Administrationszugang via Telnet gegen SSH ausgetauscht werden. Das gleiche gilt für die seriellen Ports. Beides ließ sich leicht mit zwei Kommandos bewerkstelligen. Ebenso ging die Konfiguration eines Zeitservers glatt vonstatten, anders lässt sich leider die Zeit nicht stellen. Es kommt kein echter NTP-Dämon zum Einsatz, sondern der CCM befragt in vielfachen Werten einer Stunde ein NTP-Server. Unabhängig davon, lässt sich die Zeitzone nicht stellen: Die Uhr tickt immer in UTC.
Unix-Systemlogging kennt der Avocent nicht, nur mittels SNMP-Traps gibt der Avocent Meldungen von sich. Diese sollten allerdings sorgsam freigeschaltet werden: Gleichzeitig wird der SNMP-Agent angeknipst, der von Haus aus keine ACLs hat und per default eine „public-write community” hat und daher potenziell Systemveränderungen ohne Passwort erlaubt. snmptrapd hat eine Reihe Ereignisse vordefiniert, wie Login in den CCM oder auf einen Port. Schön wäre, wenn er noch einen fehlenden Carrier am RJ45-Port bemerken würde. Avocent lieferte, wie anderswo üblich, keine MIBs mit, sondern verweist auf die eigene Webseite. Diese vermochten jedoch die OIDs nicht mit ASCII-Leben zu füllen. Schade, das der CCM kein UNIX-gemäßes Syslogging oder eine Weiterleitung kennt. Eine LDAP-Authentifizierung gibt es erst in der extra zu bezahlenden Software DSView, die weitere Funktionen bietet, ähnlich dem AlterPath Manager von Cyclades (siehe Kasten).
Ein lokaler Benutzer ließ sich problemlos einrichten. Jedoch konnte dieser auch auf Ports zugreifen, auf denen es ihm nicht gestattet sein sollte, wenn er sich denn zunächst per SSH beim Konsolenserver für eine interaktive Sitzung authentifiziert hatte und danach connect {meine-verbotene-Portnummer} eingab. Direkt per ssh userid@avocent -p portoffset, sah er sich korrekt mit einer Zugriffsverweigerung konfrontiert.
Sieht man mal von der entdeckten Sicherheitslücke und dem Default-Protokoll Telnet ab, kann der Avocent mit einem Kampfpreis aufwarten, für den man allerdings keinen Featureprotz erwarten sollte. Das Java-GUI hinterließ beim kurzen Test einen positiven Eindruck.
Raritan Dominion SX 32
Wie der Avocent hat der Raritan Dominion SX Lüfter, die vergleichbar laut den alten Catalyst-Switches (2900/3500) von Cisco sind. Das Gehäuse hinterlässt einen stabilen Eindruck. Der DSX 48 – das Topmodell mit zwei Ethernet-Schnittstellen und Netzteilen – hat es nicht zur Redaktion zum Test geschafft.Die sogar in Deutsch erhältliche Dokumentation ist mit 159 DIN A4 Seiten relativ ausführlich und einfach verständlich. Ein kleiner Wermutstropfen: Manchmal sträubte sich der Übersetzer zu sehr gegen bereits eingedeutschte Begriffe aus dem Englischen. Auf der anderen Seite schmerzt die Beugung „gedownloadet” doch sehr. Ein Schlagwortverzeichnis fehlte. Die englischsprachige Ausgabe der Dokumentation liefert der Web-Server des Dominion fast vollständig beim Klick aufs Fragezeichen aus.
Die Inbetriebnahme des Dominion geschieht über eine feste IP-Adresse mit einem Web-Browser, der per HTTP direct vom HTTPS-Port ein im Browserfenster laufendes Java-Applet lädt, womit die initialen Einstellungen (IP, Root-Zugang) vorgenommen werden. Gleichzeitig generiert der Dominion ein (selbst-unterschriebenes) Zertifikat für den HTTPS-Port. CSRs und eigene (Signing-)CAs unterstützt der Dominion ebenfalls. Dies alles, sowie die Tatsache, dass per Default Telnet grundsätzlich abgeschaltet ist, hinterlässt zunächst einen sicherheitsbewussten Eindruck der Entwicklungsabteilung. Auch wird beim Anlegen von Benutzerkonten die Stärke des Passwortes überprüft.
Leider war das von Verisign signierte Applet für den Portzugriff seit drei Monaten nicht mehr gültig und der SX kam ein wenig mit der Zeit – obwohl via NTP vorgegeben – durcheinander, sodass die Gültigkeit der Appletsignatur zur Konfiguration des Konsolenservers einen Tag in der Zukunft lag. Eine kleine Sünde: Das Handbuch erwähnt für direkten Portzugriff eine URL (HTTPS), die Passwort und Benutzernamen enthält. Es warnt zwar davor, diese URL nicht auf einer Webseite zu platzieren. Das derlei GET-Request noch woanders auftauchen (Server- oder Proxy-Log-Datei, Browser-History, eventuell Bookmark) schien die Entwicklungsabteilung vergessen zu haben.
Eine wirkliche Sünde sind zwei Bugs, auf die der Autor im Labor gestoßen ist: Ein unauthentifizierter Shellzugriff via ssh zum zum Linux des Konsolenservers. Vorgesehen beim Dominion ist nur ein Zugriff auf die (proprietäre) Kommandozeile. Zwei Benutzer (sshd und dominion) hatten keine Passwörter und sind „geschützt” durch das Kommando „exit” in .profile. Das zweite Krabbeltier: /etc/shadow ist auf diese Art lesbar, das Busybox-Binary und der Linux-Kernel ist gar schreibbar aus dem Netz heraus. Auf Hinweisen des Autors hin gab es zunächst einen teilweisen Fix, der einen, dann einen weiteren, der beide offenen Benutzerkonten schützt.
Die für die Konfiguration von Funktionen wie SNMP-Traps oder das Weiterleiten der Port-Log-Dateien via NFS obligatorische Kommandozeile nimmt es genau: Eine verkürzte Eingabe à la IOS oder eine Ergänzung mit Tabs funktioniert nicht, sie kennt keine History-Funktion und keinen Einfügemodus. Für SNMP-Traps stehen eine Anzahl vordefinierter Ereignisse zur Verfügung, weitere lassen sich mittels der Skriptsprache TCL ergänzen. Der Bug des unbeabsichtigten Zugriffs bot das Feature einer Systemanalyse, die enthüllte, dass kein snmpd lief und diesem die Konfigurationsdatei am richtigen Platz fehlte.
Eine Möglichkeit zur Syslog-Weiterleitung ist vorhanden: Das im Handbuch unterm Tisch gefallene Kommando cfglog kann Syslogs lokal in eine Datei schreiben als auch an andere Server senden. Leider betrift dies wieder nur die „Facility” local. Kernel-, Dämon- oder Authentifizierungsmeldungen bleiben ähnlich wie beim Digi das Geheimnis des syslogd.
Der LDAP-Client im Dominion kann sich nur in LDAPv2 und mit einem authentifizierten Bind mit einem LDAP-Server unterhalten. Nach entsprechenden Vorkehrungen am v3-Server scheiterte allerdings immer noch die Authentifizierung eines LDAP-Benutzers mittels Applet.
Wie bei den Geräten von Avocent, Digi, Cyclades und MRV unterstützt der Dominion schaltbare Steckdosenleisten der eigenen Firma, die verdächtig ähnlich den in den USA erhältlichen Baytech „powerstrips” sind.
Unterm Strich bleibt wegen der kritischen Bugs ein etwas bitterer Geschmack zurück, obwohl die Appliance anders als ihre Konkurrenten mit guten Sicherheitseinstellungen ab Werk dienen kann.
Fazit
In puncto Sicherheit hinterlässt der Vergleichstest der Appliances höflich ausgedrückt gemischte Gefühle beim Autor. Vier nicht zuvor entdeckte sicherheitsrelevante Bugs (siehe auch Blog) in drei Appliances ohne echte „Pentests” sind keine gute Statistik. Zusätzlich sind zu viele per Default verfügbare Klartextprotokolle, Telnet-Ports, die eines unauthentifizierten Zugriffs harren, eine nicht positive Bilanz für Geräte, die einen Administratorzugang für andere meistens für die IT-Infrastruktur wichtige Knoten bieten sollen.
|
| Abb. 3: Tabelle Linux-Konsolenserver |
Eine ebenso wenig erfreuliche Bilanz für die freie
Softwaregemeinde: Die GPL oder ein ein gedruckter
Hinweis hierauf – ein Teil des GNU-Copyrights –
waren nur bei zwei Herstellern zu finden. Ein Dritter
wurde im Laufe des Tests GPL-konform.
Von den weiteren Herstellern kam bis zum Redaktionsschluss ein
halbwegs glaubwürdiges Bekenntnis, dass man der
GPL alsbald möglich gerecht würde, was zumindest
als ein kleiner Erfolg verbucht werden kann.
Manche Hersteller lehnen sich mit den
angepriesenen Features etwas aus dem Fenster. Eine
LDAP-Authentifizierung, so wie
Otto-Unix-Systemadministrator es erwarten würde,
funktionierte nur teilweise und war stellenweise
schlecht dokumentiert.
Der Lärm der in drei von sieben Geräten
vorhandenen Lüfter ist aufgrund des Einsatzzwecks
sicherlich zweitrangig. Potenziell setzt die
Verwendung eines nicht ausfallsicheren Lüfters
allerdings die Verfügbarkeit herab.
Das Testfeld ist relativ breit aufgestellt im
Hinblick auf das Preis-/Port-Verhältnis
(50-113 €). Was die Auswahl einfach macht:
Nicht alle Hersteller lassen sich Ihren
Funktionsreichtum, so man ihn denn benötigt, mit
barer Münze bezahlen (siehe Tabelle). Nach so viel
Schatten gibt es also auch etwas Licht.
Literatur
[1] Axel Urbanski, KVM Over IP: Zehn Geräte im Vergleich; Allein zu Haus, iX 4/2005, S.48[2] Dirk Wetter, Cyclades Alterpath, Powered by Penguins, iX 4/2003, S.58
iX-TRACT
- Konsolenserver erhöhen die Verfügbarkeit und Administrierbarkeit von Unix-Servern, Netzwerkequipment und vieles mehr.
- Fast alle der derzeit verfügbaren Lösungen am Markt sind Linux-basiert.
- Preis-/Port-Verhältnis, Benutzerfreundlichkeit und Sicherheitseinstellungen ab Werk differieren dramatisch.
- Für große Umgebungen existieren eine Reihe Managementlösungen, die alle Out-Of-Band-Geräte unter einem Dach administrieren hilft.
Copyleft
Einige Hersteller schienen vergessen zu haben, dass GNU-Software trotz ihrer „Freiheit” eine einzuhaltene Lizenz hat und dass diese – wenn auch relativ schmerzfreie – Bedingungen beinhaltet, unter denen die Software verwendet werden darf. Wie zuletzt der Fall Fortinet unterstrich, ist die Einhaltung der GPL in Deutschland rechtlich einklagbar.Nun ist es nicht das Ziel, Hersteller an die Wand zu nageln. Die freie Softwaregemeinschaft möchte schließlich, dass ihre Software verwendet wird, allerdings unter Einhaltung der freien Rahmenbedingungen, unter der sie programmiert haben. Darüber hinaus soll Aufmerksamkeit und ein Bewusstsein für GNU-Software und für die GPL geschaffen werden.
Im Wesentlichen sind für Hersteller drei Punkte zu berücksichtigen: Es muss ersichtlich sein, dass Sie die Software verwenden und welcher Teil der GPL unterliegt. Sie müssen eine Kopie der GPL in irgendeiner Form der Appliance beilegen; was die Ersichtlichkeit angeht, freuen sich die GNU-Softwareentwickler, wenn an der Stelle, wo Warenzeichen und andere Softwarelizenzbedingungen im Handbuch erwähnt sind, passenderweise auch das GNU-Copyright erwähnt ist. Schließlich muss ein schriftliches Angebot beiliegen, wo die Quellen erhältlich sind. Die Dokumentations-CD oder die Firmenwebseite bietet sich dafür an. Eine Stolperfalle für Hersteller: Bei Updates, die GNU-Software enthält, muss auch der Quellcode des Updates bereitgehalten werden. Der Quellcode ist wichtig, da die GPL die Freiheit vorsieht, selbst Änderungen am GPL unterliegenden Werk vornehmen zu können und Verbesserungen zurückfließen zu lassen. Soweit zu den Randbedingungen.
Vor diesem Hintergrund fand die Untersuchung der Einhaltung der GPL statt.
Das zunächst Erschreckende: Obwohl alle Konsolenserver Linux nebst anderer GPL-Software verwenden, befanden sich nur von zwei Herstellern Hinweise hierauf in der Dokumentation, siehe Kasten. Die restlichen fünf Hersteller wurden höflich angeschrieben, meistens über den deutschen Vertrieb. Es kam jedoch nicht von allen bis zum Redaktionsschluss eine zufriedenstellende Antwort zurück.
MRV reagierte äußerst prompt: Am nächsten Tag kam von der Chefin der Entwicklungsabteilung aus Boston der Dank für den hilfreichen Hinweis mit der Aussage, dass MRV bald doe verlangte Lizenz beilegen und über deren Webseite die Software erhältlich sein wird.
Die Firma Avocent ließ sich nur wenig länger Zeit. Ebenso sind hier die Hinweise des Autors auf fruchtbaren Boden gefallen und sie baldige Besserung gelobten, so dass die Handbücher neugedruckt werden und ein Hinweis auf der Homepage erscheint.
Nachdem Digi der richtige Ansprechpartner gefunden wurde, war es dort auch nur eine Frage von wenigen Tagen, bis Sie sich dazu mündlich verpflichteten, der Verfügungsstellung der Sourcen nachzukommen und die GPL in Ihre Dokumentation künftig einzuarbeiten.
Cyclades hat das Problem vorab erkannt, obwohl die deutsche Vertretung dies nicht mitbekam: Ab 2005 befindet sich auf der CD zumindest die GPL, die Quellen sind via Web erhältlich. Zu Missverständnissen führte die Tatsache, dass der Autor noch eine alte CD hatte und Cyclades am längsten für eine Antwort brauchte und mehr als viermal kontaktiert werden musste.
Bei Raritan dauerte es 3 Anläufe, ehe per E-Mail zurückkam, dass Sie den Prozess gestartet haben, GPL Komponenten in all Ihren Linux-basierten Produkten zu identifizieren und Notizen und Informationen hinzuzufügen wie Zugriff auf die Quellen.
Die Lippenbekenntnisse per E-Mail müssten in naher Zukunft auf ihre Umsetzung überprüft werden. Bei Lantronix und Logical, die den ersten beiden Punkte gerecht wurden, steht wie bei allen anderen dann noch der Versuch aus, an die GNU-Quellen zu kommen.
Großes Band oder kleines
Hat man mehr als eine Handvoll Konsolenserver, möchte man nicht allen Administratoren Zugriff auf alle Ports geben, oder man ist es leid, mit einer langen Liste von Zuordnungen von Portnummern zu Maschinennamen sowie Benutzeraccounts zu hantieren, fängt das Systemmanagement an, Kopfschmerzen zu bereiten. Abgesehen von den von verschiedenen Herstellern angebotenen eingebauten Clustermöglichkeiten verschaffen Konsolenservermangementlösungen Linderung. Dieses Scrabbleweltrekord-verdächtige Wort manifestiert sich entweder als ein Stückchen Software auf einer bereitzustellenden Hardware der Wahl oder als Appliance.conserver: Schnell zum Ziel
Die zwei prominentesten Software-Vertreter: conserver und CLIM von Ki Networks. Ersteres ist ein Stück freier Software, letztes kostet Geld. Beide benötigen einen Rechner zur Installation der Software. Die Pakete unterscheiden sich darüberhinaus in puncto Leistungsumfang: conserver ist eine einfache, robuste Lösung, die dazu dient, auf verschiedenen Konsolenservern Benutzer oder Benutzergruppen nebst derer Zugriffsrecht auf Ports zu verwalten. Es bietet Logging der Konsolen, zusätzliches Mitlesen der Ein- und Ausgaben in einer Read-Only-Session, natürlich wird auch SSH zu den Ports unterstützt.
CLIM: Teurere Features mit GUI
CLIM (Command Line Interface Manager) ist eher ein Featureprotz: Es konfiguriert gar Konsolenserver, es bietet ein GUI (Ki Works) für sämtliche Konfigurationsaufgaben wie zum Zugriff auf Ports. Hardware für CLIM kann redundant ausgelegt werden, bietet Event-Notification verschiedener Art (SNMP-Traps, E-Mail, GUI-Popup) mit sinnvollen vordefinierten Zeichenketten, es archiviert bei Wunsch Log-Dateien. Nette Features sind wie bei Suns Cluster Console das „Gang Connect”. Auch einige KVM-over-IP-Geräte und schaltbare Steckdosenleisten unterstützt CLIM und ist daher anders als die Management-Appliances von Raritan (Command Center), Cyclades (Alterpath Manager) oder Lantronix (SecureLinx Management Appliance) nicht beschränkt auf deren eigene Hardware.
Wie sich diese Geräte und CLIM gegeneinander behaupten und inwieweit all diese Fremdstandards wie IPMI, Suns LOM, HP-ILO und Dells DRAC zu unterstützen, bleibt einer weiteren Untersuchung vorbehalten.
Dies gibt es alles nicht umsonst, die Preise sind recht happig. So ist einer von CLIMs Wermutstropfen sein Preis, der mit 250 € zu Buche schlägt, pro Knoten am Konsolenserver. Zudem waren in der Vergangenheit die Release-Zyklen zuweilen recht willkürlich.
Der Praxisteil ist auch in der UpTimes veröffentlicht.