Ubuntu: Alte Kernel-Pakete löschen

Bei Ubuntu (und vermutlich auch bei anderen Linux-Distributionen) verbleiben nach einem apt-get update && apt-get upgrade die alten Kernel-Pakete in /usr/src/. Da diese Pakete aus unzähligen Ordnern und kleinen Dateien bestehen, kann es bei einer kleineres Festplatte (ich hab dem System hier in der VM nur 8GB zugewiesen) schnell dazu kommen, dass keine weiteren Dateien mehr auf der Festplatte gespeichert werden können, da die zur Verfügung stehenden Inodes erschöpft sind. Wenn man also mit df -h noch erkennt, dass eigentlich noch genug Festplattenplatz zur Verfügung stehen sollte, aber man trotzdem bspw. bei der Installation von Aktualisierungen die Fehlermeldung erhält, dass kein Festplattenplatz mehr da wäre, dann kann df -i Aufschluss darüber geben, ob auch noch genügend Inodes zur Verfügung stehen. Steht hier bei IUse 100%, hat man zu viele Dateien und Ordner auf der Festplatte.

Weiterlesen

Kerio Connect und fail2ban

Wer einen Mailserver betreibt, kennt das Problem, dass man neben den normalen E-Mails auch irgendwann höhere Mengen an Spam erhält. Bei dem von mir verwalteten Webserver mit Kerio Connect sind es so ungefähr 98% aller SMTP-Anfragen, die mit Spam zu tun haben.

Natürlich bietet Kerio Connect hier schon eine Auswahl an Antispam-Mechanismen an. So greift ein Spamassassin ein sowie verschiedene individuell zu gestaltende Spamfilter und Blacklist-Abfragen. Diese Möglichkeiten sollte man auf jeden Fall auch nutzen.

Das ändert aber nichts daran, dass der Mailserver immer wieder die gleichen Anfragen von den denselben Spam-Servern annehmen und verarbeiten muss. Hinzu kommen noch Script-Kiddies, die irgendwann auf den Webmailer aufmerksam werden und dort mit Exploit-Scripts versuchen, irgendwie Zugriff zu erlangen.

An dieser Stelle kommt dann das Tool fail2ban ins Spiel. Jedenfalls wenn man den Kerio Connect Server nicht unter Windows, sondern unter einem Linux laufen lässt.

Weiterlesen

Die Leistung eines Systemadministrators

Heute ist, wie jeden letzten Freitag im Juli, der Tag des Systemadministrators. Und obwohl es diesen speziellen Feiertag für meine Berufsgruppe schon seit 14 Jahren gibt, wissen es immer noch nur wenige Leute. Dieser Tag ist dazu gedacht, seinem/n Systemadministrator/en Danke zu sagen für alles, was er geleistet hat.

Manchen Leuten hingegen kommt gar nicht in den Sinn, dem Admin den Dank auszusprechen. Einige sind sogar der Meinung, dass eher der Admin dankbar dafür sein sollte, dass er überhaupt einen Arbeitslohn erhält, da seine Leistung ja überhaupt nicht im Verhältnis zu seinem Lohn stehe.

Ich sehe das anders. Natürlich, ich bin ja auch Admin. Ich finde, wir Admins bekommen – zumindest teilweise – zu wenig für die Leistung bezahlt. Es mag Admins geben, die sich jeden Monat nen neuen Porsche kaufen können, aber das ist die Ausnahme. Und ja, es gibt auch Admins, die eher unfähig sind und somit auch mit dem Durchschnittsgehalt deutlich überbezahlt sind. Aber auch das ist eher die Ausnahme.

Doch wie berechnet man eigentlich die Leistung eines Admins? (Ich gehe mal vom „klassischen“ Mix aus Admin und Helpdesk aus, wie es in kleinen und mittelständischen Unternehmen am ehesten anzutreffen ist.) Schließlich ist so einer doch nur ne Kostenstelle. Er beschafft neue Hardware und neue Software und erklärt den Kollegen, wie sie bunt statt schwarz-weiß drucken können. Und ansonsten verbieten sie einem ständig nur die Nutzung von irgendwelchen Programmen und Pornoseiten oder sind nur am Meckern, wenn man mal eigenmächtig was „optimiert“ hat. Sie produzieren nichts, sie bringen keinen Gewinn ein, sie kosten einfach nur und sitzen in ihrem Kämmerlein und drehen Däumchen.

Zumindest habe ich das Gefühl, dass Admins oftmals so wahrgenommen werden.

Man bemerkt Admins nur, wenn mal was NICHT funktioniert. So ist das eben mit der selektiven Wahrnehmung. Während ein Arbeiter am Fließband daran gemessen werden kann, wie viele Kugelschreiber er zusammengeschraubt hat, während ein Vertriebler daran gemessen werden kann, wie viele Produkte er verkauft hat, während das Marketing daran gemessen werden kann, wie stark der Umsatz gestiegen ist (und dazu noch die ganzen hübschen Marketing-Medien wie Bilder, Videos, Präsentationen etc.), kann ein Admin offenbar nur danach gemessen werden, wie häufig es Probleme mit der IT gab. Dann heißt es gleich: was für ein unfähiger Admin, wofür bezahlen wir den denn? (Wie schon gesagt, auch solche gibt es, aber ich halte es eher für die Ausnahme.) Und wenn es gar keine Probleme gab, dann heißt es: der macht doch eh nix, wofür wird der eigentlich bezahlt?

Und da genau liegt doch der Hund begraben. Der Admin arbeitet „im Verborgenen“ und kümmert sich drum, dass der Arbeitsalltag weitgehend unproblematisch für die Angestellten abläuft. Das heißt: niemand bemerkt es, weil alles gut ist. Ich frage mich manchmal, wie sich ein Angestellter – oder auch eine Führungskraft – die Arbeit eines Admins vorstellt. Soll er den ganzen Tag durch die Büros wuseln und Kabel verlegen? Irgendwann sind doch alle Kabel verlegt – im besten Fall müssen doch gar keine neuen Kabel verlegt werden. Oder sollen Admins abwechselnd an einem Tag Kabel verlegen (so sinnlos sie auch sein mögen) und am nächsten Tag die Kabel wieder entfernen?

Besser ist doch, dass der Admin – in welcher Form auch immer – alle Systeme im Blick hat und bei Unregelmäßigkeiten sofort reagieren kann. Ich gebe zu, ich gucke mir auch Katzenbilder und unsinnige Sachen im Internet an. Es gibt am Tag mehrmals Momente, da hab ich nichts Besseres zu tun. Aber es gibt jeden Tag irgendwas zu machen – und sei es nur, den Spamfilter zu justieren, damit die Kollegen nicht merken, dass es überhaupt ein Spamproblem gibt.

An Beispielen mangelt es mir nicht. Ich kann hier zwar nur für mich selbst sprechen, denke aber, dass es bei anderen Admins in anderen Firmen ähnlich ist. Die Spamfilter hab ich ja schon erwähnt. Man guckt sich dabei die Log-Dateien an, was durch den Spamfilter gerutscht ist und definiert dann nach eigenem Gutdünken, wie man zukünftig solchen Spam vermeiden kann. Dabei kann man bspw. strikt nach Keywords filtern, muss aber auch im Hinterkopf haben, dass manche Keywords auch in legitimen Mails vorhanden sein können. So habe ich erst kürzlich den Fehler gemacht, dass ich das Wort „Qualitat“ gefiltert habe (irgendwelche dubiosen Finanzagenten sollten angeworben werden und da der Versender aus dem Ausland kommt, gibt es keine Umlaute). Das erschien mir sinnvoll. Allerdings habe ich dabei nicht bedacht, dass dieser Begriff auch im Wort „qualitativ“ vorkommt. Und schon wurde eine legitime Mail vom Spamfilter abgewiesen.

Ich muss Passwörter zurücksetzen, weil Mac- und Linux-Nutzer ihre Passwörter nicht selbst am Active Directory ändern können. Accounts müssen entsperrt werden, weil Nutzer ihr Passwort mehrfach falsch eingegeben haben (oder bei einem Passwortwechsel vergessen wurde, auch das WLAN-Passwort im Smartphone zu ändern). Neue Benutzer müssen eingerichtet werden, wenn neue Kollegen kommen. Und Accounts ausgeschiedener Mitarbeiter muss ich entsprechend deaktivieren. Software-Updates müssen verteilt werden, damit sich niemand über Sicherheitslücken irgendwelche Schadsoftware einfängt. Die AntiVirus-Lösung muss überwacht werden (und per Mail ankommende Viren, die noch nicht erkannt werden, eingesendet werden). Und wenn doch mal ein Virus seinen Weg auf einen Rechner geschafft hat, muss ich den betroffenen Rechner säubern. Die Firewall muss überwacht werden, um Angriffe zu erkennen, Schadsoftware im eigenen Netzwerk zu entdecken oder einfach nur Verbindungsprobleme zu analysieren. Im Allgemeinen muss die IT-Sicherheit gewährleistet werden. Dazu gehört, einschlägige Medien regelmäßig zu lesen (ich nehme hier Heise, Golem und Winfuture) und ggf. Gegenmaßnahmen zu ergreifen (wie beim Heartbleed-Problem Anfang April 2014). Ich muss die Drucker überwachen (kleinere Defekte und Papierstau beheben, Papier auffüllen, Toner und andere Verbrauchsmaterialien tauschen). Ich muss den Zustand der Server überwachen, wie die Prozessor- und Speicherauslastung ist, wie die Festplattenauslastung ist, ob wichtige Updates für Dienste bereit stehen. Wenn Bedarf besteht, muss ich neue PCs oder Macs bestellen und einrichten. Die Telefonanlage verwaltet sich nicht von selbst und auch Netzwerkdosen müssen gepatcht werden, wenn eine (wieder) in Betrieb genommen wird. Zu meinen Aufgaben gehört außerdem das Planen der Arbeitsplatzverteilung, wenn neue Mitarbeiter kommen oder sich neue Teams bilden. Ich muss neue Dienste, die den Kollegen Erleichterung bei ihrer täglichen Arbeit bringen, evaluieren und installieren. Ich muss das Backup im Auge haben und prüfen, wer eine wichtige Datei gelöscht oder zumindest verändert hat. Die Konferenzräume müssen regelmäßig geprüft werden, ob alle Kabel, Adapter und Geräte vorhanden und einsatzbereit sind. Mitarbeiter müssen ständig und wiederholt auf Gefahren hingewiesen werden (es kommt leider hin und wieder mal vor, dass eine Rechnung.pdf.exe ausgeführt wird) oder darin ermuntert werden, bei Problemen erstmal einen Neustart durchzuführen.

Auch sonstige Probleme und Wehwehchen im Büroalltag sind (unfreiwillig) zu meinen Aufgaben geworden. Ist der Geschirrspüler kaputt oder muss eine Glühbirne gewechselt werden, bin ich der erste Ansprechpartner, weil das ja mit nem Schalter bedient wird. Manche glauben sogar, dass ich neues Klopapier auf die Toiletten bringen muss.

Ich könnte vermutlich ein dickes Buch darüber schreiben, was ein Admin alles zu tun hat. Und manchmal wird ein Admin auch für Arbeiten eingespannt, die normalerweise nicht in seine Stellenbeschreibung passen. Ja, man könnte sich weigern, solche Aufgaben durchzuführen, weil die Stellenbeschreibung solche Hausmeisterarbeiten nicht umfasst. Aber wozu die Diskussion?

Anders herum fühlt man sich manchmal ein bisschen verarscht. So kommt es auch schon vor, dass jemand ohne Ahnung, aber mit Macht (Kunden, Geschäftsführer etc.), dem Admin irgendwelche Lösungen für Problemstellungen diktiert. Da kann man sich noch so mit Händen und Füßen gegen wehren, meistens bleibt einem nichts anderes übrig, als die „Lösung“ umzusetzen und zu demonstrieren, dass es nicht funktioniert. Ein „ich habs dir doch gesagt“ hilft da übrigens nicht. Letztendlich heißt es trotzdem, dass es die Unzulänglichkeit des Admins ist.

[Tech-Tipp] Windows Server 2012 Firewall und Linux Server LDAP-Abfrage

Ausgangssituation: In unserer Serverumgebung haben wir als Domain-Controller Windows Server 2012 im Einsatz. Einige Dienste (bspw. Confluence, Jira, Fisheye) laufen auf Linux-Servern und rufen die User-Credentials per LDAP-Anbindung von den Domain-Controllern ab. In den Log-Dateien der Linux-basierten Dienste haben wir regelmäßig Timeouts bzw. fehlgeschlagene LDAP-Verbindungen gefunden. Außerdem war es häufiger nötig, die Linux-Dienste neu zu starten, damit eine Benutzeranmeldung (wieder) möglich war.

Lösung: nach einiger Recherche bin ich darauf gestoßen, dass die Firewall der Windows Server seit Windows Server 2008 einen so genannten Stealth-Mode besitzt. Soweit ich das verstanden habe, werden dadurch Verbindungen von Clients zum Server kurz verzögert oder bei zu vielen Anfragen (automatisierte Anfragen) abgelehnt. Dieser Stealth-Mode kann nur über eine Änderung an der Registry ausgeschaltet werden. Weitere Infos: http://technet.microsoft.com/en-us/library/dd448557%28WS.10%29)

HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile

Hier einen neuen DWORD-Eintrag mit dem Namen „DisableStealthMode“ (Groß- und Kleinschreibung beachten) und dem Wert „1“ anlegen. Nach einem Neustart des Servers ist der Stealth-Mode für das Domänen-Profil der Firewall deaktiviert. Unter Umständen kann es notwendig sein, dass auch in den anderen Firewall-Profilen (falls angelegt und in Benutzung) dieser Eintrag gemacht werden muss.

Fazit: Seit der beschriebenen Änderung an den Domain-Controllern kommt es zu keinen Fehlermeldungen mehr und keiner der Linux-Server bzw. Linux-Dienste musste seitdem neugestartet werden.

Redundante Servervirtualisierung

Gekürzte und etwas veränderte Dokumentation eines Projekts der Firma Sylphen, welches ich durchgeführt habe. Achtung! Diese Informationen sind relativ alt und ich würde es heute auch nicht mehr so machen. Wer keine Angst vor Microsoft hat, sollte sich auf jeden Fall den kostenlosen Hyper-V Server 2012 anschauen.

Projektbeschreibung

Aus Platz-, Kosten- und Energieeffizienzgründen sollen die bestehenden physikalischen Server eines Unternehmens virtualisiert und auf einem einzigen physikalischen Server in virtuellen Maschinen installiert werden.

Weiterhin soll ein Backupserver zur Verfügung gestellt werden, der bei einem Ausfall des Hauptservers dessen Arbeit übernimmt, so dass ein unterbrechungsfreier Arbeitsfluss gewährleistet wird. Hier wird ein Distributed Replicated Block Device (DRBD) angestrebt, welches, ähnlich einem RAID1-System, für Redundanz im Serverbetrieb sorgt und somit eine optimale Lösung für einen Ausfallserver darstellt.

Lösungsansätze

In Betracht kamen zwei Lösungsansätze:

  1. Synchronisierung des Hauptservers mit dem Ausfallserver über rSync
  2. Einsatz eines DRBD

Aufgrund der großen Datenmengen würde rSync schnell an seine Grenzen geraten, insbesondere da virtuelle Maschinen teilweise sehr groß (10 GB und mehr) werden können. Würde nun während einer Synchronisierungsphase der Hauptserver ausfallen, wäre die virtuelle Maschine, die gerade synchronisiert wird, auf dem Ausfallserver ebenfalls defekt. Der entscheidende Vorteil von DRBD ist jedoch aufgrund der Ähnlichkeit zu einem RAID1, dass hier jedes geänderte Bit einzeln übertragen wird und bei Ausfall des Hauptservers das Backup nur wenige Sekunden alt ist und die Arbeit nach nur einer kurzen Unterbrechung direkt wieder an der Stelle aufgenommen werden kann, die zum Zeitpunkt des Ausfalls bestand.

Der Einsatz von DRBD ist somit die geeignetste Lösung.

Realisierung

Grundsystem

Als Grundsystem wird ein Debian 5.0 (Lenny) 64bit installiert, auf dem der VMware-Server installiert wird. Da das Betreiben eines VMware-Servers auf dem Host-System keine großen Ansprüche hat, reicht die Basisinstallation des Debian-Systems.

Dabei werden dem System eine statische IP sowie ein Hostname zugewiesen. Der Server erhält folgende Netzwerkkonfiguration für die erste Netzwerkkarte (eth0):

Hostname: hauptserver
IP: 192.168.0.11
Subnetzmaske: 255.255.255.0
Standardgateway: 192.168.0.254

Die Rolle des Standardgateways übernimmt hier der vorhandene DSL-Router.

Es wird zusätzlich zu root der Benutzer vmware eingerichtet.

Um zu gewährleisten, dass keine aktuell bekannten Probleme den Betrieb stören, wird ein Update des Debian-Systems mit apt-get update durchgeführt.

Der Backupserver erhält die gleiche Konfiguration wie der Hauptserver. Einzig die IP-Adresse und der Hostname werden anders gewählt:

Hostname: ausfallserver
IP: 192.168.0.12

DRBD

Auf beiden Systemen kann nun DRBD installiert werden. Dazu ist es notwendig, noch einige Pakete zu installieren:

apt-get install make gcc flex drbd8-utils drbd8-modules-2.6-686
apt-get install linux-headers-2.6.26-686 psmisc build-essential

Es wird zunächst in das Verzeichnis /usr/src gewechselt, um die Source-Dateien von DRBD herunter zu laden und zu entpacken:

wget http://oss.linbit.com/drbd/8.3/drbd-8.3.1.tar.gz
tar -xzf drbd-8.3.1.tar.gz

DRBD soll als Modul gestartet werden, also nicht direkt in den Kernel eingebunden werden. Deshalb wird folgender Befehl ausgeführt:

cd drbd-8.3.1
make clean all

Ist die Kompilierung zum Modul erfolgreich verlaufen, wird das Modul im System installiert:

make install

Beide Systeme erhalten nun auf der zweiten Netzwerkkarte IP-Adressen, um miteinander kommunizieren zu können. Die zweite Netzwerkarte ist insofern nützlich, als das der gewöhnliche Netzwerk-Verkehr durch das DRBD nicht eingeschränkt wird.

Das Hauptsystem, hauptserver, erhält die IP-Adresse 192.168.1.11 auf eth1 und der Backupserver, ausfallserver, erhält die IP-Adresse 192.168.1.12 auf eth1.

Wichtig ist es, in die Datei /etc/hosts beide Server mit ihren Adressen auf eth1 einzutragen, um später eine Namensauflösung zu ermöglichen:

192.168.1.11            hauptserver
192.168.1.12            ausfallserver

Die Systeme werden direkt miteinander verbunden, um den Umweg über einen Switch zu vermeiden, womit auch eine potentielle Problem- oder Fehlerquelle ausgeschlossen wird.

Nach der Installation des DRBD-Moduls und der Konfiguration der Netzwerkumgebung wird die Datei /etc/drbd.conf auf jedem Server angepasst.

global {
  usage-count no;
}

common {
  protocol C;
}

resource r0 {
  on hauptserver {
    device    /dev/drbd0;
    disk      /dev/sdb;
    address   192.168.1.11:7789;
    meta-disk internal;
  }
  on ausfallserver {
    device    /dev/drbd0;
    disk      /dev/sdb;
    address   192.168.1.12:7789;
    meta-disk internal;
  }
}

Um das DRBD zu initialisieren, wird der Befehl drbdadm up r0 ausgeführt. Dieser Befehl beinhaltet die einzelnen Befehle create-md, attach, syncer und connect. Mit create-md werden die Metadaten des DRBD erstellt. Der Befehl attach asoziiert das DRBD mit seinem Gegenpart, während syncer die die Synchronisierungsparameter setzt und connect schließlich die Verbindung zum Gegenpart herstellt.

Um zu prüfen, ob das DRBD erfolgreich initialisiert wurde, wird der Befehl cat /proc/drbd eingegeben. Das Ergebnis sieht ungefähr wie folgt aus:

version: 0.7.22 (api:79/proto:74)
SVN Revision: 2554 build by root@hauptserver, 2009-06-19 20:47:34
 0: cs:Connected st:Secondary/Secondary ld:Inconsistent
    ns:0 nr:0 dw:0 dr:0 al:0 bm:752 lo:0 pe:0 ua:0 ap:0

Um dem DRBD nun noch mitzuteilen, welches System das Primärsystem ist, wird folgender Befehl auf hauptserver eingegeben:

drbdadm -- --overwrite-data-of-peer primary r0

DRBD beginnt nun, sich zu synchronisieren, was einige Minuten in Anspruch nimmt. Das DRBD ist somit erschaffen.

Im Anschluss wird das DRBD mit einem Dateisystem zu versehen, damit es verwendet werden kann:

 mkfs.ext3 /dev/drbd0

Heartbeat

Damit ausfallserver im Notfall als Ausfallserver einspringen kann, ist es notwendig, zusätzlich ein Heartbeat-Service einzurichten. Andernfalls würde das DRBD nur ein nicht-lesbares Device auf ausfallserver zur Verfügung stellen.

Zunächst wird Heartbeat auf beiden Systemen installiert:

apt-get install heartbeat-2

Für die Konfiguration des Heartbeat-Services werden nun auf hauptserver die Konfigurationsdateien erstellt:

cd /etc/ha.d
cp -a /usr/share/doc/heartbeat-2/authkeys .
chmod 0600 authkeys
cp -a /usr/share/doc/heartbeat-2/ha.cf.gz .
gunzip ha.cf.gz
cp -a /usr/share/doc/heartbeat-2/haresources.gz .
gunzip haresources.gz

Die Datei ha.cf wird folgendermaßen angepasst:

logfacility     local0
ucast eth1 192.168.1.12
auto_failback on
node    hauptserver
node    ausfallserver

Die Datei  haresources wird mit folgenden Werten gespeichert:

hauptserver drbddisk::r0 \ Filesystem::/dev/drbd0::/data::ext3 \

Zum Abschluss der Grundkonfiguration wird in der Datei authkeys noch die Authentifizierungsmethode gewählt. Da es sich um eine vertrauenswürdige Umgebung handelt, wird die einfachste Methode „CRC“ gewählt:

auth 1
1 crc

Anschließend werden die Konfigurationsdateien, die auf beiden Servern, mit einer Ausnahme in der ha.cf, identisch sein müssen, nach ausfallserver übertragen:

scp ha.cf haresources authkey ausfallserver$PWD:

Auf ausfallserver wird in der ha.cf die IP-Adresse auf 192.168.1.11 geändert.

Initial wird der Heartbeat-Service mit folgendem Befehl auf beiden Systemen gestartet:

/etc/init.d/heartbeat

Unter /data ist nun der Speicherplatz vorhanden, der für die VMs genutzt werden soll.

VMware

Zur Installation des VMware-Servers sind weiterhin noch zusätzliche Pakete notwendig, die noch nachinstalliert werden müssen:

apt-get install psmisc build-essential

Vorbereitend zur Installation des VMware-Servers wird das Verzeichnis /data/VMs erstellt, in dem später die virtuellen Maschinen gespeichert werden sollen.

Der VMware-Server befindet sich bereits auf einer CD, die in das System gemounted wird. Das VMware-Server-Paket wird nach /tmp kopiert und dort entpackt.

cd /tmp
tar xvfz VMware-server-2.0.1-156745.x86_64.tar.gz

Nach dem Entpacken des Paketes wird der VMware-Server installiert.

cd VMware-server-2.0.1-156725.x86_64
./vmware-install.pl

Alle Abfragen, die das Installationsscript stellt, werden mit den Standardwerten beantwortet. Die Annahme der Lizenzvereinbarung wird mit der Eingabe „yes“ bestätigt. Bei der Abfrage nach dem Speicherort für die virtuellen Maschinen wird der Pfad /data/VMs angegeben.

Der Abschluss der Installation ist die Eingabe Seriennummer für den VMware-Server.

Nun können über die Weboberfläche des VMware-Servers (hier https://192.168.0.11:8333) die virtuellen Maschinen angelegt werden.

Fehlervermeidung und -behebung

Die  virtuellen Maschinen werden bei einem Ausfall des primären Servers automatisch auf dem Sekundärserver gestartet. Da vorher in der Regel kein Beenden der virtuellen Maschinen auf dem Primärsystem durchgeführt wurde, kann es dazu kommen, dass die Dateisysteme der virtuellen Maschinen inkonsistent werden. Nach Möglichkeit sollten deshalb so bald wie möglich die virtuellen Maschinen neu gestartet werden, um Inkonsistenzen durch Checkdisk zu beheben.

Sollte die Verbindung zwischen beiden Systemen unterbrochen werden, starten sich die virtuellen Maschinen auf dem Sekundärsystem automatisch, wodurch jeder virtuelle Server nun zweimal im Netzwerk vorhanden ist. In diesem Fall müssen die virtuellen Maschinen auf dem Sekundärsystem manuell wieder heruntergefahren werden. Abhilfe kann hier die Implementierung von STONITH (Shoot the other node in the head) schaffen.

Um weitere Probleme zu vermeiden, sollte man, wenn nötig, immer zuerst das Sekundärsystem herunter fahren und danach das Primärsystem. Bei der Startreihenfolge ist die umgekehrte Reihenfolge zu beachten. Zuerst sollte das Primärsystem gestartet werden, danach erst das Sekundärsystem.

Präsentation

Unter folgendem Link steht die Präsentation des Projektes im PowerPoint 2007 Format zur Verfügung: Präsentation Redundante Servervirtualisierung