Auf Client Seite ist unser Netzwerk bunt gemischt. Mit MacOSX, Linux und Windows sind alle nennenswerten Betriebsysteme vertreten. Nun möchten alle natürlich, dass der Router morgens anspringt sobald der eigene Rechner eine Internetverbindung benötigt. Dazu habe ich den Router so konfiguriert, dass er auf Wake-On-Lan Pakete reagiert.

Für MacOSX und Linux habe ich ein kleines Python Script gebastelt, dass ein MagicPaket sendet und so den Router aufweckt (der merkwürdig aussehende String in der letzten Zeile des Skriptes ist die Mac-Adresse des zu weckenden Rechners).

    #!/usr/bin/env python
    import socket
    s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    s.sendto('\xff'*6+'\x01\x40\x24\x2b\x12\xf7'*16, ('192.168.2.2', 80))

Unter Linux das Skript einfach per Autostart ausführen. Unter MacOSX könnte man das Skript einfach zu den Login-Items hinzufügen, um es bei jedem Anmelden auszuführen.

Allerdings habe ich unter MacOSX einen etwas anderen Usecase. Ich schalte den Rechner praktisch nie aus, sondern versetze ihn nur in den SleepModus. Deshalb muss ich das Skript immer dann ausführen, wenn der Rechner aus dem SleepModus wieder aufwacht. Dazu nutze ich das kleine Tool SleepWatcher. SleepWatcher kann Skripte beim Aufwachen und Schlafengehen von MacOSX ausführen.

Bleibt die Windows-Dose. Auch hier hat der Usecase eine kleine Besonderheit, denn das WOL-Paket muss über WLAN gesendet werden das erst einige Sekunden nach dem Login verfügbar ist. Außerdem muss der Windows-Rechner nach dem Starten des Routers dazu gebracht werden sich vom DHCP Server eine neue IP zu holen.

Zum Senden des MagicPackets habe ich das kleine Tool MC-WOL heruntergeladen. Dabei handelt es sich um ein Kommandozeilenprogramm, dass als Parameter einfach nur die MacAdresse des zu weckenden Rechners bekommt. Das ganze habe ich in eine Batch-Datei verpackt:

ping localhost -n 15 > NULL
c:\mc-wol.exe 01:40:24:2b:12:f7
ping localhost -n 60 > NULL
ipconfig /renew

Die beiden Ping Befehle sind ein kleiner Hack. Windows Batch Dateien kennen keinen “sleep”-Befehl. Ein Ping dauert jedoch genau eine Sekunde. Wenn man nun 15mal ins leere Pingt, hat man effektiv einen Sleep von 15 Sekunden. Die ersten 15s warten sind zum aktivieren der WLAN-Verbindung, dann sendet die Batch das MagicPaket, wartet wiederum 60s (bis der Router hochgefahren ist) und holt sich dannach eine neue IP.

Von dieser Batch Datei einfach noch eine Verknüpfung erstellen und in den Autostart Ordner verschieben. Der Verknüpfung kann man nun noch sagen, dass sie minimiert starten soll und den Benutzer so nicht stört (geht über die Eigenschaften der Verknüpfung).

Nachdem ich vor ein paar Tagen ein Update meiner Ubuntu-VM auf 10.04 gemacht hatte konnte ich mich nicht mehr einloggen. Das Problem: Im Login-Screen von GDM funktionierte keine Tastatur mehr. Maus kein Problem, aber ohne Tastatur kann man halt schlecht ein Passwort eingeben.

Das Problem ist ein falscher Eintrag in der Datei /etc/default/console-setup. Nach der Ubuntu 10.04 Installation findet man dort unter anderem folgende Einträge:

XKBMODEL=”SKIP”
XKBLAYOUT=”us”
XKBVARIANT=”U.S. English”
XKBOPTIONS=”"

Die Einträge müssen wie folgt angepasst werden damit die Tastatur unter VMWare(Fusion) wieder läuft:

XKBMODEL=”pc105″
XKBLAYOUT=”us”
XKBVARIANT=”"
XKBOPTIONS=”"

Bleibt die Frage – wie an die Datei herankommen wenn man sich nicht einloggen kann? Zu diesem Problem gibt es zwei Lösungen:

1. Möglichkeit: Beim Booten in Grub den Konsolen-Login auswählen – dort funktioniert die Tastatur einwandfrei.

2. Möglichkeit: Das on-screen Keyboard zum einloggen benutzen. Dazu klickt man im Login-Screen auf das Symbol für die “Universal Access Preferences” (im Standard 10.04 Theme das kleine Männchen mit dem Kreis drumherum) und aktiviert im Folgedialog die Option “Use on-screen keyboard”. Leider kann es nun durch einen anderen Bug passieren, dass das Keyboard zwar kurz zu sehen ist aber sofort wieder verschwindet. In diesem Fall die VM einfach einmal neubooten, dann sollte das Keyboard sichtbar sein.

Nach dem einloggen die oben genannte Datei ändern und neustarten – dann sollte alles wieder wie gewohnt funktionieren. Ich hatte übrigens noch einen weiteren Bug beim Booten. Bei mir erschien der LoginManager für 1-2 Sekunden, dannach wurde der Bildschirm aber wieder schwarz. Hier hilft es beim Booten einfach mal “F2″ zu drücken und damit die Bootkonsole zu aktivieren.

Nach ein bisschen Recherche im Web habe ich mich für das Paket VS Linux L 4.0 von HostEurope entschieden. Eine Alternative wäre noch der vServer Pro X4 von Server4You gewesen. Letzterer ist bei vergleichbarer Leistung deutlich billiger, allerdings verbinde ich mit Server4You nur negative Nachrichten aus deren Anfangszeiten. Mag sein, dass sie mittlerweile dazugelernt haben, das negative Bild hat sich bei mir aber zu sehr eingebrannt. Meine Domains werde ich weiter über den DomainRobot von Hetzner verwalten, da gibt es für mich keine Alternative.

Demnächst steht also ein Umzug aller Dienste und Daten an. Nun habe ich mir überlegt, wenn ich schon alles umziehen und neumachen muss, dann kann ich das auch richtig machen. Deshalb werde ich im gleichen Schritt auch von MySQL auf LDAP als Datenbackend umsteigen. Natürlich ist ein LDAP Server für einen so kleinen Server mit rund 10 Domains und 20 Email-Konten etwas oversized, aber es ist die sauberste Lösung und ausprobieren wollte ich das schon länger mal. Ich habe mir für den neuen Server folgende Struktur überlegt:

Postfix als MTA mit Amavis, Spamassassin und PolicyD als Content Filter – so bleibt das Email-Postfach sauber! Zum Senden/Relayen von Mails ist natürlich eine Authentifizierung erforderlich. Dazu wird Postfix über Cyrus-SASL an den LDAP angebunden. Darüberhinaus benutzt Postfix den LDAP um Domain/Mailbox Lookups zu machen (also sicherzustellen, dass die Emailadressen an die Mails gesendet werden sollen auch auf dem Server existieren).

Dovecot habe ich seit etwas mehr als einem Jahr im produktiven Einsatz und bin damit sehr zufrieden. Dovecot unterstützt eine direkte Anbindung an LDAP (zur Authentifizierung). Sowohl Postfix als auch Dovecot werden für MUAs nur per SSL/TLS erreichbar sein. Als Webmail Applikation bleibe ich bei RoundCube – ich find den Web2.0 Style von RoundCube einfach hübscher als SquirrelMail.

Auch den Apache möchte ich an das LDAP Backend anbinden. Sowohl zur Verwaltung von (Sub-)Domains als auch zur Authentifizierung beim SVN und WebDAV Dienst (ob das überhaupt möglich ist weiß ich aber noch nicht).

Zu guter letzt möchte ich meinen Router hier Zuhause als BackupMX konfigurieren. Falls der vServer einmal ausfällt soll unser heimische Router die Mails entgegennehmen. Dazu muss er natürlich auf die Domaindaten zugreifen können. Deshalb muss auf dem Router ein LDAP-Replica-Server laufen der alle Daten vorhält. Auch müssen hier alle Antispam und Antiviren Maßnahmen installiert sein, denn Spammer benutzen gerne den BackupMX um ihren Müll abzuladen. Inwieweit dies umsetzbar ist muss ich ebenfalls noch ausprobieren.

Ich stelle das ganze Vorhaben hier deshalb so ausführlich vor, weil ich mir vorgenommen habe zu allen Diensten und Konfigurationen hier im Blog Tutorials zu veröffentlichen. Falls ich diesem Vorsatz nachkommem kann ensteht hier nicht nur eine Dokumentation für mich selbst, sondern hoffentlich auch ein nützliches Nachschlagewerk für andere.

Zur Virtualisierung benutze ich das konstenlose Virtual Box. Um mein Gast-System als vollwertigen Server zu nutzen, muss ich das virtualisierte Ubuntu in mein Netzwerk einbinden. Das System soll eine eigene IP im Netzwerk haben und auch von anderen Rechnern aus ansprechbar sein, als wäre es ein zusätzlicher Rechner im Netzwerk. Seit Virtual Box 2.2 soll dies sehr einfach sein – zumindestens laut Dokumentation. Man muss in den Einstellungen der virtuellen Maschine unter dem Punkt Netzwerk lediglich ein paar Einstellungen ändern. Wichtig ist, dass man unter dem Punkt Angeschlossen an Netzwerkbrücke auswählt. Als Netzwerk-Schnittstelle muss man die Netzwerkkarte auswählen, die an das lokale Netzwerk angeschlossen ist. Was in der Dokumentation leider nicht erwähnt wird, ist, dass der Bridge Modus nicht mit jedem virtuellen Adaptertyp funktioniert.

Standardmäßig arbeitet die Virtual Box mit dem Adaptertyp PCnet-Fast III, der bei meinen Bemühungen aber nicht als Bridge arbeiten wollte. Ich habe mich dann für die Intel PRO/1000 T Server entschieden – damit lief der Bridge Modus auf Anhieb. Man muss dem Netzwerkadapter im Gast-System dann einfach eine IP aus dem lokalen Netzwerk zuweisen, den Rest übernimmt VirtualBox. Über die zugewiesene IP ist die virtuelle Ubuntu Maschine dann auch von anderen Rechnern im LAN aus ansprechbar. Der Zugriff aufs Internet aus dem Gastsystem heraus funktionierte bei mir auch auf Anhieb. Ich habe unter Ubuntu dazu einfach die IP meines Routers als Gateway und DNS Server eingetragen.

Erstmal ist wichtig nicht zu versuchen die Festplatte mit irgendwelchen Windows Tools wieder zu retten, denn wenn das schiefgeht sind die Daten vielleicht wirklich weg. Mein erster Schritt war also eine Ubuntu Live CD zu booten und die gesamte Festplatte mit dem Linux Tool dd auf eine externe USB Platte zu sichern:

dd if=/dev/sda of=/media/disk/sda.dd.img

Das dauert ein Weilchen, denn dd kopiert byte für byte genau wie die Daten auf der Festplatte stehen, alles in eine Datei. Dabei werden auch leere Bereich der Festplatte mitkopiert. Das heißt, dass eine 120GB Festplatte wie in meinem Fall – selbst wenn nur 10GB belegt sind – ein Image der Größe 120GB erzeugt.

Nachdem die Festplatte gesichert ist können wir das Problem etwas genauer analysieren. Mit sfdisk ersteinmal schauen, was von der Partitionstabelle noch übrig ist:

sfdisk -d /media/disk/sda.dd.img 
Warnung: erweiterte Partition beginnt nicht an einer Zylindergrenze
DOS und Linux werden den Inhalt unterschiedlich interpretieren.
\# Partitionstabelle von /media/disk/sda.dd.img
unit: sectors

/media/disk/sda.dd.img1 : start=229197824, size=  5240832, Id= c, bootable
/media/disk/sda.dd.img2 : start=   241664, size= 20971520, Id= 7
/media/disk/sda.dd.img3 : start= 21213184, size=207982592, Id= 7, bootable
/media/disk/sda.dd.img4 : start=229195776, size=  5242880, Id= f
/media/disk/sda.dd.img5 : start=229197824, size=  5240832, Id= 0

Sieht ja garnicht so schlecht aus. Ich weiß, dass die Platte drei Partitionen hatte (es handelt sich um ein DELL Notebook, zwei der drei Partitionen sind von DELL angelegt, eine der angezeigten 5 Partitionen ist wohl eine erweiterte). Die Daten-Partition ist die Wichtige um die es mir geht. Woran man die erkennt? Es sollte eine der größeren Partitionen sein. Jetzt sind ein paar Grundkenntnisse über Festplatten-Partionierung und Dateisysteme vorteilhaft. Nach der Ausgabe von sfdisk vermute ich, dass es sich bei img2 um eine erweiterte Partition handelt (also nur um den Container für eine logische Partition). img3 scheint mir die Daten-Partition zu sein nach der ich suche. Um diese Partition jetzt zu mounten, muss ich noch den richtigen Offset berechnen. sfdisk sagt mir, dass img3 bei “21213184″ startet. Dieser Wert muss jetzt aber noch mit 512 multipliziert werden (Bei (S)ATA Platten ist ein Sektor 512 Byte groß). Der mount-Befehl sieht dann so aus:

mount /media/disk/sda.dd.img /mnt/sda-3 -t ntfs-3g -o ro,loop,offset=10861150208

Bingo! Ich kann die Partition aus dem Image heraus lesen. Alle Daten scheinen da zu sein! Jetzt kann ich mich an die Reparatur der Festplatte wagen. Dazu werde ich TestDisk benutzen, aber alle anderen (auch Windows Tools) sind jetzt auch in Ordnung – zur Not hat man ja ein komplettes Image der Festplatte das man zurückspielen kann.