HBBTV = Hybrid Broadcast Broadband TV; das ist eine standardisierte Methode, auf dem Fernsehgerät weitere Online-Inhalte des gerade aktiven Senders anzuschauen, wie bspw. die Mediathek.

Toshiba hat Fernsehgeräte, mit denen man HBBTV nutzen kann. Nun haben wir vor kurzem ein solches Gerät, ein 32SL833G, in der Firma angeschafft und was funktionierte nicht? HBBTV! Nach einigen Recherchen wurde dann klar, dass die Firmware des Geräts noch keine entsprechende Unterstützung für HBBTV integriert hat (obwohl der Fernseher als HBBTV-Gerät beworben und verkauft wird). Eine aktuelle Firmware für das Gerät ist für Deutschland noch nicht verfügbar, jedoch für Frankreich und (vermutlich) Russland.

In einem Forum ging es um genau dieses Problem, allerdings mit einem anderen Toshiba-Gerät. Dort haben einzelne User verraten, dass man problemlos die Firmware für ein anderes Land nutzen kann. Das brachte mich auf die Idee, die russische Firmware für unser Gerät mit der französischen zu vergleichen. Der Downloadlink ist derselbe, enstprechend wird in beiden Fällen dieselbe Datei herunter geladen. Somit war ich mir auch relativ sicher, dass die Firmware auch für deutsche Geräte einsetzbar ist.

Die Firmware ließ sich jedenfalls problemlos installieren, HBBTV läuft super (vorher in den Präferenzen Hybrid-TV aktivieren) und auch sonst scheint alles in Ordnung. Wer also nicht auf die Freigabe von Toshiba warten möchte (vielleicht haben die es auch eifnach nur vergessen), der kann sich die Firmware für ein anderes Land (aber natürlich für das gleiche Gerät!) auf dem Fernseher installieren.

Nachdem ich nun die verschiedensten Einstellungen ausprobiert habe – ich habe den Webschutz deaktiviert, ich habe das Chrome-Verzeichnis in die Ausnahmen übernommen, die Firewall deaktiviert… also, nachdem ich nun viel rumprobiert habe, fiel mir ein kleines Häkchen in den Einstellungen beim Wächter auf, welches beim Punkt “Verhaltensüberwachung” gesetzt ist. Nimmt man das Häkchen dort raus, deaktiviert also die Verhaltensüberwachung, läuft Google Chrome wieder ohne zu zucken. Kleines Häkchen, große Wirkung!+

[Update 22.07.2011]
Weil mir diese Sache keine Ruhe ließ, habe ich mich vor einiger Zeit deswegen an GDATA gewendet. Mit dem Support habe ich etliche Szenarien und Einstellungen durchprobiert und letztendlich auch mit einem Debugger aufgezeichnet, was so passiert, wenn die Verhaltensüberwachung aktiv ist und Google Chrome gestartet wird. Gestern Abend bekam ich dann einen Hotfix von GDATA zugeschickt, den ich ausprobieren sollte. Offenbar ist das Problem nun behoben, denn es ließ sich nicht mehr reproduzieren.

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

In der Dokumentation erkläre ich, wie man ein redundantes System erschafft, auf dem virtuelle Maschinen beinahe ausfallsicher zum Einsatz kommen.

Stichworte: Debian, DRBD, Heartbeat, VMware-Server

Update 19.06.2009: Der angekündigte Artikel ist heute in meinem Blog erschienen.

Ein Tipp von meinem Arbeitskollegen: die Computerverwaltung (%SystemRoot%\system32\compmgmt.msc) als Admin ausführen und unter System -> Freigegebene Ordner -> Freigaben über die Funktion “Freigabe hinzufügen” nun die Rechte des Ordners mühelos verändern.

In der Datei winlogon.exe (sie befindet sich unter C:\Windows\System32) wird fälschlicherweise ein Trojaner vermutet: “Trojan.Generic.1423603″. Wer die Datei gelöscht hat, muss sie manuell über die Wiederherstellungskonsole zurück kopieren. Auf der Festplatte sollte eine Kopie der winlogon.exe im Ordner C:\Windows\ServicePackFiles\i386 liegen. Ist dieser Ordner nicht vorhanden, muss die Datei von der Windows-CD zurück auf die Festplatte kopiert werden. Dabei ist aber zu beachten, dass es sich um eine Windows-CD handelt, die dasselbe ServicePack enthält, wie die aktuelle Windows-Installation. Die Dateibefindet sich im Ordner i386 auf der CD. Mit dem Befehl expand winlogon.ex_ C:\Windows\System32, den man von dort ausführt, wird die Datei wiederhergestellt.

Neben GDATA AntiVirus war auch BitDefender von dem Problem betroffen. Inzwischen sind fehlerfreie Signaturen veröffentlicht worden.

Merke: Wenn Dein Virenscanner einen Virus findet, prüfe IMMER nach, welche Datei betroffen ist. Gegebenenfalls sollte die verdächtige Datei zusätzlich online bei einem Virenscanner-Dienst wie Jotti geprüft werden.

Nach einem Rechtsklick auf die Taskleiste wählt man den Punkt “Eigenschaften”. In dem sich nun öffnenden Dialogfenster wählt man den Reiter “Startmenü” und klickt auf den Button “Anpassen”. Ganz oben aktiviert man, wie in der nachstehenden Grafik angezeigt wird, den Punkt “Ausführen” (Häkchen setzen) und bestätigt am Ende alles mit “Ok”.

Diese “Malware” von Apple lässt sich aber relativ einfach und schnell wie folgt deinstallieren:

Start -> Ausführen (unter Vista muss dieser Befehlsschalter ggf. noch aktiviert werden) und folgendes eingeben:

“C:\Program Files\Bonjour\mDNSResponder.exe” -remove

(Der Pfad muss ggf. angepasst werden. Bei Windows-XP ist es auf einem deutschen System C:\Programme\…)

Abhilfe schafft hier, im Profilverzeichnis von Firefox die Datei signons3.txt zu löschen (dass man ein Backup vorher macht, sollte ich wohl kaum erwähnen). In Windows XP findet man die Datei für gewöhnlich unter C:\Dokumente und Einstellungen\[Benutzerprofil]\Anwendungsdaten\Mozilla\Firefox\Profile\[irgendwas].default\ und in Windows Vista befindet sich die Datei unter C:\Benutzer\[Benutzerprofil]\AppData\Remote\Mozilla\Firefox\Profiles\[irgendwas].default\

Wenn man den Firefox jetzt wieder startet, sind alle Passwörter wieder da.

[Update]

Alles Passwörter wieder da? Nicht ganz! Ich musste feststellen, dass es nur die Passwörter waren, die ich bis zu einem bestimmten Zeitpunkt, ich schätze mal bis zum Update von Firefox 2 auf Firefox 3, gespeichert hatte.

Kommende Woche soll Version 3.0.3 von Firefox erscheinen, worin das Problem mit dem Passwort-Manager gelöst ist. Das Backup der signons3.txt kann dann wieder die von Firefox neu angelegte signons3.txt ersetzen.