Es war einmal vor langer Zeit ein Server-Betreiber in einem fernen Land im Norden Frankreichs. Dieser bot für einen fairen Preis Server für seine Kunden an. Dies ging eine ganze Weile so, bis dieser Anbieter eines Tages beschloss, sein Angebot zu ändern. Daraufhin beschlossen einige seiner Kunden, ihr bisheriges Angebot vor dieser Umstellung noch durch eine leistungsstärkere Alternative auszutauschen, was auch ohne Größere Probleme ging: Kaum wurde das neue Angebot bestellt, folgte 2 Tage später bereits die Lieferung – natürlich frisch aus neuen Einzelteilen zusammengebaut!
Und so begab es sich, das ein mutiger Server-Admin eines Tages eben diesen Umtausch vornehmen wollte und nach der Bestellung seines neuen Migrations-RPS3 auch bereit für diesen wagemutigen Schritt war. Das Versprechen des Händlers lautete ungefähr 5 Minuten Downtime; da dachte sich der Admin „das ist verkraftbar“ und betätigte nach längerem Suchen in seinem ManagerV3 den mit „Jetzt migrieren“ beschrifteten Knopf in der Weboberfläche, nach dem er sorgfältig die neue physische Maschine als Ziel dieser Operation auserkohren hatte.
Und so nahm das Schicksal seinen Lauf: Nach gerade einmal 2 Minuten begann die Migration, nachdem alles korrekt initialisiert worden war. Nach weiteren viereinhalb Minuten war gar der Systemtest der neuen Maschine abgeschlossen! Und so war der mutige Admin frohem Gemütes, dass er seinen Server in näherer Zukunft wieder in Empfang nehmen könne …
Doch daraus wurde so schnell nichts! Das Herunterfahren seines treuen alten Servers benötigte fast 10 Minuten und so beschloss der Admin, erst einmal eine Pause in Form von Frühstück einzulegen – immerhin war es bereits halb 12 blendender Zeit – und der Admin war gerade frisch aufgestanden. Nach weiteren 5 Minuten des Wartens erblickte der Admin Fortschritt. In leuchtenden Buchstaben verkündete der ManagerV3, dass die Migration Erfolgreich abgeschlossen sei und auch die obligatorischen pings auf diverse, für diesen Vorgang relevante IPs deuteten darauf hin, dass der neue Server nun einsatzbereit sei.
Doch weit gefehlt: Das Migrationstool beschloss bei Abschluss des Umzugs, dass es den treuen Server des mutigen Admins doch gerne in frischer Installation erblicken möchte und versetzte das System in den Reinstall-Modus, anstatt wie üblich das System sauber zu booten. Auch das Ändern der Netboot-Option für seinen treuen Server wollte der ManagerV3 nicht Folge leisten: Diese Operation sei im aktuellen Systemzustand leider nicht möglich.
Dies – zusammen mit der Tatsache, dass der hungrige Admin sein Frühstück fertig zubereitet hatte – sorgte somit vorerst für eine kleine Verschnaufpause. Denn mit leerem Magen telefoniert es sich schlecht mit dem Support. Somit ergab sich vorerst eine mehr oder weniger erzwungene Pause, nach deren Abschluss der nun gesättigte Admin beim Support des Händlers anrief.
Dort erklärte er nun in aller Ruhe sein Problem, was vom zuständigen Techniker auch sofort durch Einwahl in das System bestätigt wurde mit der Auskunft, dass der Server nicht – wie vom mutigen Admin bis hierher angenommen – im normalen, sondern im Reinstall-Rescuemode war und es daher gut war, dass er sich gemeldet hat. Der Techniker entfernte daraufhin nun sofort den Reinstall-Modus und bat den mutigen Admin darum, das System nun über die Oberfläche normal hochzufahren, was dank eh bereits geschehenem Login in wenigen Augenblicken erledigt war. Zusätzlich führte der mutige Admin wie angewiesen einen Reboot aus, um diese neue Konfiguration zu aktivieren.
Der treue Server des Admins bootete nun wieder wie gewünscht, auch wenn es zuerst fast 2 Minuten dauerte, bis irgendwelche Ports des Servers als offen gemeldet wurden, was u.a. an der recht umfangreichen und vielseitigen Konfiguration des treuen Servers lag.
Nachdem auch der Admin wieder auf seinen – nun auf frische Hardware umgezogenen – Server zugreifen konnte, stellte der Admin noch eine letzte Frage, die IP-Konfiguration betreffend: Wie ändert man die Default-IP mit der sich der Server gegenüber der Außenwelt zeigt? Auch hierauf erhielt der wissbegierige Admin prompt eine Antwort: Nach Abgleich der Email-Adresse versendete der Techniker prompt eine Mail an unseren mutigen Admin, in der ein Link enthalten war. Dieser Link zeigte auf das Forum des Händlers, in dem verschiedene andere Kunden bereits eine ähnliche Frage gehabt hatten und es ein recht wirksames Script gab, dass genau die von unserem mutigen Admin zu erledigende Aufgabe bewältigte:
#! /usr/bin/perl
$IP1 = `ifconfig eth0`;
if ($IP1 =~ /(Adresse|addr):(\d+\.\d+\.\d+\.\d+)/im) {$IP1 = $2;} else { $IP1 = ""; }
$IP2 = `ifconfig eth0:0`;
if ($IP2 =~ /(Adresse|addr):(\d+\.\d+\.\d+\.\d+)/im) {$IP2 = $2;} else { $IP2 = ""; }
print "IP #1: $IP1\n";
print "IP #2: $IP2\n";
if (!$IP1 || !$IP2) { print "IP Konfiguration ist nicht wie erwartet => EXIT!\n\n"; exit 1; }
$route = `ip route show | grep default`; chomp ($route);
print "route: $route\n\n";
if ($route =~ /src\s+$IP2/im)
{
print "=> Als Source IP ist bereit IP #2 ($IP2) konfiguriert!\n\n";
print "folgender Befehl kann verwendet werden, um $IP1 als Source-IP festzulegen:\n";
$route =~ s/\s+src\s+$IP2//im;
print "ip route change $route\n\n";
}
else
{
# print "folgender Befehl kann verwendet werden, um $IP2 als source-IP festzulegen:\n";
print "Konfiguriere nun $IP2 als Source-IP:\n";
print `ip route change $route src $IP2\n\n`;
print `ip route show`;
}
Nach einer kurzen Ergänzung eines Aufrufs dieses Scripts in /etc/rc.local
/sbin/change-outgoing-ip.pl >> /var/log/outgoing-ip.log
vor dem abschließenden
exit 0
war der Admin nun beruhigt, dass endlich einer seiner Kollegen nicht mehr über den Reversename-Mismatch seines Mailservers rummeckern wird.
Blieb nur noch die Aufgabe über, die 17 Domains auf die neue IP-KKonfiguration anzupassen, was aber dank der flinken Finger unseres Admins in wenigen Minuten erledigt war. Und auch die Dienste, die sich bisher dem Starten verweigern wollten, wurden von unserem geliebten Admin kurzerhand zum Funktionieren verdonnert. Denn nicht funktionierende Services werden von unserem Admin nicht geduldet, was sich auch entsprechend unter den bisher widerwilligen Diensten rumsprach, weshalb die notwendige Überzeugungsarbeit auf ein Minimum beschränkt bleiben konnte.
Und so lebte der mutige Admin glücklich und zufrieden bis zum nächsten Problem mit seinem treuen Server.
Was für eine Aktion – war dir da nicht manchmal bisschen mulmig während des Vorgangs? Das Schärfste wär doch gewesen, wenn die Neu-Installation wirklich durchgeführt worden wäre… das hätte dir eine Menge Spaß bereitet. 😀 Wie schauts mit der neuen Hardware aus? 😉
Kommentar by Peter Großöhme — 27.08.2009 @ 19:29:32
LOL Wieder mal Spaß gehabt mit deinem Server? Und wenn meinst du mit dieser Andeutung Betreff EMail?
Kommentar by neo — 28.08.2009 @ 14:25:34
Ja, wen werd ich wohl meinen 😛
Und ja: Ich hatte echt Spaß mit’m Server, jetzt wo alles soweit geht und die Performance merklich besser geworden ist. Gab nur eine kurze Nachwirkung, die aber inzwischen auch abgeklungen sein dürfte (Musste paar Domains umziehen auf andre IPs, was bei einer Domain gegen den Cache gelaufen ist 🙁 ).
Kommentar by BenBE — 28.08.2009 @ 14:36:01
Mit Spaß bei der Sache. Und du weist es doch, es geht immer etwas schief. Ich habe noch keinen Server Umzug gesehen der wirklich 100%ig ohne Probleme verlaufen ist.
Kommentar by neo — 01.09.2009 @ 12:54:45