Absicherung von Apache Webservern durch virtuelle Maschinen

Transcription

Absicherung von Apache Webservern
durch virtuelle Maschinen
unter Debian GNU/Linux
Dokumentation der betrieblichen Projektarbeit
zur Erlangung des Abschlusses
Fachinformatiker/Systemintegration
Robin Schröder
Institut für Theoretische Physik IV
Ruhr-Universität Bochum
18. November 2005
Absicherung von Webservern durch Virtualisierung
18. November 2005
Inhaltsverzeichnis
1 Projektüberblick
1.1 Projektthema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Projektbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Projektumfeld und Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . .
3
3
3
3
2 Problemanalyse
2.1 Ist-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Soll-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Kosten-Nutzen-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
4
5
3 Auswahl des Lösungswegs
3.1 Alternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
7
7
4 Planung der Durchführung
4.1 Zeitplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
8
5 Durchführung
5.1 Konfiguration der Hard- und Software . . . . . . . . . .
5.1.1 Installation der Test-Maschine . . . . . . . . . .
5.1.2 Konfiguration der VMs auf der Test-Maschine . .
5.1.3 Tests auf der Test-Maschine . . . . . . . . . . . .
5.1.4 Installation der Produktiv-Maschine . . . . . . .
5.1.5 Übertragen der VMs auf die Produktiv-Maschine
5.2 Abschließende Arbeiten und Tests . . . . . . . . . . . .
5.3 Probleme . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Abweichung vom Projektantrag . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
9
9
9
10
10
11
11
11
12
12
6 Evaluation der Projektergebnisse
6.1 Vergleich mit dem Soll-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
13
7 Anhang
7.1 Skript create xm“ zum Erzeugen einer VM (auszugsweise)
”
7.2 Dokumentation für Administratoren . . . . . . . . . . . . .
7.2.1 Installation der Xen-Kernel und Xen-Tools . . . . .
7.2.2 Erzeugen virtueller Maschinen . . . . . . . . . . . .
7.2.3 Grundkonfiguration virtueller Maschinen . . . . . . .
7.2.4 Bedienung von Xen mit dem Befehl xm . . . . . . . .
7.2.5 Antworten auf verschiedene Fragen . . . . . . . . . .
14
14
16
16
17
18
19
21
Robin Schröder
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18. November 2005
1 Projektüberblick
1.1 Projektthema
Thema dieses Projekts ist die Installation und Konfiguration der Virtualisierungslösung Xen
auf einem Server der Fakultät für Physik und Astronomie der Ruhr-Universität Bochum zum
sicheren Betrieb von Webservern auf virtuellen Maschinen. Als Betriebssystem wird Debian
GNU/Linux 3.1 (im Folgenden Debian Sarge genannt) auf der amd64 -Architektur verwendet.
1.2 Projektbeschreibung
Zur Erhöhung der Sicherheit und zur Vereinfachung der Wartung vieler Apache2 Webserver
soll in der Fakultät für Physik und Astronomie der Ruhr-Universität Bochum ein auf virtuellen Maschinen basierendes System geschaffen werden. Virtuelle Maschinen (im Folgenden VM
genannt) sind komplette Betriebssysteme, die parallel auf derselben Hardware laufen und sich
die Systemressourcen effizient teilen. Die Virtualisierungs-Technologie Xen stellt dafür KernelKomponenten und Userspace-Tools zur Verfügung, die an Debian Sarge anzupassen sind.
Die zahlreichen Webseiten der Fakultät für Physik und Astronomie, die derzeit auf einem einzigen Apache2 Webserver laufen, sollen in verschiedene VMs auf einer neuen Maschine ausgelagert
werden. Dazu muss auf einer neuen, jedoch bereits vorhandenen Maschine Debian Sarge installiert werden. Im Anschluss daran muss ein neuer Kernel modifiziert, konfiguriert und kompiliert
werden. Pro VM ist ein virtuelles Dateisystem mit den wichtigsten Datei- und Verzeichnisstrukturen sowie einem Apache2 Webserver mit entsprechenden Tools zu erstellen. Die Konfiguration
für VMs sowie nötige Vorarbeiten werde ich zunächst an einem Testsystem durchführen und für
den Produktivbetrieb vorbereiten. Dies umfasst das Kompilieren der Kernel sowie der UserspaceTools und das Erstellen der VMs. Im Anschluss daran werde ich die vorbereiteten Arbeiten auf
die Produktiv-Maschine übertragen.
1.3 Projektumfeld und Rahmenbedingungen
Das Institut für Theoretische Physik IV (Weltraum- und Astrophysik) betreibt für sich selbst
sowie für die gesamte Fakultät für Physik und Astronomie Mail-, Web- und Datenbank-Server
sowie einige weitere Dienste und greift dabei auf die IT-Infrastruktur des Rechenzentrums der
Ruhr-Universität Bochum zurück.
Die komplette Bearbeitung des Projekts wird in den Räumen des Instituts für Theoretische
Physik IV durchgeführt werden. Dort wird das Testsystem installiert und konfiguriert sowie das
neue Produktivsystem getestet und in Betrieb genommen. Nach der Durchführung des Projekts
wird der Auftraggeber eine Unterweisung erhalten.
Auftraggeber des Projekts ist Herr Bernd Neubacher als Bevollmächtigter des Instituts für
Theoretische Physik IV der Ruhr-Universität Bochum. Durch Herrn Neubacher erfolgt auch die
Abnahme des Projekts inklusive der Dokumentation für Administratoren.
Robin Schröder
3
18. November 2005
2 Problemanalyse
2.1 Ist-Analyse
Die Fakultät für Physik und Astronomie sowie das Institut für Theoretische Physik IV der
Ruhr-Universität Bochum verfügen derzeit über jeweils eine Maschine, die mit Apache2 unter
Debian Sarge betrieben wird und als Mail- und Webserver sowie als zentraler MultifunktionsServer (NIS, DHCP, DNS, SMTP, IMAP) dient. Das Hosting verschiedener Websites wird zur Zeit
über Apache2 VirtualHosts geregelt. Lediglich ein Apache2 Daemon pro Maschine bedient bis
zu 20 verschiedene Domains, teilweise im Produktiv-, teilweise im Testbetrieb.
Aufgrund vermehrter Angriffe auf diese Webserver in letzter Zeit stieg der Administrationsaufwand enorm. Angreifern ist es zurzeit möglich einen kompletten Server zu kompromittieren,
wenn eine Möglichkeit zum Einbruch durch nur eine der gehosteten Websites gefunden wird.
NIS, NFS, DNS
HTTP, HTTPS
Clients
DHCP, SMTP, IMAP
Server
Abbildung 2.1: Zugriff von Clients auf denselben Server über verschiedene Netzwerk-Interfaces
2.2 Soll-Konzept
Ziel dieses Projekts ist es, die auf Apache2 basierenden Webserver des Instituts für Theoretische
Physik IV und der Fakultät für Physik und Astronomie der Ruhr-Universität Bochum mit Xen
zu virtualisieren.
Das Hosting der vorhandenen Websites soll von den Maschinen des Instituts für Theoretische Physik IV und der Fakultät für Physik und Astronomie in VMs auf eine neue Maschine
ausgelagert werden. Ziel ist es, dadurch eine flexible, einfach zu wartende, den Ansprüchen von
Backups genügende und einfach zu ersetzende, sichere Lösung zu schaffen. Es soll weiterhin eine
minimale Ausfallzeit nach einer Kompromittierung erreicht werden. Virtuelle Maschinen sollen
zum einen aus Kostengründen, zum anderen aus Gründen der einfacheren Wartung verwendet
werden.
Robin Schröder
4
Xen Server
18. November 2005
Clients
HTTP
VMs
HTTPS
NIS, NFS, DNS, DHCP
SMTP, IMAP
Abbildung 2.2: Zugriff von Clients auf virtuelle Maschinen im Xen Server
Aus der Auslagerung der Websites resultieren folgende Vorteile bzw. Verbesserungen gegenüber der bisherigen Lösung:
Vorteil
höhere Flexibilität
einfachere Wartung
höhere Sicherheit
Hardware-Kosten
Begründung
VMs können schnell und einfach ausgetauscht und konfiguriert werden. Sie können auf Testsystemen vorbereitet und problemlos auf das
Produktivsystem übertragen werden.
Die Wartung von VMs kann einzeln erfolgen, dabei wird nicht das komplette Produktivsystem beeinträchtigt.
Durch Abschottung voneinander und durch schreibgeschütztes Mounten einzelner Daten in VMs ist eine erheblich höhere Sicherheit gegenüber Angriffen gegeben.
Es wird nur einmal Hardware benötigt. Bei ausreichender Dimensionierung können viele VMs darauf betrieben werden.
Tabelle 2.1: Vorteile der Verwendung virtueller Maschinen
2.3 Kosten-Nutzen-Analyse
Bei der Ist-Lösung entstehen im Fall einer Kompromittierung der Produktiv-Maschine durch
eine der Websites erfahrungsgemäß in etwa folgende Kosten für die Wiederherstellung eines
sicheren Zustands der kompromittierten Maschine:
Im Institut für Theoretische Physik IV der Ruhr-Universität Bochum arbeiten ca. 20 Physiker
8 Stunden pro Tag zu einem Stundenlohn von je 25 e. Durch einen Kollateralschaden wie die
Kompromittierung einer der vorhandenen zentralen Maschinen, die momentan die Websites
hosten, entstehen aufgrund des Produktionsausfalls folgende Kosten:
Kosten der Physiker: 25 e · 8 Std. · 20 Physiker = 4.000 e
Hinzu kommen die Kosten für eine Fachkraft, die ca. 8 Stunden zu einem Stundenlohn von etwa
25 e arbeitet, um die kompromittierte Maschine wieder in einen produktionsfähigen Zustand
zu versetzen:
Robin Schröder
5
18. November 2005
Kosten für eine Fachkraft: 25 e · 8 Std. = 200 e
Gesamtkosten Ist-Lösung: 4.000 e + 200 e = 4.200 e
Die Soll-Lösung verursacht bei gleichem Szenario wesentlich geringere Kosten, da der Kollateralschaden ausbleibt. Die ca. 20 Physiker können lediglich unter Umständen ihre Webseite
zeitweise nicht aufrufen. Die Kosten für diesen Ausfall sind allerdings nicht zu beziffern, da die
Anzahl der potenziellen Webseitenaufrufe während des Ausfalls der VM nicht bekannt ist. Es
bleiben also nur die Kosten für eine Fachkraft, die zudem wesentlich weniger Zeit für die Rekonstruktion eines produktionsfähigen Zustands benötigt, da lediglich ein Webserver im ungünstigsten Fall neu installiert werden muss, keine weiteren unter Umständen betroffenen Services
(in unserem Fall NIS, NFS, DNS, DHCP, SMTP oder IMAP):
Kosten für eine Fachkraft: 25 e · 2 Std. = 50 e
Die Ausfallzeit eines kompromittierten Webservers verringert sich durch die Soll-Lösung auf
ca. ein Achtel der Ausfallzeit der Ist-Lösung. Um die Kosten der Soll-Lösung zu ermitteln bedarf
es jedoch zusätzlich einer Berücksichtigung der für dieses Projekt einmalig entstehenden Kosten.
Diese setzen sich wie folgt zusammen:
4,26 e
35 Std.
4, 26 e · 35 Std. = 149, 10 e
885,99 e
Stundenlohn Auszubildender:
Arbeitszeit:
Kosten für Arbeitsleistungen:
Kosten für neue Maschine:
Die Projektgesamtkosten belaufen sich also auf 149, 10 e + 885, 99 e = 1.035, 09 e.
Das Projekt rentiert sich bereits bei der ersten Kompromittierung, was folgende Rechnung
verdeutlicht:
Nach etwa n Kompromittierungen rentiert sich das Projekt, wobei
n · (Gesamtkosten Ist-Lösung) = n · (Kosten Fachkraft Soll-Lösung) + Projektgesamtkosten
also
Projektgesamtkosten
=n
(Gesamtkosten Ist-Lösung) − (Kosten Fachkraft Soll-Lösung)
Das Projekt rentiert sich also nach
1.035,09 e
= 0,25
(4.200 e) − (50 e)
Kompromittierungen. Da n < 1 ist, rentiert sich das Projekt schon bei der ersten Kompromittierung.
Robin Schröder
6
18. November 2005
3 Auswahl des Lösungswegs
3.1 Alternativen
Auf dem Markt befindet sich eine Vielzahl von Produkten, die Virtualisierungstechnik bieten.
Die bekanntesten und am weitesten verbreiteten Produkte für den Bereich Unix/Linux wurden
für dieses Projekt in Betracht gezogen. Es gibt trotz der im Kern gleichen Funktionalität große
Unterschiede zwischen den Produkten in folgenden Bereichen:
• Anschaffungskosten
• Hardware-Ausnutzung
• Flexibilität
• Stabilität
• Performance
• vorhandene Erfahrung meinerseits
3.2 Auswahl
Nach meiner Erfahrung und nach Recherchen auf den Webseiten der Hersteller und in diversen
Foren im Internet stellte ich folgende Produkte und Informationen zur Entscheidungsfindung
zusammen:
Kriterium
Anschaffungskosten
Hardware-Ausnutzung
Flexibilität
Stabilität
Performance
Erfahrung vorhanden
VMware1
hoch
gut
gut
sehr gut
gut
ja
Xen2
gering
gut
sehr gut
sehr gut
sehr gut
ja
UserModeLinux3
gering
eher schlecht
gut
schlecht
eher schlecht
ja
VServer4
gering
gut
sehr gut
gut
sehr gut
nein
Tabelle 3.1: Entscheidungskriterien für den gewählten Lösungsweg
VMware scheidet von vornherein aufgrund seiner hohen Anschaffungskosten in den in Frage
kommenden Varianten GSX Server und ESX Server aus. Xen bietet klare Vorteile gegenüber
UserModeLinux und VServer aufgrund seiner Stabilität und Performance.
Nach Abwägung der Vor- und Nachteile sowie nach Rücksprache mit dem Auftraggeber entschied ich mich für den Einsatz von Xen als Virtualisierungstechnologie. Eigene Erfahrung ist
bereits aus vorangegangenen Projekten vorhanden und Xen ist kostenlos zu beschaffen, da es
Open Source ist und unter der GNU General Public License 5 (GPL) steht.
1
http://www.vmware.com/
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
3
http://user-mode-linux.sourceforge.net/
4
http://linux-vserver.org/
5
http://www.gnu.org/licenses/gpl.html
2
Robin Schröder
7
18. November 2005
4 Planung der Durchführung
4.1 Zeitplan
Vorbereitung
Planung der Serverkonzeption
3,5 Std.
• Beschaffung einer geeigneten Maschine
• Erfassung der zu migrierenden Websites
• Klärung der Netz-Anbindung der neuen Maschine mit
dem Auftraggeber
Durchführung
Installation der Test-Maschine
23 Std.
• Installation von Debian Sarge und entspr. Software
• Installation und Konfiguration von Xen
Konfiguration der Test-Maschine
• Anpassen des Skripts zur Erzeugung einer virtuellen
Maschine
• Erzeugen der virtuellen Maschinen
• Erzeugen von Konfigurationen für den Produktivbetrieb
Produktiv-Maschine
• Installation von Debian Sarge und entspr. Software
• Installation und Konfiguration von Xen
• Kopieren der VM-Konfigurationen des Testsystems
Dokumentation
Projektdokumentation
7,5 Std.
• Erstellen der Projektdokumentation nach den Vorgaben
der IHK Bochum
Dokumentation für Administratoren
• Erstellen einer Dokumentation für Administratoren
Übergabe
Abnahme des Projekts durch Herrn Neubacher
1 Std.
Insgesamt: 35 Std.
Tabelle 4.1: Installation der Virtualisierungslösung Xen auf einem Webserver
Robin Schröder
8
18. November 2005
5 Durchführung
5.1 Konfiguration der Hard- und Software
Zur Durchführung des Projekts verwendete ich eine Test-Maschine mit folgender Ausstattung:
CPU:
Mainboard:
RAM:
HDD:
CD-ROM:
Netzteil:
Gehäuse:
AMD Athlon64 3000+
MSI K8N Neo2 Platinum
512 MB DDR-RAM CL3 (Kingston, non-ECC)
80 GB IDE, Maxtor
40-fach
Enermax EG365AX-VE(G) 353 Watt
Standard-ATX-Tower
Als Produktiv-System beschaffte ich eine Maschine mit folgender Ausstattung:
CPU:
Mainboard:
RAM:
HDDs:
Netzteil:
Gehäuse:
AMD Athlon64 3200+
TYAN Tomcat K8E (S2865)
2x 512 MB DDR-RAM CL3 (Kingston, non-ECC)
80 GB SATA, Maxtor (System u. VMs)
2x 250 GB SATA Hitachi (Daten)
Enermax EG365AX-VE(G) 353 Watt
19” 2HE Chenbro (CB-223)
5.1.1 Installation der Test-Maschine
Zunächst nahm ich auf der Test-Maschine eine Grundinstallation von Debian Sarge vor. Im Anschluss installierte ich weitere Programmpakete, die für den Kompiliervorgang von Xen nötig
sind. Dies sind Compiler und benötigte Bibliotheken zur Erzeugung der Xen-Kernel, Werkzeuge zur Konfiguration der Netzwerk-Schnittstellen, LATEX-Tools zum Erzeugen der Xen Dokumentation und Werkzeuge zum Erzeugen neuer Instanzen von Debian GNU/Linux. Weiterhin
installierte ich noch einen NFS-Server, mit dessen Hilfe später Daten für die VMs freigegeben
werden. Als Bootmanager verwendete ich GRUB, den Standard Bootmanager von Debian Sarge,
um eine reibungslose Zusammenarbeit mit Xen zu ermöglichen.
Nach dem Download des Xen Quellcodes kompilierte ich diesen zunächst mit den Standardeinstellungen auf der Test-Maschine. Danach passte ich den Dom0 -Kernel (Kernel für das HostSystem Domain 0“) sowie den DomU -Kernel (Kernel für VMs) an die vorhandene Hardware
”
und an den gewünschten Funktionsumfang an. Die Vorgehensweise ist im Wesentlichen dieselbe
wie bei Standard-Kernels. Den Dom0 - und DomU -Kernel kompilierte ich danach erneut und
installierte sie anschließend. Weiterhin passte ich die GRUB Konfiguration so an, dass der XenKernel beim Booten automatisch gestartet wird. Dieser lädt dann den Dom0 -Kernel nach und
bootet die Domain 0. Aus Domain 0 heraus werden später mit dem Xen Userspace Tool xm
weitere Domains (DomU ) gestartet.
Vor dem Booten des Xen-Kernels erstellte ich unter /dev noch weitere 56 Loop-devices, da
standardmäßig nur 8 zur Verfügung stehen. Man benötigt für jede in einer VM gemounteten
Robin Schröder
9
18. November 2005
Festplattenpartition ein Loop-device, d.h. 3 pro VM. Die Anzahl der Loop-Devices muss dem
Dom0 -Kernel beim Booten übergeben werden (Kernel-Parameter max loop=64).
5.1.2 Konfiguration der VMs auf der Test-Maschine
Das Erzeugen und die weitgehende Konfiguration einer VM ist ein immer wiederkehrender Vorgang, den ich bereits im Vorfeld dieses Projekts in einem einfachen Shell-Skript zusammengefasst
habe. Das Skript wurde von mir für dieses Projekt lediglich modifiziert. Der Quellcode der modifizierten Version befindet sich auszugsweise im Anhang dieses Dokuments. Ich gehe in diesem
Abschnitt auf die Arbeitsschritte ein, die das Script automatisiert in ca. 3–4 Minuten durchführt.
Zu Beginn des Skripts wird ein Verzeichnis für die neue VM erstellt. Darin werden drei Dateien erzeugt. In zwei der Dateien (jeweils 512 MB) wird anschließend ein EXT3 -Dateisystem
angelegt, in einer (128 MB) ein SWAP -Dateisystem für SWAP -Speicher in der VM. In einem
Unterverzeichnis (loop/) werden die zwei mit EXT3 formatierten Dateien gemountet (nach
loop/ und loop/var/).
Mit Hilfe des Programms debootstrap wird nun in den gemounteten Dateien ein DebianSarge-Grundsystem installiert. Dieses wird im Anschluss konfiguriert, d.h. Position der Dateisysteme, Hostname der VM, Zeitzone und Netzwerkeinstellungen und weitere Optionen werden
in Dateien unterhalb loop/etc/ eingetragen. Weiterhin werden noch die lokalen Debian-Mirror
in loop/etc/apt/sources.list eingetragen, damit automatisch Updates auf der VM gefahren
werden können und die restliche Software installiert werden kann.
Nach dem Durchlauf von debootstrap ist nur ein Minimalsystem installiert, das noch durch
weitere Software (ssh, apache2, ...) ergänzt werden muss. Auch diese Software wird durch Modifikation mehrerer Dateien unterhalb loop/etc/ konfiguriert. Es wird eine Standard Apache2Konfiguration erstellt und ein Verzeichnis für NFS eingerichtet, wenn am Anfang des Scripts
entsprechende Eingaben gemacht wurden.
Zum Abschluss fragt das Skript noch ein root Passwort für die neue VM ab und es erscheinen
Hinweise zum Start der neu erstellten VM. Nach dem Unmounten der Dateisysteme ist der
Durchlauf des Skripts abgeschlossen. Es existiert eine fertige VM.
Manuelle Anpassungen in jeder automatisiert erzeugten VM müssen nur im Bereich der
Webserver-Konfiguration vorgenommen werden, da mein Skript lediglich eine Standardkonfiguration erzeugt.
Es wurden von mir insgesamt folgende sieben VMs auf der Test-Maschine erzeugt, die später
unverändert auf die Produktiv-Maschine übertragen wurden:
schulforschung.physik.ruhr-uni-bochum.de
iau.physik.ruhr-uni-bochum.de
suedpol.physik.ruhr-uni-bochum.de
debian.physik.ruhr-uni-bochum.de
fechten.physik.ruhr-uni-bochum.de
sfb591.physik.ruhr-uni-bochum.de
dp.physik.ruhr-uni-bochum.de
www-rest.physik.ruhr-uni-bochum.de
5.1.3 Tests auf der Test-Maschine
Ich testete den Zugriff auf jede VM per HTTP, auf der Maschine suedpol auch per HTTPS. Dabei
trat lediglich das Problem auf, dass sich nach erfolgter Eintragung der neuen VMs ins DNS noch
Robin Schröder
10
18. November 2005
veraltete Einträge im DNS-Cache unseres Instituts befanden, die eine erfolgreiche Verbindung zu
der VM debian zunächst verhinderten. Ein Leeren des DNS-Cache löste das Problem.
5.1.4 Installation der Produktiv-Maschine
Die Installation der Produktiv-Maschine führte ich zunächst genau so durch wie die Installation
der Test-Maschine. Das Konfigurieren und Kompilieren des Xen Quellcodes habe ich jedoch nicht
noch einmal im Ganzen durchgeführt. Ich kopierte den fertig konfigurierten Verzeichnisbaum
von der Test-Maschine auf die Produktiv-Maschine und konnte ihn reibungslos dort installieren.
Lediglich Dom0 - und DomU -Kernel mussten vor der Installation auf der Produktiv-Maschine
an die andere Hardware angepasst und erneut kompiliert werden.
Vor einem Reboot passte ich noch, wie auf der Test-Maschine, den GRUB Bootmanager an
und kopierte rekursiv den Inhalt des Verzeichnisses /etc/xen von der Test-Maschine auf die
Produktiv-Maschine. Unterhalb von /etc/xen befinden sich die zum Start der VMs nötigen
Skripte und Definitions-Dateien.
5.1.5 Übertragen der VMs auf die Produktiv-Maschine
Im Anschluss an die Installation von Xen auf der Produktiv-Maschine und einem Reboot kopierte
ich die auf der Test-Maschine mit Hilfe meines Skripts vorbereiteten VMs in das Verzeichnis
/opt/xen-machines/ der Produktiv-Maschine. Ich konnte die VMs nach manuellem Ändern
der Netzwerk-Konfiguration einzeln probeweise starten. Dabei traten keine Fehler auf.
Vor der Migration der Webseiten in die erzeugten VMs war es nötig, sich Gedanken über die
MySQL-Anbindung einzelner Webseiten zu machen. Der MySQL-Server ist nach der Migration
nicht mehr localhost“, sondern er bleibt weiterhin auf dem derzeitigen Server-System. Sämt”
liche Verbindungs-Initialisierungen in den betroffenen Webseiten müssen umgeschrieben sowie
auf dem SQL-Server die Zugriffsberechtigungen angepasst werden.
Das Anpassen der Berechtigungen auf dem MySQL-Server erledigte ich mit wenigen SQLBefehlen. Die Anpassung der betroffenen Webseiten delegierte ich an die zuständigen Personen.
Diese hatten im Allgemeinen nicht viel zu ändern, da die Verbindung meist zentral in einer
PHP-Datei aufgebaut wird.
5.2 Abschließende Arbeiten und Tests
Um das interne Netz zu entlasten, beschloss ich in Absprache mit dem Auftraggeber, die Webseiten lokal auf der Produktiv-Maschine abzulegen und von dort aus für die VMs zu exportieren.
Der Umfang der Webseiten überschreitet inklusive Debian-Mirror 300 GB, so dass ich das Kopieren der Daten über Nacht per rsync durchführte, nachdem ich den Schreibzugriff auf dem
alten System unterbunden hatte.
In einem ersten Schritt migrierte ich den Debian-Mirror debian.physik.ruhr-uni-bochum.de
zur VM debian. Einen Tag später folgte der Umzug der restlichen Websites in die vorbereiteten
VMs. Um IP-Konflikte zu vermeiden, musste ich darauf achten, zuerst den VirtualHost und
das entsprechende Netzwerk-Interface auf dem alten Webserver zu deaktivieren, dann erst die
VM zu booten. Es entstand dabei pro VM eine Ausfallzeit der Webseiten von weniger als fünf
Minuten.
Jede neu gebootete VM testete ich durch Zugriffe von verschiedenen Clients aus, bevor ich
mich an die nächste VM begab.
Robin Schröder
11
18. November 2005
5.3 Probleme
Beim Testen einer VM trat ein Problem mit der MySQL-Konfiguration auf. Es handelte sich
um einen Tippfehler, der aufgrund des im Web-Browser angezeigten MySQL-Error schnell zu
finden und zu beheben war. Der zuständige Webmaster wurde von mir im Nachhinein über die
durchgeführte Korrektur in Kenntnis gesetzt.
Einen Tag nach Migration der VM debian trat ein weiteres Problem auf: Die VM debian
hat einen im Vergleich zu den anderen VMs extrem hohen Traffic auf dem virtuellen NetzwerkInterface, da sie unser Debian-Mirror ist. Dies verursachte in unregelmäßigen Abständen unter
hoher Last einen Absturz der VM durch Kernel Panic. Das Nachforschen auf der Mailingliste
xen-devel1 ergab schnell, dass der Kernel Panic in der beschriebenen Situation ein bekanntes
Problem des Netzwerk-Treibers für VMs unter Xen ist, an dessen Behebung gearbeitet wird.
Abhilfe schaffte vorerst das Erhöhen des der VM zugewiesenen Arbeitsspeichers von 128 MB
auf 256 MB. Sobald ein Patch zum Beheben des Problems verfügbar ist, sollte dieser eingespielt
werden.
5.4 Abweichung vom Projektantrag
In der Zeit zwischen Projektantrag und Beginn des Durchführungszeitraums hat sich auf den
beiden Server-Systemen, die ursprünglich mit Xen ausgestattet werden sollten, einiges verändert.
Sie sind für den täglichen Ablauf unabdingbar, so dass ein längerer Ausfall der Systeme einen
weitgehenden Ausfall der Infrastruktur des Netzwerks der Physik mit sich bringen würde.
Aus diesem Grund weiche ich in der Durchführung geringfügig vom Projektantrag ab: Ich
habe Xen nicht auf den zwei ursprünglich vorgesehenen, sich bereits im produktiven Einsatz
befindenden Maschinen installiert, sondern auf einer neuen Maschine, die nach Abschluss des
Projekts sämtliche Webseiten der Fakultät für Physik und Astronomie zur Verfügung stellt. Die
Maschine ist von mir zu Beginn des Projekts beschafft und mit einer Grundinstallation von
Debian Sarge installiert worden.
1
http://lists.xensource.com/xen-devel
Robin Schröder
12
18. November 2005
6 Evaluation der Projektergebnisse
6.1 Vergleich mit dem Soll-Konzept
Das Projekt konnte unter Einhaltung der vorgesehenen 35 Stunden durchgeführt werden. Der
Rückgriff auf die angesetzte Pufferzeit ergab sich zu 0,5 Stunden im Bereich der Vorbereitung,
zu 1 Stunde im Bereich der Durchführung und zu 1,5 Stunden im Bereich der Dokumentation.
Die vorgegebenen Ziele
• Erhöhung der Sicherheit
• Erhöhung der Flexibilität
• Erhöhung der Stabilität
• hohe Performance
• optimale Hardware-Ausnutzung
• einfache Wartung
• niedrige Anschaffungskosten
wurden erreicht.
6.2 Ausblick
Das Projekt ist erfolgreich durchgeführt und abgeschlossen worden. Die verfolgten Ziele wurden
trotz kleinerer Probleme unter Nutzung von Pufferzeit erreicht.
Die in diesem Projekt aufgesetzte Maschine wird in der Fakultät für Physik und Astronomie der Ruhr-Universität Bochum seit Abschluss des Projekts produktiv eingesetzt. Durch die
erhöhte Sicherheit des Systems ist mit wesentlich weniger Ausfallzeiten nach einer Kompromittierung zu rechnen. Daher soll das durchgeführte Projekt in naher Zukunft unter anderem um
folgende Punkte erweitert werden:
• Anbindung an das vorhandene Backup-System
• automatisierte Wartungsroutinen durch Skript-Lösung (Eigenentwicklung)
• Mailserver (MTAs) in virtuellen Maschinen
• Logging der VMs auf einem zentralen Log-Server
• verschlüsselte MySQL-Anbindung der Websites in den VMs durch SSH-Tunnel
Aufgrund guter erster Erfahrungen mit Xen als Grundlage für Webserver sollen eventuell
weitere Dienste mit Hilfe zusätzlicher Host-Maschinen mit Xen virtualisiert werden.
Robin Schröder
13
18. November 2005
7 Anhang
7.1 Skript create xm“ zum Erzeugen einer VM (auszugsweise)
”
#!/bin/sh
#################################################################
# Script zur Erzeugung einer neuen virtuellen Maschine fuer Xen #
#################################################################
# Variablen definieren
MACHINES ROOT="/opt/xen-machines"
# Verzeichnis, in dem alle Maschinen liegen
KERNEL="/boot/vmlinuz-2.6-xenU"
# Kernel der virtuellen Maschine
MEMSIZE=128
# Arbeitsspeicher der virtuellen Maschine
DEBIAN MIRROR="http://debian.physik.ruhr-uni-bochum.de/debian-amd64/debian-pure64"
DIST="sarge"
# Version (z.Zt. nur ’sarge’ getestet)
# Debian Mirror
# Parameter fuer ’debootstrap’
DEBOOTSTRAP ARGS="--arch amd64 --exclude=pcmcia-cs,ppp,pppconfig,pppoe,pppoeconf,exim4,exim4-base,\
exim4-config,exim4-daemon-light,mailx,at,fdutils,info,modconf,libident"
# Zusaetzlich zu installierende Pakete
INSTALL PACKAGES="dnsutils bzip2 lynx less apache2 libapache2-mod-php4 php4-mysql mysql-client"
LOCALE="Europe/Berlin"
# Locale relativ zu /usr/share/zoneinfo/
LOGPATH="/tmp"
# Pfad der Log-Datei
LOGFILE="create xm.$$.log"
# Name der Log-Datei
LOG="${LOGPATH}/${LOGFILE}"
# Name der Maschine vom Benutzer abfragen (unbedingt noetig)
echo ""
echo -n "Name der Maschine: "
read THIS MACHINE
# MAC Adresse der Maschine vom Benutzer abfragen (unbedingt noetig)
echo ""
echo -n "MAC Adresse der Maschine (XX:XX:XX:XX:XX:XX): "
read MAC
# Abfrage, ob die virtuelle Maschine beim Booten
# des Host Systems mit gebootet werden soll
echo ""
echo -n "Soll die virtuelle Maschine beim Booten des Host Systems automatisch mit gebootet werden (j/N)? "
read AUTOBOOT
# Umgebungsvariablen setzen, um Fehlermeldungen zu vermeiden
export LANGUAGE=C
export LC ALL=C
export LANG=C
# Verzeichnis erstellen und rein wechseln
echo -n "Erstelle Verzeichnis "
mkdir ${MACHINES ROOT}/${THIS MACHINE}
cd ${MACHINES ROOT}/${THIS MACHINE}
# Disk-Images erzeugen und formatieren
echo -n "Erzeuge und formatiere Disk Images "
dd if=/dev/zero of=${THIS MACHINE}-root bs=1M seek=512 count=1 >> ${LOG} 2>&1
mke2fs -F -j ${THIS MACHINE}-root >> ${LOG} 2>&1
tune2fs -c0 -i0 ${THIS MACHINE}-root >> ${LOG} 2>&1
dd if=/dev/zero of=${THIS MACHINE}-var bs=1M seek=512 count=1 >> ${LOG} 2>&1
mke2fs -F -j ${THIS MACHINE}-var >> ${LOG} 2>&1
tune2fs -c0 -i0 ${THIS MACHINE}-var >> ${LOG} 2>&1
dd if=/dev/zero of=${THIS MACHINE}-swap bs=1M seek=128 count=1 >> ${LOG} 2>&1
mkswap ${THIS MACHINE}-swap >> ${LOG} 2>&1
# Root-Image mounten und Debian Sarge rein installieren
echo -n "Mounte Root Image "
mkdir ${MACHINES ROOT}/${THIS MACHINE}/loop
mount -t ext3 -o loop ${THIS MACHINE}-root ${MACHINES ROOT}/${THIS MACHINE}/loop >> ${LOG} 2>&1
mkdir ${MACHINES ROOT}/${THIS MACHINE}/loop/var
mount -t ext3 -o loop ${THIS MACHINE}-var ${MACHINES ROOT}/${THIS MACHINE}/loop/var >> ${LOG} 2>&1
echo -n "Erzeuge Basis-System (Ausgabe in ${LOG}) "
debootstrap ${DEBOOTSTRAP ARGS} ${DIST} ${MACHINES ROOT}/${THIS MACHINE}/loop ${DEBIAN MIRROR} >> ${LOG} 2>&1
# Wichtige Dateien im Root-Image modifizieren
echo -n "Konfiguriere virtuelle Maschine "
Robin Schröder
14
echo "# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/hda1 / ext3 defaults,errors=remount-ro 0 1
/dev/hda2 /var ext3 defaults 0 2
/dev/hda3 none swap sw 0 0"> ${MACHINES ROOT}/${THIS MACHINE}/loop/etc/fstab
echo ${THIS MACHINE} > ${MACHINES ROOT}/${THIS MACHINE}/loop/etc/hostname
echo "127.0.0.1 localhost"> ${MACHINES ROOT}/${THIS MACHINE}/loop/etc/hosts
ln -sf /usr/share/zoneinfo/${LOCALE} ${MACHINES ROOT}/${THIS MACHINE}/loop/etc/localtime
echo "auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp"> ${MACHINES ROOT}/${THIS MACHINE}/loop/etc/network/interfaces
echo "deb http://debian.physik.ruhr-uni-bochum.de/debian-amd64/debian-pure64 sarge main contrib non-free
deb http://debian.physik.ruhr-uni-bochum.de/debian-security sarge/updates main contrib non-free"\
> ${MACHINES ROOT}/${THIS MACHINE}/loop/etc/apt/sources.list
# PROC Dateisystem ins Root-Image mounten
echo -n "Mounte PROC Dateisystem ins Root-Image "
mount -t proc none ${MACHINES ROOT}/${THIS MACHINE}/loop/proc >> ${LOG} 2>&1
# Pakete (INSTALL PACKAGES) im Root-Image installieren
chroot ${MACHINES ROOT}/${THIS MACHINE}/loop/ apt-get clean >> ${LOG} 2>&1
chroot ${MACHINES ROOT}/${THIS MACHINE}/loop/ apt-get --assume-yes update >> ${LOG} 2>&1
chroot ${MACHINES ROOT}/${THIS MACHINE}/loop/ apt-get --assume-yes upgrade
chroot ${MACHINES ROOT}/${THIS MACHINE}/loop/ apt-get --assume-yes install ${INSTALL PACKAGES}
chroot ${MACHINES ROOT}/${THIS MACHINE}/loop/ apt-get clean >> ${LOG} 2>&1
# Konfiguration der installierten Pakete
echo ""
echo -n "Konfiguriere installierte Pakete "
# Apache2 aktivieren
sed -ie ’s/NO START=1/NO START=0/’ ${MACHINES ROOT}/${THIS MACHINE}/loop/etc/default/apache2
# Root-Passwort setzen (wartet auf Benutzer-Eingabe)
echo "Bitte geben Sie ein Root Passwort fuer die neue Maschine ein:"
chroot ${MACHINES ROOT}/${THIS MACHINE}/loop/ passwd root
# Image unmounten
umount ${MACHINES ROOT}/${THIS MACHINE}/loop/proc/ >> ${LOG}
umount ${MACHINES ROOT}/${THIS MACHINE}/loop/var/ >> ${LOG} 2>&1 \
|| umount -l ${MACHINES ROOT}/${THIS MACHINE}/loop/var/ >> ${LOG} 2>&1
umount ${MACHINES ROOT}/${THIS MACHINE}/loop/ >> ${LOG} 2>&1 \
|| umount -l ${MACHINES ROOT}/${THIS MACHINE}/loop/ >> ${LOG} 2>&1
# Xen-Konfiguration fuer virtuelle Maschine erzeugen
echo -n "Erzeuge Xen Konfigurationsdatei "
echo "# -*- mode: python; -*kernel = ’${KERNEL}’
memory = ${MEMSIZE}
name = ’${THIS MACHINE}’
nics=1
vif = [ ’mac=${MAC}, bridge=xenbr0’ ]
disk = [ ’file:${MACHINES ROOT}/${THIS MACHINE}/${THIS MACHINE}-root,hda1,w’,
’file:${MACHINES ROOT}/${THIS MACHINE}/${THIS MACHINE}-var,hda2,w’,
’file:${MACHINES ROOT}/${THIS MACHINE}/${THIS MACHINE}-swap,hda3,w’ ]
root = ’/dev/hda1 ro noapic’
on poweroff = ’destroy’
on reboot = ’restart’
on crash = ’restart"’ > /etc/xen/${THIS MACHINE}
if [ ${AUTOBOOT} = "j"]
then
ln -sf /etc/xen/${THIS MACHINE} /etc/xen/auto/${THIS MACHINE} 2>&1
fi
# Log-Datei im Verzeichnis der virtuellen Maschine speichern
echo -n "Log-Datei in ${MACHINES ROOT}/${THIS MACHINE}/${LOGFILE} speichern "
mv ${LOG} ${MACHINES ROOT}/${THIS MACHINE}/${LOGFILE}
# Anschliessende Nachricht an User
echo ""
echo "FERTIG."
echo ""
echo "Starten Sie die neue virtuelle Maschine mit"
echo "# xm create -c ${THIS MACHINE}"
echo ""
if [ ${AUTOBOOT} = "j"]
then
echo "Nach einem Reboot des Host Systems wird die virtuelle"
echo "Maschine automatisch mit gestartet."
echo ""
fi
Robin Schröder
15
18. November 2005
18. November 2005
7.2 Dokumentation für Administratoren
7.2.1 Installation der Xen-Kernel und Xen-Tools
Nach der Grund-Installation von Debian Sarge werden mit dem Befehl apt-get install folgende für Xen benötigte Pakete installiert:
make gcc libc6-dev libncurses5-dev zlib1g-dev python python-dev
python-twisted bridge-utils iproute libcurl3 libcurl3-dev bzip2
module-init-tools latex transfig tgif debootstrap lsb-base
nfs-kernel-server
Als Bootmanager sollte bei der Grundinstallation GRUB gewählt werden, da
diese Anleitung lediglich die Konfiguration von GRUB berücksichtigt. Wurde LILO
ausgewählt, dann ist es jetzt Zeit, ihn durch GRUB zu ersetzen und das System neu zu booten.
Im Anschluss an die Installation der Pakete werden die Xen-Quellen von der University of
Cambridge heruntergeladen. Sie sind in der aktuellen Version 3.0 (unstable) unter
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/
zu finden. Die für die Durchführung des Projekts benutzte Datei heißt xen-unstable-src.tgz
und stammt vom 27.10.2005. Das ist wichtig, da vom Unstable-Zweig jede Nacht eine neue
Version erzeugt wird und nicht garantiert werden kann, dass jede Version lauffähig ist. Leider
werden von den Entwicklern von Xen keine fertigen Debian-Pakete zur Verfügung gestellt. Die
eigene Erstellung von Debian-Paketen schlug aufgrund der umfangreichen Veränderungen am
Kernel-Tree fehl, so dass ich auf Debian-Pakete verzichten musste.
Nach dem Download und Speicherung des Archivs unter /opt/xen-src/ wird die Datei dort
entpackt. Es wird automatisch das Verzeichnis /opt/xen-src/xen-unstable erzeugt. Nach dem
Wechsel in das Verzeichnis wird dort make world ausgeführt. Der Befehl lädt zunächst die
Kernel-Quellen in der Version 2.6.12.6 von http://www.kernel.org/ herunter, patcht sie mit
den Xen-spezifischen Erweiterungen (d.h. es wird eine Architektur namens xen hinzugefügt)
und kompiliert sie anschließend. Im Anschluss daran kompiliert der Befehl die Xen Userspace
Tools (xm, xend etc.). Xen-Kernel und Xen-Tools muss man anschließend mit make install
installieren.
Die installierten Kernel sind jedoch Standard-Kernel, die zwar umfangreiche Hardware Unterstützung enthalten, jedoch nicht speziell an unsere Gegebenheiten angepasst sind. Deshalb
ist es nach erfolgreicher Installation erforderlich, angepasste Kernel zu erstellen. Dies geschieht
für den Host-Kernel (Dom0 -Kernel) im Verzeichnis linux-2.6.12-xen0/, für den VM-Kernel
(DomU -Kernel) im Verzeichnis linux-2.6.12-xenU/. Dort muss jeweils
make ARCH=xen menuconfig
aufgerufen und die entsprechende Konfiguration erzeugt werden.
Es ist darauf zu achten, dass beim Aufruf von make IMMER mit ARCH=xen die
Xen-Architektur angegeben wird, da der Kernel ansonsten für die Architektur des
Host-Systems konfiguriert bzw. kompiliert würde!
Nach der Konfiguration der Kernel werden diese im Verzeichnis /opt/xen-src/xen-unstable
mit dem Befehl make kernels && make install-kernels erneut kompiliert und installiert.
Danach wird die Datei /boot/grub/menu.lst angepasst, indem folgende Zeilen vor die automatisch erzeugten Zeilen geschrieben werden (ca. in Zeile 43):
Robin Schröder
16
18. November 2005
title Xen 3.0 / XenLinux 2.6
kernel /boot/xen-3.0.gz dom0 mem=196608 console=vga
module /boot/vmlinuz-2.6-xen0 root=/dev/sda1 ro console=tty0 max loop=64 noacpi
Die Zeilen legen einen neuen Starteintrag für den GRUB Bootmanager an. Der Parameter
dom0 mem=196608 für den Xen-Kernel legt fest, dass 192 MB Arbeitsspeicher für die Domain 0
zur Verfügung stehen. Der Parameter max loop=64 für den Kernel der Domain 0 legt fest, dass
64 Loop-Devices (/dev/loop0 - /dev/loop63) zur Verfügung stehen. Für den Dom0 -Kernel ist
der Parameter noacpi erforderlich, da er ansonsten wegen einer fehlerhaften Implementation
des Advanced Configuration and Power Interface (ACPI ) nicht bootet.
Nun müssen noch 56 der 64 Loop-Devices angelegt werden, da standardmäßig nur 8 zur
Verfügung stehen (/dev/loop0 - /dev/loop7). Dies geschieht mit folgender kleiner Schleife, die
die Loop-Devices 8-63 mit entsprechenden Berechtigungen anlegt und der Gruppe disk zuweist:
for i in ‘seq 8 63‘
do
mknod -m 0660 /dev/loop${i} b 7 ${i}
chgrp disk /dev/loop${i}
done
Vor einem ersten Reboot mit dem neuen Kernel müssen noch ein paar weitere Modifikationen
am System vorgenommen werden. Dies geschieht mit folgenden Befehlen:
update-rc.d xend start 98 2 3 4 5 . stop 02 0 1 6 .
update-rc.d xendomains start 99 2 3 4 5 . stop 01 0 1 6 .
mkdir /var/lock/subsys
Hier werden die beiden Startskripte für Xen und dessen VMs in den Bootvorgang eingebunden
sowie ein Verzeichnis angelegt, was von den Xen-Startskripten benötigt wird.
Nach Durchführung der Modifikationen kann der neue Kernel gebootet werden. Nach einem
Reboot sollte der GRUB Bootmanager als ersten Eintrag
Xen 3.0 / XenLinux 2.6
anzeigen. Dieser Eintrag muss zum booten ausgewählt werden, damit der Xen-Kernel bootet
und den Dom0 -Kernel nachlädt. Das System sollte dann ordnungsgemäß booten.
7.2.2 Erzeugen virtueller Maschinen
Das Erzeugen einer VM ist ein immer wiederkehrender Vorgang, den ich in einem einfachen
Skript zusammengefasst habe. Es befindet sich in /opt/xen-tools/create xm. Ein Aufruf des
Skripts erstellt eine neue VM mit Standard-Konfiguration des Netzwerk-Interfaces über DHCP.
Folgende Schritte führt das Skript durch:
Das Erzeugen einer VM beginnt mit der Abfrage des Hostnamens und der MAC-Adresse der
zu erzeugenden Maschine. Bei der Vergabe der MAC-Adressen ist darauf zu achten, dass der
herstellerspezifische Teil immer "aa:00:00" ist. Weiterhin wird ein zu mountendes NFS-Share
und dessen Mountpoint abgefragt. Es folgt die Abfrage, ob die VM beim Booten des HostSystems automatisch mit gebootet werden soll, oder ob dies nur manuell geschehen soll.
Seine eigentliche Arbeit beginnt das Skript mit dem Erzeugen eines Unterverzeichnisses für die
neue VM in /opt/xen-machines, das den Namen der neuen VM trägt, z.B. debian (für unseren
Robin Schröder
17
18. November 2005
lokalen Debian Mirror). In diesem Verzeichnis werden nun die Dateien debian-root (512 MB
groß) und debian-var (512 MB groß) für das Dateisystem sowie debian-swap (128 MB groß)
als SWAP Speicher und das Verzeichnis loop/ zum mounten des Dateisystems erzeugt. In den
Dateien debian-root und debian-var wird anschließend ein EXT3 -Dateisystem erzeugt, in der
Datei debian-swap ein SWAP-Dateisystem.
Nach dem Mounten der Dateien debian-root nach loop/ und debian-var nach loop/var/
(Verzeichnis wird vorher angelegt) wird mit Hilfe des Programms debootstrap unter loop/ ein
neues Debian-Sarge-System erzeugt, d.h. es werden die nötigen Debian-Pakete herunter geladen
und unterhalb von loop/ installiert.
7.2.3 Grundkonfiguration virtueller Maschinen
Da debootstrap das neu erzeugte System nur installiert, aber nicht konfiguriert, sind noch ein
paar weitere Schritte nötig, um ein lauffähiges System zu bekommen.
Zunächst wird die Datei loop/etc/fstab angepasst und der Hostname in loop/etc/hostname
gesetzt. In die Datei loop/etc/hosts wird eine Zeile für localhost“ eingefügt. Es muss nun
”
noch ein root Passwort für die neue VM gesetzt werden. Damit sind alle wesentlichen Konfigurationsschritte getan, so dass nach dem Unmounten von loop/ die Maschine prinzipiell
ordnungsgemäß gebootet werden kann. Sie hat jedoch noch keine Xen-Konfigurationsdatei und
keinen konfigurierten Webserver. Die Xen-Konfigurationsdatei wird unter /etc/xen (auf dem
Host System) erzeugt und heißt wie die VM. In ihr werden Kernel, Parameter und das NetzwerkInterface definiert. Die Konfiguration des Webservers Apache2 wird vom Script nur partiell erledigt, da dies für jede VM individuell geschehen muss. Einzig das DocumentRoot wird in einer
Standard-Konfiguration festgelegt und ist immer /var/www.
Weiterhin erledigt das Script bei Bedarf das Mounten eines NFS-Shares in die VM. Dazu werden
am Anfang des Scripts vor der Durchführung aller Aufgaben entsprechende Fragen gestellt.
Nach dem Erzeugen einer VM mit Hilfe des Scripts befindet sich eine Logdatei namens
create xm.$$.log im Verzeichnis der VM. $$ ist ein Zufallswert. Sie enthält ein Protokoll
der Installation.
Konfiguration der VMs nach dem ersten Booten
Nach erfolgreichem Bootvorgang einer VM muss in ihr die Apache2 -Konfiguration erzeugt werden. Es wird lediglich eine Standardkonfiguration automatisch per Skript erzeugt, da alles Weitere zu individuell ist. Sie befindet sich in
/etc/apache2/sites-available/default
und ist den Gegebenheiten anzupassen. Im Fall dieses Projekts heißt das, dass die alte Konfigurationsdatei des Apache2 VirtualHost, der jetzt in der VM laufen soll, in die VM an o.g.
Stelle kopiert wurde, so dass die Standardkonfiguration überschrieben wurde. Es wurden dann
am Anfang der Datei die Zeilen
NameVirtualHost *
<VirtualHost *>
ServerAdmin webmaster@[Web-Adresse]
eingefügt bzw. sinngemäß angepasst. [Web-Adresse] ist z.B. physik.ruhr-uni-bochum.de.
Da ich beim Erzeugen der VMs mit Hilfe meines Scripts bei den Angaben zum NFS-Share darauf geachtet habe, dass das Verzeichnis in der VM immer nach /httpdata/[altes Verzeichnis]
Robin Schröder
18
18. November 2005
gemountet wird, sind in der Apache2-Konfiguration keine weiteren Anpassungen nötig. Lediglich
in den Webseiten selbst sind bei Bedarf die Angaben zum MySQL-Server von localhost“ auf
”
mysql“ zu ändern, da nicht jede VM einen eigenen MySQL-Server bekommt.
”
Damit der Apache2 ordnungsgemäß startet, muss noch das in den Zeilen ErrorLog und
CustomLog angegebene Log-Verzeichnis erstellt werden. Dies geschieht ganz normal mit dem
Befehl mkdir -p [Log-Verzeichnis]. Der Befehl
/etc/init.d/apache2 restart
startet den Apache2 -Server neu. Ab jetzt sollte er korrekte Daten liefern.
7.2.4 Bedienung von Xen mit dem Befehl xm
Der zentrale Befehl zur Bedienung von Xen ist xm. Die Eingabe von xm help (Abbildung 7.1)
gibt eine Übersicht über verfügbare Kommandos aus.
Mit xm help [Kommando] ist eine detailliertere Hilfe des jeweiligen xm Kommandos abrufbar.
Eine Liste der momentan aktiven VMs, im Xen-Jargon Domains genannt, erhält man mit dem
Befehl xm list (Abbildung 7.2), wobei immer auch Domain 0, das Host-System, auftaucht. In
Abbildung 7.2 ist zu sehen, dass nur die VM debian läuft.
Abbildung 7.1: Übersicht über verfügbare Kommandos
In den meisten Fällen werden die Befehle xm create [domain] zum Starten einer ungestarteten VM, xm reboot [domain] zum neustarten einer VM, xm shutdown [domain] zum Herunterfahren und xm destroy [domain] zum Zerstören“, also zum harten“ Abschalten einer
”
”
VM ohne sie herunterzufahren, verwendet. Dem Befehl xm create [domain] kann zusätzlich
der Parameter -c übergeben werden (also xm create -c [domain]), um direkt in eine Konsole
der bootenden VM verbunden zu werden.
Robin Schröder
19
18. November 2005
Abbildung 7.2: Liste momentan aktiver Domains
Der Befehl xm console [domain] startet eine Verbindung zur Konsole der VM. Man befindet
sich danach auf der VM, nicht mehr auf dem Host-System. Um aus der VM wieder heraus auf
das Host-System zu kommen, drückt man die Tastenkombination Strg+] bzw. Strg+AltGr+9
oder Strg+5. Eventuell ist es notwendig, diese Tastenkombination mehrfach zu drücken. Ist man
unter Windows mit dem SSH-Client PuTTY 1 zum Host-System verbunden, so funktioniert nur
Strg+5.
Neu in Xen 3.0 ist der Befehl xm top (Abbildung 7.4), der, ähnlich wie das Unix-Programm
top, Daten über die VMs zeigt. Er ist nicht so umfangreich wie sein Unix-Vorbild, zeigt aber
dennoch übersichliche und aktuelle Informationen:
Abbildung 7.3: Xen-Kernel Messages (auszugsweise)
Als nützlicher Befehl erweist sich auch oft xm dmesg (Abbildung 7.3), der wie dmesg Kernel Messages ausgibt. Allerdings nicht wie dmesg vom Kernel des Host-Systems, sondern vom
Xen-Kernel. Die Ausgabe sieht auf der für dieses Projekt verwendeten Produktiv-Maschine folgendermaßen aus:
Weitergehende Informationen zur Bedienung von Xen findet man auf der Xen-Website2 . Dort
1
2
http://www.putty.nl/
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html
Robin Schröder
20
18. November 2005
Abbildung 7.4: Übersicht mit xm top
sind umfangreiche Informationen und FAQs zu finden. Im nachfolgenden Kapitel gehe ich auch
noch kurz auf die wichtigsten Fragen ein, die in der Produktionsphase des Projekts aufkommen
könnten.
7.2.5 Antworten auf verschiedene Fragen
Welche Dateien müssen für eine VM gesichert werden?
Eine VM besteht aus den drei großen Dateien in ihrem Verzeichnis unter /opt/xen-machines/
sowie aus der Datei mit dem Namen der Maschine unter /etc/xen/ und gegebenenfalls einem
Link unter /etc/xen/auto/. Diese Dateien sollten gesichert werden.
Was muss sonst noch gesichert werden?
Alle Daten befinden sich unter /export/httpdata/. Eine Ausnahme bildet der Debian Mirror.
Er befindet sich unter /export/mirror/. Teile davon (der amd64 -Tree) befinden sich noch
unter /export/httpdata/mirror/. Dieses Verzeichnis sowie /export/mirror/ können von der
Datensicherung ausgenommen werden, da der Debian Mirror bei Bedarf vollständig vom Master
Server bei Debian zu rekonstruieren ist. Alles Weitere unter /export/httpdata/ sollte gesichert
werden.
Wann wird eine VM beim Booten des Host-Systems automatisch gebootet, wann nicht?
Existiert unter /etc/xen/auto/ ein Link auf die Maschinen-Definitionsdatei unter /etc/xen/,
so wird die VM beim Booten des Host-Systems automatisch mit gebootet. Existiert der Link
nicht, so muss die VM manuell mit xm create [domain] gebootet werden.
Vor dem Herunterfahren des Host-Systems werden immer automatisch alle VMs heruntergefahren, unabhängig davon, ob sie nach dem Booten des Host-Systems auch automatisch gebootet werden. Das automatische Booten und herunterfahren der VMs wird von dem Skript
/etc/init.d/xendomains erledigt.
Robin Schröder
21

Absicherung von Apache Webservern durch virtuelle Maschinen

Transcription

Documents pareils

Prospekt - Teil 2

Lackiermaschine Roller Coating Machine

Cornelius Loop OTK 6 Hähne Wasserfilterstation inkl. Wasserfilter

Audi A6 Avant 3.0 TDI quattro S tronic NAVI, XEN

Neue Sachbücher

Schneidemaschine Cutting Machine Machine à couper

rollformer für siding paneele rollforming machine for siding panels