Installation in Virtuozzo Container

Dieser Artikel beschreibt die Installation von Gentoo Linux in einem Virtuozzo-Container bei einem Server-Provider am Beispiel eines Strato V-PowerServer. Virtuozzo ist eine Virtualisierungslösung auf Basis von OpenVZ, die sehr häufig bei gemieteten virtuellen Servern eingesetzt wird.

[Bearbeiten] Voraussetzungen

• Virtueller Server in einem Virtuozzo- oder OpenVZ-Container.
• Recovery-System, das statt des Standard-Systems gebootet werden kann und Zugriff auf die Daten des echten Systems erlaubt. Der Wechsel zwischen den beiden Systemen sollte relativ einfach über die Web-Oberfläche des Providers durchgeführt werden können, da dieser Wechsel möglicherweise mehrfach durchgeführt werden muss.
• Diese Anleitung sollte nur auf einem neuen Server ausgeführt werden, auf dem noch keine wichtigen Daten liegen, da dabei sämtliche Daten gelöscht werden.
• Außerdem setzt diese Anleitung allgemeine Installations-Kenntnisse für Gentoo voraus. Wer noch nie Gentoo installiert hat, sollte sowieso erstmal in einer geschützten Umgebung (z.B. Zuhause oder im Büro) üben.
• Auch wenn der Provider prinzipiell erlaubt ein anderes System zu installieren, kann man dabei leider meist keinen Support erwarten. Darüber sollte man sich bewusst sein.

[Bearbeiten] Vorbereitung

Schon eine gute Wahl der vorinstallierten Distribution ist wichtig, wie die Erfahrung gezeigt hat. Bei Strato hat man beispielsweise u.a. openSUSE, Ubuntu und CentOS zur Auswahl. Man sollte immer diejenige Distribution wählen, deren Init-System dem von Gentoo möglichst ähnlich ist. Bei den aktuellen (Ende 2010) V-PowerServern hat sich beispielsweise CentOS als gute Wahl herausgestellt, Ubuntu hingegen als schlechte. Der Grund dafür ist, dass die Virtuozzo-Container je nach Distribution teilweise auch etwas anderes konfiguriert sein können.

Bei Strato kann man in der Web-Oberfläche zur Konfiguration des Servers die entsprechende Distribution auswählen und auf Knopfdruck installieren lassen. Danach muss man auf das Recovery-System umstellen, wonach der Server automatisch neu gestartet wird. Danach kann man sich per SSH mit dem auf der Web-Oberfläche angegebenen root-Passwort einloggen.

[Bearbeiten] Installation des Basis-Systems

[Bearbeiten] Stage 3 Installation

Zunächst wechseln wir ins repair-Verzeichnis, wo die bisherige Distribution liegt. Dort sichern wir uns zunächst die Konfiguration des ursprünglichen Distribution in das private-backup-Verzeichnis und löschen den Rest.

Danach laden wir das aktuelle stage3- und Portage-Archiv herunter und entpacken beides. Die nachfolgenden Zeilen stellen nur ein Beispiel dar. Bitte selbst auf einem Mirror eine passende aktuelle Version auswählen:

Wenn wget nicht vorhanden ist, funktioniert auch 'curl http:\\mirror\stage3-xyz.tar.bz2 > stage3-xyz.tar.bz2'

Bevor wir mit chroot ins neue System wechseln können, müssen wir noch die resolv.conf-Datei aus dem Recovery-System in unser neues System kopieren sowie /proc und /dev mounten:

Nun können wir endlich erstmals per chroot in unser neues System wechseln:

Wenn alles soweit geklappt hat, können wir nun das Portage-Repository auf den aktuellen Stand bringen:

Bevor wir weiter machen, sollten wir noch prüfen, ob das richtige Profil ausgewählt ist. Das Standard-Profil (default/linux/x86/10.0) leistet hierbei gute Dienste:

Als nächstes sollten wir die Einstellungen in der Datei /etc/make.conf prüfen und gegebenenfalls auf die persönlichen Bedürfnisse anpassen. Die Compiler-Einstellungen sollte man normal so lassen können, wie sie sind, aber je nach Einsatzzweck des Servers sollten gegebenenfalls noch entsprechende USE Flags gesetzt werden:

Außerdem sollten die Locale-Einstellungen noch angepasst werden. Für einen Server ist hier en_US.UTF-8 UTF-8 empfehlenswert:

Ebenso sollte noch die lokale Zeitzone des Servers konfiguriert werden.

[Bearbeiten] Konfiguration des Basis-Systems

[Bearbeiten] Dateisystem

Die Datei /etc/fstab sollte so angepasst werden, wie sie bei der ursprünglich auf dem Server installierten Distribution war:

Normal sollte man alles auskommentieren können und dafür folgende Zeilen am Ende hinzufügen:

proc                    /proc           proc            defaults        0 0
none                    /dev/pts        devpts          rw              0 0

[Bearbeiten] Netzwerk

In der Datei /etc/conf.d/hostname muss der Hostname konfiguriert werden.

Die Datei sollte am Ende ungefähr so aussehen:

# Set to the hostname of this machine
hostname="hostname"

In der Datei /etc/conf.d/net müssen die statischen IP-Adressen des Servers konfiguriert werden. Die IP-Adressen können mit Hilfe des ifconfig-Befehls herausgefunden werden, das benötigte Default-Gateay mit Hilfe von route. Das richtige Interface ist hierbei venet0. Die Nameserver stehen in der Datei /etc/resolv.conf.

Die Datei sollte am Ende ungefähr so aussehen:

config_venet0=("<IP-Addresse 1>/32"
                   "<IP-Addresse 2>/32") 
 
routes_venet0=("<IP-Addresse 1>/32"
                   "<Default Gateway>/32"
                   "default via <Default Gateway>")
 
dns_servers_venet0="<Nameserver 1> <Nameserver 2>"
 
dns_domain_venet0="domainname.tld"
nis_domain_venet0="domainname.tld"

Außerdem muss das Interface auch in den Init-Prozess eingebunden werden:

Außerdem sollte die Datei /etc/hosts noch entsprechend erweitert werden.

Die Datei sollte am Ende ungefähr so aussehen:

# /etc/hosts: Local Host Database
#
# This file describes a number of aliases-to-address mappings for the for
# local hosts that share this file.
#
# In the presence of the domain name service or NIS, this file may not be
# consulted at all; see /etc/host.conf for the resolution order.
#
 
# IPv4 and IPv6 localhost aliases
127.0.0.1       localhost
::1             localhost
 
<IP-Adresse 1>  hostname.domainname.tld    hostname

[Bearbeiten] SSH/Login

Damit wir uns nach einem Neustart auch einloggen können, müssen wir den SSH-Daemon noch entsprechend konfigurieren.

Folgende Optionen sollten mindestens gesetzt sein, damit wir uns mit dem root-Account einloggen können. Dies ist nur für den ersten Test. Später sollten Logins über den root-Account unbedingt abgeschaltet werden und am besten auch auf Key-Authentication umgestellt werden.

Port 22
ListenAddress 0.0.0.0
ListenAddress ::
PermitRootLogin yes         # TODO: Später einen separaten Account anlegen und auf no setzen
PasswordAuthentication yes  # TODO: Später auf Key-Authentication umstellen und auf no setzen
PermitEmptyPasswords no
UsePAM yes

Und schließlich noch den SSH-Daemon in den Init-Prozess einbinden:

Natürlich muss auch noch das root-Passwort gesetzt werden, mit dem man sich später einloggen kann.

[Bearbeiten] Boot-Konfiguration

Damit der Boot-Prozess reibungslos klappt, müssen in der Datei /etc/rc.conf noch ein paar Einstellungen vorgenommen werden.

Es muss mindestens die folgende Einstellung vorgenommen werden.

rc_sys="openvz"

Es ist empfehlenswert, auch noch folgende Einstellungen zu setzen. Alle anderen Einstellungen sollten am besten zunächst auf den Default-Werten belassen werden.

rc_parallel="NO"
rc_interactive="NO"
rc_depend_strict="YES"
rc_logger="YES"

Zusätzlich sollten wir in der Datei /etc/inittab noch die nicht benötigten Terminals auskommentieren, da wir die sowieso nicht verwenden können.

Alles andere in der Datei sollte man so lassen können, wie es standardmäßig ist.

# TERMINALS
#c1:12345:respawn:/sbin/agetty 38400 tty1 linux
#c2:2345:respawn:/sbin/agetty 38400 tty2 linux
#c3:2345:respawn:/sbin/agetty 38400 tty3 linux
#c4:2345:respawn:/sbin/agetty 38400 tty4 linux
#c5:2345:respawn:/sbin/agetty 38400 tty5 linux
#c6:2345:respawn:/sbin/agetty 38400 tty6 linux

[Bearbeiten] Weitere Pakete

Gegebenenfalls können jetzt noch weitere Pakete aus dem Gentoo Handbuch installiert werden.

[Bearbeiten] Logger

Es ist zumindest empfehlenswert, jetzt schon einen Logger (z.B. app-admin/syslog-ng ) zu installieren, um bei Problemen gegebenenfalls schon Logs zu erhalten. Dabei sollte man darauf achten, dass der Logger nicht auf das nicht verfügbare Terminal /dev/tty12 schreiben will, ansonsten werden die Logs mit entsprechenden Warnungen zugemüllt. Bei app-admin/syslog-ng  muss man dazu beispielsweise in der Datei /etc/syslog-ng/syslog-ng.conf folgende Zeilen auskommentieren:

#destination console_all { file("/dev/tty12"); };
#log { source(src); destination(console_all); };

[Bearbeiten] Abschluss

Zum Abschluss muss der Boot-Modus des Servers über die Web-Oberfläche des Providers zurück umgestellt werden und der Server neu gestartet werden. Der Neustart sollte ebenfalls über die Web-Oberfläche durchgeführt werden.

Mit etwas Glück kann man sich danach per SSH einloggen.

Ansonsten geht es jetzt an die Fehlersuche. Manche Provider wie beispielsweise Strato erlauben es, dass man eine Liste der laufenden Prozesse des Servers über die Web-Oberfläche einsehen kann. Sieht man hier überhaupt keinen Prozess (d.h. nicht einmal den init-Prozess), ist das ein schlechtes Zeichen und man sollte überprüfen, ob sys-apps/sysvinit  korrekt installiert ist und gegebenenfalls eine andere Distribution als Ausgangspunkt wählen. Startet hingegen zumindest der init-Prozess sind wir auf dem richtigen Weg und die Chancen stehen gar nicht schlecht, dass auch irgendwelche Log-Dateien gefüllt sind, beispielsweise /var/log/rc.log, die als Ausgangspunkt für die Fehlersuche dienen können, beispielsweise Fehlermeldungen über die Netzwerk-Konfiguration oder den SSH-Daemon. Um diese Log-Dateien zu lesen, muss natürlich wieder auf das Recovery-System umgestellt und neu gebootet werden.

[Bearbeiten] Sonstige Tipps und Tricks

• Der Server sollte immer über die Web-Oberfläche des Providers neu gestartet werden, da die Erfahrung gezeigt hat, dass er sonst (manchmal?) nicht mehr selbständig hochfährt. Ist dies passiert, kann er aber wieder über einen Neustart über die Web-Oberfläche des Providers zum Leben erweckt werden.

[Bearbeiten] Links

• Gentoo Handbuch - Offizielles Gentoo Handbuch
• Gentoo on a 1&1 vServer - Etwas älterer Blog-Eintrag zum Thema.