Untertitel: Was man bei einem Serverumzug alles erleben kann. - Das fing schon damit an, daß ich beim bisherigen Webhoster nichts gefunden habe, was auch nur ansatzweise den Ansprüchen genügt hätte. Jaja, genug Plattenplatz, Inklusivdomains, Traffic "Unlimited", ... bloß, ich brauche keine 10 Inklusivdomains (ich ziehe sowieso meine eigenen Nameserver vor), Plattenplatz ist sekundär, und nach den ersten 1000 GB dann alle 300 GB auf ein Knöpfchen drücken zu müssen, um die Netzwerkschnittstelle von 10 wieder zurück auf 100 MBit zu stellen, ist mindestens äußerst nervig.
Naja, und daß es nur 2 IP-Adressen pro Maschine gibt, ist auf die Dauer eine lästige Einschränkung.
=> Hosterwechsel.
- Dann wollte ich auf der Kiste, wie von Firma und altem Forumsserver gewohnt, eine Trennung der verschiedenen Bereiche durchführen: Forum, Datenbank, Achims Sachen, meine Sachen, alles in getrennten Containern ("vserver"), mit linux-vserver.
Was soll ich sagen, linux-vserver war mit der Kernelversion auf der Maschine nicht dazu zu bewegen, stabil zu laufen.
Und da insgesamt die Situation rund um linux-vserver etwas unschön ist, bin ich dann auf lxc umgestiegen.
- Was, natürlich, auch wieder einige Überraschungen mit sich brachte. Eine ist, daß es ein Programm namens lxc-attach gibt, mit dem man theoretisch einen Prozess im Kontext eines Containers ausführen lassen kann. Praktisch kann man nicht, weil das irgendwelche Kernelpatches erfordert, die im Standardkernel nicht drin sind. Naja, es gibt Umwege.
- lxc-create / lxc-ubuntu, die Programme zum Einrichten eines ubuntu-Linux-Containers, erfordern manuelles Nachflicken. Das, was da installiert und konfiguriert wird, ist so jedenfalls nicht direkt lauffähig.
Und wie man einen ubuntu-10.10-Container zum Laufen bekommt, habe ich bis heute nicht heraus.
Nicht daß das wichtig wäre - ich wollte in den meisten Containern sowieso lieber 10.04 haben (nicht weil ich glaube, den 5-Jahres-Support wirklich zu brauchen - das Forum neigt ja doch dazu, deutlich früher nach neuer Hardware zu verlangen - sondern weil ich schon mal ein paar Probleme mit Updates unter Ubuntu hatte (kleineres Zeug, zugegeben), aber nicht einmal bei einem LTS-Release.
- Ich hab' erwartet gehabt, eine ähnliche interne Netzwerkkonfiguration für die vserver (NAT/Masquerading, Bridging) zum Laufen zu bekommen. Kurz gesagt: War nicht. Auf der positiven Seite: Jetzt ist es verständlicher.
Da hab' ich übrigens auf das falsche Pferd gesetzt - ich hätte mit proxy arp das ganze wesentlich schöner hinbekommen.
- Aus praktischen Gründen wollte ich ein VPN mit openvpn einrichten. Das hat auch ganz wunderbar geklappt (wenn man davon absieht, daß ich gerne mal eine Beschreibung hätte, wie deren Routing eigentlich funktioniert - *das* scheine ich nicht verstanden zu haben). Nur wenn es dem Esel zu gut geht...
Ich wollte dann noch die alte Kiste an das VPN anschließen. Mit dem Nettoresultat, daß die sich aufgehängt hat, als ich die neue mal neu gestartet habe. Oops. Klar, ich könnte den Kernel auf der alten Maschine aktualisieren, aber der Sinn der Übung ist eben nicht gewesen, an der alten Maschine etwas zu ändern.
- Geplant war, den Inhalt der Datenbank der alten Maschine (Postgres 8.3) auf die neue (9.0) zu replizieren. Das hat gar nicht geklappt, mit keinem der verfügbaren Tools.
- Bisher waren so einige Sachen des Forums quer über das System verteilt (ein paar Konfigurationdateien in /etc/, ein paar Cachedateien in /tmp oder in htdocs/cache, die Logs gleich an mehreren Stellen). Das sollte sich auf der neuen Kiste ändern. Unbedingt, wohlgemerkt. Und es sollte nur ein paar Stunden kosten.
Es hat ein paar Tage gekostet - ich hab' nämlich mal dank eines dämlichen Fehlers die Arbeit eines Tages verloren.
- Apropos Cache: Die Forumssoftware verwendet memcache, über ein Interface in einem Paket namens php5-memcache. Es gibt auch noch ein Paket namens php5-memcached. Jaja, das kleine "d" macht das vollständig inkompatibel. Wie ich jetzt aus praktischer Erfahrung weiß
- Ich war der Meinung, bereits alle Inkompatibilitäten mit PHP 5.3 ausgeräumt zu haben - immerhin läuft die Software an zwei Stellen auf PHP 5.3. Ok, jetzt weiß ich es besser - sie lief zwar, aber wie? Naja, nicht sauber. Oder stolperte sie mehr?
- Was mich zu einem anderen Thema bringt: Das Fehlerhandling. Da war etwas abgeschaltet, was eigentlich hätte angeschaltet sein *müssen*. Und so sind mir einige Dutzend Warnungen lange, lange erspart gewesen - bis zu dem Zeitpunkt, wo ich sie gar nicht brauchen konnte.
- Die eigentliche Umzugsprozedur hatte ich bereits mehrfach getestet - Dateien synchronisieren, Datenbank neu importieren, php-fcgi-Prozesse neu starten. Der Einfachheit halber hab' ich mir dafür ein Script geschrieben. Und das lief 8 mal ohne Schwierigkeiten durch, wenn auch der Datenbankexport etwas länger als erwünscht dauerte (so rund 30 Minuten).
Am Tage des Umzugs allerdings lief es nicht durch, sondern warf Fehlermeldungen beim Datenbankimport. Damit war meine Hoffnung von einem ruhigen Vormittag dahin, und ich durfte frickeln, bis ich dann bei dritten oder vierten Versuch endlich die Daten in die DB bekam.
Nur leider waren sie dann nicht ganz in dem Zustand, den sie haben sollten. Einige der über das Profil gemachten Einstellungen sind einfach weg... Nein, ich weiß nicht, wie das passieren konnte. Ich weiß noch nicht mal, was passiert ist, nur was herausgekommen ist. Zum Glück bekomme ich das wohl halbwegs sauber aus dem Backup gelesen.
Teil 2 demnächst. Gruß, Uwe |
