Xen-Tools: Xen-Hooks

Wer einen Server mit Xen betreibt wird häufig eine bestimmte Grundkonfiguration für die virtuellen Maschinen (VM) verwenden. Diese bei jeder neuen Maschine manuell herzustellen ist fehleranfällig und zeitaufwendig.

Mit Xen-Tools kann man hier Abhilfe schaffen.

Der Befehl xen-create-image kennt sog. Hooks die nach der Durchführung von debootstrap angewendet werden. Diese Hooks ermöglichen eine umfassende Systemkonfiguration während der Erstellung einer neuen VM. Sie befinden sich in Form von Shell-Scripten im Verzeichnis /usr/lib/xen-tools/. In dem Verzeichnis gibt es für jede Distribution die über den Parameter –dist angegeben werden kann bestimmte Hooks.

Diese leiten sich in der Regel in Form von Symlinks von einer common-Scriptsammlung ab. Lediglich distributionsspezifische Abweichungen werden nicht von common abgeleitet. Diese Hooks können z.B. Benutzer von Hostsystem in die VM übernehmen. Es können aber auch eigene Scripte in den Erstellungsablauf eingestellt werden:

#!/bin/sh

prefix=$1

#
# Source our common functions
#
if [ -e /usr/lib/xen-tools/common.sh ]; then
  . /usr/lib/xen-tools/common.sh
else
  . ./hooks/common.sh
fi

#
# Log our start
#
logMessage Script $0 starting

#
# create /backup
#
if [ ! -d ${prefix}/backup ]; then
  if mkdir -p ${prefix}/backup; then
    logMessage “successfully created /backup”
  else
    logMessage “failed to create /backup”
  fi
fi

#
# add user backupuser
#
if chroot ${prefix} /usr/sbin/useradd -d /backup/obnam -m backupuser; then
  logMessage “successfully added backupuser”
else
  logMessage “failed to add backupuser”
fi

#
# create .ssh directory
#
if [ ! -d ${prefix}/backup/obnam/.ssh ]; then
  if mkdir -p ${prefix}/backup/obnam/.ssh; then
    logMessage “successfully created .ssh”
  else
    logMessage “failed to create .ssh”
  fi
fi

#
# add ssh-key to authorized_keys2
#
if echo “ssh-rsa [rsa_key_from ~/.ssh/id_rsa.pub] root@hosting” >> ${prefix}/backup/obnam/.ssh/authorized_keys2; then
  logMessage “successfully added ssh-key”
else
  logMessage “failed to add ssh-key”
fi

#
# disable sftp-subsystem and enable internal sftp
#
if [ -f ${prefix}/etc/ssh/sshd_config ]; then
  if sed -i ‘s/Subsystem sftp/#Subsystem sftp/’ ${prefix}/etc/ssh/sshd_config; then
    logMessage “successfully disabled sftp-Subsystem”
  else
    logMessage “failed to disable sftp-Subsystem”
  fi
if (cat << 'EOF' >> ${prefix}/etc/ssh/sshd_config
Subsystem sftp internal-sftp
Match user backupuser
ChrootDirectory /backup/obnam
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
EOF
); then
    logMessage “successfully altered sshd_config”
  else
    logMessage “failed to alter sshd_config”
  fi
fi

#
# Set user and group for sftp jail
#
if chown root:root ${prefix}/backup/obnam; then
  logMessage “successfully chowned /backup/obnam for sftp-jail”
else
  logMessage “failed to chown /backup/obnam for sftp-jail”
fi
if mkdir ${prefix}/backup/obnam/repo; then
  logMessage “successfully created repo-dir for obnam”
else
  logMessage “failed to create repo-dir for obnam”
fi
if chroot ${prefix} chown backupuser:backupuser /backup/obnam/repo; then
  logMessage “successfully chowned /backup/obnam/repo”
else
  logMessage “failed to chown /backup/obnam/repo”
fi

#
# Install obnam
#
installDebianPackage ${prefix} obnam

#
# Log our finish
#
logMessage Script $0 finished

Das oben aufgeführte Script 97-cust-backup-config dient zur Grundeinrichtung eines auf Debian Wheezy basierenden Backupsystems.

Das Script nimmt grundlegende Systemeinstellungen vor, legt Benutzer an, Installiert und Konfiguriert diverse Zusatzprogramme und stellt Anbindungen zu Überwachungssystemen wie Iginga und Munin her.

Zunächst werden Funktionen wie logMessage und installDebianPackage initialisiert und dem Script zur Verfügung gestellt.

Danach geben wir den Start des entsprechenden Scriptes bekannt, diese Nachricht wird nur angezeigt und im Logfile vermerkt wenn xen-create-image mit dem Parameter –verbose ausgeführt wurde.

Im Anschluss legen das Verzeichnis /backup in der VM an. Der Parameter ${prefix} verweist hierbei auf den im Xen-Hostsystem gemounteten Inhalt der neuen VM. Lässt man ${prefix} weg würde das Verzeichnis im Xen-Hostsystem angelegt, was ebenfalls praktisch sein kann. Die korrekte Erzeugung des Verzeichnisses wird durch die if-Abfrage überwacht und es wird entsprechende Meldung ausgegeben (wenn –verbose aktiv ist).

Nun wird der Benutzer backupuser mit dem Homeverzeichnis /backup/obnam/ erzeugt. Außerdem wird die Datei .authorized_keys2 für den backupuser abgelegt. Mit dieser Einstellung kann das zu sichernde System selbstständig und ohne Kennwortinteraktion auf den Backupserver zugreifen und dort Daten ablegen.

Für den Benutzer backupuser wird nun noch ein SFTP-Jail eingerichtet und hierzu die /etc/ssh/sshd_config angepasst. Der Backupuser ist somit in seinem Homeverzeichnis eingesperrt und kann nicht mit dem eigentlichen Betriebssystem interagieren, was die Sicherheit des Systems erhöht. Das Verzeichnis /backup/obnam/repo/ wird für den Benutzer angelegt und schreibbar gemacht. Hier wird später das Backup abgelegt.

Abschließend wird das Backupprogramm obnam installiert. Dies ist nicht zwingend nötig, da das Backup von dem zu sichernden System aus nur auf dem Backupserver abgelegt wird, aber so wird die Funktion obnam nagios-last-backup-age auf dem Backupserver nutzbar.

Um Befehle direkt in der (noch nicht gestarteten) VM, statt im Xen-Hostsystem, auszuführen wird dem gewünschten Befehl chroot ${prefix} vorangestellt.

Services müssen nach einer Konfigurationsänderung nicht neu gestartet werden, da die Konfiguration der VM noch im ausgeschalteten Zustand vorgenommen wird und erst bei Start der VM erstmals aktiv werden.

Tags: linux xen xentools xen hooks vm