Unison vollautomatisiert per SSH ersetzt Windows Offline Files

“Eine Software, die von Millionen von Leuten eingesetzt wird, kann doch nicht schlecht sein”. Wie oft hab ich mir das gedacht und wie oft wurde ich eines besseren belehrt. Dass Microsoft-Software oft wirklich schlecht ist, und es perfekten Open-Source-Ersatz gibt, der fehlerfrei funktioniert, zeigt das Beispiel der Offline-Dateien.

Da ich meine Daten gerne zentral auf dem Server ablege (autom. taägliches Backup und remote-Zugriff), jedoch trotzdem gerne auf meinem mobilen Computer habe, habe ich anfangs die “Offline-Dateien” von Windows verwendet, um die benötigten Dateien auf dem Netzlaufwerk des Servers offline verfügbar zu machen. Anfangs ganz euphorisch wie toll das ist, kam immer mehr die Ernüchterung, dass das System in Wirklichkeit gar nicht funktioniert. Viele Fehler und Probleme mit der Synchronisation, Probleme beim Erkennen des “Offline-Zustandes”, Unfähigkeit gewisse Daten zu synchronisieren und am schlimmsten: Absolutes Chaos und Datenverlust (!) wenn ich zusätzlich auf das Laufwerk mit dem PDA synchronisiere.

Also hab ich mich am 07.10.2006 für den Ersatz “unison” entschieden. Wirklich, keine schöne Oberfläche, manueller Start, aber nach ein paar Monaten Tests kann ich sagen: Überzeugend. Unison ist extrem stabil und zuverlässig. Keine Datenverluste, keine inkonsistenten Dateien.

Da jedoch Unison anfangs nicht so arbeitete, wie ich will (über ssh automatisiert) und in google kaum was darüber zu finden war, benötigte es ein paar Hacks, die ich in diesem Artikel beschreibe, falls wer die Windows Offlinefiles ebenfalls satt hat und einen zuverlässigen Ersatz sucht...

Unison im Normaleinsatz geht einfach - z.B. per Netzlaufwerk. Aber wenn schon denn schon - dachte ich mir - muss das gleich per SSH gehen. Das hat viele Vorteile:

• Sichere Verschlüsselung
• Synchronisation von unterwegs - auch ohne VPN
• Unabhängig vom Windows-Netzwerk

Das bereitete aber viele Probleme, vor allem die Automatisierung. Zu den Problemen fand man leider wenig in google.

Vorbereitung

Lokal sollen keine Daten gespeichert werden, die nicht synchronisiert wurden. Mit den Windows Offlinedateien bin ich so vorgegangen:

• Freigabe des Homeverzeichnisses ~/daten durch Samba
• Einbindung dieser Freigabe auf u:\ durch das Domain Anmeldescript
• Alle “Offline”-Dateien liegen in u:\offline
• u:\offline wird offline verfügbar gemacht
• u:\offline wird zusätzlich per Netzlaufwerk auf o:\ verfügbar gemacht

Alle Dateien, die auf dem Server sind, liegen nun auf o:\.

Das soll auch mit der neuen Konstellation so sein. Aus diesem Grunde wird auf dem lokalen, “temp”-Laufwerk “D” ein Verzeichnis “d:\cache\o” erstellt. Dieses wird per subst auf o:\ gemappt. Dies regelt gleich die logon.cmd des Samba PDCs.:

if exist d:\cache\exist.dat subst o: d:\cache\o

Auf dem Server existiert nach wie vor das Verzeichnis /home/niki/daten/offline, in dem diese Daten zu liegen kommen. /home/niki/daten/offline auf dem Server soll nun mit d:\cache\o auf dem mobilen Rechner per Unison synchronisiert werden.

Einfache Methode

Die einfache Methode ist, wie bereits beschrieben, einfach über u:\ zu synchronisieren. Dazu reicht:

unison d:\cache\o u:\offline

Bessere Methode: ssh

Das gute dran: Kein “Server” auf dem Server nötig. Zuerst wird einmal ein public key erstellt, um sich ohne Passwort anmelden zu können. Das geschieht entweder mit putty-keygen unter Windows oder mit ssh-keygen unter Linux. Den privaten Schlüssel habe ich in das Benutzerprofile unter unison.ppk gelegt.

Nun braucht man noch plink.exe - ein SSH Client Programm für Windows aus der Putty-Suite. Unison hat leider nur rudimentäre SSH-Konfigurationsmöglichkeiten, weshalb ich einen Wrapper für plink geschrieben habe - d:\usr\bin\unison_ssh.cmd:

@echo off
plink -i "%USERPROFILE%\unison.ppk" -P 1984 -l niki www.nobaq.net

Wie man sieht, wird der Private-Key im Profilverzeichnis verwendet, den Port habe ich auch 1984 ersetzt (um Skriptattacken etwas zu minimieren), niki gibt den Loginnamen ein und www.nobaq.net ist der SSH-Server.

Gleiche unison-Version auf dem Server!!

Zuerst wollte ich mittels aptitude install das unison von Debian installieren. Doch bin ich draufgekommen, dass das nicht geht, wenn man unison im Servermode verwenden will! Die Versionsinformation muss ident sein! Deswegen hab ich das Original-Unison von der Homepage geladen und nach ~/bin/unison kopiert. Anpassung am Server

Für die Serverkonfiguration braucht nur mehr ein Eintrag in ~/.ssh/authorized_keys hinzugefügt werden. Das hat viele Vorteile:

• Verwendung des gleichen Accounts wie der normale
• Keine Speicherung des Plain-Passworts für plink
• Einschränkung der Rechte - Einzig erlaubte Operation mit dem Key: Ausführen von unison.

Die folgende Zeile kommt in ~/.ssh/authorized_keys:

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/home/niki/bin/unison -server -dumbtty" ssh-rsa

Das startet nun unison im Servermode, wenn eine SSH-Verbindung mit dem passenden Public-Key kommt. Die Optionen schränken die Rechte ein, sollte der private Schlüssel doch einmal in falsche Hände gelangen. “no-pty” ist wichtig, sonst funktioniert unison nicht richtig. Leider kommt dann auch eine Fehlermeldung, die aber kein weiteres Problem darstellt. command gibt schließlich das einzig erlaubte Kommando an - unison! “-server” gibt an, unison im Servermode zu starten und “-dumbtty” gibt an, dass es ein “dummes” Terminal ist - also keine Steuerungskeys etc unterstützt. ”

” bitte durch den öffentlichen Schlüssel ersetzen!

Feinheiten

Um das ganze per Knopfdruck starten zu können, hab ich das in eine Batch-Datei gestülpt. Damit nicht zusätzlich aus Versehen synchronisiert wird, falls das gar nicht der Fall sein soll, wird eine Datei ’sync.dat’ erwartet. Ist diese nicht vorhanden, wird die Synchronisation erst gar nicht gestartet:

@echo off
IF EXIST "d:\cache\o\sync.dat" (
unison -batch -rsync -log -logfile "d:\cache\unison_o.log" -auto -xferbycopying -contactquietly -fastcheck true -sshcmd unison_ssh.cmd d:\cache\o ssh://niki@www.nobaq.net//home/niki/daten/offline
) ELSE (
echo sync.dat not found! )
pause

Das Resultat

Unison “in action”. Wie man sieht, werden Dateien brav ignoriert, wenn darauf zugegriffen wird. z.B. Miranda oder Outlook. Ändern sich Dateien während der Synchronisation ist unison intelligent genug, das zu bemerken und den Transfer auszulassen. Zusätzlich wird das ganze in eine Logdatei protokolliert. Falls mir wirklich einmal ein Fehler auffallen sollte, kann ich das schön nachvollziehen. Und durch das serverseitige, tägliche Backup auch restlos wieder herstellen!

Kommentare

  1.
     Nightwolf sagt,
     am 26. Apr. 2007
     Vielen Dank für das HowTo, funktioniert hervorragend!