Nein, es geht hier nicht darum, wie man durch irgendwelche Hackertools fremde Server lahm legt. Vielmehr möchte ich hier eine kleine Sammlung von Dingen anfangen, die man möglichst NICHT auf seinem Server tun sollte, wenn man eine möglichst hohe Uptime erreichen möchte. 2 Möglichkeiten möchte ich hier bereits einmal nennen, weitere Vorschläge sind aber gern in den Kommentaren gesehen.
Eine erste, fast bereits schon klassische Variante, seinen Server zu erden ist die Konfiguration der Netzwerkschnittstellen. Nehmen wir hierzu einmal an, man hat eine Netzwerkkarte, auf der IPv4+IPv6 (eth0) konfiguriert ist und ein zweites Interface, auf dem eine Fallback-IPv4 (eth0:0) vorhanden ist. WAS sollte man nun nicht tun, um eine geänderte IP-Konfiguration zu laden:
sleep 5; ifdown eth0; ifup eth0
oder
sleep 5; ifdown eth0:0; ifup eth0:0
Diese beiden Zeilen sind beide semantisch korrekt und funktionieren bei groben Hinschauen wie erwartet … Probieren wir es also einmal aus!
Bei Ausführung der ersten Zeile, also dem Update der Konfiguration auf eth0 passiert nichts weiter. Tatsächlich geht das Interface kurz down, fährt dann aber ohne Probleme auch wieder hoch und eine eventuell vorhandene SSH-Sitzung wird nicht einmal unterbrochen, wenn man während der Ausführung kurz wartet und nichts weiter tut.
Anders sieht es hier jedoch mit dem Fallback-Interface aus. Selbst bei korrekter Konfiguration (in meinem Fall habe ich auf eth0 die IPv6-Subnetze angepasst) kann man etwas Spaß haben. Die erste Auswirkung dieses Befehls ist die Nichterreichbarkeit des Servers. Scheinbar fährt er nicht nur eth0:0 runter, sondern auch eth0. Nach dem also nach etwa 10 Sekunden kein neuer Bash-Prompt erscheint erhält man stattdessen nach etwa einer halben Minute einen Connection-Timeout seiner SSH-Sitzung. Zusätzlich informiert einen der Anbieter über das im Hintergrund angeschlossene Monitoring-System, dass der eigene Server ausgefallen ist. Gut: Hardware-Reboot und alles läuft wieder. Hätten wir also an Auswirkungen: 10 Minuten Downtime + 2 Mails vom Anbieter.
Etwas subtiler und daher problematischer ist da schon ein anderer Weg, seinen Server zur Aufgabe zu überreden. Wiir nehmen eine Sitzung mit screen sowie einen offenen mcedit. Auf der Client-Seite holen wir PuTTY in den Vollbild-Modus (hohe Bildschirm-Auflösungen eignen sich hervorragend) und gehen in den Fenstermodus von PuTTY. Je kleiner das Fenster in diesem Modus im Vergleich zum Vollbild ist, desto erfolgreicher wird nun der MC gigantische Mengen an Speicher reservieren. Typische Mengen liegen hierbei zwischen 900 MB und 1,6 GB. Zusätzlich hängt sich mcedit in einer Endlosschleife unter Nutzung einer vollständigen CPU auf. Hat man Glück, kann man noch versuchen, mit einem killall mc seinen Server zu stabilisieren … hat man Pech hilft auch hier nur ein freundlicher Hinweis an den Server, dass ein Hardware-Reboot des Systems durchzuführen ist.
Bliebe nur noch die Frage offen, welche anderen Dinge man ggf. NICHT auf einem Server ausprobieren sollte, wenn einem die Uptime lieb ist 😉
Wie währe es die Firewall Regeln auf Null zu Reseten. Ist von mir schon getestet. Funktioniert wunderbar. Ich habe das jetzt mit 2003 und 2008 Server geschafft. Sollte aber sicher auch auf Linux so machbar sein. Bei mir half da nur eine Hardware Konsole zu nutzen um die Firewall komplett zu deaktivieren oder ein neues Installieren des Systems.
Kommentar by neo — 04.09.2009 @ 16:30:18
Wie wärs mit /etc/init.d/network restart? 😉 Dies sollte einen schmerzfreien Übergang ermöglichen…
Kommentar by Peter Großöhme — 07.09.2009 @ 10:26:14