von Gert Redlich im Mai 2014 - Unsere diversen Internet-Server betreiben wir seit April 1997, erst in den eigenen Räumen in Wi-Bierstadt, dann in einer "Housing"-Lokation der Wi(esbadener)-T(ele)com, die neben den ganzen Glasfaserstrecken in Wiesbaden auch zwei große Server-Housings (Server-Keller) betreibt. - - - - - - - -

Die Internet-Server-EDV ist ziemlich komplex und die Server-Systeme für einen Internet-Betrieb sind "verkettet". Stürzt ein Glied in der Kette ab, so trifft es oft alle.

Noch im laufenden Betrieb werden die betroffenen "Bestandteile" des Betriebssytems auf der Festplatte ausgetauscht und das Ganze wird am Bildschirm genau bewacht - Fehler werden aufgeschrieben. Dann wird mit Hilfe des Hypervisors ein Häuschen (also eine VM) nach der anderen "runter gefahren" und der XEN-Server neu gestartet. Das ist alles nichts Ungewöhnliches und dauert in der Regel weniger als 1 Minute. Doch aus irgend einem Grund startet jetzt dieser (veränderte) Server nicht mehr. Und jetzt wird gesucht und repariert und recherchiert, was denn da schief gelaufen sein könnte.

Die oben drauf sitzenden VMs, also die vrtuellen Server, sind natürlich alle ebenfalls offline - also tot. Damit stehen (bei uns) bestimmte Internet-Funktionen nicht mehr zur Verfügung, die aber von den restlichen Servern dringend benötigt werden.

Weiterhin gibt es im Internet so eine ähnliche Technik wie ein Telefonbuch. "Ich sage Dir, wen ich (an)sprechen will und Du gibst mir dessen IP-Nummer." - Also ich rufe www-google-de auf und du sagst mir, welche IP-Nummer dieser Server hat - die IP-Nummer wäre dann "uuu.xxx.yyy.zzz".

Alles ganz prima. Wenn aber dieser DNS Service, (DNS steht für "domain name system") nicht verfügbar ist, kann man die Software nicht installieren, denn auf der CD wird "download.opensuse.org/xxxxx" verlangt. Dort wohnen/lagern nämlich die ganzen Software- Module, die wir dringend benötigen.
.

Und jetzt kommen wir zur "Überintelligenz" von Hardware. Die Compaq/HP Server-Entwickler sind wirklich gut, eigentlich überragend gut. Darum haben sie bestimmte Sperren (gegen Fehler bei Hektik und Stress) eingebaut. Nämlich: Wenn der Server mal stromlos - also ausgeschaltet - war, dann bekommt man ihn nur wieder zum Laufen, wenn wirklich alle seine "Eingeweide" - die Komponenten - korrekt und sauber funktionieren. Trotz meines Frustes, es macht Sinn !

Findet die Speicher- Test-Routine einen fehlerhaften RAM Streifen, geht es einfach nicht mehr weiter. Und der Server hat viele davon. Ist die Stützbatterie des RAID Controllers (ein NMH Akku) unbrauchbar geworden (überaltert), gehts auch da nicht weiter. Ist einer der Prozessor Stromwandler defekt, startet der Server auch nicht - gnadenlos.

Also muß man den Server aus dem Rack ausbauen und mitnehmen, denn Teile haben wir nur in der Werkstatt, und dort dann schnell reprieren. Zum Glück sind es nur 3km bis zu den sogenannten Kollokations-EDV-Kellern und wir können auch Nachts rein, super.
.

Es ist Freitag früh, Morgens um 8 Uhr. Jetzt kommt (Leidens-) Druck und Zeitdruck auf, weil der secondary DNS anscheinend doch nicht synchronisiert (= aktuell) war. Die Kunden können keine Mails mehr senden und/oder empfangen und ich natürlich auch nicht !!!!!! Das wird jetzt nicht nur komisch, es wird kritisch.

Also in den "secondary DNS" mal schnell rein schaun (der läuft ja noch) und die Fehler korrigieren/beseitigen. Es sind aber zu viele Fehler. Diese Lösung ist Mist. Ist aber auch kein Problem, dann eben auf dem Reserve-Server eine weitere der vorbereiteten VMs aufsetzen und den "primary DNS" dort installieren und die Sicherung einspielen, dauert in der Regel 20 Minuten. Hatte aber nicht funktioniert (diese Version der Suse Software war inzwischen nicht mehr verfügbar - Mist).

Ist dennoch immer noch kein Problem. Dann mal schnell einen unserer weiteren Reserve Sever aus dem Standby hochfahren und die DNS Software auf diesem Server installieren und das Backup rein spielen, dauert in der Regel 10 Minuten, ist vermeintlich gar kein Problem (jedenfalls theoretisch).
.

Die Compaq/HP Proliant Server haben seit Jahren einen sehr hilfreichen völlig separaten zusätzlichen Hilfs-Prozessor mit eigener Ethernet-Schnittstelle, über die man sich die Server-Tastatur und den Bildschirm bequem Nachhause ins Büro holen kann - immer, auch wenn der Server gerade im Standby "schläft" oder wenn er total abgestürzt wäre. Das funktioniert bei uns seit etwa 2007. Ich mußte ab 2007 nur noch seltenst runter in den EDV Keller und mal "aufs RESET-Knöfpchen drücken" oder die berühmte dämliche "F1 Taste" drücken.

Bei Compaq/HP heißt diese Funktion iLO = "integriertes Licht aus" System, eine sehr mächtige geniale tolle Funktion. Aber vor ein paar Tagen waren alle iLOs weg. Ich war dann am 9.4. bei meinen Servern und habe sie alle "stromlos" !!!! machen müssen (also wirklich alle runterfahren und Stecker raus), damit der (vermutlich abgeschossene) iLO Prozessor wieder online war. Kann ja nach 3 Jahren mal vorkommen - aber alle 5 Server gleichzeitig - sehr merkwürdig ???
.

Wieder Zuhause im Büro - es ist bereits 4.30 und wird gerade hell, das nächste Erwachen: Bei jeder Installation von zusätzlicher Software greift das Installationspro- gramm auf die zum System notwendigen Netzwerk-Quellen zurück. Doch die waren inzwischen vom Software-Hersteller (Novell-Suse) gekillt worden, diese Software Version würde nicht mehr unterstützt. Vor ein paar Tagen gingen die aber noch, ich habs zum Glück protokolliert. - Aber geholfen hatte es nichts. Also einen anderen laufenden Server mit einer aktuellen Suse Software ansprechen und dort auf Suse 12.3 den DHCP Server installieren und konfigurieren. Prima, hat alles geklappt.

Jetzt zurück auf die ILO Konsole des Delinquenten und hoppla, die ganzen ILOs sind ja schon wieder alle weg. Wenn man jetzt Klarheit haben möchte, was da abgeht, geht das aber nur an der echten physikalischen Konsole unten im EDV Keller. Startet man dort den Server per Netzschalter, verblüfft uns der Monitor ganz am Anfang : "ILO temporarily not available." Es ist bereits 6.oo Morgens.

Eine über Google vor Tagen gefundene Antwort zum ILO "Blackout" sagte dazu, der Server muß stromlos gemacht werden. Einen Grund für das Verhalten nennt keiner.

Nur, ich brauche diese ILO Fernsteuerung unserer Server, alles andere ist viel zu unhandlich und mühselig. Im Serverraum sind es etwa 110 Dezibel an Lüftergeräusch, wenn die Klimanalge NICHT läuft. Wenn die läuft, ist es unerträglich und man kann fast keinen vernünftigen Gedanken mehr fassen und zuende bringen.
.

Als Firewall hatte ich vor Jahren "ipcop" schätzen gelernt und war auch sofort mit der aktuellen soeben herunter geladenen und gebrannten CD an einem weiteren Reserve-Server hier im Büro. Einen 12Port Hub hatte ich auch sofort zur Hand. Also alles kein Problem, doch dann sagt ipcop 2.11 auf einmal : Dieser Chipsatz wird nicht mehr unterstützt und das wars. Es war ein Compaq DL360 G1, eigentlich mit 800 MHz völlig ausreichend für eine Firewall. Also die uralte ipcop 1.4.2 CD (aus 2007) aus dem Archiv geholt und der Firewall Server lief nach 1 Stunde. Es ist bereits Morgens um 6.oo.

Nix wie ins Auto, auch den kleinen Switch und genügend kurze Ethernet Kabel eingepackt, ist ja alles im Lager in Mengen vorhanden. Den "ipcop" Server hatte ich bereits im Büro konfiguriert mit rotem Bereich (im Internet) und grünem Bereich (im geschützen Netzwerk). Doch heute klappt gar nichts richtig - denn ganz nebenbei - das große Schiebetor vor der Zufahrt zu unseren Server-Räumen rollt zwar auf, aber die Schranke geht nicht hoch. Nun gut, es sind nur etwa 300 Meter und mit den Servern auf dem Sackkarren ist es erträglich. Runter gehts mit dem Aufzug, der geht wenigstens noch.

Server in unseren Schrank geschoben, alle Kabel gesteckt, mit der Console direkt am Server einen Test (ping) auf das Gateway (das Türchen) nach draußen und dann noch mal den google Server irgendwo draußen geprüft, alles ok. Einen weiteren dicken schweren HP DL385 Reserve-Server hatte ich ja auch noch mitgebracht (der ist recht schwer) und auch noch angeschlossen. Und wieder nach Hause gefahren.

Es war wie beim Mäusemelken, vom Büro aus konnte ich auf den Firewall-Server per https nicht zugreifen. Egal, was ich versucht hatte, es ging nicht. Also Notebook eingepackt und wieder ins Auto und ab in den EDV Keller. Der Sicherheitsdienst wollte schon wissen, ob ich da vielleicht LKW-weise Server klaue?

Vom Notebook aus konnte ich die Firewall per Webinterface konfigurieren. Die großen Server hatte ich dann unten um Keller von Hand an der physikalischen Konsole hoch gefahren, sodaß ich sie mit vom Büro aus (man nennt das bei uns per SSH-Konsole) mindestens mal administrieren konnte.

Wieder Zuhause angekommen hatte ich dann einen primary DNS Server auf dem Kunden-Server einer noch freien VM installiert und die Server mit den Kunden Webs wieder am Laufen. Auf der gleichen Maschine läuft auch der secondary DNS und den habe ich dann auch erst mal synchronisert. Damit  waren wieder mehrere halbe oder ganze Stunden rum.

Vorab muß man wissen, daß auf solch einem Server mit nur einer IP-Nummer viele verschiedene "Dienste" ansprechbar sind, und zwar über deren "Port"-Nummern. Im Handbuch der Firewall "ipcop" steht, daß die Firewall aus Sicherheitsgründen über die weitgehend ungebräuchlichen Ports 81 und 445 administriert wird. Das wäre für uns wie ein Kanadischer Indianer Dialekt bei den Genfer Verhandlungen über die Krim mit den Russen und Chinesen. -

Also weiter: Mit meinem Notebook direkt am Switch im EDV-Keller hatte es ja funktioniert. Der sogenannte Ping auf die IP-Nummer des Servers funktioniert auch vom Büro aus, also ist der Server am Leben und eigentlich ok. Doch die Fritzbox bei uns im Büro blockt diese ungebräuchlichen IP-Ports, wie ich dann zur Kenntnis nehmen mußte, - aber ohne mich zu fragen und ohne mir auch im Fritz-Box Expertenmodus die Möglichkeit der Freischaltung bzw. Öffnung anzubieten. Also kann ich vom Büro aus diese Firewall nicht administrieren - ganz grosser Mist.

Habe dann im Netz gesucht nach Tricks, die Fritzbox für diese Ports 81 und 445 zu öffnen. Suchzeit ca. 2 Std mit 2 DIN A 4 Seiten an Tips und Tricks. Nur ist die dort genannte "ar7.cfg" Konfigurations-Datei in der Fritzbox schreibgeschützt. - auch Mist. Insgesamt waren das dann weitere 4 Stunden ohne brauchbares Ergebnis - mit einer Ausnahme - ich weiß jetzt ziemlich genau, was alles NICHT !!! funktioniert.

Dann - der Tag war inzwischen (unerfolgreich) fast rum, es wurde bereits dunkel - einen Freund (auch EDV Administrator) kontaktiert und das Problem geschildert, er würde mir gerne helfen, wenn ich ihm als Firewall einen ganz simplen Suse Server mit zwei Netzwerkkarten und mit Version 13.1 bereitstelle.
.

Und wieder einen Server aus dem Regal geholt, einen DL 360 G2 sogar mit ILO drinnen. Meine Suse 13.1 NET CD stockt gleich am Anfang und sagt mir, das ist ja nur eine 32 Bit CPU, die mag ich nicht. Nun gut, also "mal schnell" die 32 Bit NET Variante von SUSE 13.1 herunter laden, doch ausgerechnet zu der Zeit war das alles sehr sehr lahm, und dann eine CD gebrannt. - Und auch sofort ans Installieren gegangen. Für die minimale opensuse Text-Version brauchte er an diesem Abend geschlagende 2 Stunden, sonst weniger als 15 Minuten .....

Mit allen Tricks meines Freundes konnte ich nach vielen Stunden des Nachts um 2.oo wieder auf die ILO Schnittstellen aller 5 Server zugreifen, denn der vermutlich Java-Web Client nutzt anscheinend ein JAVA Applet, das nur mit "plain" IP-Nummern arbeitet, also nicht mit angehängten Ergänzungen wie der Portnummer. Die eigentlich gängige Port-Weiterleitung (oder Umleitung) in der Firewall funktioniert somit für diese ILOs hier bei uns auch nicht - wieder eine Erfahrung mehr - Mist !
.