by ·3 Kommentare

Vor einer Weile schrieb ich ja schon dass mich Proxmox VE ziemlich überzeugt hat. In der Zwischenzeit habe ich nicht mehr allzu viel damit gespielt, jetzt denke ich dass ich das vielleicht einfach mal über die Feiertage zur Grundlage meines Netzes mache… ein weiser Kollege aus München (der hier vielleicht sogar bisweilen rein sieht) hat mir mal die goldenen Worte „wenn Scheiße, dann Scheiße mit Schwung“ mitgegeben… :-)

Ich habe einen zweiten Server hier der in etwa so mächtig ist wie der bestehende. Darauf habe ich ein Proxmox installiert. Die KVM-virtualisierten Systeme waren einfach. Einfach eine passende VM auf Proxmox anlegen und die Laufwerksimages austauschen. Schwieriger sind die paravirtualisierten Maschinen, da hier eine völlig andere Technik eingesetzt wird. Beim Umstieg von Linux-Vserver auf OpenVZ müssen ein paar Extra-Schritte gemacht werden. Ansatzweise ist das auch hier beschrieben, aber ich gebe mal meine eigene Erfahrung wieder.

An dieser Stelle sei kurz angemerkt: OpenVZ ist mir leicht suspekt. Proxmox wäre wesentlich sympathischer wenn es mit Vservern arbeiten würde, aber man kann nicht alles haben.

Also hier kurz ein Log, falls noch jemand vor einem ähnlichen Problem stehen sollte — oder falls ich mich in einem halben Jahr (oder Morgen… :-) ) frage wie ich das gemacht habe.

Erstmal habe ich auf dem alten Server das Root-Verzeichnis des Vservers zusammengetart. Dann auf dem Proxmox-System eine virtuelle Maschine angelegt die in etwa dem alten System entspricht (ID 103). Weiterhin gibt es einen Container mit einem einfachen Debian (ID 104, erstellt nach dem Proxmox-Template für Debian Squeeze) und eine virtuelle Maschine bei der ich bereits in der /etc/network/interfaces konfiguriert habe dass eth0 per DHCP konfiguriert werden soll.

Folgendes ist dann zu tun:

root@proxmox:/var/lib/vz/private# scp server:/mnt/system/vservers/vserver.tar .
root@proxmox:/var/lib/vz/private# tar xf vserver.tar
root@proxmox:/var/lib/vz/private# rm -rf 103
root@proxmox:/var/lib/vz/private# mv vserver 103
root@proxmox:/var/lib/vz/private# rm -rf 103/dev
root@proxmox:/var/lib/vz/private# cp -a 104/dev/ 103/
root@proxmox:/var/lib/vz/private# cp 104/etc/inittab 103/etc/
root@proxmox:/var/lib/vz/private# cp 102/etc/network/interfaces 103/etc/network/
root@proxmox:/var/lib/vz/private# chroot 103
root@proxmox:/# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
root@proxmox:/# exit

Also, was passiert hier?

  • Das Tar-File der Maschine wird vom alten Server bezogen und entpackt.
  • Die Dateien der Temporären virtuellen Maschine (ID 103) werden entsorgt und durch den Verzeichnisbaum der alten Maschine ersetzt.
  • Vserver mounten das /dev-Verzeichnis des Host-Systems, also wird das duch eine Kopie aus dem Template-System (ID 104) ersetzt.
  • Die /etc/inittab wird ebenfalls übernommen, anderenfalls fehlt ein Eintrag (1:2345:respawn:/sbin/getty 38400 tty1) der zu einer Fehlermeldung führt nach der der Init-Prozess nicht mehr weiß was er tun soll (no more processes left in this runlevel).
  • Aus ID 102 wird die /etc/network/interfaces kopiert, die enthält die Konfiguration nach der eth0 per DHCP konfiguriert werden soll.
  • Ich habe mir nie die Mühe gemacht den Vservern ein Root-Passwort zu verpassen, da ich bei Bedarf einfach per ‚vserver enter…‘ eingestiegen bin. Das muss nachgeholt werden.

Danach kann ich den Container booten, und bis jetzt sieht alles so aus als ob es funktionieren würde… falls noch was zu ergänzen ist werde ich das zu gegebener Zeit nachholen.

by ·2 Kommentare

Letzte Tage habe ich mal wieder eine Datei per Mail bekommen die ich nicht ohne weiteres öffnen konnte. Ich brauche extrem selten irgendwelche Office-Anwendungen, daher gibt es sowas nicht auf meinem Notebook. Arch Linux macht ‚rolling updates‘, das heißt dass man mit einer neuen Version eines Programms nicht warten muss bis das nächste Release der Distribution ansteht, sondern die Neuigkeiten direkt rauspustet. Wenn ich hier ein OpenOffice drauf hätte würde ich das wahrscheinlich diverse Male updaten müssen ohne es zwischendurch benutzt zu haben. Und bei meiner bekanntermaßen lahmen Netzanbindung würde das echt Nerven kosten.

Bis jetzt habe ich in so einer Situation immer das Notebook meiner Frau gequält, die hat da ein Kubuntu und somit auch ein Office.

Da ich aber eh außer Gefecht gesetzt war habe ich eine Lösung gebastelt die mich hoffentlich dauerhaft glücklich macht. Eine Art Terminal-Server. Allerdings nicht auf Basis von LTSP oder x2go, sondern mit Nomachine NX. Also kein wirklicher Terminal Server von dem ich auch booten kann (zumindest bis jetzt noch nicht), sondern einfach nur eine zentrale Maschine auf der ich Anwendungen starten kann — wie zum Beispiel OpenOffice.

Den Server habe ich als VServer auf meinem total überdimensionierten Home-Server angelegt. Das Host-System ist ein Debian Stable, die virtuelle Maschine sollte in diesem Fall ein Kubuntu sein, damit die Anwendungen dort halbwegs aktuell sind. Den VServer anzulegen ist nicht ganz einfach, weil Kubuntu nicht mehr auf das gute alte System V Init setzt, sondern stattdessen Upstart benutzt.

Angelegt habe ich die Maschine letztendlich mit dem folgenden Kommando:

vserver terminator build -m debootstrap --context 40012 \
--hostname terminator.asgard --interface eth0:192.168.0.63/24 -- \
-d karmic -m http://odin:9999/ubuntu/

Dabei ist terminator der Name meiner neuen Maschine, asgard die Domäne, und auf dem Server odin läuft ein apt-proxy, damit sich die realten und virtuellen Rechner die mühsam aus dem Netz gelutschten Pakete teilen können. Ach ja, und karmic ist der Name der aktuellen Kubuntu-Distribution (Karmic Koala, Version 9.10).

An den Klippen von Upstart habe ich mir erst die Zähne ausgebissen. Kurz vor der Kapitulation — ich dachte es läge daran dass Kubuntu damit rechnet von CD installiert zu werden, statt mit debootstrap — habe ich dann noch einen Artikel über Upstart Issues gefunden. Genau was ich brauchte, sogar zugeschnitten auf Karmic. Damit ging es dann endlich.

Dann noch nach dem Ubuntu-Wiki den NX-Server installiert, und es kann losgehen. OpenOffice ist schon drauf, und ich glaube dass es sich bei einer lokalen Installation auf meinem Notebook nicht viel schneller anfühlen würde.

Was man jetzt noch — auch im Sinne eines höheren WAF — verbessern könnte wäre eine Art Application Launcher auf dem Server. Ich könnte einen kompletten Desktop auf dem Server starten, das würde aber mein ästhetisches Empfinden stören. Ich habe die Fenster lieber in einer Optik die so wirkt als ob die Anwendungen lokal laufen würden. Jetzt öffnet der NX-Client ein xterm auf dem Server mit dem ich nach Belieben Anwendungen starten kann. Ein kleines Menü würde mir da aber besser gefallen.

Vorschläge?

Ach ja, die Datei die den Anstoß für diese Aktion gegeben hat war übrigens belanglos: eine Präsentation mit dem alten 710-Gag. ;-)