wiki:Server/VM klonen

Backups/Klonen der eLearning-VM

Diese Seite beschreibt, wie man die eLearning-VM klont. Das haben wir zum einen als Backup-Strategie gemacht (siehe Server/Backup für Alternativen seit 2015) und zum anderen um eine funktionierende realitätsnahe Kopie von ILIAS oder dem POTT inklusive aller Benutzerdaten zu erhalten. Mit der kann man dann Experimente ausführen, zB. neue Software oder Konfiguration. Seitdem das ILIAS von der VM in einen ITP-Account und damit auf die ITP-Webserver gezogen ist, können wir direkt die eLearning-VM zum Experimentieren nutzen und brauchen sie nicht mehr klonen. Ticket #1018 beschreibt, wie man dorthinkommt.

Diese Seite erläutert auch, wie man einen Tarball, den man vom Linux Root-Verzeichnis / gemacht hat, wieder in eine funktionsfähige Linux-Maschine verwandelt.

Diese Seite ist dennoch vor allem historischer Natur. Die Problematiken, die hier beschrieben werden, gibt es so nicht mehr.

Problematik

Die verwendete VM-Softwarelösung ist KVM. Life-Snapshots für Backups müssten auf dem VM-Wirt geschehen. Aus der VM können keine atomaren Snapshots gemacht werden. Nur wenige Dateisysteme (etwa zfs) unterstützen Hot Backups, ext4 tut es nicht. LVM kann es auch; wird aber nicht verwendet.

Übrig bleibt: Quick & Dirty-Backups/Snapshots, die nicht atomar sind, mit beliebigen Werkzeugen (rsync, tar, dump, …), immerhin als root und damit vollständig. In dem man sich nur auf das Root-Dateisystem beschränkt, bleibt sysfs/udev/…-Kram draußen.

Interessante (Closed-Source)-Alternative: http://en.wikipedia.org/wiki/Hot_copy

Für den aktuellen Zustand sowie die Historie siehe unten.

Snapshots ins ITP-Netz (05.09.11)

Auf die /home/work-itp-Partition (12TB, 300GB frei) hab ich unter /home/work-itp/koeppel/physik-elearning mit Backups über ssh und tar experimentiert. Funktioniert ganz gut, netter Nebeneffekt ist "Sparsity" bzw. kompakte Backups (keine 80GB Partitionsgröße), läuft (derzeit, 2GB belegt) in nur wenigen Minuten durch mit exakt 100Mbit/sec.

Für gute Backups muss mit mysqldump eine Hot Copy der Datenbank angefertigt werden. Das ist zumindest der kritischste Punkt am System.

Anschließend kann das Backup in eine beliebige Linux-VM entpackt werden. Mittels einem kleinen Script können Sofortänderungen vorgenommen werden (Netzwerkeinstellungen ändern, etc.). Man braucht vmtl. auch einen anderen Kernel für andere Virtualisierungslösungen (VMware, Virtualbox, …).

Position des VM-Images

Zufällig gefunden; Mit nobody-Rechten einfach auslesbar… O_O

koeppel@turk:/home/work-itp/kvm$ ls -lh
total 20G
-rw------- 1 nobody nogroup     4.9G 2011-09-05 20:46 elearning.img
-rw------- 1 nobody nogroup     9.8G 2011-09-05 20:46 gridmaster.img
-rw-r--r-- 1 nobody nogroup     3.3G 2011-09-05 20:45 lm.qcow2
-rw------- 1 nobody Debian-exim 2.2G 2011-09-05 20:35 sogo.img
-rw------- 1 root   root        9.8G 2011-08-11 14:42 test.img
-rw-r--r-- 1 nobody Debian-exim 685M 2011-06-09 14:02 ubuntu-10.04.2-server-amd64.iso
-rw------- 1 root   root        9.8G 2011-01-19 16:43 vt-win.img

Toolchain

Das Aufsetzen einer Spiegel-VM unter VirtualBox ist straight forward:

Einsetzen eines Linux-Tarballs in eine Virtualbox-Umgebung ===

  1. VM für Linux64 aufsetzen (1GB RAM, 80GB HDD), 64bit-Life-Linux laden (http://grml.org)
  2. Partitionstabelle erstellen (Swap braucht niemand), ext4-Partition erstellen und mounten:
        cfdisk /dev/sda  # Primary, Bootable, Type  83 Linux, Write and Quit
        mkfs.ext4  /dev/sda1
    
  3. Tarball runterladen und im Root entpacken.
        mkdir /mnt/linux && cd /mnt/linux
        mount /dev/sda1 /mnt/linux
        # ca 20-80GB runterladen:
        scp koeppel@th.physik.uni-frankfurt.de:/home/elearning/backups/elearning-vm/snapshots/hdd-backup-2013-03-18T02:15.tar.gz .
        # bitte Fingerprint 6f:59:b4:82:2a:74:74:be:29:df:f2:3f:19:fb:4d:d4 überprüfen
        tar xvfz hdd-backup-2013-03-18T02:15.tar.gz
        # dauert je nach Maschine ca 15-30 Minuten
    
  4. Linux für VM fitmachen: /etc/fstab aufräumen (Swap entfernen), mit tune2fs -U die UUID aus alter /etc/fstab übernehmen, damit Rootpartition beim Booten gefunden wird, Hostname fixen
        cd /mnt/linux
        vim etc/fstab  # swap entfernen, UUID von root aufschreiben
        tune2fs -U aacceef1-e708-.... /dev/sda1
        echo "LOCALVMelearningLOCALVM" > etc/hostname
        echo "127.0.0.1  LOCALVMelearningLOCALVM" >> etc/hosts
    
  5. Bootloader einstellen: Mit 64bit-Lifelinux chrooten, grub-install ausführen, Reboot
        mount --bind /dev  /mnt/linux/dev
        mount sysfs -t sysfs /mnt/linux/sys
        mount proc -t proc /mnt/linux/proc
        chroot /mnt/linux
        grub-install /dev/sda
        exit
        reboot
    
  6. Netzwerk geht bereits per DHCP. Wenn die VM per Netzwerk-Bridging laufen lässt, kommt man auch von außen dran.
  7. Anwendungsfixing (Apache, Exim, …) siehe unten

Beim Neueinspielen eines Images braucht man nur noch ein Lifelinux booten und Schritte 3 und 7 wiederholen.

Lokale Anwendungsanpassungen

Lokale Anpassungen im Einzelnen:

  • Achtung: dmesg|grep eth0 → er benennt eth0 zu eth1 um, dhclient muss gegebenenfalls händisch aus geführt werden nach ifconfig eth1 up
    # damit das bei jedem Systemstart passiert:
    ifconfig eth1 up
    dhclient eth1
    # in die /etc/rc.local vor exit 0 einfuegen
    
  • Apache für neue lokale Hostnamen fixen: (ein lokaler DNS-Server wird benötigt der *.elearning.physik.uni-frankfurt.de.lan auflöst)
    cd /etc/apache2/sites-enabled && sudo perl -pi -w -e 's/uni-frankfurt.de/uni-frankfurt.de.lan/g;' *
    
    alle relevanten Hosts müssen auch noch zur /etc/hosts hinzugefügt werden, wenn man keinen DNS-Server verwendet

Nun kann die VM von außen erreicht werden und Apache beantwortet Webanfragen richtig. Aufpassen muss man eigentlich nur noch, dass alle Dienste lokal sind, also etwaige Datenbanken (das war aber ohnehin die Prämisse bei dieser Anleitung). Ferner darf die VM keine Mails schicken. Darauf muss man entweder per Hand aufpassen oder folgenden Absatz noch lesen.

Man sollte im ILIAS-Setup die Installation umbenennen, um nicht durcheinander zu kommen.

Enriched Image: Entwicklungsumgebung in VM

Screenshot der "enriched VM" im jetzigen Zustand mit LXDE, eigenem Hintergrundbild und Firefox Nach obigen Schritten hat man einen Klon der VM, auf den man per SSH zugreifen kann. Um allerdings eine bequeme Lösung zu haben, bei der auch DNS-Namen keine Probleme machen, empfiehlt sich ein enriched Image #547, das ist mein Name für eine GUI und grafische Entwicklungsumgebung in der man direkt in der VM portabel arbeiten kann.

  • E-Mails lokal umleiten:
    sudo -s
    cd /etc/exim4/conf.d/router
    cat > 102-LOCALVM-CATCHALL << EOF
    catch_all_outgoing:
       driver = accept
       transport = catch_all_local
       no_more
    EOF
    cd /etc/exim4/conf.d/transport
    cat > 05-LOCALVM-CATCHALL  << EOF
    catch_all_local:
       debug_print  = "T: catch_all_local for $local_part@$domain"
       driver = appendfile
       file = /var/mail/elearning
       group = mail
       mode = 0660
       mode_fail_narrower = false
       delivery_date_add
       envelope_to_add = true
       return_path_add = true
    EOF
    gpasswd -a Debian-exim mail
    gpasswd -a elearning mail
    update-exim4.conf
    service exim4 restart
    
  • Alias für elearning entfernen (fakultativ)
     vim /etc/aliases # Zeile "elearning:" suchen und entfernen
    
  • GUI aufsetzen. Als schlankes Desktop Environment empfehle ich http://lxde.org/ , man kann aber auch beliebige andere installieren:
       sudo apt-get install lxde lxdm lxsession thunderbird firefox chromium virtualbox-ose-guest-utils virtualbox-ose-guest-x11
    
  • GUI kann man nun manuell starten, ansonsten passiert das bei Systemstart automatisch: sudo lxdm. Einloggen als Benutzer elearning mit bekanntem Passwort.
  • Konfiguration von Thunderbird (Unix Mailspool) und Firefox werden hier nicht erläutert.

Das Gesamtimage ist ca 60GB groß und kann gemütlich verteilt werden. Die Zugangsdaten zum Download der enriched VM stehen in #554.

Bugfixes im Enriched Image

Der HRZ-Login geht (verständlicherweise) in der VM nicht. Lokale Radius-Anmeldungen gegen Accounts in /etc/freeradius/users.hrzdemo sollten aber gehen. Insbesondere läuft der Freeradius-Daemon aber in der deployten VM-Version von Ende März 2013 nicht. Irgendwelche Gruppen sind total kaputtgegangen (weiß nicht wieso). Dagegen helfen hässliche Tricks wie

sudo -s
find / -uid 121 | xargs chown freerad:freerad
cd /etc/freeradius; chgrp -R freeradius .
cd /etc/ssl/private; chmod 777 *  # sehr hässlich!
chgrp -R freerad /etc/ssl/private/  # noch hässlicher...
service freeradius start

Aktueller Zustand (15.10.2012, 2013)

Obigen Informationen ist hinzuzufügen: Das Fullbackup läuft mittlerweile nächtlich in /home/elearing und nicht mehr auf work-itp. Im Fehlerfall kriegt Sven eine E-Mail. Die Backups sammeln sich bis mehrere Terabyte an und müssen dann manuell gelöscht werden. Ist alles nicht besonders elegant.

Ferner werden die VMs mittlerweile mehr oder minder gebackupt, heißt es. Eine gescheite Backuplösung ist wohl mittelfristig nicht mehr so dringend, da die elearning-VM ohnehin abgewrackt wird.

Folgendes stammt aus einer ITP-Rundmail (MOTD) von THW, 17.07.12:

in den nächsten Tagen werde ich alle unsere virtuelle Maschinen auf einen anderen NFS Server ziehen (von magnum auf titan). Davon betroffen sind (lm, sogo, elearning). […] Dort gibt es dann auch sowas wie eine Backup und der Server hat mehr Reserven als der bisherige. Backup heißt: Die Images werden gesichert. Ob das zurück spielen und wieder anfahren funktioniert muss ich noch austesten.

Last modified 16 months ago Last modified on Jan 14, 2016 6:32:59 PM

Attachments (1)

Download all attachments as: .zip