S4Y Upgrade Suse 9.3 > 10.x

c't Update

Moin moin,

auch wenn Paulix das Update aufgegeben hat und es ja inzwischen im Powerpanel die Möglichkeit gibt, auf SuSE 10.1 zu wechseln, kann ich bestätigen, dass ein Update, wie es in der c't 13/2007 beschrieben wurde, tatsächlich funktioniert. Seit ich das Update auf 10.2 (eigentlich ist es ja eine Neuinstallation) vor zwei Wochen durchgeführt habe, kann ich wieder ruhiger schlafen :)

Die Nachteile sind:
  • Es ist schon etwas Erfahrung nötig, insbesondere wenn die Daten von bestehenden Datenbanken, imap, etc. erhalten werden sollen (aber das Problem wird man wohl bei jeder Upgrade-Aktion haben...)
  • Confixx und andere providerspezifische Tools funktionieren nicht mehr (braucht man aber je nachdem auch nicht)
  • höherer Ressourcenverbrauch: Ich habe den Eindruck, dass SuSE 10.2 mehr libraries verwendet, als die 9.3er Version (kann das aber nicht quantitativ belegen). Jedenfalls ist die lsof-Liste ziemlich lang und ich bin erstmalig an die Grenze der numfiles meines vServer BASIC gestoßen...

Für Nicht-c't-Leser hier eine kurze Zusammenfassung des Vorgangs; c't-Leser werden einige Unterschiede und Erweiterungen erkennen, die nicht im Artikel erwähnt wurden und die ich aus Erfahrung so gemacht habe oder bei denen ich teilweise während des Umzugs rausfinden musste, dass es anders nicht geht (mingetty...). Damit nicht jeder selber die Fehler suchen muss, habe ich den Vorgang mal dokumentiert:
  1. Zu Hause neue Installation mit SuSE 10.2 auf einer VMWARE-Instanz oder einem separaten Rechner durchführen. Dabei
    • eine einzige Partition wählen
    • IP-Adressen entsprechend dem Heim-Netzwerk
    • die einzelnen Dienste gleich wie beim vServer konfigurieren, aber nicht einfach nur die Konfig-Dateien kopieren, sondern auch eventuelle Format-Änderungen bei den neueren Programm-Versionen berücksichtigen.
    • Daten migrieren: Den jeweiligen Dienst auf dem vServer stoppen, Daten per tar zusammenpacken, Dienst wieder starten und Daten auf dem lokalen Rechner auspacken. Je nach Dienst muss man sich die nötigen Konvertierungsschritte "zusammen-googeln". Dabei alles genau protokollieren, damit es nachher beim Umzug gleich richtig klappt.
    • Online-Update durchführen.
    • Alles gut testen.
  2. Neuen Rechner runterfahren, und von CD starten und die Verzeichnisse /bin /etc /lib /opt /root /sbin /usr /var in ein Tar-File packen und auf den vServer schieben.
  3. Für Angsthasen: Backup des vServers durchführen
  4. Auf dem vServer zwei Verzeichnisse anlegen: /alt und /neu
  5. Neue Installation in /neu auspacken (dabei unbedingt die Option --numeric-owner verwenden) und an den Server anpassen:
    • evtl. fehlende Benutzer aus /etc/passwd und /etc/shadow in die entsprechenden Dateien in /neu übertragen
    • /etc/hosts kopieren
    • /neu/etc/inittab: alle getty-Einträge löschen, der vServer hat keine Konsole... (andernfalls bootet er nicht richtig!)
    • /etc/fstab kopieren
    • Das /dev-Verzeichnis mit tar nach /neu kopieren
    • evtl. ssh-Hostkeys kopieren
    • /etc/vz mit tar nach /neu kopieren
    • IP-Adressen und Hostnamen aller Dienste in /neu/etc anpassen (insbesondere Postfix)
  6. Die folgenden Dinge gehen am Besten in einer chroot-Umgebung:
    • mkdir /neu/proc
    • mount --bind /proc /neu/proc
    • chroot /neu /bin/bash
    • yast2 ->runlevel-Editor: weitere unnötige Dienste abschalten: udev, hwscan, hotplug, etc...
    • yast2 -> Netzwerkkarte entfernen (kann man auch lassen, da die ohnehin über ihre MAC-Adresse identifiziert wird, die ja auf dem vServer so nicht existiert. Ansonsten brauchen keine IP-Adressen/Routen definiert werden, das geschieht automatisch von ausserhalb der vz).
    • yast2 ->/etc/sysconfig-Editor: System->Boot->RUN_PARALLEL: no (andernfalls reichen die zugeteilten Ressourcen der vz beim Booten nicht aus)
    • exit
  7. Dienste des vServers anhalten, deren Daten sich zwischenzeitlich geändert haben und die aktuellen Daten wie oben beschrieben in die neue Installation kopieren.
  8. shutdown -h now
  9. Rescue-System booten und sich dort per ssh einloggen
  10. evtl. mount -o remount -rw /mnt (war bei mir komischerweise einmal ro...)
  11. mv /mnt{/bin,/etc,/lib,/opt,/root,/sbin,/usr,/var} /mnt/alt
  12. mv /mnt/neu/* /mnt
  13. shutdown -h now
  14. Rescue-System im Powerpanel deaktivieren
Wenn Ihr alles richtig gemacht habt (und ich in der Aufzählung nichts vergessen habe...) sollte Euer frisches System jetzt booten und ihr könnt Euch per ssh einloggen, um noch die zwischenzeitlich geänderten Daten (mysql, imap,...) in das neue Format zu migrieren. Evtl. bietet es sich an, dazu vorher die entsprechenden Ports in der Firewall zu sperren, und erst nach erfolgreicher Migration wieder zu öffnen.

Im Prinzip ist alles nicht sonderlich schwer, aber der Aufwand ist beträchtlich -- in einem Nachmittag (wie ich ursprünglich dachte) ist es jedenfalls nicht getan... Glücklicherweise kann man mit der beschriebenen Vorgehensweise die für die Benutzer sichtbare "downtime" auf ca. eine halbe Stunden begrenzen.

Vielleicht hilft es ja jemandem...
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top